Thanks for your answers. It is much clearer to me now that native vs Dalvik does not make much of a difference in this scenario.
On May 13, 11:47 am, Tim <[email protected]> wrote: > 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-bina... > > > 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.
