2. If you run in to obfuscated smali filenames in the APK, a simple search replace will help you rename the files.
3. Instead of trying to understand the proprietary encryption/decryption, just run the decryption code without understanding it.
4. OP Created a smali emulator for this task (#3). Only supporting a small subset of dalvik instructions.
Which means than for now, the emulator can be defeated using as many dalvik opcodes as possible in your encryption/decryption code.
A simple check-cast for example (Throw a ClassCastException if the reference in the given register cannot be cast to the indicated type.)
can break the emulator.
5. Being written in python, relying heavily on regular expressions and without much algorithmic improvements (the opcode lookup for example is a for loop instead of a lookup table) - there's a lot to improve the emulator performance, but this is an incredible first step.
> Instead of trying to understand the proprietary encryption/decryption, just run the decryption code without understanding it.
When I have encountered this sort of problem in the past, I would drop the encryption module into another Android app and directly call the functions. I would then run the other Android app on a phone or Android emulator. Custom emulation seems unnecessary for most cases.
maybe you could make a chrome extension which blocks all forms of fun and frivolity. you could just hide images from various meme sites, maybe do some checksum comparisons?
It’s always funny how large developers – say, Google – still try to obfuscate their code when it’s so easy to reverse.
Even better, as in many legislations a derivate of manually deobfuscated code does not count as derivate of the original source, they even give up their copyright on their code, practically.
I’m surprised that this still happens. By now anyone should know that if you can run a piece of code, you can decompile, deobfuscate, and understand it. DRM and obfuscation only work to waste a week or two of the time of the person taking it apart.
"DRM and obfuscation only work to waste a week or two of the time of the person taking it apart."
Not only that, it also drastically decreases the amount of people in the world capable of reverse engineering your code.
It also decreases the amount of people willing to. In the end, security is a game of effort vs gain.
More effort -> might not be worth the gain.
Also - a lot of these techniques are used by malware to evade anti viruses and static code analysis.
> Even better, as in many legislations a derivate of manually deobfuscated code does not count as derivate of the original source, they even give up their copyright on their code, practically.
I never heard that, source ? It's not really "clean room".
> DRM and obfuscation only work to waste a week or two of the time of the person taking it apart.
I don't think it's that simple. There's some distribution of time wasted that goes from 0 (already prepared tools for automated deobfuscation) to infinity (it's enough of a roadblock to stop the effort). If you automate the obfuscation and just stick it into the publishing pipeline, you effectively stopped >0 people with ~0 effort. So why not do it?
> DRM and obfuscation only work to waste a week or two of the time of the person taking it apart.
I remember reading an article featured here that the latest PC video game needed something like 6 months to be cracked and the crackers (Chinese I think) almost abandoned.
> DRM and obfuscation only work to waste a week or two of the time of the person taking it apart.
For 90 percent of Play Store apps, that would be more effort than the initial development effort for the app (and with 90 percent, I'm being very, very generous).
This stomps on motivation to develop any novell code, because for all the years of hard work you put into r&d, there will alway be a lot of people who are just waiting for something to slip through your fingers, so they can steal it and call it theirs.
I don't see how publishing a research without disclosing specific details about the app itself or any kind of "crack" could stomp on motivation to develop something ... unless you trust in "security through obscurity" of course ... which was proven more than once to be a fail :)
You realise that you never had any copyright to your algorithms, etc anyway?
If you spend years of R&D on algorithms, patent them.
But boilerplate code can neither be patented nor copyrighted (except in its source form, but the binary, for example, can’t), so you never owned anything to begin with.
Disclaimer: This is just a general info about EU law, this is not legal advice, I am not a lawyer.
[+] [-] dkopi|10 years ago|reply
1. Great link with the Dalvik opcodes manual http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html
This came up with a google search: https://source.android.com/devices/tech/dalvik/dalvik-byteco...
2. If you run in to obfuscated smali filenames in the APK, a simple search replace will help you rename the files.
3. Instead of trying to understand the proprietary encryption/decryption, just run the decryption code without understanding it.
4. OP Created a smali emulator for this task (#3). Only supporting a small subset of dalvik instructions. Which means than for now, the emulator can be defeated using as many dalvik opcodes as possible in your encryption/decryption code. A simple check-cast for example (Throw a ClassCastException if the reference in the given register cannot be cast to the indicated type.) can break the emulator.
5. Being written in python, relying heavily on regular expressions and without much algorithmic improvements (the opcode lookup for example is a for loop instead of a lookup table) - there's a lot to improve the emulator performance, but this is an incredible first step.
[+] [-] kanzure|10 years ago|reply
When I have encountered this sort of problem in the past, I would drop the encryption module into another Android app and directly call the functions. I would then run the other Android app on a phone or Android emulator. Custom emulation seems unnecessary for most cases.
[+] [-] calebfenton|10 years ago|reply
[+] [-] evilsocket|10 years ago|reply
[+] [-] unlinker|10 years ago|reply
[+] [-] evilsocket|10 years ago|reply
[+] [-] hawleyal|10 years ago|reply
[+] [-] calebfenton|10 years ago|reply
[+] [-] tyingq|10 years ago|reply
[+] [-] kuschku|10 years ago|reply
Even better, as in many legislations a derivate of manually deobfuscated code does not count as derivate of the original source, they even give up their copyright on their code, practically.
I’m surprised that this still happens. By now anyone should know that if you can run a piece of code, you can decompile, deobfuscate, and understand it. DRM and obfuscation only work to waste a week or two of the time of the person taking it apart.
[+] [-] dkopi|10 years ago|reply
Also - a lot of these techniques are used by malware to evade anti viruses and static code analysis.
[+] [-] Aissen|10 years ago|reply
I never heard that, source ? It's not really "clean room".
[+] [-] viraptor|10 years ago|reply
I don't think it's that simple. There's some distribution of time wasted that goes from 0 (already prepared tools for automated deobfuscation) to infinity (it's enough of a roadblock to stop the effort). If you automate the obfuscation and just stick it into the publishing pipeline, you effectively stopped >0 people with ~0 effort. So why not do it?
[+] [-] jmnicolas|10 years ago|reply
I remember reading an article featured here that the latest PC video game needed something like 6 months to be cracked and the crackers (Chinese I think) almost abandoned.
Will try to find the link.
[+] [-] raverbashing|10 years ago|reply
100% protection does not exist, which doesn't mean you shouldn't try to make it a bit difficult
(keeping honest people honest and all that)
[+] [-] _pmf_|10 years ago|reply
For 90 percent of Play Store apps, that would be more effort than the initial development effort for the app (and with 90 percent, I'm being very, very generous).
[+] [-] ultramancool|10 years ago|reply
I know several for .NET including SimpleAssemblyExplorer and De4Dot (though de4dot also includes several specific deobs).
EDIT: Looking around you might try something like https://github.com/CalebFenton/simplify or https://github.com/contra/JMD after converting with dex2jar or similar.
[+] [-] marcelftw|10 years ago|reply
https://www.pnfsoftware.com/
(not my product)
[+] [-] evilsocket|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] torkable|10 years ago|reply
[deleted]
[+] [-] abpavel|10 years ago|reply
[+] [-] evilsocket|10 years ago|reply
[+] [-] viraptor|10 years ago|reply
[+] [-] kuschku|10 years ago|reply
If you spend years of R&D on algorithms, patent them.
But boilerplate code can neither be patented nor copyrighted (except in its source form, but the binary, for example, can’t), so you never owned anything to begin with.
Disclaimer: This is just a general info about EU law, this is not legal advice, I am not a lawyer.
[+] [-] cyphar|10 years ago|reply
[+] [-] duncan_bayne|10 years ago|reply
[+] [-] hawleyal|10 years ago|reply