Hello all,

This is a strange problem I've been having. I used SoftIce to reverse a small application and to make in-memory changes. Everything seemed to work, so I noted the required changes, and went ahead to patch the file. But when I ran the executable, after applying the changes, it crashed precisely when executing the code I modified. I should note that the file isn't packed, and that I patched it with a hex editor.
I double checked everything, and even disassembled the file with Wdasm to make sure the changes were correct. But still, it crashes.

I have come up with one possible explanation. The changes I made included adding code right after the last instruction in the file, and a call to that location. It was initially zero filled, and Wdasm showed it as part of the code, so I figured that I could overwrite it. Is it possible that the app crashes because it tries to access code that isn't inside a valid code section?

Any help would be greatly appreciated. TIA.

Did you remember to NOP out suff that was left behind (remaining parts of the code changed if any)... otherwise the CPU will try to execute invalid opcodes and you will crash... just a thought...

Have you corrected PE header (Virtual & File size of executable section), to include your new code?
Neviens.

NervGaz:
Yes, I did that, and it ran perfectly well when I edited it in memory.

neviens:
That's the thing exactly, I didn't extend any section. There was just some unused space at the end of .text where I inserted my code, so I didn't have to update the PE header.


UPDATE:
It seems that the crash doesn't occur at the new code, but rather at some completely unrelated part of the app. I get a page fault which normally doesn't happen.
Again, I made the exact same changes to the code, first "live" and then to the file, but when I run from disk it crashes. Any thoughts?

Checksum ? CRC ?

Correct me if I am wrong: You make the changes when the prog is already loaded in memory, using Sice, and it works fine, but if you make the changes on disk the program crashes, in a different section of the code with a page fault?

Smells to me Some thing wrong is happening during the early stages of the program, i.e, program loading, like a CRC check, or code alignment, or decoding stuff, that you bypass when you load the program in memory and modify the bytes later.

I would try this approach, Listen carefully:

Load your program in Sice symbol loader and make it stop at winmain function: This will load the program and place a breakpoint at the program entry point. When Sice breaks, place bpm's on the addresses of the bytes you modify, and try to fish out the part of the code that reads those bytes early during the program initial stages.

When you find it, deactivate or correct what needs to be corrected.

Also, the 0's you see at the end of the .text section where you placed your extra code may be used at an early stage of the program, either wrongly reading or overwriting some of your bytes.

Just a suggestion.

Another possibility :
when you debug with Softice it puts CC (= int 3) opcodes where you want breakpoints. When you exit from Softice it replaces the CC's with the original opcodes.
Sometimes (depending on how you exit from Softice) the replacement is not made and the remaining CC's cause a crash.

A good precaution is to debug with a copy of the prog, and then patch and run the original prog.

My 2 cents.
Artifex

i've had the same problems with some upx'ed programs. usually you can insert your own code where it jumps to the oep, but sometimes this wouldn't work, even though the space seems to be unused. in such a case i end up searching for another free spot, which normally isn't hard to find.

i haven't looked deeper into it, but i was wondering why...

Thanks for all the replies.

I thought of a checksum myself, but it seems a bit unlikely, becuase (as maybe I should have mentioned earlier) the crash doesn't happen at startup. It doesn't happen after a fixed amount of time either.
Still, I will try naides' method, maybe it will give me some new insight.

Artifex, I did patch a fresh copy of the app.

I will report back if I find the cause to this.

Apparently it was a CRC check. I guess it is calculated at startup but compared only later. Anyway, I wrote a small proggie to change the values after the executable is loaded, and now it works.
Thanks for the help.