FWIW, people may not have noticed that the latest IDA update has provided Dalvik support, so it's pretty easy to open up both a native library and the dalvik counter part.
-Tim Strazzere Security Engineer Lookout Mobile Security On Fri, May 13, 2011 at 9:39 AM, Chris Palmer <[email protected]> wrote: > 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. > > -- 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.
