On Fri, May 13, 2011 at 10:59 AM, Twinkie <[email protected]> wrote: > I was hoping to find a whitepaper/online article/book to bolster my > argument that an All-Dalvik app is as good security-wise as an app > with sensitive logic "hidden" in native code.
Some of my favorite examples of why native code is not "obscure" just because most developers don't understand how computers work: http://portal.acm.org/citation.cfm?id=1130388 Linux' CRNG is so poorly written that it is easier to analyze the object code than the source code. The authors found serious bugs in the generator by analyzing the object code. They also did this for Windows' CRNG, described in another paper. Obviously they never had any source code for Windows. http://blog.zynamics.com/2011/01/21/recovering-uml-diagrams-from-binaries-using-rtti-inheritance-as-poset/ Thomas Dullien analyzes object code to generate documentation at least as good as what the original developers of a proprietary product have. http://www.hex-rays.com/idapro/ Just spend some time with this thing. If your native code developers really understand native code, they will know that every line of C is equivalent to about 1 - 10 lines of pretty straightforward assembler code. I wish my IDE had a call/branch graph as good as IDA... > I know with effort > either can be decompiled, the aim is to make that effort as much as > possible. I once disassembled a program that required a dongle (= DRM) to run. The program was encrypted with a key on the dongle, and it decrypts itself at startup. (This is called "packing" a binary.) I probably could have broken it in any number of ways, but the easiest was to simply let the program launch and then attach WinDbg. Then I used WinDbg to get assembly of the parts of the code I cared about. I could probably have slurped the process memory image and fed it to IDA Pro with a bit more work. Chances are low you'll achieve a solution as "strong" as that on Android. No dongles, for starters... > I agree with your previous point that ideally there should be no > sensitive logic client side. However, while most of it is server-side, > some of it necessarily (business requirements) has to be client side - > decryption of data in the intent & a couple of actions taken on the > basis of it. Why do you encrypt data in the Intent? It should be to prevent other processes that sniff your Intents from understanding the data. Even better, of course, is to not put sensitive data in Intents at all. See this paper by Jesse Burns on developing secure Android applications: https://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf -- http://noncombatant.org/ "These days, though, you have to be pretty technical before you can even aspire to crudeness." — William Gibson -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
