Hi,

I'm currently unpacking an Themida proctected dll which is a plugin in a big framework. To be honest I'm not exactly trying to unpacking in first instance because I'm more interested in beating the license protection of the dll.

I hope that a necessary sub routine of license check is not virutalized and therefore it could be possible to beat it with a loader approach.

What I'm currently trying it breaking hooking CreateFileA with a filter for the license file name. This works like a charm. I inserted also a MessageBox which is pausing the dll execution until i press ok. Right after the MessageBox call i have inserted an INT 3.

I successfully was able to attach with my debugger, but the INT 3 is never executed. Something seems to interfere somewhere.

Either the debugger attachment is detected or the event when the debugger catches the INT 3.

Any solutions to detect the origin of the problem without the use of ring0.

Thanks and a good new year,

OHPen

Debugger attaching can be detected through hooking of NtContinue - see e.g. this OllyDbg plugin for a countermeasure: http://www.openrce.org/downloads/details/177/AttachAnyway

As far as I know a program cannot detect (from ring 3) that a debugger is catching its exceptions - Windows passes the exception to the debugger first, and if the debugger says to go ahead it passes it to the program as if there had been no debugger interference.

If your int3 just doesn't work out, you can always try placing a hardware breakpoint on the "ret" of MessageBoxA after attaching. Don't forget to remove it again after breaking because the program could be doing hardware breakpoint detection.

Hey _arc,

thank you for your answer. I'm sure its not a NtContinue-Hook. I check it already. It must be something else. I will try what you suggested with the MessageBox-Breakpoint.

Regards,

OHPen.

emm, Themida loads copy of main sys-dlls from directly from files, so you will miss most your BPs;
but not alls!

hey,

i know what is themida doing but not how. first thing is, it detects the attaching process of olly and the second is that it catches all int 3s before olly is getting control.

probably by the use of a driver, even if i didn't saw a driver to be loaded. somehow i have to determine how themida is doing it. it pretty interesting.

regards,

OHPen

i know that former versions of themida used to manually mapped kernel32.dll
in protected address space but my target seems to manually map ntdll.dll into my targets address space.

can anybody confirm that technique with themida ?

regards,
OHPen

I believe Themida maps kernel32, ntdll, advapi32, and user32. Not 100% sure though. Try bping CreateFile in Olly and see what's happening.

@rendari: i already tried to filter CreateFile access for these files. Although NTDLL is opened only a view bytes are read not the whole file, what indicates that this access is not intended to copy the file to memory using this simple way. This is using a different way to map these dlls.

I'm currently writting a driver to detect how temida is manually mapping the mentioned dlls. hope this will result in success.

regards,
OHPen

Yeah, weird. I looked at it further due to this thread and can't figure out how it's doing it either. In my case, in some targets I have Themida doesn't even map the DLLs to memory. Might have to do with the fact that I'm on Vista? Will look into it further; I have extensive notes on its import routine, so I will be able to narrow down where it loads an API into one of the redirect buffs.