0

There is a game that keeps crashing at the same assembly code point and I don't have source code so the only way to fix it by directly editing the exe file.

The place that keeps crashing, according to the disassembler, is at address 0x00629115 with pointer address access where ECX pointer is at a uninitialized address with more than 50% chance being 0x0 (probably using an uninitialized pointer in C code). Before that address there is a JGE command that skips the crashing code if the comparison succeeds.

Now what I want to do is modifying the JGE command at 0x00629106 to a JMP command so that it always skips the crashing code.

enter image description here

However I noticed that if I open the .exe file in a hex editor and go to the address 0x00629106 the binary code is not the same as what is shown in the disassembler. I am wondering how should I edit the exe binary.

enter image description here

cr001
  • 655
  • 4
  • 16

1 Answers1

2

Executables contain the code, but wrapped with headers, segment pointers, ... so even with the address offset you cannot use this address alone to find your code.

You have to locate a position-independent yet recognizable instruction(s) string and search for it (if there are relocations you won't find it), make sure this is the correct one / there is only one occurrence.

Make sure you're looking for position-independent code or offset correction will fail the match.

If your patch code is longer than the original code, this will be harder. You'll have to find useless/unused code or data, patch there, and bsr to that zone to remain in the available patch byte size.

Another last difficulty: some editors use executable packers to "encrypt" their code (because unpacking program does not exist officially but this one is pretty efficient) or/and make it smaller.

The trick is: if the executable does not compress very well with 7zip for instance, then it's probably packed. Use some executable depackers to create the runnable but unpacked exe, and change this version (no need to repack afterwards).

Jean-François Fabre
  • 137,073
  • 23
  • 153
  • 219
  • Thank you, searching for the code in hex editor works and the real address appears to be 0x00229106 which is 400000 bytes off...I don't know why the disassembler actually thinks it is at 0x00629115 which is miles larger than the actual address; headers of negative length? – cr001 Aug 26 '16 at 11:47
  • 1
    or this is the actual physical address in memory. You cannot trust that, unless you're manually loading the segments in memory yourself /gain access to that information from the system loader. Keep it simple, just search for bytes :) – Jean-François Fabre Aug 26 '16 at 11:54
  • 1
    @cr001: the file isn't mapped into memory at virtual address `0x00000000`, because we want NULL-pointer dereference to fault, instead of hitting the first byte of the file. There was an SO question about finding the right offset in a Windows PE executable given a code address; I'll see if I can find it and mark this question as a duplicate. – Peter Cordes Aug 26 '16 at 12:03
  • @cr001: found it. Neitsa's answer is super-detailed. If searching for a unique sequence of code bytes works, though, it's probably easier! – Peter Cordes Aug 26 '16 at 12:10