How can the serious protection vendors protect against spoofing DLLs?

I mean, sure, you can return signatures and authentication and whatnot, but ultimately these are just more of the good guy/bad guy checks, right?

Indeed you are correct - cracking is basically just changing the flow of the program to where you want it to go. Encryptions are also easily defeated, as for the code to run, it must be eventually decrypted.

You should've realised by now that all software protection systems are based on a single binary decision - "good guy/bad guy checks", as you said. As it is your machine that it is running on, your processor, you decide where you want it to flow. "Change its flow and away you go..."

If "work" is done inside the DLLs (as opposed to just checking registration values, and return true/false), then spoofing them won't help. By "work" I mean the functionality of features of the application.

Not meaning to nitpick, but it doesn't necessarily reduce to a single conditional jump. Say for example that your serial is checked against four different algorithms, each of which needs to succeed in order for the program to decrypt the next tier of encryption. This scheme cannot be cracked by altering a single jump (unless it was very poorly implemented).
But of course, the concept is firm: Only finitely many jumps will need 'patching' in order to get a program to do whatever you want it to (within its capabilities).

I'd disagree with this. Consider the case of self-decrypting code. Assume a portion of the exe is encrypted, say the "File - Save" routine. To enable the application to save, the user must register it. The registration key is actually half of a key pair that allows the code in "File - Save" to be decrypted. Provide the wrong key, the code won't decrypt. You can't patch the code (short of rewriting the entire save routine and inserting it into the exe over the encrypted code), but the developer still gets to distribute the entire exe and provide registration via a serial - which, IMO, is more user-friendly than supplying a brand new installation for the Full version.

Using that method there's no single logic pattern to patch because the important bit is supplied by the user, not contained within the exe. There's no way to generate the key pair. So there's no way to circumvent the protection short of obtaining a real key.

Perhaps I should've explained myself a bit more clearly... what I mean is that all software protection systems at one point decide whether or not to go ahead, even in the case of encryption where the check is if the key is valid or not, and this check is to prevent the execution of (improperly decrypted) random instructions.


You shan't need to decrypt and get the exactly original routine, although in some cases bruteforcing is one way. The other way is to pretend that the encrypted routine never existed and create it yourself from the intimate knowledge of the program, which is one of the highest, most difficult levels of RCE (adding functionality to existing programs). Either way, the save-disabled program now saves. The "protection" has been defeated.

Hm, ok, I can accept it's possible to recreate the code yourself in the case of File-Save, in some cases. But what about a more complex function?

Take the "Styles & Formatting" system in MS Word. That would absolutely lend itself to being in a DLL or a chunk of code. If that code was encrypted in the manner I'm suggesting, there is absolutely no way a reverser could recreate the code. The app would still work, the user could still use the trial version of Word and see if they liked it, but they wouldn't have access to a core part of the application function.

Ignore bruteforcing for a moment, because that is an indication of a weak encryption implementation rather than a flaw in my theory. I'd contend that using this technique would make it impossible to defeat the protection. The only issue is to ensure unique keys are issued for every version of the app. Without unique keys per copy of the application it would be possible to register the app legally once then use the same key for registering N apps.This isn't a technically difficult issue, it's a logistical one and is no different to WON keys from Valve or the watermarking in IDA.

This type of protection isn't hard to code, either. I'm surprised it's not more common.

Actually, I've ran into a few times, and everytime I've always just recoded it. Every time I've encountered it, they've only encrypted a few functions and none of the support functions, so it's never been too big of a deal.

I've never seen one like you describe ("Styles & Formatting", which arguably would be more trouble than it's worth. I can only assume the reason is that it would be hard for a potential customer to evaluate a "Demo" that is so saverly crippled. Mostly, they stick to "can't print", "can't save", "put a logo all over the output", and "try for 30 days".

Despite all of the wickedly cool protection schemes that are available, I must say that 99% of things I actually run accross are still "jnz -> nop" or "cmp -> mov". Even a lot of dongled software is still boiling down to setting good guy to true, forgoing the insane amount of work that went into making the dongle drivers secure. Kind of pathetic, really.

The programmers have to want it. I've seen a couple cheap shareware apps that had painful to break protections (talking hair pulling, etc.). I truely believe the corolation was that if their software got cracked, they didn't eat, so they gave it their all.

A lot of software is written by 9to5 guys who only put in protection because their boss told them too. Usually it's a good guy / bad guy thing, but occasionally they will wrap it with some protection the IT guys heard about on the internet or found out about from a vendor. That protection will probably support things like function decryption, but a lot of times, that would take away from a lunch break, so it never gets put in...

OK, back on topic. Spoofing DLLs, Yummy!

Stating the obvious, but "dumpbin /exports" gets you all the function names. In masm, have each proc just jmp to the real DLL entry, and then on the ones you care about, trap 'em. I have yet to see anybody so much as check a file version, even though it would only take a few lines of code. HINT: LoadLibraryEx will allow you to load the Real DLL from your fake one without alerting its DllMain(), just incase the startup code is doing something troublesome (like messing with your debugger).

I just think it's kind of weird that shareware text editors and cute clock programs have *infinitely* more protection than expensive image editing and compositing software. I guess there's only so much that can get done between 9 and 5...

Okay, you've got me interested. I'd like your thoughts on 2 scenarios:

1. What are some of the toughest protections you have run across?

2. Suppose I'm writing a professional app (not a game) and I want to make whatever protection I am using very secure. I don't have the option of my own drivers (StarForce) or constant net access (many online games). I've heard and seen the usual speil (sp?) about anti-debugging tricks, encryption, etc. But what I really want to avoid is the good guy/bad guy stuff. Is the best approach just to use the returned value in a calculation of some kind that is essential to the program, and will fail if the value is not correct?

Either way, I want to hear about the 'wickedly cool' schemes out there you are talking about.

Here's the one I'm checking out at the moment.

http://www.nalpeiron.com/

Has anyone seen this one before?



Do you have any examples (especially links and/or binaries!) that I could try out? I just tried hacking FileFerret, and finally figured it out, though I don't think I could issue a binary patch just yet.

There ya go !! .

Woodmann

Hmmm!

This looks familiar, I've run into at least 3 targets that seem to incorporate variations on something similar - all 3 are completely (1 only), or "partially packed", may have a fake OEP, with Arma - various versions, all 3 invoke special dll's during the registration process, 1 with the dll's located in the Doc's and settings area the other 2 unpack and implement at runtime, 1 uses something called "registration plugin", the other uses "virtual security", I'm sure that just unpacking these would defeat this scheme, but I've yet to be successful - have'nt tried very hard. They also share another attribute - they are all low cost, so it seems that the protection would be very inexpensive or free.

SiGiNT