What tools would I need, to see what source code corresponds to the places where the original binary has been patched in order to crack it?
I am in possession of the original binary and of the cracked one (Windows only), and an hex diff already showed the few places where it has been tampered with.
I’m not an expert about analyzing an executable after it has been generated by Visual Studio, so… now what?
I’d love to hear the answer to this! I’ve never done any cracking, would be interested to hear about the tools + tricks they’ve used.
With dumpbin.exe you should be able to get an assembly listing of both versions, and then you can compare them. If you still have the original pdb symbols of your binary, it should be easy to find which function have been tampered.
Thank you for your quick answer!
Ah, so I’d need to generate the PDB file also for the Release builds, and keep the one corresponding to each released version. That’s good to know.
With that, how would I proceed with loading the released exectuable together with its original PDB, and to find the tampered location (sorry for the noob question)
Until now, in case of these events I’ve just kept around the assembly listing files generated by Visual Studio, sort of one listing file for each object file that’s compiled. I guess I cannot do much with those at the moment?
I believe that, if you have plugin.dll and plugin.pdb in the same directory:
dumpbin /disasm plugin.dll > plugin.asm
will give you the assembly listing with symbols of your original release binary. Then copy plugin-cracked.dll to plugin.dll and repeat the process, you should have the listing for the cracked binary, also with symbols. And then compare them with any text diff tool. You can probably do that also in visual studio but to be honest I don’t know how to use it.
IDA is the definitive tool for pulling things apart if you don’t have the symbols.
https://www.hex-rays.com/products/ida/
The trick is to make your binary difficult to crack with IDA…
I’ve tried cracking before, and have seen it done on complex game consoles and their games.
Check out OllyDbg, a dissassembler for Windows: http://www.ollydbg.de
There are no tricks except an insane amount of time and patience. I’m sure there are patterns though.
Thank you for all your valuable information.
We’ve been able to determine that the patch did simply force some ‘if’ branches to be always taken, regardless of the condition.
It was easy for us to implement it, so it was plain for them to crack it.
Do you have any good suggestion for making the source code less prone to this, for example some way to make the cracking task unbearably boring?
Do you have any good suggestion for making the source code less prone to this, for example some way to make the cracking task unbearably boring?
Yeah, get your app/plugin checked for security vulnerabilities!
Klocwork is my go-to resource for doing that sort of thing: https://www.klocwork.com/
In terms of things that wouldn’t require much extra effort, I always thought the isUnlocked method from the OnlineUnlockStatus juce_product_unlocking class was really clever - not the fact that it returns a var, but the suggestion that inlining it will make it more annoying for crackers to work around since you’ll have instances of it scattered throughout code.
Overall,
Investing in protection should be evaluated for how much you gain from it.
Currently I’ve yet to see a product that isn’t protected by one of the security companies and wasn’t compromised to some extent.
I’ve also heard some very clever developers giving interesting tips, yet, some of them was eventually also sacrificed.
So here are some of the tricks I’ve heard/read, similar to var used by isUnlocked mentioned by @jonathonracz.
Your best “protection” would be to have a cracked product with less reliability than the original. but those who won’t buy your product, usually won’t buy it even it won’t be cracked.
No system nor host system is safe!
“No system nor host system is safe:”
I’d suggest you read carefully what you’ve quoted by me.
I’ve clearly stated the brute force possibility under Windows.
Your link is dated back from 2015.
Currently all compromises were under Windows only. And latest I saw was almost a year ago.
So until I see compromise under MacOS I wouldn’t consider it as cracked.
If you have any actual proof or proof of concept feel free to chime.
Very sorry.
Not really, as my post was in jest. For crying out loud I linked something from TorrentFreak!
Unfortunately our NDA prohibits us from sharing any insights we have gained via Steinbergs’ postmortem of the crack. Not only Nexus was affected, but all protected products. The crackers exploited an oversight that has been fixed about a month after the crack, with their newer SDK. Since then it’s been uncracked. The crackers, back then, stated that it was pure luck they found it and they don’t believe there is another way to crack it.
Nexus was last cracked at version 2.2.0 in mid/late 2009. Nothing since then, except a few unsuccessful attempts in late 2012 / early 2013.
I can tell you about the economic impact. Nexus was always selling very well (in relation to company-size etc.), but the moment the crack came out, our sales dropped to 1/3. We lost 60-65% of our revenue overnight. Fortunately we build a buffer from the years prior that kept us afloat until sales recovered over the next 2-3 years, back to their previous levels.
Now the crack is almost meaningless, as it’s so old and outdated. We’ve added new features since then and all new expansions are unavailable to the crack-users. Also the crack is Windows only (Nexus2 was never cracked on macOS) and 32-bit only. We’ve released over 100 expansions since the crack came out. None of those are usable in the crack.
The Steinberg dongle system works great for us but also has some disadvantages:
Dongle needs to be plugged in = one USB port taken
If dongle gets lost/stolen, you can’t verify that the customer really lost it. He might be lying to you, trying to get another license for a friend or to sell on eBay etc.
If dongle gets broken, customers have to send it in, so you can verify the license was really on the broken dongle (this works by holding the two pieces together on their four contact-points, thus being able to read the dongle and even copy the license to a new one).
The dongle drivers needs to be installed for the product to even work.
The customer needs to pay extra for the dongle and its shipping, or they have to source it themselves locally = no more instant gratification people get used to.
The Steinberg protection has to be actively integrated into your products. You actually need to use their SDK and write the protection code using their methods/functions/classes. AFAIK the PACE / iLok stuff is just a wrapper that you put around the finished product. It’s apparently rather easily removed. Hence the constant cracks of ALL PACE / iLok “protected” products.
The PACE / iLok system suffers from the same drawbacks as the Steinberg one, but is more expensive (per license and for the hardware) and at the same time less safe.
If you have to choose between Steinberg dongle and PACE / iLok, you should always go with the Steinberg dongle. It’s smarter, harder to crack and cheaper.
Cheers,
Mike
That’s incorrect.
Rail
So the newer “Fusion” stuff is then also something you have to embed into your code?
Yes, but they still offer the ‘wrap only’ service. Fusion is a higher price tier, and as far as I know hasn’t been cracked.
I guess some developers here are under NDA so we can only use available information. Mind link by
@jrlanglois, many cracks back then was proud enough to mention Fusion if it was used and cracked for that specific product. Including the Fusion version.
