PG simply does not work

Hey... check this out.

Install PG, run Regmon.exe (from sysinternals) and set it as a protected app. Run a program called Video Link Parser (vlprs.exe, from Zheadware).

Vlprs.exe shuts down the protected app everytime. No change or setting in PG prevents this from happening.

I want to see what this app is doing to my registery. The guys at Zheadware don't want us to find out so their code shuts down sysinternal's Regmon and Filemon utilities.

So much for PG guard..... time to delete it from my system come up with another way to sandbox vlprs.exe.

 

maybe you did not have PG setup right.. maybe PG was in learning mode, or something..

PG works for me.. recently, my av had a false-positive and was trying to close and remove a program that was protected by PG, but it couldn't.. while i was fooling around, trying to deal with the false-positive issue, i temporarily disabled PG's protection, and then, while PG's protection was disabled, my av closed and deleted the program.. (i wasn't thinking about that happening when i disabled PG's protection )

 

I can confirm this.

PG set to full protection (full version), only allowed the pgm to run.



During the installation of this pgm, no drivers where installed, services are blocked from installing drivers, and PG was set to block. So unless this pgm can bypass PG alltogether (on installation), then no drivers where installed.
Very strange, this certainly needs to be looked at.

EDIT
Have checked the system (various pgms/utilities), no drivers where installed. (well nothing showing up to now)
I am currently running PG3.3 beta4(full version)
As a side note, there is another executable within this pgm,....avsrch.exe, which also terminates regmon.

 

Thanks for the report, I can confirm your findings but I can't give you much feedback yet as there's a lot of testing still to do. This is quite an interesting problem and I'm not sure if any other HIPS-style programs can protect against it yet - our initial tests suggest not. The program (VLPRS.EXE) is protected by an anti-debug/anti-monitor system called ICE, and it's ICE that's doing the killing (not the main program itself). It's very heavily protected though (commercial-grade protection) which makes analysis a lot slower and more difficult, especially due to the large size of both the program and the ICE components, but we're getting there.
It'll be a fun weekend no doubt ...

 

I will be interested if anybody can try AntiHook here, just to see whether it can stop it or not.

 

Have just installed to check,....same result.

 

After running the pgm within a sandbox, and checking the dll`s loaded/executed, it appears the protection is similar to this:- http://www.siskinsoft.com/protector/introduct.html I did have a play, but attempts to "intervene" caused the pgm to alert "application was modified illegally" ...ooopps. This as got me very interested though, but probably beyond the scope of the forum.

 

Thanks Stem!

 

There are a lot of different executable compressors and protectors out there, but ACProtect doesn't terminate analysis/debugging tools like ICE does so it's not really related to this problem (ACProtected programs simply refuse to run if they detect debugging tools).

[edit] I've just completed my analysis of ICE and know exactly what it's doing now so with any luck we'll have a new beta of PG available early in the week.
Enjoy the rest of the weekend,
Wayne

 

sounds like the 3.3 beta testing phase may just have been extended again

 

'some made up name',

Only once more, and it'll only set back the non-beta release by a week so it's not much of a problem - not fixing it would certainly be a bigger problem.

Best regards,
Wayne

 

Thanks for the info, it shows how much I still have to learn, (I will be digging for quite some time)

Excellent, well done.
Best Regards
Stem

 

So Wayne it is just to kill one protection. I wonder how many might be more existing in commercial products that PG might not kill. Just a thought!
BTW, I can well understand no software can be 100% in any regard.

 

"I've just completed my analysis of ICE and know exactly what it's doing now"

It would be quite helpful to disclose your findings. Is this merely a new termination method or does it also allow code injection or the like?

 

I agree. The latter would be quite scary, indeed.

 

I know this is a bit off topic ..
But ICE seams to target Regmon on a window caption basis.
A bit of hex editing of regmon.exe plus ressource hacker get arround the limitation pretty easily.


On another note i confirm that Appdefend does not handle the forced close of regmon. However appdenfend does not handle window messaging so it may be normal.

 

aigle,

Actually this is the first such problem of its kind for almost two years now - pretty much every update to ProcessGuard has been feature enhancements, there have only been a couple of required security updates. It would be very unwise to assume that simply because one new trick works that many more will - there are very few ways to terminate processes, and our freeware APT program demonstrates practically all of them (both for security and testing purposes). We're aiming at updating PG this week so that it's resistant to this new trick, so even though a new trick has come along it has only been effective for a few days before we've been able to counter it. We have the upper hand.

",.-" (sorry, i'm not sure how to pronounce that):

That is a programming/reverse engineering question, and is not in the realm of general ProcessGuard support - even if I did disclose my findings most people wouldn't understand it as it's something only developers/analysts would understand. I'm sure developers of other programs trying to do what PG does would also like it if I disclosed my findings to save them some work ...
To our valued ProcessGuard customers who're curious about this - yes I now know exactly what tricks ICE uses, I have spent all of last night and today analysing it (it's a commercial software protection system so it is heavily resistant to debuggers/disassemblers which makes things a lot harder for analysts like myself), and I know its internal operations quite intimately now, so it shouldn't be a problem to implement countermeasures in ProcessGuard for this.

f3x,

I can confirm that ICE uses both the window caption and window class to initially identify programs such as Regmon. It has 24 different programs in its 'blacklist', as can be seen when they're decrypted on the stack (ICE uses the RC4 algorithm for its encryption/decryption). For obvious reasons though I cannot list the programs here.

Best regards,
Wayne

 

Oh man ...

1.
I am not Jason or competitor xyz but Nautilus.

,.- is pronounced "Gunner" (former Ratboard members will remember the name ;-)

2.
One day of work...big asset to disclose? You are also offering freeware right?

3.
We are talking about http://www.ionworx.com/IceLicense.html

Description :

This procedure allow you to protect your code against debugger or tracer and monitors (like regmon, filemon, others), it's antidebugging enveloppe inside your code.

Just need to call procedure like : IceLicense1.AntiTrace;

Example :

procedure TForm1.BitBtn2Click(Sender: TObject);
begin
IceLicense1.Antitrace; // Antidebugging Protection
ShowMessage('You can put this protection anywhere in your code');
end;

Can't be so difficult to analyze this component because you can download it from the developers website ...


4.
IceLicense Protection contains special code to defeat most debuggers and monitors including W32Dasm, SoftIce, TRW 2000, Turbo Debugger, Sourcer, Filemon, ExeSpy, ResSpy, RegMon and Memory Monitor which are all tools in the crackers toolkit. Big secret (see website)?

5.
I did not ask for support or any detailed explanation. My only question was whether this method also allows for code injection or other dangerous stuff. Or is it just a message based kill method (i.e., are we talking about an important issue or not)? But never mind ...

6.
Another stupid question instead: Frequently, people accuse me of prohibited reverse engineering. Do you have a tip for me how to justify this behaviour? *g*

 

Unfortunately my friend just because you can download something from the developers website doesn't mean it's easier to analyse, nor does it make the analysis of many thousands of lines of code any easier than if you had've downloaded it from anywhere else.

We're talking about commercial-grade software protection here -- protected programs that are designed to be hard to analyse -- the VLPRS.EXE program that the original poster of this thread (Joe) effectively has exactly the same strength as the original program from the developer (the Ionworx ICE system , because the developer is supplying all the security), so there is very little difference in analysing VLPRS.EXE as opposed to the program from the developers website - analysing VLPRS.EXE is virtually the same as analysing the Ionworx program itself because at the end of the day they're both simply two normal 32-bit Windows programs that have been protected by the same protection system - ICE in this case.

The component/wrapper in question is a professional anti-debug/anti-analysis system - it is designed to prevent people from analysing the real code (mainly to thwart would-be crackers), and when implemented correctly is generally strong enough to prevent the vast majority of would-be crackers/analysts. That is why it wasn't easy to figure out which termination trick it was using - there were so many anti-debug tricks that I had to defeat first before I even got up to the stage of analyzing its real code to check for terminations.

That is just the Delphi (Pascal) source code that developers use when implementing ICE protection before compiling - there is a big difference between using protection software and analyzing it - using it has little to do with the actual analysis of the binary code from the compiled executable, and that itself is encased in various other anti-debug routines anyway so even getting to that routine isn't as trivial as you might think - feel free to disassemble it yourself.

Best regards,
Wayne

 

Wayne:

Never mind. This wanna-be anti-crack protection system is so damn stupid that it kills your browser if you open the following website:

http://www.pc-magazin.de/downloads/...odus=suche&such=InCtrl 5&DTT_filter=&sfiles=1

Maybe you should not even THINK about InCtrl ... *lol*

But please do something about it...protect my browser ;-))

Btw.: my reversing question was serious. It can't be true that you and me did something illegal. Did you ever talk to a lawyer about this issue? Most AV/AT software seem to be very confident that they are protected by some rule of reason, right?

 

Yes there's a fine line between maintaining software integrity and going overboard -- the more a program tries to protect itself the more problems its legitimate users will encounter, which obviously isn't a good thing. It's something of a balancing act - the developer must protect the software for the sake of him/herself as well as his/her customers, but at the same time not implement too many protections which might drive the customer crazy.

ICE is an interesting example of where extreme protection has possibly been taken a little bit too far (although some may argue that too far is never enough) - most protection systems simply prevent the program from running when a program like Regmon is detected, whereas ICE goes one step further and actually tries to terminate the detected 'hostile' process. Whether or not this is ethical/moral is your personal decision and beyond the realm of this thread. From a security/analytical point of view it doesn't matter if a protection system terminates a potential target such as Regmon - such checks are easily defeated so they only offer security against amateur crackers, so this additional step of terminating processes like Regmon offers very little extra security to the program being protected.

ProcessGuard does offer a LOT of additional protection to any web browser, see here for more info:
http://www.firewallleaktester.com/pg.htm
(They've found through their own independent testing that ProcessGuard protects against the vast majority of web browser attacks better than any other program they've tested).

Each country has its own laws obviously and you should get on good terms with an IT lawyer if you're serious about these matters or work in the industry (I'm very happy with mine and he's provided insight into things I hadn't even thought about before), but generally speaking it is not illegal to disassemble/debug a program, even if it is stated so in the end user agreement that such an act is illegal. It's a clause that every developer adds to their EULA's (as a deterent) but never follows up on in court, because it simply will not hold up in court. If you distribute modified versions of the program, or serials/keyfiles etc, then yes that IS illegal, but disassembly/debugging/analysis in itself is only as illegal as reading a book.

 

Keep up the good work Wayne. We don't want to cause any harm. Just don't want to recieve any.

 

Yes ... A bit too far indeed.
It closed my hex editor because it has the filename in it's caption.
Eg if i edit a file called regmon .exe
It's say UltraEdit .... C:/regmon.exe
Wich is enougth to triger to kill.

I guess it's the same thing with the one who had a browser problem.
Without giving too much detail on what you consider to be "professional secret" would you at least categorise the kill method ?

Eg
windows messaging / user interaction simmulation
undocumented windows API designed to kill process
bug in a that would result in the process being killed
code injection
Kernel / memory manipulation

 

I have a problem when a program terminates, spies or modifies memory outside of its own memory space without my permission.

Sure, I can choose to not run or use programs that use ICE. The problem with this is that there will eventually be unwelcome trojans created that will use similar methods to shut down or disable malware/virus protection programs. It is only a matter of time.

VLPRS.EXE was shutting down filemon from a non admin user login. I was troubleshooting a problem on one of my daughters computers from a admin account and could not figure out what file handle was open to a DLL in ./local/temp. (I suspected malware) VLPRS.EXE was left running by the non admin user and was shutting down filemon when run as admin.

 

Also reported to the Core Force forum.