Radare2: ESIL can't 'call dword [esp]'

[pyllyukko]

Trying to run a binary via ESIL to emulate unpacker. When call dword [esp] is encountered (at 0x00405026), ESIL doesn't call the address at the stack (0x00405015), but runs right through the call instruction to the next instruction (0x00405029).

radare2 version

radare2 2.1.0 0 @ linux-x86-64 git.2.1.0
commit: HEAD build: 2017-11-27__20:16:15

Steps to reproduce

1. Get Lab01-03.exe from https://github.com/mikesiko/PracticalMalwareAnalysis-Labs
2. Open with radare2
3. Initialize ESIL
4. Start stepping through the disassembly
5. Witness ESIL not calling the address from the stack at 0x00405026 and elsewhere

[radare]

Because thats the plt. And this only works if the memory has been initialized by the system linker, libraries loaded and symbols resolved. And esil doesnt do any of this. You can hook those addresses to r2pipe scripts to emulate the libc or whatever lib calls are

On 1 Dec 2017, at 19:43, pyllyukko [e-mail] wrote:

Trying to run a binary via ESIL to emulate unpacker. When call dword [esp] is encountered (at 0x00405026), ESIL doesn't call the address at the stack (0x00405015), but runs right through the call instruction to the next instruction (0x00405029).

radare2 version

radare2 2.1.0 0 @ linux-x86-64 git.2.1.0
commit: HEAD build: 2017-11-27__20:16:15
Steps to reproduce

Get Lab01-03.exe from https://github.com/mikesiko/PracticalMalwareAnalysis-Labs
Open with radare2
Initialize ESIL
Start stepping through the disassembly
Witness ESIL not calling the address from the stack at 0x00405026 and elsewhere
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[pyllyukko]

No it's not PLT (procedure linkage table). There is no lib calls happening at this point. The code it should call is right there on the same screenshot:

            0x00405000      bbd0014000     mov ebx, 0x4001d0           ; section 2 va=0x00405000 pa=0x00000e00 sz=512 vsz=4096 rwx=m-rw- sect_2               
            0x00405005      bf00104000     mov edi, 0x401000           ; section.sect_0                                                                       
            0x0040500a      be00404000     mov esi, 0x404000           ; section.sect_1                                                                       
               ; JMP XREF from 0x004050b9 (entry0 + 185)                                                                                                      
            0x0040500f      53             push ebx                                                                                                           
            0x00405010      e80a000000     call 0x40501f               ;[1]                                                                                   
            0x00405015      02d2           add dl, dl                  <- HERE

[giuscri]

To get the binary:

$ wget --quiet https://github.com/mikesiko/PracticalMalwareAnalysis-Labs/raw/master/PracticalMalwareAnalysis-Labs.7z
$ 7z e ./PracticalMalwareAnalysis-Labs.7z 
...
$ unrar x ./PracticalMalwareAnalysis-Labs.exe 
...
$ sha256sum ./Practical\ Malware\ Analysis\ Labs/BinaryCollection/Chapter_1L/Lab01-03.exe 
7983a582939924c70e3da2da80fd3352ebc90de7b8c4c427d484ff4f050f0aec  ./Practical Malware Analysis Labs/BinaryCollection/Chapter_1L/Lab01-03.exe

Password for the 7z archive is malware

[giuscri]

Can confirm the bug, as of 8e8f54fab4db218bef0ba53a0e7a4d682bfcb6e7.

Address stored at esp is 0x405015 but eip is not updated, keeps pointing to the next instruction

[radare]

Can you write a test for this?

On 14 Feb 2018, at 15:27, Giuseppe [e-mail] wrote:

Can confirm the bug

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[giuscri]

~I tried yesterday, but evaluating push eax, 1234; call [esp] in esil environment actually put 1234 into the eip so maybe triggering the bug may be harder. I'll take a better look next week.~

[pyllyukko]

Can you write a test for this?

Would this do?

[radare]

Use p8 4 instead of px to avoid the hexdump header

On 18 Feb 2018, at 10:22, pyllyukko [e-mail] wrote:

Would this do?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[pyllyukko]

Use p8 4 instead of px to avoid the hexdump header

Done.

[giuscri]

ESIL expression is wrong. Currently it's eip,4,esp,-=,esp,=[],esp,[4],eip,= which should put eip on the stack, then take that value back into eip. That is why the jump isn't performed.

To my understanding, getarg() should be changed such to produce esp,4,+, producing eip,4,esp,-=,esp,=[], esp,+,4 ,[4],eip,= as the ESIL expression.

[pyllyukko]

@giuscri: Thank you!