I've worked a number of programs and recently I ran into the first one that I can't do anything with.
It looks like I have to unpack it....this would be my first. This program also uses many anti-debugging tricks.

I've searched the web and found a recent article about an older version of this very program and how to manually unpack it....
ARTEAM EZINE ISSUE III rev.1 Article 2.
Great magazine btw, very interesting articles and information!

I'd like to start out by learning how to find the OEP for this program.

The Article by CondZero explained how to load the program, goto the executable modules, list the names in kernel32.dll,
and put a BP on GetModuleHandleA API. Run the program and wait for the break on the API. Then open up the memory map
and place a break on the Code section of the program. Run again, break on the API. Run again and break on the OEP.

A few questions about this process...

Why BP on GetModuleHandleA ?
Should other APIs be tried, which ones ?

I suspect the program is unpacked, then a break on the api would allow you to place a BP on the code section so when the
program first starts to execute anything in that section it is most likely the beginning of the program, the OEP.
Does this method usually work ?

The program uses Anti-Debugging tricks. Even when I start it first to try and attach to it, the second I start OllyDbg the
program shuts down. I've tried many of the plugins to hide OllyDbg but nothing works.
Can anyone suggest a plugin or method that would work ?

Thanks !

> Why BP on GetModuleHandleA ?

I think it's because that API is used by a large majority of programs early in their (unpacked) execution, just for general use. You usually need to backtrace and "guess" the OEP.
Oh, rereading your post it sounds like the packer itself is using GetModuleHandleA. Same idea, but it sounds like in the tut that there is a foreknowledge that that API is used by the packer and is useful, maybe used after the main unpacking. Heck, break on VirtuallAlloc if you want to examine the import resolution done by some packers, break on VirtualFree when it's done. There are several packer specific tricks I guess you could use.


For finding the OEP, OllyBone is often useful:

http://www.woodmann.com/collaborative/tools/OllyBonE

There's also the "ESP trick" in Olly which again often works, depending on the packer. This article describes it:

http://securitylabs.websense.com/content/Blogs/2927.aspx


Not sure about the debugger detection, if plugins like Olly Advanced don't work you may have to trace it and find which of the 3 million detections methods it uses..

Excellent information, thanks !

I did a little snooping around today and found the following...

CPU Dump
Address Hex dump ASCII
00A27243 4F 4C 4C 59|44 42 47 00|47 42 44 59|4C 4C 4F 00| OLLYDBG.GBDYLLO.
00A27253 70 65 64 69|79 30 36 pediy06

The program finds OllyDbg very quickly, even if I try to start OllyDbg
after the program starts and try to attach. I'm sure the above text
has a little to do with that, but my question is... what is "pediy06" ?
That text is also part of the same routine. Searching leads me to
a chinese bbs/forums site. Anyone know what "pediy06" is ?

Thanks

peid?

The protection seems to be looking for window class names. You can modify Olly to use custom class names. Some of the hacked Olly versions probably already do that, but if you might be interested in a method to do that:

Disasm Olly in IDA, click on CreateWindowExA under Imports and modify lpClassName for any of the windows that might be detected. Be sure to set Options/Cross References/Number of displayed xrefs in IDA to a suitably high number (i.e. 20) to display them all.

For the main Olly window, click on the first WinMain XREF you encounter under CreateWindowExA. You'll see lpClassName is referenced as an offset (lea ecx, [esi+1832h]). Highlight the "ESI" and scan back to the start of the function (WinMain) to find the starting offset of the block ESI points to (004B59E6). Add 1832h and you will see the main class name string (OLLYDBG).
Change the string, check it with Spy++, and you've now hidden Olly from that one particular detection method.

Another thing that you might want to try is LordPE, or PEID. So that you could identify the packer. It might be that you could find an essay about the new version of the packer, and how to unpack it as well. That might save you a little time.

I definitly will have to try that...downloading IDA pro now.

All the plugins I've tried are not working.
Can you recommend a good 'hidden' olly version & link ?
I went to exetools.com and found ollydrx-110u.rar, but rapidshare.com sucks !

I think the proper Tools will be the key with this specific program.

Trying to get through the anti-debugging stuff first. What a pain !
I've never run into anything this hard, atleast for me....might be easy
for someone with more experience. No Fing way I'm giving up. I havn't
lost a fight yet and this is not gonna be the first !

Did a little more snooping around today...

When I placed a bp on GetModuleHandleA the program would crash sooner then normal.
So... I placed a hardware rw access bp on the first byte of GetModuleHandleA. Sure enough
I broke on a routine that was checking a number of APIs...

APIs Checked in the following order from start.
---------------------------------------------

kernel32.LoadLibraryA
kernel32.LoadLibraryA
kernel32.GetLocalTime
kernel32.GetModuleHandleA
USER32.MessageBoxExA
ADVAPI32.RegCreateKeyA
ADVAPI32.RegFlushKey
ADVAPI32.something?(below)
Address Hex dump Command Comments
77DDEBE7 6A 2C PUSH 2C
77DDEBE9 68 28EDDD77 PUSH ADVAPI32.77DDED28
77DDEBEE E8 267DFFFF CALL 77DD6919
ADVAPI32.RegCloseKey
AVDAPI32.RegQueryValueExA
kernel32.CreateFileA
kernel32.GetCommandLineA
kernel32.SetEvent
kernel32.WaitForSingleObject
kernel32.CreateEventA
kernel32.LoadLibraryA
kernel32.FreeLibrary
kernel32.GetProcAddress
kernel32.GetEnvironmentVariableA
USER32.wsprintfA
kernel32.GetVersion
kernel32.CreateFileA
kernel32.ExitProcess
kernel32.DeviceIoControl
kernel32.RegOpenKeyA
kernel32.CloseHandle
kernel32.Sleep
kernel32.GetVersionExA
ADVAPI32.RegCloseKey
ADVAPI32.RegQueryValueExA

Illegal instruction exception
(shift-f9 keeps me going)

kernel32.Sleep
kernel32.CreateFileA
kernel32.GetFileSize
kernel32.VirtualAlloc
kernel32.something?(below)
Address Hex dump Command Comments
7C80180E 6A 20 PUSH 20 ; BOOL kernel32.ReadFile(hFile,Buffer,Size,pBytesRead,pOverlapped)
7C801810 68 D89B807C PUSH kernel32.7C809BD8
7C801815 E8 B10C0000 CALL 7C8024CB
kernel32.GetVersionExA
kernel32.GetSystemDirectoryA
kernel32.CloseHandle
kernel32.Process32Next
kernel32.IsBadReadPtr
ntdll.ZwQueryInformationProcess
kernel32.lstrcmpiA "ntice.sys" text in stack
kernel32.IsBadReadPtr
kernel32.lstrcmpiA "iceext.sys" text in stack
kernel32.lstrsmpiA "Syser.sys" text in stack
kernel32.lstrcmpiA "HanOlly.sys" text in stack
kernel32.lstrcmpiA "extrem.sys" text in stack
kernel32.lstrcmpiA "FRDTSC.SYS" text in stack

Then a message box pops up,
"A debugger has been found running in your system..."

Ok, so far so good.... tomorrow I'll have to look past the last kernel32.lstrcmpiA
and try to find what is making it display the "debugger found" message box.

I would like to ask a few questions regarding all this...

I notice that hardware breakpoints work great and rarely interfere with the normal
operation of a program..... but why ? and why only 4 in OllyDbg ?

Are checking APIs normal, or is it some sort of reversing 'road bump' ?

Hardware breakpoints are just that, HARDWARE ones. They are set using special registers in the X86 family of processors. That being the case, no code in the application has to change to enable them. Whereas your "normal" breakpoint is achieved by changing the 1st byte at the target break location to a "$CC", which is a special opcode that is the "breakpoint command" (INT 3). Most packers, and protectors and the like that act as a loader will register themselves as the exception handler so that they get notified when a normal exception occurs. This is what happens when the processor executes this $CC opcode. It causes an exception to be thrown, which the protector catches, and knows that you're inside messing around. Whereas the hardware breakpoints use a different mechanism for signaling, and thus are more difficult for the protector to catch.

Now, why are there 4? Because that's what the processor supports. They are hardware registers, and that's how many there are.

Lastly, as for checking the APIs. One possible reason for doing this is to make sure that they aren't "hooked". (One would hook an API so that you could either alter it's functionality, or it could be used as a pseudo breakpoint. Think of it this way. If you knew that the first thing that the program did when it started was a specific call, you could hook that call, and when it gets called, that's your alert that control has been transferred to the protected program, and you could look at the return address, and have an idea where the initial entry point was, or if you were super studly, you might even write a tool that dumps the protected program to disk, and tie it in with a hooked API call.) So, this is yet another attack vector that they're trying to cover.

Hope this all makes sense!

Yes, it does.
I'm sure the information here will help others also.

I found the program I'm working on is Themida Professional protected.
From everything I've read, Themida is extreamly hard to work through for
the average reverser. I have found a hacked version of Olly called RAMODBG
or "OllyDbg RAMODBG changed for Themida". So far its worked great.
I am able to run the program without any issues.

I've been reading about Themida at oreans.com. Looks like its going to be
a challenge. I'm a little worried about running into EntryPoint Obfuscation
or any of the other methods used.

I'm in the same area, learning how to unpack Themida.
Although I've been able to make fair process dumps in the past.
Trying to get a better understanding this time so I can get fixed API, etc.

Out of accident I found it 's using the "FindWindowA" API to look for some common names (logically by class name as it's easier to change a window title/name):

FindWindowA: N: "", C: "OLLYDBG" R: 011F78E5
FindWindowA: N: "", C: "GBDYLLO" R: 011F7ABB
FindWindowA: N: "", C: "pediy06" R: 011F7CD0
FindWindowA: N: "", C: "OLLYDBG" R: 011F78E5
FindWindowA: N: "", C: "GBDYLLO" R: 011F7ABB
FindWindowA: N: "", C: "pediy06" R: 011F7CD0
FindWindowA: N: "", C: "Regmonclass"
FindWindowA: N: "", C: "18467-41"
FindWindowA: N: "", C: "Filemonclass"

Heh according to:
http://www.enigmaprotector.com/en/tutorials/tutorial2.html (some sort of protection product)
"18467-41" is a class name used by a lot of sysinternals tools apparently.

I like this and your post above. Get me thinking of making my own unpacker (dumper at least) that starts off by virtualizing some things.

Hurray, I was able to find the OEP !
(now I can sleep at night)

I found it using a modified version of Olly, Plugins, and a Script.
The problem with this is that I havn't learned very much about how and why everything worked, although
its definitly better then not having the OEP. I have more questions now, then before finding the OEP !

Next steps I think are....
Fixing the API Virtual Machine, IAT Repair, and any Anti-Dumping.
I'm pretty sure I understand, but could someone explain briefly what each of those mean, and why they need to be fixed ?

After using the script I was able to put a hwbp on the oep, restart and run, then break on the OEP.
Are the next steps (fixing api/iat and anti-dumping) done AFTER breaking on the OEP ?
I guess what I'm saying is that I don't understand the order of the steps involved.

I also heard it "has cisc VM which saves you dumpign VM. Which can be really annoying."
Why would cisc VM save me from dumping VM ?