this is fourth day I am trying to figure out how to break down an exe.
Still having no luck, file is giving debugger error right after it is runned. I am using OllyDBG, it seems that file is either compressed or contains big ammount of data.
I think it is just for debugging protection, however I can not get it working.
I am trying to learn assembly and this is my “new level” achievment of getting better in testing applications.
All I want to change is one text to other, inside the file exe. So this is one variable change. I would be satisfied even with simple number change inside it. Just want to know how.
The file orginally runs other exe after it is opened, but this is not anything I want to touch or edit.
This is how the file open:
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
below this there are many DB calls, I tried to breakpoint every other RETN, but they are not called. Can someone give me a hint, how to deal with this kind of exe files?
Thank you for your time,
udis86 disassembler library has a very useful and handy disassembler called
udcli.For example, what I did to understand your code:
First, copy all the hex code bytes into an ASCII file. I copied your OllyDbg output and then cut off with Vim everything except the binary code, resulting in a text file like this (let’s say
hexcode.txt):Then wondering whether this is 16-bit, 32-bit or 64-bit Intel code… usually you can see and feel if the code seems strange, in that case it’s either wrong processor, wrong processor mode or the code may be encrypted or it may be data and not code.
Let’s try if it’s 16-bit code:
In Linux console,
$ cat hexcode.txt | udcli -x -16Hmmm. Already in the beginning
inc sp, very strange instruction. Conclusion: not 16-bit code.Maybe it’s 32-bit code?
$ cat hexcode.txt | udcli -x -32This looks already better. First, you could set a breakpoint into
0x445001. As thatdwordgets pushed immediately before acall dword 0xbfollowed by aret, it may be that theretaftercall 0xbactually pops the value0x445001from stack and jumps tocs:0x445001. On the other hand, if there’s an intent to obfuscate the code, it may be that the function called withcall dword 0xbmay modify the value0x445001pushed into stack, so thatretaftercall dword 0xbwould not jump to0x445001, but somewhere else. So set another breakpoint to the stack address where0x445001is stored. Before the function callcall dword 0xb[ss:esp]should point to the value0x445001, so set the breakpoint there. It can be set also inside the function, but in that case the address will be[ss:esp+4]([ss:esp]holds the return address). So I would try first set these 2 breakpoints and then trace the code with single-stepping inside thecall dword 0xbfunction.A final thought: what if this is 64-bit code?
$ cat hexcode.txt | udcli -x -64Begins the same way as 32-bit code, but later there’s an invalid instruction, so probably it’s not 64-bit code (unless the code hooks invalid opcode exception handler
int 6), or never executes that code.