My personal opinion is that if the attacker is allowed to custom design a ROM to hide themselves then you're basically screwed and you really can't do too much. This is why being root sucks, and using rooted roms is something that you do at your own risk. Then again, most popular roms *probably* aren't written with malicious possibilities in mind, but still...
Kris On Sun, Jun 2, 2013 at 10:00 AM, nick lidis <[email protected]> wrote: > > Hello, > > thanks to all who replied. Please allow me to comment to all of you at > once instead of commenting on each reply separately. > > As you said, trying to detect a rooted device is not always successful, as > the traditional methods (search for su, superuser etc) already has a low > detection rate, plus some false alarms. I have not dealt with more advance > techniques and maybe it is not 100% possible to protect the app data > against them. The resources you provided are very interesting and I have to > study them to get the best knowledge (I only knew the > tommascannon.netresource). > > Having used dex2jar and knowing what damage it can make, we are against > keeping secrets in the code, thus requiring user input to generate the > keys.We estimated that the risk of attaching into the running process would > be low, but I see that this is not the case,given that there are techniques > unknown to the common programmers. > > Leaving the rooted devices aside for just one moment, modifying the apk as > Jeff says (instrumenting and repackaging) sounds "easier" to do, like the > thing someone would try first, but wouldn't that force the attacker to > remove the original application in order to install the tampered one?By > means of, the retargeted application would have a different signature than > the original,right? > > If we take rooted devices into account, given that the attacker has means > to hide his presence, what other options can we consider to protect the > data?Of course at some point the data must be in clear text in order to use > it.It is feasible (I am not saying possible) for the attacker to use this > window of opportunity even if the data remains unencrypted for as little > time as possible? > > I will try to get our hands dirty with all the tools and resources you > suggested in order to gain some insight of what can be achieved from an > attacker. > > > Nick, > > > > > > -- > 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. > > > -- 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.
