This probably works to avoid decompilation, since you can generally find a semantically equivalent program which wouldn't normally be generated by a compiler. But thwarting disassembly is much harder, since it's basically just prettifying what's already there. Still, reading disassembled code is hard, so your technique is probably the best compromise considering that most attackers are just going to be people using automated tools and won't have the time / incentive to hack your hack at the bytecode level.
Kris On Thu, Aug 29, 2013 at 6:04 AM, Keith Makan <k3170ma...@gmail.com> wrote: > > Here's my two cents: > > With regards to making you app un-reverse-engineer-able I think one > effective action you could look into is > "attacking" popular debuggers and obfuscating your dex bytecode so that > decompilers like smali, Dex2Jar would fail at > interpretting them. Though the only effect this would have is thwart > unskilled "skiddy" type attackers who rely heavily > on automated tool sets, but it is worth a try if you are really seriously > concerned about someone reading your source code. > btw you shouldn't be worried about it really, your code should be able to > defend your users no matter who sees it. > > There are many ways to beat the popular de-compilers, and they usually > involve adding dead pieces of code that crash > the interpreter by using code structures that the de-compiler doesn't > support there's a lot of space > still unused in the opcode instructions space, for instance opcodes like > FF, FG etc. that would > probably cause problems and you may be able to add them without crashing > libdex and the VM on android devices, > you just need to find someway to have them safely ignored. > > The other option is to wait a couple years until homomorphic encryption > hits the mobile platform, and deploy encrypted > applications ;) *this is a joke btw, it probably won't* *anytime soon * > > > See this presentation : > http://www.strazzere.com/papers/DexEducation-PracticingSafeDex.pdf > > Regards > k3 > > > > > On Wednesday, August 21, 2013 12:20:50 PM UTC+2, pioneer...@gmail.comwrote: >> >> Hi >> I'm going to create a e-book reader application. This application can >> open up encrypted book files after receiving key from a web server. >> All key communication process and information transferred are encrypted >> by some other keys. >> >> I want to apply a mechanism on server-side to control identity of sender. >> >> I used user-name & password, random hash-key & device IMEI. >> >> >> 1. However i want to know is it possible to check which application >> is sending request to server or not? e.g. is it possible to check CRC or >> signature of apk which send requests to server? >> 2. Are there some mechanism for securing source codes, more >> sophisticated than ProGaurd for hiding source codes and libraries >> inherited >> in APK file or not? >> >> Reason that I'm asking this question is: >> As long as i checked it is possible to do reverse-engineering on APK >> files.Using ProGaurd make it harder to decompile codes and understand them >> but it *will not make it impossible* (may be I'm wrong about this). >> I want to make some mechanism that if somebody accessed my source codes >> and generated new app out of it, I'can control application-identity using >> its signature or something else on server side before sending private >> information toward it and avoid leakage of information >> >> It is impossible to secure information in all aspects but it will be so >> hard if i cannot secure my source codes. >> Thanks for your notice in advance :) >> > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to > android-security-discuss@googlegroups.com. > Visit this group at > http://groups.google.com/group/android-security-discuss. > For more options, visit 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 android-security-discuss+unsubscr...@googlegroups.com. To post to this group, send email to android-security-discuss@googlegroups.com. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/groups/opt_out.
