A code protector claims that it "ensures it is physically impossible to run code without a serial number" is this a scam?

Question

VMProtect Software (found at http://vmpsoft.com/) claims that it:

"allows the generation and verification of serial numbers. Both manual and automatic generation are supported. Serial numbers can be limited by time or date and locked to the hardware, while the free upgrade period can also be limited. VMProtect ensures it is physically impossible to run code without a serial number."

I believe that the word "impossible" is clearly incorrect because I thought that any serial number protection mechanism could be cracked by spending enough time reverse engineering it.

However, I have searched online and VMProtect was used as a packer to obfuscate malware through virtualized protection as described here https://www.f-secure.com/v-descs/vmprotect.shtml so it does seem to achieve "protects code by executing it on a virtual machine" as it claims. I understand the ideas of Virtualization-Obfuscated Software and am not seeking a response on that (I just used it as an example of one thing that VMProtector claims to do, which it does infact do).

Is this false advertisement, or are there new fancy ways to make code not run without serial numbers?

Answer 1

So their market is protecting your app from the prying eyes of reverse engineers. Myself, I find that page a little too fluffy, and a little too scant on details. I certainly wouldn't buy their product based solely on the descriptions on that page.

Based on the descriptions, it looks like they generate some custom assembly language for each app, then you run the bizzaro code inside their assembly translator (aka virtual machine) which produces actual assembly code at runtime. Am I correct? I can see why that makes code hard to reverse-engineer.

Now to your question. Since they control the harness that your code runs in, they could easily add a check at startup that says "does the serial number they provided match [the serial number I'm expecting]? If not, abort". So, the simple answer to the question "are there new fancy ways to make code not run without serial numbers?" is yes, but the better question is "how to prevent reverse engineers from figuring out what serial number it's expecting?".

First, I wonder what they mean by "serial number". In the strictest sense, that means "take the previous number issued, and add one to it". That shouldn't be too hard to spoof. Also, how do they get the [serial number I'm expecting] part to compare to? Does their product require internet access to phone home for the correct serial number? Sure they can do an SSL connection home to protect it from packet sniffing, but since it's running on my hardware, can I do a memory dump and extract the [the serial number I'm expecting] directly?

Maybe instead of "serial number", they mean some sort of fingerprint of the system's hardware. It's a common trick in the security industry to hash together the MAC address, serial number of the motherboard, model number of the processor, today's date (if the code is only good for one day), etc. That way I don't care if you extract the hash I'm expecting from my source code, good luck virtualizing hardware that produces a matching hash. A trick like that would be consistent with their statement that it's "locked to the hardware", but couldn't really be called a "serial number".

Even if they do have some super fancy fingerprint checker, their harness is regular assembly, as a reverse-engineer, can I put in a goto to bypass the check?

So the longer answer is: there might be ways to make an app that will refuse to run without the proper serial number / key / fingerprint, but your intuition is probably right that it can be cracked with enough effort. Moreover, their description page definitely does not give enough details to inspire confidence. But *heh*, they're in the obfuscation game, what else should I expect? Whatever they've done is probably good enough to keep the folks at Symantec busy for a couple months while they rake in some cash.