Parsing a file that contains big data or is compressed

Question

This is the fourth day. I am trying to figure out how to break an exe.

Still no luck, the file gives a debugger error right after it starts. I use OllyDBG, it seems that the file is either compressed or contains a large amount of data. I think this is just to protect debugging, but I can't get it to work.

I'm trying to learn assembly, and this is my “new level” that helps improve application testing. All I want to change is one text to another, inside an exe file. So this is one change to the variable. I would be satisfied even with a simple change of number inside it. Just want to know how to do this.

The orginally file launches another exe after opening it, but that is not what I want to touch or change.

Here's how the file opens:

00401000 >/$ 68 01504400 PUSH tryme.00445001 00401005 |. E8 01000000 CALL tryme.0040100B 0040100A \. C3 RETN 0040100B $ C3 RETN 0040100C A9 DB A9 0040100D FE DB FE 0040100E 39 DB 39 ; CHAR '9' 0040100F B1 DB B1 00401010 30 DB 30 ; CHAR '0' 00401011 D8 DB D8 00401012 BB DB BB 00401013 A6 DB A6 00401014 45 DB 45 ; CHAR 'E' 00401015 23 DB 23 ; CHAR '#' 00401016 92 DB 92 00401017 AC DB AC 00401018 3D DB 3D ; CHAR '=' 00401019 B3 DB B3 0040101A 9C DB 9C 0040101B 8C DB 8C 0040101C 90 NOP 0040101D 0E DB 0E 0040101E 26 DB 26 ; CHAR '&' 0040101F 3B DB 3B ; CHAR ';' 00401020 D3 DB D3 00401021 48 DB 48 ; CHAR 'H' 00401022 49 DB 49 ; CHAR 'I' 00401023 70 DB 70 ; CHAR 'p' 00401024 88 DB 88 00401025 07 DB 07 00401026 78 DB 78 ; CHAR 'x' 00401027 36 DB 36 ; CHAR '6' 00401028 7C DB 7C ; CHAR '|' 00401029 88 DB 88 

there are many DB calls below this, I tried to block all other RETNs, but they are not called. Can someone give me a hint how to deal with such exe files?

Thank you for your time,

Answer 1

The disassembler udis86 library has a very useful and convenient disassembler called udcli .

For example, what I did to understand your code:

First copy all the hex bytes into an ASCII file. I copied your output from OllyDbg, and then disabled Vim everything except the binary code, the result was a text file (let hexcode.txt ):

 68 01 50 44 00 E8 01 00 00 00 C3 C3 A9 FE 39 B1 30 D8 BB A6 45 23 92 AC 3D B3 9C 8C 90 0E 26 3B D3 48 49 70 88 07 78 36 7C 88 

Then I wonder if this is 16-bit, 32-bit, or 64-bit Intel code ... usually you can see and feel that the code seems strange, in which case it is either the wrong processor, or the wrong processor mode, or the code may be encrypted or may be data, not code.

Try if this is 16-bit code:

In the Linux console, $ cat hexcode.txt | udcli -x -16 $ cat hexcode.txt | udcli -x -16

 0000000000000000 680150 push word 0x5001 0000000000000003 44 inc sp 0000000000000004 00e8 add al, ch 0000000000000006 0100 add [bx+si], ax 0000000000000008 0000 add [bx+si], al 000000000000000a c3 ret 000000000000000b c3 ret 000000000000000c a9fe39 test ax, 0x39fe 000000000000000f b130 mov cl, 0x30 0000000000000011 d8bba645 fdivr dword [bp+di+0x45a6] 0000000000000015 2392ac3d and dx, [bp+si+0x3dac] 0000000000000019 b39c mov bl, 0x9c 000000000000001b 8c900e26 mov [bx+si+0x260e], ss 000000000000001f 3bd3 cmp dx, bx 0000000000000021 48 dec ax 0000000000000022 49 dec cx 0000000000000023 7088 jo 0xffffffffffffffad 0000000000000025 07 pop es 0000000000000026 7836 js 0x5e 0000000000000028 7c88 jl 0xffffffffffffffb2 

Hmmm. Already at the beginning of inc sp very strange instruction. Conclusion: not a 16-bit code.

Maybe this is 32-bit code?

$ cat hexcode.txt | udcli -x -32

 0000000000000000 6801504400 push dword 0x445001 0000000000000005 e801000000 call dword 0xb 000000000000000a c3 ret 000000000000000b c3 ret 000000000000000c a9fe39b130 test eax, 0x30b139fe 0000000000000011 d8bba6452392 fdivr dword [ebx+0x922345a6] 0000000000000017 ac lodsb 0000000000000018 3db39c8c90 cmp eax, 0x908c9cb3 000000000000001d 0e push cs 000000000000001e 263bd3 cmp edx, ebx 0000000000000021 48 dec eax 0000000000000022 49 dec ecx 0000000000000023 7088 jo 0xffffffffffffffad 0000000000000025 07 pop es 0000000000000026 7836 js 0x5e 0000000000000028 7c88 jl 0xffffffffffffffb2 

It looks better already. First, you can set a breakpoint at 0x445001 . Since this dword starts immediately before call dword 0xb followed by ret , it may be that ret after call 0xb actually 0x445001 from the stack and switches to cs:0x445001 . On the other hand, if you intend to confuse the code, it may be that a function called with call dword 0xb can change the value 0x445001 stack so that ret after call dword 0xb will not go to 0x445001 , but somewhere else . So set another breakpoint to the address of the stack where 0x445001 is stored. Before calling the call dword 0xb [ss:esp] 0x445001 , specify the value 0x445001 , so set a breakpoint there. It can also be set inside the function, but in this case the address will be [ss:esp+4] ( [ss:esp] has a return address). Therefore, I would try to set these 2 breakpoints first, and then trace the code with a single step inside the call dword 0xb .

One final thought: what if it is 64-bit code?

$ cat hexcode.txt | udcli -x -64

 0000000000000000 6801504400 push dword 0x445001 0000000000000005 e801000000 call dword 0xb 000000000000000a c3 ret 000000000000000b c3 ret 000000000000000c a9fe39b130 test eax, 0x30b139fe 0000000000000011 d8bba6452392 fdivr dword [rbx-0x6ddcba5a] 0000000000000017 ac lodsb 0000000000000018 3db39c8c90 cmp eax, 0x908c9cb3 000000000000001d 0e invalid 000000000000001e 263bd3 cmp edx, ebx 0000000000000021 48497088 jo 0xffffffffffffffad 0000000000000025 07 invalid 0000000000000026 7836 js 0x5e 0000000000000028 7c88 jl 0xffffffffffffffb2 

It starts the same way as 32-bit code, but there is an invalid command later, so it may not be 64-bit code (unless the code catches the invalid opcode int 6 exception handler) or never executes this code.