Hi All
I am trying to reverse a demo PE file I would call PROG.EXE. Sometime back I successfully reversed an older demo version of this PROG using W32DSM by NOPing certain checks and it worked perfectly well. Now with this new version using W32DSM crashed my PC. I searched the forums and tried ProcDump and PEID etc but I simply could not understand them. I had gone through the Newbees sections and FAQs and unpacking tutorials but this bugger is probably more difficult.

I tried IDA and it disassmbled it however IDA freeware I have doesnt have a debugger. I came to Ollydbg and successfully made a Dump. However when I debug the Dump it stops on module MSVFW32 saying "Don't know how to step because memory at 0000001 is not readdable, try to change the EIP or pass exception to Program". Exactly the same message I got when I tried debugging the PROG.exe.

The Trace looks like this from top to bottom:

796313E9 8B7424 0C MOV ESI,DWORD PTR SS:[ESP+C];MSVFW32.796310A7
796313ED 57 PUSH EDI ; <ModuleEntryPoint>
796313EE 56 PUSH ESI ; <ModuleEntryPoint>
796313EF A3 68506479 MOV DWORD PTR DS:[79645068],EAX
796313F4 68 7C506479 PUSH MSVFW32.7964507C ; ASCII "MSVFW32.DLL"
796313F9 68 70506479 PUSH MSVFW32.79645070 ; ASCII "MSVIDEO.DLL"
796313FE E8 39110000 CALL MSVFW32.7963253C
7963253C 5A POP EDX ; <ModuleEntryPoint>
7963253D 68 4D256379 PUSH MSVFW32.7963254D ; ASCII "ls_ThunkData16"
79632542 68 D8506479 PUSH OFFSET MSVFW32.ls_ThunkData32
79632547 52 PUSH EDX ; KERNEL32.BFFC9490
79632548 E9 4F9E0000 JMP <JMP.&KERNEL32.ThunkConnect32>
7963C39C -FF25 10D66479 JMP DWORD PTR DS:[<&KERNEL32.ThunkConnec>
79631403 57 PUSH EDI ; <ModuleEntryPoint>
79631404 56 PUSH ESI ; MSVFW32.796310A7
79631405 68 7C506479 PUSH MSVFW32.7964507C ; ASCII "MSVFW32.DLL"
7963140A 68 70506479 PUSH MSVFW32.79645070 ; ASCII "MSVIDEO.DLL"
7963140F E8 A7100000 CALL MSVFW32.796324BB
796324BB 5A POP EDX ; <ModuleEntryPoint>
796324BC 68 AC246379 PUSH MSVFW32.796324AC; ASCII "sl_ThunkData16"
796324C1 68 B4506479 PUSH OFFSET MSVFW32.sl_ThunkData32
796324C6 52 PUSH EDX
796324C7 E9 D09E0000 JMP <JMP.&KERNEL32.ThunkConnect32>
7963C39C -FF25 10D66479 JMP DWORD PTR DS:[<&KERNEL32.ThunkConnec>
79631414 B8 01000000 MOV EAX,<ModuleEntryPoint>
79631419 5F POP EDI ; 01CDFC10
7963141A 5E POP ESI ; 01CDFC10
7963141B C2 0C00 RETN 0C
00000001 ???

I kept the Dump Entry Point the same (00D635CE) and few line before the entry and after the entry are looking like this:

00D635B0 -FF25 4C681301 JMP DWORD PTR DS:[<&MSVCRT.fprintf>] ; MSVCRT.fprintf
00D635B6 -FF25 50681301 JMP DWORD PTR DS:[<&MSVCRT.fwrite>] ; MSVCRT.fwrite
00D635BC -FF25 54681301 JMP DWORD PTR DS:[<&MSVCRT.fread>] ; MSVCRT.fread
00D635C2 -FF25 58681301 JMP DWORD PTR DS:[<&MSVCRT.log10>] ; MSVCRT.log10
00D635C8 -FF25 5C681301 JMP DWORD PTR DS:[<&MSVCRT.remove>] ; MSVCRT.remove
00D635CE > 55 PUSH EBP
00D635CF 8BEC MOV EBP,ESP
00D635D1 6A FF PUSH -1
00D635D3 68 F8CBFF00 PUSH DUMP.00FFCBF8
00D635D8 68 4A37D600 PUSH <JMP.&MSVCRT._except_handler3>
00D635DD 64:A1 00000000 MOV EAX,DWORD PTR FS:[0]
00D635E3 50 PUSH EAX
00D635E4 64:8925 00000000 MOV DWORD PTR FS:[0],ESP
00D635EB 83EC 68 SUB ESP,68
00D635EE 53 PUSH EBX
00D635EF 56 PUSH ESI
00D635F0 57 PUSH EDI
00D635F1 8965 E8 MOV DWORD PTR SS:[EBP-18],ESP
00D635F4 33DB XOR EBX,EBX
00D635F6 895D FC MOV DWORD PTR SS:[EBP-4],EBX
00D635F9 6A 02 PUSH 2
00D635FB FF15 A8681301 CALL DWORD PTR DS:[<&MSVCRT.__set_app_ty>; MSVCRT.__set_app_type
00D63601 59 POP ECX ; DUMP.00400000

Well my experience with WDSM has been very good but this new stuff is bugging me specially how to proceed with this whole thing in a step by step manner. Apart from the packing/unpacking thing the real objective would be to overcome the protection mechanisms.

I would highly appreciate help in this matter.
aam245

Well, I'd suggest you do the following:
First off, do the required reading of the pe header (and exactly what that means is somewhat fuzzy. Just get ahold of some pe-documents - try www.wotsit.org, for instance - and read those. There should be plenty of threads on this board too, search for PE).
Secondly, learn how to use a filescanner. If the file is packed (and something would suggest that it is) it's always best to know with what. If you're lucky, you can just apply an unpacker. If not, at least you may search for essays that can help.
Thirdly, run the thing in ollydbg - if it doesn't crash, it should load at ep and you should be able to look at things (from the code you posted, it doesn't look too much like you ever got near the ep with your dump)
Fourthly, stay away from dumps till you know what you're dealing with - in the end, you might find that a loader is a much easier way, or that something else is.

Fake

well the 635ce looks like standard msvc compiled exes prolog so you probably have
the right entry point
and above it there is a jump table so probably the import table is merged in code section
olly puts out that message if it encounters an illegal instruction that it cant execute
like 0xffff etc etc and it will put out that message even if you pass the exception to the app without letting olly handle it
so when it pops up press ok then if it not paused but running press f12 and pause
when if it paused click the k button (view call stack ) and locate what calls are still pending in stack (you can follow the call procedure etc from that window)
if there are some calls from the module you are tarcing follow there and set a break point and restart ollydbg
olly should now pause in you break point now you can probaly single step through and find where some problem is occurs

Thanks Fake and Blabberer

I will once more referesh my PE header knowledge. The Dump.exe and Prog.exe are looking exactly the same and I kept the entry offset also the same.

Yes Import table may be merged in the code however when I see the Memory map and follow the PE header section it clearly gives the start, size and offsets of import table for the main module.

The EP is definitely 635CE as both IDA and Olly are showing it. There is one intersting thing just one line down after the ep, Note again this is the 3rd line after ep in the main module (same in Dump.exe and Prog.exe):

00D635D3 68 F8CBFF00 PUSH DUMP.00FFCBF8

When I try to look for the immediate constant for the address, this address is found in .rdata section and both IDA and Olly are showing unknown command in disassembly. It looks like this at 00FFCBF9,
00FFCBF1 33D6 XOR EDX,ESI ; MSVFW32.79630000
00FFCBF3 0000 ADD BYTE PTR DS:[EAX],AL
00FFCBF5 0000 ADD BYTE PTR DS:[EAX],AL
00FFCBF7 00FF ADD BH,BH
00FFCBF9 FFFF ??? ; Unknown command
00FFCBFB FF0C37 DEC DWORD PTR DS:[EDI+ESI]
00FFCBFE D6 SALC
00FFCBFF 0020 ADD BYTE PTR DS:[EAX],AH
What the Heck is this unknown command ????? and what is it doing in .rdata, and why the main program calling such thing just after the ep. When I sift through the .rdata there are several of this kind scattered there;

As for the call stack the only thing visible on Call stack is MSVFW32.dll and there are calls within it. The program halts after the appearance of the error message I mentioned inoriginal mail and no key Ctrl+F(any) works.

Any further suggestions are highly regarded.
Thanks

ffff is unknown command because it is not defined
ffff is not an opcode so no disassembler can decode it properly
in ollydbg there is an option in options ---> debugging option--->security-->
allow stepping into unknown commands
if you check it olly will let you step through it

but before that what ever is in r data probably has no bearing to the disassembly you quoted
all those commands are single steppable without generating any exceptions



as i said you need to single step through the code by breaking some where
before it puts out the message

try to make it run before unpacking inside debugger
use debugger options --> exceptions--> add range (add all) then check every box in that dialog and press ok
get hide debugger plugins and hide the debugger
find the find window code in dll and conditional break point some where down deep inside its code and when you find it use a condition to parse stack for ollydbgstring and make it stop only for that string and when it stops
nullify the string or modify the string so it fails automatically
find unhandled exception filter code and patch it
what ever it takes to fool the application to believe it is running outside debugger while actually it is running inside it
then when it is fooled and it is running use pause inside debugger and verify the call stack for pending calls
then from there use ctrl+g enter etc and play through the fully running code

Wow...Thats something...Thanks again Blabberer...
One little thing however....You said "when you find it use a condition to parse stack for ollydbgstring and make it stop only for that string.."

Can you explian it a bit further how to set up thsi Ollydbgstring ???
Appreciate all the help.. and will gothrough one step at a time.
Regards,

so both of them are strings or class name may be an atom (we leave that possibility now) so since they are strings they have to passed in clear (system dlls have no way to decrypt your schmuck)
now at the start of find windows code
it will have the string in
stack top and stacktop+4 (esp ,esp+4)
you can set set condition like this
[string [esp]] == "you string"
now if you prefer to set conditional break point some where deep

just change [esp] to [esp+ whatever position] (you need to find it once independent)
but it will remain same no matter what for next n times in your computer
get olly script plugin or get ollymachine plugin
and try to write scripts that do this automatically for you
its kinda involved the best tutor is f7 experiment

thanks again blabberer....I will follow this lead...and yes you are right about the best tutor...however direction from peers is equally important...and direction you gave is just great....
will report on my tries after a while .....l dont want to get infamous with this famous software....

you don't need the debugger in IDA. When IDA disassembles the file does it complain about a hashed import table? If not, then it's probably not packed. You can verify that in IDA by looking under the 'Jump' menu and click 'Jump to segment' on the menu that pops up. Highlight '.idata' and press OK. You'll land in the imports section. In a packed app, this section will be be almost completely wiped out.

Something seem out of order in your trace. For example, why is there a minus sign ( - ) in front of FF in your jmp statements?

7963C39C -FF25 10D66479 JMP DWORD PTR DS:[<&KERNEL32.

there are no such signs anywhere else. I don't know if that's a peculiarity with Ollydebug, or what. But there should be no minus sign in that jump statement. If it's there in your code it will no doubt throw an exception.

Also, given the address range, you seem to be tracing through a system file.
Is this a dump from MSVFW32.DLL, and if so, why would you want to modify it? It seems to me it's a system file. It's highly unlikely a programmer would mess with a system file when adding protection.



you'll find as you get into more complex stuff that WDASM is very limited. I know it's tough to learn an app like IDA or softice, but that's where your bread and butter will be as you progress. I'm not going to say anything negative about Ollydebug because I've never used it.

IDA gives you a lot of advantages for tracing through raw code. It's called an interactive disassembler because you are required to interact with it. That's not easy at first, but as you get used to it, you can squeeze information out of disassemblies that you could never get out of WDASM. Do yourself a favour and take the plunge. Also, try softice and compare it to Ollydebug.

If I'm reading you correctly, that you dumped memory from Ollydebug, then tried to run it through a debugger, it doesn't surprise me you got an error. If you loaded your dump in IDA, provided it would load, and you were tracing visually and came to the following statement:

CALL MSVFW32.7963253C

what would you expect to happen? You need to call MSVFW32.dll but it's not loaded or connected to the dump. You have no where to go. When you load your app in IDA, it loads only the app, not the import DLL's.

When Ollydebug loads an app to debug it, the app loads exactly as it would normally. That means the loader fixes up all the CALL statements like the one above, so the execution sequence can find the DLL. When you dump it, it doesn't dump the DLL as well. It only dumps the CALL to it.

That's because this is not code. Look at the instructions. ADD BH, BH makes little sense in this context and opcodes of 00 00, which translate to:

ADD BYTE PTR DS:[EAX], AL, is not good code. Also, the other instructions are garbage.

The RDATA section doesn't contain code normally. But a disassembler often mistakes it for code and tries to translate ordinary numbers into opcodes. That's what happened below. The FFFF is not meant to be an instruction.

Disassemblers, even good ones like IDA make mistakes. Don't rely on them being accurate. They rely on you to know what is good code and what isn't.

Data usually, but not always aligns on even boundaries like 00000000, 00000004, 00000008, 0000000C. The opcode for XOR can be 33 but it's unlikely that they'd XOR EDX and ESI. So, look for a data boundary, say at 00FFCB4. That would give 00000000, the next boundary is at 00FFCB8, giving
FFFFFFFF. That's what your code is, the data byte FFFFFFFF. Next byte is at 00FFCBC and that's 0C37D600.

If you were in IDA, you could get it to fix that by declaring it unknown and resetting it to data.


It looks like this at 00FFCBF9,
00FFCBF1 33D6 XOR EDX,ESI ; MSVFW32.79630000
00FFCBF3 0000 ADD BYTE PTR DS:[EAX],AL
00FFCBF5 0000 ADD BYTE PTR DS:[EAX],AL
00FFCBF7 00FF ADD BH,BH
00FFCBF9 FFFF ??? ; Unknown command
00FFCBFB FF0C37 DEC DWORD PTR DS:[EDI+ESI]
00FFCBFE D6 SALC
00FFCBFF 0020 ADD BYTE PTR DS:[EAX],AH

waxford
the - in front of jmp table means it was analysed by ollydbg and it doesnt have any valid referance
for ex
olly will put if it finds a valid call that is calling this jmp table


if it is unanalysed or it cant find a referance to the call then it will put


btw ida did not disassemble it correctly coz the f9cbff points to 0xffffffff == -1
and it is shown as in midlle of another instruction so one cant actually go by idas disassembly without using c | u | d whatever it takes to make it disassemble it right

thanks for explanation.



It is an 'interactive' disassembler. I do a lot of fixing up when I use IDA. It gets an amazing amount of stuff right, but with the modern OOP stuff, there's data everywhere. Also, the compiler puts it's own references in the code too, like in a statement such as:

mov eax, [eax+ecx*4+18h]

the value moved to eax is dependent on the variable of [eax + ecx]. Sometimes the values used for eax and ecx are listed as data bytes in the middle of some code. It's a little table of data bytes keys inserted in the code by the compiler. It's little wonder IDA gets messed up from time to time.

Then there's jump tables. You'll find series of doublewords in the middle of code. I find IDA sometimes gets messed up in the middle of that.

Gentlemen
Thnaks for your comments.
First of all I only used IDA first for disassembly, it disassmbled the code and I can see the nice function calls and graphs etc but it could not debug as I only have the IDA freeware. IDA didnt complain the hash table etc. now I have a .idb file from IDA which i am using to see the disassembly. I also made an .asm file and when I tried using WDASM on this .asm file it took hours and ultimately hanged my PC and my w386.swp in windows grew to 800 M. I stopped on that path.

Then I used the Olly...in olly I got that message that I mentioned earlier...I saw the trace and message is coming out of the system file MSVFW32...I didnt touch the system file...nor I am planning to...
I Dumped the code and Olly created the FileDUMP.exe for me...I kept the same offset for the ep...so the ep in Dump is appearing to be on same address...so that i dont have to calculate everything all the time....
Both Dump.exe and Prog.exe are looking the same and throwing the same error. Both on the third line of entry are pointing to an address at .rdata...blaberer says its only loading the address on stack...but my question is why it is loading that address which is in .rdata and olly and IDA both can't identify the instructions.

about the trace the trace is offcourse from the system file because where olly crashed..again I am using Olly as debuger and not IDA...and its loading the .dll when called whether from Dump or PROG.exe.

yes the line at the trace is showing the - sign in fact there is only one line in the trace as it jumps back to some other location in the same dll however if I look around that line in the dll there are several of these kind... such as:

7963C384 -FF25 20D66479 JMP DWORD PTR DS:[<&KERNEL32.K32Thk1632P>
7963C38A -FF25 1CD66479 JMP DWORD PTR DS:[<&KERNEL32.K32Thk1632E>
7963C390 -FF25 18D66479 JMP DWORD PTR DS:[<&KERNEL32.MapSLFix>]
7963C396 -FF25 14D66479 JMP DWORD PTR DS:[<&KERNEL32.UnMapSLFixA>
7963C39C -FF25 10D66479 JMP DWORD PTR DS:[<&KERNEL32.ThunkConnec>
7963C3A2 -FF25 0CD66479 JMP DWORD PTR DS:[<&KERNEL32.SMapLS_IP_E>
7963C3A8 -FF25 08D66479 JMP DWORD PTR DS:[<&KERNEL32.SUnMapLS_IP>
7963C3AE -FF25 04D66479 JMP DWORD PTR DS:[<&KERNEL32.SMapLS_IP_E>
7963C3B4 -FF25 00D66479 JMP DWORD PTR DS:[<&KERNEL32.SUnMapLS_IP>
7963C3BA -FF25 FCD56479 JMP DWORD PTR DS:[<&KERNEL32.SMapLS_IP_E>
7963C3C0 -FF25 F8D56479 JMP DWORD PTR DS:[<&KERNEL32.SUnMapLS_IP>
7963C3C6 -FF25 E8D56479 JMP DWORD PTR DS:[<&KERNEL32.MapLS>]
7963C3CC -FF25 E4D56479 JMP DWORD PTR DS:[<&KERNEL32.UnMapLS>]
7963C3D2 -FF25 34D86479 JMP DWORD PTR DS:[<&WINMM.#3>]
7963C3D8 -FF25 20D86479 JMP DWORD PTR DS:[<&WINMM.#1>]
7963C3DE -FF25 CCD46479 JMP DWORD PTR DS:[<&DCIMAN32.DCICreatePr>; DCIMAN32.DCICreatePrimary
7963C3E4 -FF25 C8D46479 JMP DWORD PTR DS:[<&DCIMAN32.DCIOpenProv>; DCIMAN32.DCIOpenProvider
7963C3EA -FF25 C4D46479 JMP DWORD PTR DS:[<&DCIMAN32.DCIClosePro>; DCIMAN32.DCICloseProvider
7963C3F0 -FF25 C0D46479 JMP DWORD PTR DS:[<&DCIMAN32.DCIDestroy>>; DCIMAN32.DCIDestroy
7963C3F6 -FF25 BCD46479 JMP DWORD PTR DS:[<&DCIMAN32.DCIEndAcces>; DCIMAN32.DCIEndAccess
7963C3FC -FF25 B8D46479 JMP DWORD PTR DS:[<&DCIMAN32.DCIBeginAcc>; DCIMAN32.DCIBeginAccess

My basic thing was to run the sh** step by step and overcome the protection....I am not a professional ....just doing it for my sake as it will be a usefull thing if done...
Again I will brush up my PE header knowledge....however Olly shows nice sections with starts, size, ep, and offsets etc...for all the modules in the memory map....
The independent program runs perfect except that it has a limitation...however Olly throws the error...seems lilke somewhere there is something which is detecting it although I try to hide the olly using the plugin...

Moreover if I try to search the string in IDA (which I see when runing the normal program about the limitation of demo)......I dont find it .....most of the strings shown in the IDA are looking like garbage....

May be program is encrypted and not packed...I am not very sure of the difference between the encrypted code and packed code...to my knowledge its the same thing....isn't?????
Rest assured I will slowly continue on it and try to find the nagging thing...
Thanks again to all for valuable advice..

Seriously, get Peid or some other filescanner before doing else, and find out if it's packed or not. And if it is indeed packed, look for an unpacker or some file dumper. In general, take a quick tour of protools.
It seems you're trying to run at full speed into something you have no idea what is. There's nothing wrong with manually trying to unpack some target - except if you have no idea what you're going into and how you're supposed to get out. You'll just end up wasting your resources way too quick.

Fake

Hi Fake and Other
I just used the PEID on it. Using the hardcore / deep / normal scan it says:
Microsoft Visual C++ 6.0 [Debug]
On external scan it says:
Nothing found [Debug] *

When I click >> >> on the lower right corner it gives following information:
Detected: Nothing found [Debug] *
Scan Mode: Hardcore
Entropy: 5.67 (Not Packed)
EP Check: Not Packed
Fast Check: Not Packed

However when I click PlugIns ->PEID Generic Unpacker it says snaker's tracer works with WINNT platforms...(I have WIN98)

On clicking PlugIns -> CryptoAnalyzer it gives following:
- BASE64 table::00CE65A8 :: 010E65A8
referenced at 010E65A4
- BLOWFISH [sbox] :: 00CE5010 :: 010E5010
Referenced at 00B8BA6A
- PI fraction (NIMBUS / BLOWFISH) :: 00CE4FC8 :: 010E4FC8
Referenced at 00BB8BA4F

Now my questions:
1- It looks like it is not packed...however is it encrypted ????
2- Whats the difference between encrypted code and packed code...if there is any ??
3- If it is encrypted how to proceed ??
4- in PEID readme says
"Disassembler Module..."You can have a quick disassembly of the file loaded in PEiD. Double click to follow JMPs and CALLs and use the Back button to trace back to the original positions. Thanks to Overflow for his code.""

When I give the entry point address in the disassembled code in the PEID nothing happens...the disassembly window (text window I open) is showing listing starting from ep...
All the suggestions are again highly appreciated...
Regards to all of you


3-

Ok, some answers:

1) without actually looking at the thing, it's very hard to say. There might be some uses of encryption in it, but it seems more likely that the thing isn't encrypted.
2) packed code means that the code has been packed in order to save space - that was the idea of it, once, anyway. Since modern day coders can figure out how to make small apps, they can use packers to minimize their apps. Encrypted code means that some kind of encryption has been used to modify the code. This doesn't make the code smaller, however. Packers and encryptors typically have more or less the same effect on the code: it will not be possible to do a disassemble of the app.
3) if it's encrypted or packed, you can try a filedumper or an unpacker. Procdump, LordPe, etc etc etc. What you could consider doing is actually doing a dump of the file, and compare it to what you have on disk. If the dump is a lot bigger, then the file was probably packed. If the code sections match, then the file hasn't been modified.
4) haven't been playing around with that function of peid, so can't help ya.

A few basic pointers: you might not find any strings in the app, and yet that doesn't necessarily mean that it's packed or encrypted. The app might store it's strings in some other manner.
Secondly, if the app relies heavily on some library for the main part of it's functions, then you might have some trouble locating any fun parts. Fishing around in msvc can be quite a bother, for instance.

Btw, since I'm apparently sort of interested, pm the name of the target. If I have some time, maybe I'll look into some of your questions and see if I can get you on your way.

Fake

It's not clear to me what you're trying to do, and I'm no expert. But let me see if I can get you going in a direction which will help you.

What I'd call a fully encrypted program is one like a zip file or rar file. In those files, the bytes are altered in the compression algorithm but they can also be encrypted with a password. So, no matter what you did, you could not read the program with IDA and running either through softice or Olly would not be possible. With those kinds of programs, you need another program to decrypt them. Of course, there are rar files with exe extensions that unpack themselves, but that's another matter.

There are many types of packed programs. The difference between them and the fully encrypted ones, is that packed files must be able to run (execute) on their own. That means they must have a certain amount of legitimate code at the beginning, and IDA should be able to disassemble that code. Somewhere after the good code, the file is compressed and/or encrypted, and other steps are taken to prevent (or try to prevent) unpacking. This includes hashing the import table, compressing the code, and other nasty anti-debugging tricks.

When a packed file runs, it decompresses itself using code built in to the program. This code is called a wrapper, since it wraps around the real application. This code does other things as well, like checking CRC (for modifications) or looking for debuggers. There are different strategies for bypassing that code or defeating it, and you'll find that in the archives.

Is there a chance with the program you're hacking now, that you have changed bytes in it already? Can you start again with a completely fresh copy of the app and see if it still crashes? Better still, will it run on it's own?

It seems the app is using a Sentinel software protection. Does the demo have any "register" or "install key" feature? In that case, you might choose another path.

Fake