I don't know if ours qualifies as widespread (it's use is more popular among the people I've convinced to use it) so these other links are also good, but I think is pretty well documented:
http://www.cs.umd.edu/projects/PL/redexer/ It also includes a disassembly module which dumps APKs to HTML (in the style of DOxygen). Still, pluses and minuses.. Kris On Fri, May 31, 2013 at 2:56 PM, Pau Oliva Fora <[email protected]> wrote: > just adding to what Jeffrey said: > > detecting a rooted device is nearly impossible, if the attacker has root > access it is able to hide it from your java application in many different > ways. > > There are a couple of advanced instrumentation tools that can be used to > tamper with your application and extract the decrypted data from memory: > > xposed framework - http://www.cydiasubstrate.com/ > cydia substrate - http://forum.xda-developers.** > com/showthread.php?t=1574401<http://forum.xda-developers.com/showthread.php?t=1574401> > > other instrumentation frameworks exist, but are not as well documented and > widespread. > > > On 05/31/2013 06:32 PM, Jeffrey Walton wrote: > >> On Fri, May 31, 2013 at 4:33 AM, nick lidis <[email protected]> >> wrote: >> >>> >>> ... >>> Recently one of our evaluators reported that their security department >>> insists that it is possible to attach a debugger on a running application >>> (which is built on release mode and with the debuggable flag set to >>> false) >>> and single step the application AND examine the memory in order to >>> retrieve >>> the in memory cached keys and data.They have not provided info or proof >>> on >>> how to do this, though. >>> >> They are probably extracting classes.dex, running baksmali on it, >> instrumenting it, using smali to rebuild classes.dex, and then >> building an APK with the debuggable flag. >> >> In the smaili sources, you can even wait for a debugger in >> MainActivity.onCreate: >> >> invoke-static {}, Landroid/os/Debug;->**waitForDebugger()V. >> >> After the debugger attaches, the your adversary can do all the >> customary things, like set breakpoints, examine variables, etc. >> >> I know that anyone can retrieve the source through decompiling, and even >>> create an Eclipse project with that,but how is it possible to attach the >>> debugger on the running process (which was build in release mode)?Doesn't >>> Android prevents that? >>> >> For a non-rooted device, they likely cannot debug a running process >> which *lacks* the debuggable flag. I've never had success in doing so >> with my Evo 4G, and had to use other tricks to debug the code. I've >> also seen different behavior on the device and under the simulator. >> >> Other phones with other carriers may be different. And all bets are >> off for a rooted device or they are running a mod, which they might be >> doing. >> >> Android 4.2.2 allows you to secure ADB to stop others from attaching >> to processes and extracting data. See Nikolay Elenkov's blog >> http://nelenkov.blogspot.com/**2013/02/secure-usb-debugging-** >> in-android-422.html<http://nelenkov.blogspot.com/2013/02/secure-usb-debugging-in-android-422.html> >> . >> (I've been able to do everything in Nikolay's list except attach a >> debugger to a running process). >> >> Is it possible to modify the installed (and signed apk) in place so that >>> he >>> enables debugging without even uninstalling the app (which will delete >>> all >>> its data)? Is there a mechanism on Android to detect tampered/corrupted >>> apks? >>> >> I doubt they can modify an installed APK in-situ on a stock device. >> For example, I don't know of a way to modify an APK and generate a new >> signature while the APK is on the device. But I could be wrong since I >> usually re-engineer an APK on a PC to suite my taste and then perform >> an `adb install`. >> >> I am talking mainly about a real attack on a stolen device where the >>> attacker cannot afford to erase the data,and the legitimate user >>> pass-phrase >>> is not known. >>> >> A stolen device is usually vulnerable to password and storage attacks. >> If you are prompting the user for their secret, then your threat is >> probably word lists and brute forcing. >> >> You might be vulnerable to some session related attacks, depending on >> how you are managing sessions. >> >> As of today I was not able to find anything related to such an attack, >>> so If >>> you are aware of any resources I can consult for familiarizing with the >>> risk >>> and maybe taking extra measures , it would be greatly appreciated. >>> >> Some keywords: android reversing, smali, baksmali, dex2jar, apktool. >> >> Jeff >> >> > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > android-security-discuss+**[email protected]<android-security-discuss%[email protected]> > . > To post to this group, send email to android-security-discuss@** > googlegroups.com <[email protected]>. > Visit this group at http://groups.google.com/**group/android-security-** > discuss?hl=en<http://groups.google.com/group/android-security-discuss?hl=en> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
