Hi,

I'm having a lot of trouble with a particular program I have been trying to reverse.

I used softice and was able (after countless hours) to find the "key" jump instruction i'm trying to bypass, I even know what to change the value to so that it works (I modifed the code in memory and it worked)

The huge problem I have also spent countless hours trying to figure out is where the code is in the executable file.

I am kind of new to reversing but in all the examples I have walked through it was no big deal to find the code using wdasm32 or even hexview if you know the hex values (which I do in this case).

Problem is I search and nothing. This particular jump is the jle instruction and I even went one by one through wdasm32 through all the jle instructions and there is nothing that looks like what I am seeing in memory.
The program only has two files, the executable and a dll file (which I also searched through extensively). As well I used filemon to see if there was a hidden file someone that it accesses to load this code into memory but I could not see anything other than the windows dll files that it calls.

I don't know if maybe the program uses some protection scheme where it modifies the code somehow before it gets to memory ? I tried using IDA to dissassemble the executable and I get almost no code at all (at least in wdasm32 I get something).

Any help is greatly appretiated.

Thanks,

Tom

Is your program packed? Try PEid and see what it says.

If it isn't packed, write down the sequence of bytes surrounding the instruction, then open it in a hex editor and search for that sequence. You should only find one (1) occurrence.

Try HIEW. I've found it to be a good free hex editor.

Yep, It seems you ran into your first packing protection.
Exactly as you say, the program in disk is encrypted/packed.
When you load it, a small stub unencrypts the image in memory into the working code that you were able to trace and crack IN MEMORY.

What is curious is that most (commercial) packers have anti SofIce/ Antidebug measures, but you aparently were able to trace the program with Sice, which suggest to me that you are dealing with a home/made packer or a relatively old protection.

It seems tht you have accomplished quite a bit on your own, and you are "on the ball" with your analysis.

If you, using PEID are able to identify some known packer, I suggest you search the board and the tutorial repositories for specific unpacking strategies.

The alternative solution is to code a "loader" which is s small program that loads your target, allows it to unencrypt/unpack in memory, then automagically change the byte(s) you changed mannually using Sice.


Welcome to the Board

...or UPX

Also could be Aspack, a good site for tuts is:

http://www.tuts4you.com ("http://www.tuts4you.com")

SiGiNT

Hi,

Thanks for all the replys.

I downloaded PEID and it shows UPX 0.80 - 0.84 -> Markus & Laszlo for this program I am attempting to reverse. I guess that means it is packed right ?

I will try and see where I can go from here (I haven't yet tried those tutorials and links you guys suggested or know anything about this "packing" strategy, so I got some reading to do).

Thanks again,

Tom

You're in luck!

UPX is a great place to start learning about unpacking, I'm sure you'll learn a lot,
(at least in principal), by studying this one.

SiGiNT

If you just want to unpack it and don't want to inspect the packer, download the UPX and use its -d option to unpack quickly.

If you want to unpack manually, then start debugging - UPX is very simple, no antidebug or antidump, just run it to the entrypoint, dump, and rebuild imports

PEexplorer Also do a good work with UPX, it has a pluging which let you unpack the target and rebuild original section names automatically, will rebuild the packed exe/dll like it was never packed.

My Regards

cRk,

PE Explorer works fine, but my experience has been it does not yield the same results as using UPX -d, which I assume restores the original file, but I'm just nit-picking, for the purposes of debugging or patching either is fine, but you learn a little more doing it manually.

SiGiNT

Thanks a lot for all the help.

When I have some real time I will give it a try. I think I'll go with the manual way. That way perhaps I'll learn something along the way

Best regards,

Tom

but you learn a little more doing it manually.

for sure.. that's the best way always for someone who wants to learn