Slashdot Mirror

← Back to Stories (view on slashdot.org)

Stolen Android Anti-Piracy Software Dumped On Github (torrentfreak.com)

Posted by BeauHD on from the unexpected-occurrences dept.

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.

33 comments

  1. Too late to short them! by Anonymous Coward · · Score: 0

    Damn, if only I were your lover!

    1. Re:Too late to short them! by saloomy · · Score: 1

      I don't get it? How do they prevent an application from being decompiled? I've never heard of such a thing.

    2. Re:Too late to short them! by Anonymous Coward · · Score: 0

      By making use of "features" in deobfuscation to do things like cause infinite loops.

    3. Re: Too late to short them! by Anonymous Coward · · Score: 0

      Ultimate irony...actually hitting the definition right on the head. It can't stop itself from being pirates but it's supposed to stop piracy.

      So what if your olly deobfuscate script hangs forever. Make a new one.

    4. Re:Too late to short them! by sjames · · 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.

    5. Re:Too late to short them! by Anonymous Coward · · Score: 0

      Its more a question on whether someone can initiate a debug process against the executing code. There are multiple ways to prevent this but it is not a magic bullet in securing your application. Hiding your API Keys in your APK can make it harder for your application to be cracked. Again there are multiple ways you can implement this security but there are only so many ways to do this so someone could most likely crack your app but it may take a little longer. Like everything else in the computing world there is not a 100% method of protecting your application. Adding as many mitigation factors as possible means spending more time developing your app. In the end you will need to decide if your application is important enough to spend a lot of time on knowing ahead time that you cannot create something that is 100% safe. Nobody to date has created a 100% secure system. What one genius hacker creates there are hundreds of genius hackers looking to crack your application and systems. Even systems that have no external networking connections are 100% secure. I am pretty sure Iran thought building their centrifuge in the middle of a military base with no external networking was 100% secure until Stuxnet raised its ugly little head and started playing around their centrifuges. Today most of the scariest hacks require physical access to the system you are looking to exploit. Most of the time the physical access is provided by the users of the systems you are trying to get access to. Phishing and other similar methods can give you "virtual" physical access just by getting one person to click a link. Trying to keep a nation state out of your vulnerable systems is almost impossible given the amount of resources a nation can use. If remote hacking fails and you can't get any users to anything stupid you can always cultivate an internal resource working with offers of some serious cash or you can put your resources to inserting your own espionage sleeper agents into the target location as legitimate employees. The US, Chinese, Russian, Israeli , and other governments intelligence agencies are capable
      of pulling this off.

    6. Re:Too late to short them! by Anonymous Coward · · Score: 0

      Reading this description, it seems the same, that one company had as a product for which I've worked 10+ years ago and I can see, that there is nothing new added to that what I had to work with:

              Obfuscation of arithmetic instructions, control flow, native code and library names, resources and SDK method calls
              Encryption of classes, strings, assets, resource files and native libraries
              Code packing of all combined bytecode

      Basically, it is easier to understand if you have studied algorithm and graph theory(or something - I don't remember anymore), which is pure math and adapting it to coding makes wonders.

      Bits of data(the ones that consists of 0 and 1) can be rotated, shifted, or maybe reordered by some other pattern. All of those actions happen every defined time period according to defined pattern. For example, you have pattern: rotate bits to right, add 1 bit, rotate to left, minus 1 bit, so it gets back to normal original state etc and it goes in cycle. Cycles usually are longer. Different data might have different cycles - maybe even different time periods by which data shifts. So, when you are looking at debugged code and want to understand data, you actually have runtime data, that is changing every time period and you might end up with thousands or even millions of different versions of the same code - and all of them would not work. Those cycles don't need to contain original data - there should be deobfuscating function, that would get proper data, when executing data. And then there are obfuscated arithmetic functions, or even obfuscated versions of primary functions, like arithmetic, string operations, where result will differ from what would you expect.

      Easier is to have server connection and check if client has paid for software, that's why many games require connection, besides obfuscating code would require constant processor power(and better obfuscating would mean - using more operations to obfuscate, so there are physical limits to obfuscating, that would also allow product to run) to maintain obfuscation running on and that is a downside, that some of the processing power will be drawn for this task. On mobile phone - that also means bigger drainage of battery. All of those obfuscating softwares have been cracked and fooled - it is just a matter of time to crack another one and when AI will start to write software, it will be even easier. I would imagine, that injecting unobfuscated library version would do the job to crack the software, but I don't care really - software makers should concentrate on providing services instead, as coding a tool is easy and any kid can do it. And ideas can't be patented, so once someone have seen how something operates, it is hard to stop someone to reuse it in some similar product.

    7. Re: Too late to short them! by Anonymous Coward · · Score: 0

      Tardmunch

    8. Re:Too late to short them! by Anonymous Coward · · Score: 0

      Randomizing (or omitting) names is the worst, this cannot be recreated.

      Adding junk & jumping over it? Not much of a problem, do automatic analysis and skip the junk that won't get executed.

      Encrypted code/strings? Run the sw, it decrypts itself. Work on a memory dump of that, not the encrypted binary.

    9. Re:Too late to short them! by Anonymous Coward · · Score: 0

      Also have a SHA1 for any loadable components (shared libraries) to detect tampering. Don't blow up immediately on detection :-) Perhaps zero out a shared library jump table function...

      BTW, you can crash GDB if it attaches (I don't mean deny attach as used by iTunes) by some carefully crafted code.

    10. Re:Too late to short them! by saloomy · · Score: 1

      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

    11. Re:Too late to short them! by sjames · · Score: 1

      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.

  2. "illegally posted" by Anonymous Coward · · Score: 0

    "illegally posted"

  3. Commodore 64 by Anonymous Coward · · Score: 0

    Obfuscated runtimes? What is old is new again.

  4. Captain Billy on the good ship github by deviated_prevert · · Score: 1

    Polly wanta crack it? Arrrghh! There yea go my maties! We have the secret codes.

    --
    This message was not sent from an iPhone because Peter Sellers really was a deviated prevert without a dime for the call
  5. If it is used in software, it is already public! by Anonymous Coward · · 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 have the first clue about how computers and software work.
    Typical imaginary property Mafia morons. Aka the real pirates and thieves, stealing real actual money that people really actually had to work for each time, in "return" for worthless mere copies, where nobody had to work for the copies. ... If that shit was acceptable, I could do the exact same thing, by making copies of my $100 bills, and DEMANDING that they let me pay with those worthless copies, "because I worked for the original $100, you thieves!". --.--

    Prison for all of them, is the only morally right action. And no cocaine nor LSD anymore.

  6. Re:If it is used in software, it is already public by Anonymous Coward · · Score: 0

    Yep, Let's start the revolution !

    down with all religions, politicians, psychopaths and sociopaths.

  7. Fuck them by spire3661 · · Score: 1, Insightful

    "We develop premium software for the protection of mobile applications against reverse engineering"

    No sympathy for scum like this.

    --
    Good-bye
    1. Re:Fuck them by Anonymous Coward · · Score: 0

      mobile software SHOULD be written to sane development guidelines, be unencrypted, be entirely stored on and loaded from the device (no remote-loading of un-verfied/un-approved scripts) and be able to be read and understood by humans.

      encryption, obfuscation and remote loading are just some of the methods that let shit through that is malicious, spy-ish, or otherwise violates an "app store's" rules and policies.

    2. Re:Fuck them by Anonymous Coward · · Score: 0

      why?

      fuck you

      software authors have rights - just like the ones you think you deserve to have.

  8. Well, they did jack the price up to 'whatever' by Anonymous Coward · · 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 and stick with them - none of this 'contact us and we'll look you up and decide how much to charge based on how much you seem to be worth'.

    1. Re:Well, they did jack the price up to 'whatever' by Anonymous Coward · · Score: 0

      I just started uploading cracked versions of my apps to the pirate bay myself. Folks are going to get it for free somehow, at least if I get out ahead of them I can saturate the cracker market with a version made for pirates to help me at least gauge user engagement better.

      It's judo: The crackers will come at you, so just take their excessive force and direct it to your advantage.

    2. Re:Well, they did jack the price up to 'whatever' by Anonymous Coward · · Score: 0

      Dilbert has a cartoon on software vendors pricing - how much does it cost? Answer: Exactly what it can save you.

      Worse than software is electronics components.
      This is why made in China always wins.There you can buy over-runs of parts.

  9. Features of Dexguard ideal for Malware by ffkom · · Score: 4, Insightful

    The features that are advertised for Dexguard sound like exactly what Malware programmers would be looking for to obfuscate their evil intentions. Spyware, Trojans, Adware and the like are certainly right in the middle of the target audience.

    1. Re:Features of Dexguard ideal for Malware by thygate · · Score: 2

      and this is why some (defunct imo) AV products have flagged executable packers for as long as i can remember. I have used a modified (header only) version of UPX for some products over the years, and time and time again, some AV will flag it as some generic virus. The reason I used it was to make it a little harder for script kiddies to clone the product, as just changing the UPX header would be enough to disable the generic unpacker scripts. It's gotten even worse in recent years, where a simple (un-obfuscated!) C# .net assembly that simply imports ReadProcessMemory from kernel32 gets flagged as a virus by the same "AV" products. I'm sick of AV products ignorantly flagging shit as malicious, resulting a a lot of extra support, while security-ignorant government mandated (very-well-obfuscated) backdoo... er i mean "bugs" are rampant.

    2. Re:Features of Dexguard ideal for Malware by Anonymous Coward · · Score: 0

      Yes, in the same way that every encryption software sounds like something criminals would want to use. The "honest people have nothing to hide" argument has been debunked pretty thoroughly and I'm surprised to see it marked as "Insightful" here on Slashdot.

    3. Re:Features of Dexguard ideal for Malware by thygate · · Score: 1

      THIS. mod parent up!

    4. Re:Features of Dexguard ideal for Malware by Anonymous Coward · · 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 application deployment step to make your application smaller.

          To put things into perspective: this guy has written a free application with millions of users (literally every Android developer) all by himself. But then he has the guile to try to extend his application to make some money from his work. And this new work might be used by hackers, imagine that ! What a selfish, greedy insidious bastard, I say. Clearly, a scumbag who is up to no good. Let's destroy his business and teach him a lesson.

      my 2c
      Mihai

    5. Re:Features of Dexguard ideal for Malware by Anonymous Coward · · Score: 0

      that audience already does similar on their own....and?

  10. Re:Well, they did jack the price up to 'UR 10000 by Anonymous Coward · · Score: 0

    http://thinkdiff.net/mobile/dexguard-480-eur-to-10313-eur-the-worst-software-do-not-use/

  11. Agreed it's bullshit... apk by Anonymous Coward · · Score: 0

    Agreed it's bullshit: Had it happen to me too on my APK Hosts File Engine https://tech.slashdot.org/comm... (when I used exepackers on it - I no longer do because of that crap (makes it harder to protect my work now though)).

    It took me time to overturn false positives on the VERY GROUNDS YOU NOTE (bullshit ones, they falsely accuse vs. PROVING their accusation instead)!

    * It took me a GOOD DEAL OF TIME hounding the antivirus companies (9 of them, in ArcaVir, Baidu, ClamAV, Comodo, Crowdstrike, EmsiSoft, McAfee, NOD32/ESET, Norton/Symantec, Qihoo360, SentinelOne, Trend & Sophos) to RESCIND it or be taken to courts of law for libel + restriction of trade & defamation of character etc. - which they ALL rescinded in the end.

    APK

    P.S.=> FUNNIEST PART IS, Antivirus is LOADED w/ SECURITY VULNERABILITIES (see Tavis Ormandy on that note) - they are NOBODY TO ACCUSE ANYONE of writing "malware" when THEY ARE THE ONES ALLOWING IT IN, not stopping modern threats & SLOWING YOU DOWN to boot also... apk