In Intel IMUL opcode described in one method using different descriptions:

• 6B / r ib IMUL r32, imm8 doubleword register = doubleword register * sign-extended immediate byte
• imul Gv, Ev, I
• OPC_IMUL_GvEvIb
• imul eax, [ecx+0x41], 0x10
• 6b414110 imul eax,DWORD PTR [ecx+0x41],0x10

When encountering an IMUL opcode of i386 architecture, specifically when using with an immediate 8-bit multiplier, the emulator engine does not properly multiply the number 0x5151494a by 0x10 and get the expected 0x151494a0 result.

Interesting thing, is that a standalone IMUL instruction works, but this stack-based AlphaMixed code snippet (derived from Metasploit) failed.

Will submit working proof-of-failure code soon.

I've been battling with running the python bindings on python 3.5.

I keep getting a ImportError: ERROR: fail to load the dynamic library. however I have checked that all libraries are present in .\unicorn\lib

    Directory: C:\Python\Lib\site-packages\unicorn\lib


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2016/09/24   7:23 PM         122036 libgcc_s_dw2-1.dll
-a----       2016/09/24   3:17 PM          83742 libgcc_s_seh-1.dll
-a----       2016/10/13   7:02 PM        1124259 libglib-2.0-0.dll
-a----       2015/06/29   1:25 PM        1050543 libiconv-2.dll
-a----       2016/03/31   8:50 AM         132717 libintl-8.dll
-a----       2016/10/09   5:46 PM          56978 libwinpthread-1.dll
-a----       2016/10/31   9:10 PM       26335738 unicorn.dll

The library does load the directories correctly

[-] path: 'C:\Python\lib\site-packages\unicorn\lib'
        [+] lib_file: C:\Python\lib\site-packages\unicorn\lib\libwinpthread-1.dll
        [+] lib_file: C:\Python\lib\site-packages\unicorn\lib\libgcc_s_seh-1.dll
        [+] lib_file: C:\Python\lib\site-packages\unicorn\lib\libgcc_s_dw2-1.dll
[-] path: 'C:\Python\lib\site-packages\unicorn\lib'
        [+] lib_file: C:\Python\lib\site-packages\unicorn\lib\libwinpthread-1.dll
        [+] lib_file: C:\Python\lib\site-packages\unicorn\lib\libgcc_s_seh-1.dll
        [+] lib_file: C:\Python\lib\site-packages\unicorn\lib\libgcc_s_dw2-1.dll
[-] path: ''
        [+] lib_file: libwinpthread-1.dll
        [+] lib_file: libgcc_s_seh-1.dll
        [+] lib_file: libgcc_s_dw2-1.dll
        [+] lib_file: libiconv-2.dll
        [+] lib_file: libintl-8.dll
        [+] lib_file: libglib-2.0-0.dll
[-] path: 'C:\Python\Lib\site-packages'
        [+] lib_file: C:\Python\Lib\site-packages\libwinpthread-1.dll
        [+] lib_file: C:\Python\Lib\site-packages\libgcc_s_seh-1.dll
        [+] lib_file: C:\Python\Lib\site-packages\libgcc_s_dw2-1.dll
        [+] lib_file: C:\Python\Lib\site-packages\libiconv-2.dll
        [+] lib_file: C:\Python\Lib\site-packages\libintl-8.dll
        [+] lib_file: C:\Python\Lib\site-packages\libglib-2.0-0.dll
[-] path: 'C:\Python\Lib\site-packages\unicorn\lib'
        [+] lib_file: C:\Python\Lib\site-packages\unicorn\lib\libwinpthread-1.dll
        [+] lib_file: C:\Python\Lib\site-packages\unicorn\lib\libgcc_s_seh-1.dll
        [+] lib_file: C:\Python\Lib\site-packages\unicorn\lib\libgcc_s_dw2-1.dll
[-] path: '/usr/lib64'
        [+] lib_file: /usr/lib64\libwinpthread-1.dll
        [+] lib_file: /usr/lib64\libgcc_s_seh-1.dll
        [+] lib_file: /usr/lib64\libgcc_s_dw2-1.dll
        [+] lib_file: /usr/lib64\libiconv-2.dll
        [+] lib_file: /usr/lib64\libintl-8.dll
        [+] lib_file: /usr/lib64\libglib-2.0-0.dll
Traceback (most recent call last):
  File "shellcode.py", line 5, in <module>
    from unicorn import *
  File "C:\Python\lib\site-packages\unicorn\__init__.py", line 4, in <module>
    from .unicorn import Uc, uc_version, uc_arch_supported, version_bind, debug, UcError, __version__
  File "C:\Python\lib\site-packages\unicorn\unicorn.py", line 75, in <module>
    raise ImportError("ERROR: fail to load the dynamic library.")
ImportError: ERROR: fail to load the dynamic library.

Note: the extra path was a hard-coded one for debugging.

I have no idea what the issue is here. You can see the hap-hazard file loading from a little debug print() I did :/

Its also worth noting that I have attempt the "official" 0.9 release from the website as well as my own build. Same issue regardless.

attention: @sashs, @enkomio, @adrianherrera, @cseagle, @xorstream, @lunixbochs.

recently we have new APIs uc_context_save() & uc_context_restore(). at the moment, only Python binding supports these API.

thus we need to update other bindings: .Net, Go, Haskell, Java, msvc & ruby.

thanks!

Moved to Unicorn 2 for M1 support. Getting this ~50% of the time

MIPS CPU, with Go bindings if it matters. Perhaps someone has an idea.

Process 34232 stopped
* thread #10, stop reason = EXC_BAD_ACCESS (code=2, address=0x280000098)
    frame #0: 0x0000000101040a14 libunicorn.2.dylib`tb_gen_code_mips + 304
libunicorn.2.dylib`tb_gen_code_mips:
->  0x101040a14 <+304>: str    x8, [x9, #0x18]
    0x101040a18 <+308>: ldur   w8, [x29, #-0x14]
    0x101040a1c <+312>: ldur   x9, [x29, #-0x38]
    0x101040a20 <+316>: str    w8, [x9]
Target 0: (mipsevm.test) stopped.
(lldb) bt
* thread #10, stop reason = EXC_BAD_ACCESS (code=2, address=0x280000098)
  * frame #0: 0x0000000101040a14 libunicorn.2.dylib`tb_gen_code_mips + 304
    frame #1: 0x000000010102b74c libunicorn.2.dylib`tb_find + 92
    frame #2: 0x000000010102b1b0 libunicorn.2.dylib`cpu_exec_mips + 244
    frame #3: 0x0000000100fd8ce0 libunicorn.2.dylib`tcg_cpu_exec + 76
    frame #4: 0x0000000100fd8c0c libunicorn.2.dylib`resume_all_vcpus_mips + 96
    frame #5: 0x0000000100fd8dfc libunicorn.2.dylib`vm_start_mips + 24
    frame #6: 0x0000000100fc676c libunicorn.2.dylib`uc_emu_start + 352
    frame #7: 0x00000001002f7f04 mipsevm.test`_cgo_81152a5834e5_Cfunc_uc_emu_start + 44

Speed isn't that important to me, is there any way to disable threading?

Add ability to mark memory area read only. Add new API uc_mem_map_ex to allow permissions to be passed. Change MemoryBlock to track created MemoryRegions. Add regress/ro_mem_test.c

This also solves the memory leak issue on uc->ram because now all MemoryRegion allocations are tracked in the uc->mapped_blocks array.

Added glib compatible replacements for all glib functions used in unicorn. Removed glib dependencies in Makefiles. I threw the list and hash table implementations together and have paid no attention to their performance. Feel free to replace the hash table implementation with something that performs better. Need help testing. All samples and unit tests run with same results as master on the following platforms: win32 (using mingw), OS X 64, Linux 32, Linux 64. Have not done much testing beyond that.

This is a feature that is required for UC integration in angr. We need to be able to efficiently roll back the state at a whim when we encounter symbolic data that cannot be processed by unicorn.

Originally, our internal code was just including the appropriate private header files and performing this operation manually, but as we're gearing up for distribution, this won't do. So, new feature!

I've done nothing but the bare minimum to demonstrate that it works and is useful since I don't know if this is a feature you'd appreciate having.

Hi,

I was wondering what would it take to support IBM Z in unicorn-engine? QEMU 2.1.2 seems to have sufficient support for it, so I assume the main missing things are these?

• UC_* defines
• machine definition
• hooks
• build system support

Also, based on https://github.com/unicorn-engine/unicorn/issues/1438, do I get it right that such contribution would have to wait until unicorn 2 is out, or would it make sense to also do this for 1.x?

Best regards, Ilya

osx in Travis has brew available without sudo, easy to install cmocka

For linux and appveyor, I created a small script to download and compile cmocka.

Unit test test_tb_x86_64_32_imul_Gv_Ev_Ib now failing on all platforms

TODO: see if clang works in cygwin for builds, currently following up with cmocka

What about changing the tests/unit to pass and adding it to the build process? Maybe bindings too?

I've made only few tests so far: basic arithmetic, and strlen(). No stack-related tests, no tests for resource leaks on multiple runs, no tests for hooks. Also it is limited to e500v2 and built only in ubuntu/amd64/gcc environment. So this is surely work in progress. However the changes to the common part of unicorn are few and easy to review and most likely they are not going to introduce any problem with non-ppc platforms. So if you accept the changes you are going to have an otherwise stable engine with experimental unstable ppc support.

i wanted to straightly upgrade to Qemu 2.5, but there is a lot of code changed from Qemu 2.2.1, which Unicorn is based on.

therefore, i will break this down in few phases to make it more manageable, and also easier to track bugs introduced by this task:

• upgrade to 2.3.1
• upgrade to 2.4.1
• upgrade to 2.5

expect more update on this work later.

See #1615

I just merged the changes from https://github.com/QDucasse/unicorn/pull/2. Unfortunately this doesn't seem to fix everything. The new state of the tests on the M1:

./build/test_x86
Test test_x86_in...                             [ OK ]
Test test_x86_out...                            [ OK ]
Test test_x86_mem_hook_all...                     Test interrupted by signal 10.
Test test_x86_inc_dec_pxor...                   [ OK ]
Test test_x86_relative_jump...                  [ OK ]
Test test_x86_loop...                           [ OK ]
Test test_x86_invalid_mem_read...               [ OK ]
Test test_x86_invalid_mem_write...              [ OK ]
Test test_x86_invalid_jump...                   [ OK ]
Test test_x86_64_syscall...                     [ OK ]
Test test_x86_16_add...                         [ OK ]
Test test_x86_reg_save...                       [ OK ]
Test test_x86_invalid_mem_read_stop_in_cb...    [ OK ]
Test test_x86_x87_fnstenv...                    [ OK ]
Test test_x86_mmio...                           [ OK ]
Test test_x86_missing_code...                   [ OK ]
Test test_x86_smc_xor...                        [ OK ]
Test test_x86_mmio_uc_mem_rw...                 [ OK ]
Test test_x86_sysenter...                       [ OK ]
Test test_x86_hook_cpuid...                     [ OK ]
Test test_x86_486_cpuid...                      [ OK ]
Test test_x86_clear_tb_cache...                 [ OK ]
Test test_x86_clear_empty_tb...                 [ OK ]
Test test_x86_hook_tcg_op...                    [ OK ]
Test test_x86_cmpxchg...                        [ OK ]
Test test_x86_nested_emu_start...               [ OK ]
Test test_x86_nested_emu_stop...                [ OK ]
Test test_x86_64_nested_emu_start_error...      [ OK ]
Test test_x86_eflags_reserved_bit...            [ OK ]
Test test_x86_nested_uc_emu_start_exits...      [ OK ]
Test test_x86_clear_count_cache...                Test interrupted by signal 10.
Test test_x86_correct_address_in_small_jump_hook... [ OK ]
Test test_x86_correct_address_in_long_jump_hook... [ OK ]
Test test_x86_invalid_vex_l...                  [ OK ]
Test test_x86_lazy_mapping...                   [ OK ]
Test test_x86_cpuid_1...                        [ OK ]
FAILED: 2 of 36 unit tests have failed.

Description While emulating a binary that configures and enables the MMU both physical and virtual address ranges has to be added to the Unicorn instance beforehand. Unicorn will never access the added virtual range but it will do the address translation and as expected it accesses the memory area at the physical address range. However it will crash with an unmapped memory error if the virtual address range is not added to the unicorn instance. What I see as a problem is that load_helper and store_helper functions do the Unicorn memory region lookup first and then do the address translation after it. This works fine if the MMU is disabled as the address translator will simply return the original address. However with the MMU enabled Unicorn won't find the address range for the virtual address before translation but it would find it after translating it to a physical address. I've observed the issue with ARM and ARM64 architectures but I can imagine it affects others too.

I think these is the same issue: #1602

Tested with Unicorn 2.0.0 and aarch64-linux-gnu-gcc 12.2.0

Example I've prepared a simple ARM64 example for demonstrating the issue. I've also attached the complete test environment. unicorn_mmu_bug.zip

test_mmu.s

• The code starts with the MMU being turned off
• We load the binary to the 0x0000_0000 address
• We read data from 0x4000_0000, note that this is now a physical address
• Enable MMU with the mapping below
  • 0x0000_0000- 0x3fff_ffff -> 0x0000_0000 - 0x3fff_ffff
  • 0x4000_0000- 0x7fff_ffff -> 0x4000_0000 - 0x7fff_ffff
  • 0x8000_0000- 0xbfff_ffff -> 0x4000_0000 - 0x7fff_ffff
  • 0xc000_0000- 0xffff_ffff -> 0x4000_0000 - 0x7fff_ffff
• With this MMU setting we can read the 0x4000_0000 address by reading 0x4000_0000, 0x8000_0000 or 0xc000_0000.
• Read 0x8000_0000, which should be translated to 0x4000_0000 and we should get the same value as we got by reading 0x4000_0000 before as a physical address.
• The two read results are in X1 and X2 registers.

// Based on https://developer.arm.com/documentation/dai0527/a/

    .global _start
_start:
    // Read data from physical address
    ldr X0, =0x40000000
    ldr X1, [X0]

    // Initialize translation table control registers
    ldr X0, =0x180803F20
    msr TCR_EL1, X0
    ldr X0, =0xFFFFFFFF
    msr MAIR_EL1, X0

    // Set translation table
    adr X0, ttb0_base
    msr TTBR0_EL1, X0

    // Enable caches and the MMU
    mrs X0, SCTLR_EL1
    orr X0, X0, #(0x1 << 2) // The C bit (data cache).
    orr X0, X0, #(0x1 << 12) // The I bit (instruction cache)
    orr X0, X0, #0x1 // The M bit (MMU).
    msr SCTLR_EL1, X0
    dsb SY
    isb

    // Read the same memory area through virtual address
    ldr X0, =0x80000000
    ldr X2, [X0]

    // Stop
    b .

    // Put a 64-bit value with little endianness.
    .macro PUT_64B high, low
    .word \low
    .word \high
    .endm

    // Create an entry for a 1GB block.
    .macro BLOCK_1GB PA, ATTR_HI, ATTR_LO
    PUT_64B \ATTR_HI, ((\PA) & 0xC0000000) | \ATTR_LO | 0x1
    .endm

    .align 12 // 12 for 4KB granule.
ttb0_base:
    BLOCK_1GB 0x00000000, 0, 0x740
    BLOCK_1GB 0x40000000, 0, 0x740
    BLOCK_1GB 0x40000000, 0, 0x740
    BLOCK_1GB 0x40000000, 0, 0x740

test_mmu.py

• Map 0x0000_0000 - 0x0000_2000 for the binary
• Map 0x4000_0000 - 0x4000_1000 for the test data, fill with 0x44
• Map 0x8000_0000 - 0x8000_1000 for the virtual area that we read if argv[1] == map_va, fill with 0x88
• Start emulation and print results

from unicorn import *
from unicorn.arm64_const import *
import sys

map_virtual_area = len(sys.argv) > 1 and sys.argv[1] == "map_va"

uc = Uc(UC_ARCH_ARM64, UC_MODE_ARM)

uc.mem_map(0x0000_0000, 0x2000, UC_PROT_ALL)
uc.mem_map(0x4000_0000, 0x1000, UC_PROT_ALL)

if map_virtual_area:
    uc.mem_map(0x8000_0000, 0x1000, UC_PROT_ALL)

with open("test_mmu.bin", "rb") as f:
    uc.mem_write(0x0000_0000, f.read())
uc.mem_write(0x4000_0000, bytes([0x44] * 0x1000))

if map_virtual_area:
    uc.mem_write(0x8000_0000, bytes([0x88] * 0x1000))

try:
    uc.emu_start(0, 0x44, count=100)
except UcError as e:
    print("Unicorn error:", e)

print(f"PC = 0x{uc.reg_read(UC_ARM64_REG_PC):08x}")
print(f"X0 = 0x{uc.reg_read(UC_ARM64_REG_X0):08x}")
print(f"X1 = 0x{uc.reg_read(UC_ARM64_REG_X1):08x}")
print(f"X2 = 0x{uc.reg_read(UC_ARM64_REG_X2):08x}")

Results

$ python test_mmu.py 
Unicorn error: Invalid memory read (UC_ERR_READ_UNMAPPED)
PC = 0x00000040
X0 = 0x80000000
X1 = 0x4444444444444444
X2 = 0x00000000
$ python test_mmu.py map_va
PC = 0x00000044
X0 = 0x80000000
X1 = 0x4444444444444444
X2 = 0x4444444444444444

Note that if the virtual address is mapped, it correctly read the 0x4444444444444444 from the physical address range.

A colleague and I ran across this issue when noticing that the shl instruction below neglects to set the CF, when it is supposed to. Upon digging into why this was the case, it turns out that the JIT'd code for this translation block is completely off and comes as a result of a MEM_WRITE hook being called when lifting the shl to its TCGOp representation that is the initial trigger that begins in generating the wrong JIT'd code, and results in the livenass_pass1 handler removing the necessary, remaining components of the shl handler.

0045849F 52                        push    edx
004584A0 D3 A4 0C F5 E3 5C 85      shl     dword ptr [esp+ecx-7AA31C0Bh], cl
004584A7 0F 83 80 60 13 00         jnb     loc_58E52D
004584AD 87 AC 0C F9 E3 5C 85      xchg    ebp, [esp+ecx+4+var_7AA31C0B]
004584B4 8B 8C 0C E1 E3 5C 85      mov     ecx, [esp+ecx+4+var_7AA31C23]
004584BB 66 C1 64 24 20 CA         shl     word ptr [esp+4+arg_18], 0CAh
004584C1 8B 54 24 20               mov     edx, [esp+4+arg_18]
004584C5 0F 86 FE 10 10 00         jbe     loc_5595C9

The resulting TranslationBlock is from the push up to the jnb. The shl is correctly lifted to its IR representation, including the hooks inserted via gen_jmp_im. All of this comes out of gen_shift_rm_T1. However, upon the liveness_pass1 optimization pass that eventually follows it, the necessary code is "optimized away", resulting in the incorrect JIT'd code, thus resulting into an incorrect interpretation of the flags for this instruction.

Here is the exact location where the hook that gets inserted starts the trouble:

The "fix" in our particular case, was simply removing this MEM_WRITE hook, which results in avoiding the gen_jmp_im being generated and acted upon, but this is a scary fix :) Will work on putting exact steps for repro, as this is part of a larger emulation we're doing, but I hope it can already begin pinpointing the exact root cause of the issue.

Update

Huge kudos to my colleague here w/ the necessary assist. The resulting code incorrectly generates the same issue w/ the wrong implementation of the shl instruction.

[0x1968000053c]  : and         ebx,1Fh                    ; missing the sub_i64
[0x1968000053f]  : shlx        r13,r13,rbx                ; missing the subsequent shlx
[0x19680000544]  : mov         qword ptr [rbp+80h],1021h  ; jmp_hook no no no

import unicorn
import binascii
from unicorn.x86_const import *
#from capstone import *

def code_hook(mu, access, address, size, value, user_data):
    return True
    
uc = unicorn.Uc(unicorn.UC_ARCH_X86, unicorn.UC_MODE_32)
uc.hook_add(unicorn.UC_HOOK_MEM_READ | unicorn.UC_HOOK_MEM_WRITE, code_hook)

uc.mem_map(0xFFFF0000, 0x2000)
uc.reg_write(UC_X86_REG_ESP, 0xFFFF1000)
uc.reg_write(UC_X86_REG_EBP, 0xFFFF1000)

'''
0x1000:  push    ecx
0x1001:  mov     ecx, 0x1ea53211
0x1006:  lea     ecx, [ecx + ecx*8 + 0x718e20eb]
0x100d:  or      cl, 0xd0
0x1010:  lea     ebp, [ebp + ecx - 0x5778699]
0x1017:  not     ecx
0x1019:  or      dword ptr [esp + ecx - 0x7aa31c0f], ecx
0x1020:  push    edx
0x1021:  shl     dword ptr [esp + ecx - 0x7aa31c0b], cl
0x1028:  jae     0x136087
0x102e:  ret
'''
code = binascii.unhexlify('51b91132a51e8d8cc9eb208e7180c9d08dac0d677988faf7d1098c0cf1e35c8552d3a40cf5e35c850f8380601300C3')
addr = 0x1000

uc.mem_map(0, 0x10000)
uc.mem_write(addr, code)
uc.emu_start(addr, addr + len(code), count=10)

The x64 implementation also suffers from the same issue:

import unicorn
import binascii
from unicorn.x86_const import *
#from capstone import *

def code_hook(mu, access, address, size, value, user_data):
    return True
    
'''def debug_print(mu, address, size, user_data):
    md = Cs(CS_ARCH_X86, CS_MODE_64)
    temp = mu.mem_read(address, size)
    for (addr, size, mnemonic, op_str) in md.disasm_lite(temp, 1):
        print("0x%x:\t%s\t%s" %(address, mnemonic, op_str))'''
    
uc = unicorn.Uc(unicorn.UC_ARCH_X86, unicorn.UC_MODE_64)
#uc.hook_add(unicorn.UC_HOOK_MEM_READ | unicorn.UC_HOOK_MEM_WRITE, code_hook) #jmp taken no output
uc.hook_add(unicorn.UC_HOOK_MEM_READ | unicorn.UC_HOOK_MEM_WRITE, code_hook) #jmp not taken crashing resulting in different output:
#  Traceback (most recent call last):
#    File ".\stub_64.py", line 35, in <module>
#      uc.emu_start(addr, addr + len(code), count=5)
#    File "C:\Python38\lib\site-packages\unicorn\unicorn.py", line 341, in emu_start
#      raise UcError(status)
#  unicorn.unicorn.UcError: Invalid memory fetch (UC_ERR_FETCH_UNMAPPED)
#uc.hook_add(unicorn.UC_HOOK_CODE, debug_print)

uc.mem_map(0xFFFF0000, 0x2000)
uc.reg_write(UC_X86_REG_RSP, 0xFFFF1000)
uc.reg_write(UC_X86_REG_RBP, 0xFFFF1000)
'''
0x1000: movabs  rcx, 0xffffffffffffffff
0x100a: mov     qword ptr [rsp], rcx
0x100e: shl     qword ptr [rsp], cl
0x1012: jae     0xd
0x1014: ret
'''
code = binascii.unhexlify('48B9FFFFFFFFFFFFFFFF48890C2448D32424730AC3')
addr = 0x1000

uc.mem_map(0, 0x2000)
uc.mem_write(addr, code)
uc.emu_start(addr, addr + len(code), count=5)

Hi!

One of our tools is using Unicorn for shellcode detection. While feeding it with arbitrary data, we noticed that QEMU used by Unicorn is crashing on FF D8 opcode. These bytes come from the beginning of JPEG magic (\xff\xd8\xff\xe0\x00\x10JFIF\x00\x01\x01\x01\x00)

FF D8 is invalid instruction that is parsed as CALL FAR m16:32 with mod=3, rm=0 (CALL FAR rax?) and normally results in #UD.

Is it expected to trigger tcg_abort on such non-sense code or is it indicator of a bug in QEMU?

Output from debug build executed with UNICORN_DEBUG=1 under gdb:

*** TCG before optimization:
 0:  ld_i32 tmp11,env,$0xfffffffffffffff0
 1:  movi_i32 tmp12,$0x0
 2:  brcond_i32 tmp11,tmp12,lt,$L0

 insn_idx=0 ---- 0000000000100000 0000000000000000
 1:  movi_i64 tmp3,$0x100000
 2:  st_i64 tmp3,env,$0x80
 3:  movi_i32 tmp11,$0x2
 4:  movi_i64 tmp13,$0x555555fcfe50
 5:  movi_i64 tmp14,$0x100000
 6:  movi_i32 tmp12,$0x2
 7:  call uc_tracecode,$0x0,$0,tmp11,tmp12,tmp13,tmp14
 8:  ld_i32 tmp11,env,$0xfffffffffffffff0
 9:  movi_i32 tmp12,$0x0
 10:  brcond_i32 tmp11,tmp12,lt,$L0
 11:  mov_i64 tmp0,rax
 12:  qemu_ld_i64 tmp1,tmp2,leul,2
 13:  ld_i32 tmp11,env,$0xfffffffffffffff0
 14:  movi_i32 tmp12,$0x0
 15:  brcond_i32 tmp11,tmp12,lt,$L0
 16:  movi_i64 tmp13,$0x4
 17:  add_i64 tmp2,tmp2,tmp13
 18:  qemu_ld_i64 tmp0,tmp2,leuw,2
 19:  ld_i32 tmp11,env,$0xfffffffffffffff0
 20:  movi_i32 tmp12,$0x0
 21:  brcond_i32 tmp11,tmp12,lt,$L0
 22:  mov_i32 tmp5,tmp0
 23:  movi_i64 tmp13,$0x100002
 24:  movi_i32 tmp11,$0x1
 25:  call lcall_protected,$0x0,$0,env,tmp5,tmp1,tmp11,tmp13
 26:  ld_i64 tmp7,env,$0x80
 27:  call lookup_tb_ptr,$0x6,$1,tmp14,env
 28:  goto_ptr tmp14
 29:  set_label $L0
 30:  exit_tb $0x7fffb2d42043

*** TCG before codegen:
 0:  ld_i32 tmp11,env,$0xfffffffffffffff0
 1:  movi_i32 tmp12,$0x0
 2:  brcond_i32 tmp11,tmp12,lt,$L0  dead: 0 1

 insn_idx=0 ---- 0000000000100000 0000000000000000
 1:  movi_i64 tmp3,$0x100000
 2:  st_i64 tmp3,env,$0x80  dead: 0 1
 3:  movi_i32 tmp11,$0x2
 4:  movi_i64 tmp13,$0x555555fcfe50
 5:  movi_i64 tmp14,$0x100000
 6:  movi_i32 tmp12,$0x2
 7:  call uc_tracecode,$0x0,$0,tmp11,tmp12,tmp13,tmp14  dead: 0 1 2 3
 8:  ld_i32 tmp11,env,$0xfffffffffffffff0
 9:  movi_i32 tmp12,$0x0
 10:  brcond_i32 tmp11,tmp12,lt,$L0  dead: 0 1
 11:  qemu_ld_i64 tmp1,tmp2,leul,2
 12:  ld_i32 tmp11,env,$0xfffffffffffffff0
 13:  movi_i32 tmp12,$0x0
 14:  brcond_i32 tmp11,tmp12,lt,$L0  dead: 0 1
 15:  movi_i64 tmp13,$0x4
 16:  add_i64 tmp2,tmp2,tmp13  dead: 1 2
 17:  qemu_ld_i64 tmp0,tmp2,leuw,2  dead: 1
 18:  ld_i32 tmp11,env,$0xfffffffffffffff0
 19:  movi_i32 tmp12,$0x0
 20:  brcond_i32 tmp11,tmp12,lt,$L0  dead: 0 1
 21:  mov_i32 tmp5,tmp0  dead: 1
 22:  movi_i64 tmp13,$0x100002
 23:  movi_i32 tmp11,$0x1
 24:  call lcall_protected,$0x0,$0,env,tmp5,tmp1,tmp11,tmp13  dead: 0 1 2 3 4
 25:  call lookup_tb_ptr,$0x6,$1,tmp14,env  dead: 1
 26:  goto_ptr tmp14  dead: 0
 27:  set_label $L0
 28:  exit_tb $0x7fffb2d42043
/home/psrok1/sflock/unicorn/qemu/tcg/tcg.c:3073: tcg fatal error

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350254592) at ./nptl/pthread_kill.c:44
44	./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350254592) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140737350254592) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140737350254592, [email protected]=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7c8f476 in __GI_raise ([email protected]=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff7c757f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff40aec66 in temp_load (s=0x55555606bda0, ts=0x55555606c978, desired_regs=65343, allocated_regs=48, preferred_regs=0) at /home/psrok1/sflock/unicorn/qemu/tcg/tcg.c:3073
#6  0x00007ffff40afa85 in tcg_reg_alloc_op (s=0x55555606bda0, op=0x555555ff9780) at /home/psrok1/sflock/unicorn/qemu/tcg/tcg.c:3455
#7  0x00007ffff40b0ae2 in tcg_gen_code_x86_64 (s=0x55555606bda0, tb=0x7fffb2d42040) at /home/psrok1/sflock/unicorn/qemu/tcg/tcg.c:3834
#8  0x00007ffff40dabb3 in tb_gen_code_x86_64 (cpu=0x5555560ae7a0, pc=1048576, cs_base=0, flags=4243632, cflags=-16777216) at /home/psrok1/sflock/unicorn/qemu/accel/tcg/translate-all.c:1648
#9  0x00007ffff40c3b12 in tb_find (cpu=0x5555560ae7a0, last_tb=0x0, tb_exit=0, cf_mask=0) at /home/psrok1/sflock/unicorn/qemu/accel/tcg/cpu-exec.c:256
#10 0x00007ffff40c4406 in cpu_exec_x86_64 (uc=0x555555fcfe50, cpu=0x5555560ae7a0) at /home/psrok1/sflock/unicorn/qemu/accel/tcg/cpu-exec.c:597
#11 0x00007ffff4086873 in tcg_cpu_exec (uc=0x555555fcfe50) at /home/psrok1/sflock/unicorn/qemu/softmmu/cpus.c:96
#12 0x00007ffff4086b2c in resume_all_vcpus_x86_64 (uc=0x555555fcfe50) at /home/psrok1/sflock/unicorn/qemu/softmmu/cpus.c:215
#13 0x00007ffff4086bc7 in vm_start_x86_64 (uc=0x555555fcfe50) at /home/psrok1/sflock/unicorn/qemu/softmmu/cpus.c:234
#14 0x00007ffff4072f93 in uc_emu_start (uc=0x555555fcfe50, begin=1048576, until=1048578, timeout=0, count=1048576) at /home/psrok1/sflock/unicorn/uc.c:870

We can see that our instruction was interpreted as far call: 24: call lcall_protected,$0x0,$0,env,tmp5,tmp1,tmp11,tmp13 dead: 0 1 2 3 4

This PR fixes a few test failures if the host architecture is Big Endian:

• On BE architectures, truncating an integer type will change its value, because the lower bits will be cut off, not the higher ones. Most notably, the program counter in uc_emu_start will end up zeroed. Luckily, the existing set_pc function handles all corner cases correctly.
• Reading guest memory leaks the endianness to the host, so if the host has a different endianness, this needs to be compensated for. I added a bunch of cpu_to_le and le_to_cpu functions (which are no-ops on LE hosts) for this.

Would it be possible to use Unicorn Engine in a wasm environment, specifically with the Rust bindings? Compiling the Rust bindings with --target wasm32-unknown-unknown doesn't seem to work as gcc complains about not supporting the target.