Stolen Android Anti-Piracy Software Dumped On Github (torrentfreak.com) 33
Dexguard, a tool used to protect Android software from piracy, tampering and cloning attacks, has been removed after being illegally posted on Github. A version of the tool exposed on the code repository was stolen from a customer of Guardsquare, the software's creator. TorrentFreak reports: "We develop premium software for the protection of mobile applications against reverse engineering and hacking," the [security company Guardsquare's] website reads. "Our products are used across the world in a broad range of industries, from financial services, e-commerce and the public sector to telecommunication, gaming and media." One of Guardsquare's products is Dexguard, a tool to protect Android applications from being decompiled, something that can lead to piracy, credential harvesting, tampering and cloning. Unfortunately, a version of Dexguard itself ended up on Github.
In a takedown notice filed with the Microsoft-owned code platform, Guardsquare explains that the code is unauthorized and was obtained illegally. "The listed folders... contain an older version of our commercial obfuscation software (DexGuard) for Android applications. The folder is part of a larger code base that was stolen from one of our former customers," Guardsquare writes. Guardsquare found almost 300 "forks" of the stolen software on Github and filed a request to have them all taken down.
In a takedown notice filed with the Microsoft-owned code platform, Guardsquare explains that the code is unauthorized and was obtained illegally. "The listed folders... contain an older version of our commercial obfuscation software (DexGuard) for Android applications. The folder is part of a larger code base that was stolen from one of our former customers," Guardsquare writes. Guardsquare found almost 300 "forks" of the stolen software on Github and filed a request to have them all taken down.
Re: (Score:2)
I don't get it? How do they prevent an application from being decompiled? I've never heard of such a thing.
Re:Too late to short them! (Score:5, Informative)
Such schemes have been in use since the days of Apple ][.
First, they mangle the symbol table turning meaningful names into random short strings (and patch up the relocation table to match). Then they encrypt critical code and replace the standard loader with one that first locates the key and decrypts the segments. They also encrypt the strings table so you can't get a decent hint at what a given piece of code does based on the strings it uses.
Naturally, since the code still runs, you can get everything decrypted by running in a debugger, but it makes that a pain since you have to trace your way through the loader and deal with strings being decrypted just in time.
Other tricks include adding junk into the code and adjusting jumps and brtanch inctructions to skip it. You can still figure it all out, but a simple disassembler won't give you a proper assembly listing in one go that way,
Essentially it's an advanced form of taking a nice bit of readable C source, using search and replace to change meaningful variable names like bNeedScreenUpdate with x, and removing all tab, space, and CR not actually needed by the compiler in order to make it hard to understand.
It doesn't actually stop you from decompiling the code but it does make it take a lot more time and effort.
Re: (Score:2)
You are talking about minifying and obfuscating, all of which do not prevent decompiling. I was under the impression some code could be used to crash decompiler or something. What you are talking about is making the code hard to access (encryption) or difficult to understand (obfuscation), not preventing it from decompiling.
Gotcha
Re: (Score:2)
And that would be why I explicitly stated that you can still decompile it but it's a lot harder. There are tricks added to give decompilers fits (as I pointed out), but that's all they CAN do and have the code still run. Ultimately the code still has to be executable, so it still has to be understandable.
Captain Billy on the good ship github (Score:2)
If it is used in software, it is already public! (Score:1)
Same snake oil as all other Digital Restriction Management: Send a list of commands containing an encrypted "secret" to an untrusted party (the user), send him the key too, and expect him to just tell his CPU to follow those commands blindly... which, somehow, *magically* keeps the "secret" secret from the user. Like even the biggest n00b couldn't just find at simple tool or a friend and a more advanced tool, to tell *his* CPU, to do something else... like tell the user the "secret".
Seems like they don't ha
Fuck them (Score:2, Insightful)
No sympathy for scum like this.
Well, they did jack the price up to 'whatever' (Score:2, Interesting)
Does anyone still use DexGuard after they jacked the price model up to 'however much we think your app is worth'?
Seriously, that kind of pricing scheme can basically 'fuck off' (We used to be a customer, and went to using dexprotector once guardsquares pricing scheme went that way).
We actually go out of our way to not do business with any other company either with that kind of ass-holish pricing model. I know it's fairly common in places like the US, but, seriously, put prices with actual numbers online an
Features of Dexguard ideal for Malware (Score:5, Insightful)
Re: (Score:3)
Re: (Score:2)
Re: (Score:1)
Dude, chill and don't be so quick to judge. Personally I do prefer my banking application to be harder to reverse-engineer. You know ...against hackers ?
I don't know how many hackers and evil corporations this company has helped but the CTO/founder is the same guy who wrote proguard many years ago. If you haven't heard of proguard - it is a free (GPL) piece of software used to shrink Java byte code. It is included in every Android SDK installation and launched automatically during the appli