First of all, please take the time to read my post before flaming, thanks

I have a target which is protected with a newer version of Pr*tectCD (Version 5, Build 1042). I tried to track down the blacklists and to do so, I had to patch Regmon so that my target won't detect it and exit with some complaint about a debugger running. However, this turned out to be some rather difficult thing!

I searched on the forum and via google and came up with basically two methods of detecting regmon: The window class and the process name. So I started patching...

I did the following:

- renamed regmon.exe
- patched every occurrence of strings containing "regmon" or similar
- patched the device driver (stored in a binary resource and extracted/loaded at runtime), fixed the PE header checksum for the driver, patched the symbolic device name the driver registers
- patched the version info for device driver and regmon.exe
- patched the window class regmon registers
- patched the mutex the driver creates

And still, Pr*tect can detect my regmon! At present, I am out of ideas what to patch next. My hope is that somebody here has already encountered a similar situation and can give me some tips on this matter.

I admit, I am a newbie, and Pr*tectCD is a rather tough target, I fear I am not smart enough to examine Pr*tectCD itself, so I thought I should stick to the blacklists first

Btw, I am using Regmon 6.0.12 (downloaded a few days ago from Sysinternals, so it should be current).

Sidenote: Regmon calculates two random numbers to create the window class for registering it, but fails to seed the random number generator, so it always creates the same window class I found code making use of this so I patched this problem as well, but to no avail (as I mentioned before)...

So at present I am almost back to field one and looking for some input on what to try next.

How feasible is to find/modify/deactivate the regmon DETECTION code in Pr*tectCD app itself instead of modifying regmon?

From what I read about Pr*tectCD and considering me (rather green) skills... not really an option That's why I opted to have a look at the blacklists first. I am reading as much as I can and try to learn from everything I read, however, rome wasn't built in a day
I couldn't find much information about newer Pr*tectCD versions anyway, so I guess I'll have to build up generic skills first, before I can successfully examine Pr*tectCD.

Since you recognize that Rome wasn't built in a day, you would be correct to recognize that reversing skills are also the result of some entended study of the basics of the process. If you do not yet have the assembly language skills to find the code in the protection which is detecting your debugger, that might be a good place to focus your attention at the moment.

Consider that after the detection of a "debugger" (in this case only Regmon) the code (as you describe it) is sending you to an error message. That error message has to be in the code somewhere and the call to that message has to come from somewhere. Maybe this suggests something which can permit you to look at the code besides with a debugger. Maybe IDA could show you some of the code which is being executed and the processes which lead to the message about "detection" of a debugger. Maybe it will also show you the "strings' contained in the program and where they are called from.

Regards,

From what I see in IDA, my target is heavily wrapped and encrypted. There are only two different error messages, and Pr*tectCD always walks through the whole examination process before it complains (or launches the protected target), which makes back-tracking quite difficult. Static analysis won't help much, so I guess I will have to take my SoftICE and patch it to the hilt against detection and try again
Thanks for the suggestions. I know that nobody will do *my* work, but I hoped that I could pick up some extra knowledge from all the skilled people here. (I'll spare you the part about re-inventing the wheel etc. )
I'll keep you updated about my findings.

1. You are not all that green, you serarched info about the problem and did a heluvalot of patching. . .


Another possiblity to explore: there are other programs that have similar functionality to Regmon but are not regmon. Perhaps Pr*tectCD is wired specifically for REgmon, and other apps may go below the radar.

Naides: Thanks for the compliment I'll try to find some alternative for Regmon. BTW, one thing I forgot to mention: Regmon installs a driver at runtime to hook the respective registry APIs, the existence of this driver seems to be harmless. So I went on and patched EB FE at the entrypoint of regmon, launched it and tried once more. No debugger alert again!
My conclusion was that it has to have something to do with any action that Regmon does... Maybe this does ring a bell?

I remember a long time ago seeing a good "debugger detection" piece of code. I can't remember what exactly was being detected (softice or regmon or filemon or whatever), but the approach is what was interesting:
The idea is to look thru the drivers loaded, and scan the first bytes of each, looking for a pattern. Since you had some luck regmon, the protection just might be looking for the presence of specific code in memory, or the presence of a given driver.
If you want to try looking for this, either change the name of the driver, or change some of the driver code (the startup part, likely).
Just a suggestion.

Fake

Fake51: thanks for the suggestion. As it seems, Pr*tectCD does enumerate the drivers (using NtQuerySystemInformation resp. the kernel variant ZwQuerySystemInformation using the value SystemModuleInformation), and I had changed the driver name to counter that. What I didn't try yet is changing the startup part of the driver
Another thing that might be done by Pr*tectCD is checking existing hooks on Ring0. This would be pretty difficult to neutralize I hope it doesn't do that *g*

Hi

That's quite possible/likely. It's fairly easy to detect the ServiceDescriptorTable hooks Regmon uses, as illustrated by KProcCheck by SIG^2 (www.security.org.sg):


Hiding would likely involve hooking the hookers or faking the ServiceDescriptorTable, I suspect an elegant solution has been demonstrated somewhere...

Kayaker

Hi,

To make sure that Pr*tectCD is detecting the Regmon hooks,
try to unhook the kernel by using the sdtrestore tool
described in
http://www.security.org.sg/code/sdtrestore.html
and see how the application will behave.

And post to us the results.

After this, maybe we need try to hide the regmon driver from
the ZwQuerySystemInformation function

Regards,
Opcode

Obviously, Pr*tectCD does something else. I ran my patched regmon.exe, ran sdtrestore, verified that no sdt hooks were detected anymore with KProcCheck and finally ran my target. To my surprise, it complained about a debugger again.

So I guess we are back to putting loops in regmon.exe and try up to where my target will not complain, right?
I changed the driver name to something completely different and SystemModuleInformation output indicates my changes were successful

Hi!

Oops. Even without hooks?
Maybe you should try to hide the
regmon driver from the Object Directory
using the valerino technique:
http://www.rootkit.com/newsread.php?newsid=209

Stupid question:
Do you have another debugger installed?

Yes, even without hooks KProcCheck indicates zero hooked functions.
And no, there is currently no debugger installed on my test system (for good reasons, hehe). I will have a look at the link you posted and post my findings ASAP

This thread is becoming really interesting.

I propose that moderators move this to the TOT board or even better to the mini project area with the goal of making regmon undetectable.

Doh, looks like Ring0 code to me. I don't have a dummy driver skeleton at hand to try that code right now, so this will take some time.

Meanwhile I put another endless loop in the middle of the message processing loop in WinMain() so that it stops after the window appears, and voila, Pr*tectCD complains about a debugger. Maybe it is something connected to the main window of regmon? I'll investigate a bit further on this

Update:
Pr*tectCD's Regmon detection is defeated, finally. In the end, it turned out that there is a certain signature string in regmon.exe which I overlooked. So after doing sort of a "total conversion" of all ansi and unicode strings in the exe and driver parts (and fixing the driver checksum) it is now working.
Thanks for all the valuable contribution and tips!

P.S. My next tool patching project will be Filemon. I am curious whether the same approach will work there as well. I will post my findings soon!

Post more details about this signature string.

Regards,
Opcode

Alright now folks... PAY ATTENTION:

You have an identified Target posted in this Thread. That means NO TARGET SPECIFIC CODE may be posted in this Thread.

I'm not suggesting that the string which is searched for by the Target may not be posted, I am saying that NO CODE which identifies WHERE the Target looks for that string may be posted here. We still have not changed the Rule which prohibits the posting of Target specific Code in these Fprums.

It may be somewhat close to the line here, because preventing the "protection" from recognizing regmon may not, of itself, constitute a "crack" of the protection, but nevertheless, it would violate our current Rules to post the location of the check. If the string from regmon which is detected is posted, that alone should permit others to edit their versions in a manner which prevents detection from this system, but posting it will also likely result in an "update" of the protection to circumvent the circumvention.

Our Rules do permit that the "Target specific" information about the check may be circulated by PM.

Regards,

No problem

This discussion is dead to me.

Regards,
Opcode

The "warning" was intended to be "cautionary" and not "punitive." It is simply to outline what may and what may not be posted "publically." That does NOT mean the "discussion" needs or should end, only that it follow the Rules. I also am curious as to which string it was identifying.

Regards,

Hi JMI,

It's everthing ok!
I just don't want to break any rule
of this very cool forum

Regards,
Opcode

I am fully aware of all these issues, I am not so naive to think that nobody "from the other side" may be reading this forum
The signature however is a plain ascii string and easy to find. I don't know why I overlooked it initially
I have to admit, I am glad that it turned out to be that easy, I know of protections using the method KProcCheck demonstrates. I wouldn't know how to fake an SDT for circumventing such, except for setting up an appropriate exception handler and setting the guard page flag for the memory range where the SDT is located. This may, however, have serious impact on system performance und stability