Kayaker
December 6th, 2006, 21:56
Well this sucks. I tried splitting a thread but ended up losing this one. Actually vBulletin doesn't have a SplitThread function so I did a copy/merge and still managed to f0rk it up.
Soo.. here is an ugly paste of the original thread, sorry 'bout that folks
Kayaker
December 6th, 2006, 22:00
From original poster naides:
I am placing this post in the newbie forum because that is the place it belongs. Primitive but irritating.
I am trying to defeat the protection of a rather popular application, written by a remarkable Russian coder and reverser. I have the distinct impression he frequents this board.
If that is the case, Yuri: Nothing personal. I just took the personal challenge of breaking the protection of your excellent program.
I resume,
I traced the "authorized" state of the program to a single key in the registry: an encrypted 256 binary key dictates the name, license number and the number of days the license is valid. The key is unique for every computer.
I am trying to trace the program reading, decrypting and implementing that license.
The program itself is encrypted/packed with a proprietary method. disassembly produces garbage.
For now I just would like to locate the code that reads the registry key and take it from there.
The program manages to fool RegMon. I know it reads the key, or lack of there off and RegMon does not catch it.
I can attach the main exe to Ollydbg, but the regular ADVAPI functions (RegGetKeyEx and so on) produce a lot of false positives and the program manages to read the registry bypassing my API BP
What I would like to ask from the board is a comprehensive list of registry key reading APIs, including non-documented API or strategies to read the registry without using classical ADVAPI APIs. Perhaps a suggestion for a alternative strategy to catch the program reading the key.
Also, the program uses Ring0, .sys modules. Could they read the Registry in a fashion that is invisible to Olly??
I tried placing ADVAPI BP with SoftIce, but the rate of false positives makes it quite tedious.
Well. Thank you in advance. If anybody wants to know what program I am talking about and other preliminary info please contact me via PM
evlncrn8
if it goes ring 0... of course it can do stuff olly cant see... olly is a ring 3 debugger, not a ring 0 one.. if its ring 0 driver based its probably using the NtOpenKey etc api's
Bonehead Kayaker
I'm curious as to the behaviour of Regmon, does it not log the registry accesses by the target *only*, or does it not log *any* accesses from other programs at the same time? That might be hard to confirm absolutely.
The reason I ask is.. Regmon *will* normally catch driver accesses to the registry using the standard ring0 API's, ZwOpenKey, etc. I did a little test to make sure and it all works according to plan. Regmon now uses CmRegisterCallback to register a registry callback hook. If you trace into say RegOpenKeyEx from usermode or ZwOpenKey from kernelmode when Regmon is active, you will enter the Regmon driver callback routine itself, which will eventually call NtOpenKey.
The CmRegisterCallback interface is just a polite way of doing registry SSDT Service Descriptor Table hooks now. If you check the SSDT table while Regmon is active you'll see a number of the entries point to addresses outside of ntoskrnl address space, i.e. the Regmon callback routines themselves.
Since that is the case, it could be possible that a driver might check the SSDT for these hooked registry service entries and replace them with the original addresses temporarily, especially if it can confirm Regmon is active in other ways. It's unlikely this is actually the case, that's pretty anti-rootkittenish behaviour, but I can see it as a programming possibility. Through a driver an app could temporarily "turn off" Regmon logging while it's doing sensitive accesses it wants to keep prying eyes away from..
One last possibility.. if ring0 registry API's were called from a system thread (PsCreateSystemThread), rather than from a normal driver thread, it might fool Regmon. At the very least Regmon wouldn't know which application is making the registry access, so even if it was logged it might be logged under "system" instead of the application name you were expecting. Such a system thread could still communicate with the original driver or even the usermode application itself to pass information. I haven't tested this yet but might do so for fun later.
blabberer - reply split to new thread
LLXX
Tried renaming RegMon.exe?
I know several programs that detect and specifically avoid it.
Maximus
have you checked if it spawn other executables or COM/OLE modules with separate process space? That would fool RegMon by simply place keys over another voice.
edit----
it might also check for driver's presence, even if it's not a good practice. I noted sometime TheMida catches regmon even if it's not in memory during the load phase...
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.