A few days ago, kioresk managed to come up with a method that allows un-blacklisting of banned accounts in EXECryptor-protected programs. Am talking about serials generated by EC's own licensing algorithm. Analyzing EC's console part in IDA, he found what needs to be modified at the end of EXECryptor_VerifySerialNumber internal API. Without going too much into details (though I know people want this on a golden platter), know that a 1-byte patch is enough to be able to register with banned keys ;)

Today the author of Uninstall Tool decided it's not worth having patchers floating around and (as well as yesterday or any other day in his life) he made a silent update, which brings soft to build 2454. Of course, don't expect fixed bugs - if any - or newly added stuff. This update's sole purpose was to enforce the newly discovered method of un-blacklisting ;)

Long story short, if application is patched properly, once you try to see registration details in About window, Uninstall Tool will crash. Been lurking around trying to figure out what causes this crash, since program runs fine, without complaining. If you don't feel the urge to check that window, then app won't crash and you can work it just fine.

But I am stubborn and my fingers itch. I feel Olly's calling so I start analyzing the fucker. I check the patches I've made, disable some breakpoint-checks in EC (discussed in another article here) and before you know it I find this:

Hehe. lstrcmpW. Hell yea! Guess what. He is checking a buffer of blacklisted names (all his customers) against the buffer that holds the current registration name. If the two strings match, EAX=0, used later to return a wrong address in EC code, thus crashing us.

So, I said to myself - why not trick this? How? Simple, noticed the XOR above (54DC84), did some calculus and figured out how to change that value being XOR-ed with, so that the result in EAX would be the SERIAL buffer. Comparing a buffer with name-strings against a buffer containing my serial will result in EAX!=0 ;)

So I patched it this way:

0054DC84 81F0 30D65D5C XOR EAX,5C5DD630
//XOR-ing EC's generated value in EAX with 5C5DD630 -> 46E010 (which is the serial buffer)

Result - application works, and doesn't whine or crashes. Up yours, developer! :D

chrome://browser/content/browser.xul

What the code does is to load another instance inside the existing one. Pretty neat trick, not to mention you can do it infinitely. Depending on plugins compatibility, this should work on all systems (some people claimed to have crashed their Firefox). Well, not me ;) Here's the result:

Fun fun fun.

I must admit that today I've learned something interesting about EXECryptor. Not only do I love to trace through the endless chunks of virtualized data, I also enjoy the way it handles the code it shields. Tracing from a fully registered application, I managed to tell the program to go in full mode with a few changed bits.

Such as:

MOV EAX,3
MOV ECX,EAX
RET

That would be the replacement of a function that should return a value, value that is later compared and based on which program decides whether to go in trial or registered mode (or if it's expired/not expired). Here's an example:

By following that CALL and patching the code as I mentioned above, the return value, EAX, will change from 0 to 3, thus tricking the stupid check. In similar ways one can patch the application to show the registered status in the About box ;)

Pretty neat. Anyway, this has been fun enough, so I'm going to post the patch for the new "silent" update. Author thinks he can evade reversers. Not with EXECryptor you won't :)

Enjoy!

[ Download] » Uninstall Tool v2.3.1 (build 2427) » Size - 70 KB

Was playing today with my favorite program ever - Uninstall Tool - attempting to get to the spot where, if patched, file CRC would be bypassed. Everyone (well, reversers) knows that in this protector's case, a quick breakpoint on _lopen API, combined with a little tracing, would lead you to a memory spot where a comparison is made. If open file's handle is valid, EC starts to check for modifications. How, it compares active memory with raw code from file. But what if handle is invalid? If that happens, we bypassed CRC checking of file.

To show an example, this is the spot where patching Uninstall Tool (latest, 2.3.1) can be achieved.

If you look at 552C79, you will notice that [EBP-1C] holds the file's handle and it's compared to -1 (invalid handle).

Simply changing that code to:

CMP EAX,EAX
NOP
NOP

You will notice that EC will not whine if file CRC has been changed.

---

Back to our discussion, was trying to get to that location, by simple bp _lopen. Well, to my surprise, author enabled API-checks. And this is especially performed on all critical APIs that may be used to exploit the target. If, say, by any chance, you break on an API, and EC crashes, then you know for sure that API is used for something trivial. All that remains is for you to dig deeper and see what's it used for ;)

Moving on, I wanted to know how the fucker catches me. Normal F2 breakpoints (0xCC) and hardware breakpoints (on execute) didn't lead me anywhere. EC crashed leaving me pissed. But then I started thinking - what if I use memory breakpoints to see what accesses this API? And so I did..

That is _lopen API on XP SP2:

a. Olly > Ctrl+G > _lopen > Enter.
b. Right-click, Breakpoint > Memory, on access.
c. Then Shift+F9.

I got this:

Now, based on the two pictures above, especially the 2nd one, EC reads the APIs, copies the first DWORD it finds there, and performs SHR operations on bytes, to check if there's any 0xCC or 0xCD2E (INT 2E breakpoint). So, let's catch the fucker :) I restarted application, went to those two addresses: 591B1A and 5A2E80, and set two conditional breakpoints:

Shift+F2 > eax == 7C85EA30 (that's our condition, break if _lopen API is read)

Set a regular break on _lopen (F2) and then I ran the target. Surprise..

So, one way to defeat the son of a gun is to either patch that CMP or the JNZ you see below it. If we are to trace the code further, by following that JMP at 5A2E8E, we'll find this:

INT 2E, anyone? =))

Anyway, this is how I chose to patch it (see below). Since that JNZ is always taken, when EAX != 0x66, let's force it to always jump there, by changing the CMP ;)

So, there you have it folks, a way to defeat the freaking breakpoint checks EXECryptor comes bundled with. Good luck and happy trails :)

Therefore, for those of you who are my countryman, I bring you this nifty subtitle. The movie itself is rather a comedy, with tons of well placed nice jokes and catchy phrases. The priest is the culprit of it all :)

[ Download] » ROSub » Size - 26 KB

And since I always have a "quarrel" with software authors that are happy to preserve their methods, I have to add this tool has been using EXECryptor protection software ever since it was first released. Mostly for its obfuscation capabilities, as well as for its licensing manager.

To be brief, here's what tricks I've defeated in the protector:

a. file and memory CRC;
b. disabling trial/clock manipulations;
c. removing a top-bar and the closing program nags;

My main goal is the sole protection (EXECryptor) and not the software itself. Therefore, the patcher below is generated out of pure love and sympathy for EC. Of course, done for educational purposes ONLY!

[ Download] » Uninstall Tool patch » Size - 73 KB | Pass: www.appznet.eu.tt

I've been cruising the internet in search for an answer to one of the problems I've long had with µTorrent - disk overloading. Every time download speed walked up to 9-10 MB/s, my HDD started "fumigating" - so to speak :) Found my answers, but was obliged to use an old version of this program. The developers offer us a new beta, it seems - 1.8 alpha 8205 - which has a few reported bugs fixed as well as bringing back the options I needed (from old versions I didn't want to use).

Long story short, to avoid that nasty disk overloading, you need enabling/disabling a few options as instructed in the picture below. In order to reach that location, open up main µTorrent GUI and follow this path:

Options » Preferences (Ctrl+P) » Advanced (expand tree) » Disk Cache

The options you see highlighted in a red circle are most likely the "culprits" that cause overloading. Setting up the options as you see them in the picture above seems to have resolved that issue for me. Now I can happily do other "chores" while downloading torrents - such as Firefox-ing.

Enjoy ;)

[ Download] » µTorrent 1.8 Alpha 8205 » Size - 260 KB

I've been doing the same patches for 6-7 versions now. Hopefully there will be a tougher challenge in the new beta. These being said, enjoy the new release. Everything has been done for educational purposes only and for my enjoyment, mostly! Therefore, google is your friend in the quest to finding the version this patch applies to :)

[ Download] » FlashFXP patch » Size - 63 KB | Pass: www.appznet.eu.tt

As for the trainer, here's how main GUI looks like (nothing special):

[ How to use]

a] Run the game.
b] Double click on the trainer to run it.
c] Wait for the status field to display "Ready for action..."
d] Press the keys for their designed effects.

Note: all options are toggled ON/OFF with the same key !

Trainer has been tested on all game versions listed on this page and is working 100%!

[ Detailed options]

F10 - Freeze puzzle timer ON/OFF
For those of you that like to take your time when solving this game's puzzles :)

[ Download] » Dreamfall Trainer » Size - 51 KB