[REVIEW COMPLETED] 0x5h - Testing Root Detection (Android)

[muellerberndt]

Ready for review:

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md#user-content-testing-root-detection

[anantshri]

Article looks good, some suggestions for additional content.

another sample app with both native and java based root checks. https://github.com/devadvance/rootinspector/

Safetynet is the best option at this point when it comes to root/tamper detection however its not all fool-proof. example : https://www.xda-developers.com/sultanxda-bypasses-new-safetynet-unlocked-bootloader-check-on-latest-cm13-builds-for-op3/ here the feature is bypassed by modifying the kernel itself. Hence may be a word of caution to the app developer that even if they make these protections the data protection should not be neglected assuming the device is already compromized its better to have contingencies.

"Static Analysis" section Looks pretty confusing at Line 129 onwards. Are we asking testers to consider this a positive sign or a negative sign, some more elaboration will help. Some examples on Bypassing would be nice such as: Xposed based bypass : http://mattj.io/rootcloak/

For Dynamic analysis: if you are dealing with a phone home application starting even once on a rooted phone/device might mark it on the central dashboard as a rooted device and might disable access. So Best idea would be to go through the app in a static manner or running it with all debuggers etc attached with no outbound connectivity to phone home, typical cases would be MDM solution based apps or paranoid app developers which maintain and push updates in app dynamically.

Remediations: IS there any order in which the checks should be recommended, a list of checks at this section would be good. Something which testers can refer to as a quick starting point for the recommendation.

[muellerberndt]

"Static Analysis" section Looks pretty confusing at Line 129 onwards. Are we asking testers to consider this a positive sign or a negative sign, some more elaboration will help.

I think it is not very clear at the moment that the actual purpose of this chapter is testing the effectiveness of anti-reversing defenses, which root detection is a part of. Static analysis in this context means that one should make an assessment whether root detection has been implemented, and whether the way it is implemented is effective (which can however only be judged in the context of the overall scheme).

I've been thinking whether we should restructure the guide into "Security Testing" and "Reverse Engineering / Assessing Anti-Reversing Defenses" so we can group all the reversing and resiliency testing stuff together. But this would conflict with the current separation into Android and iOS.

Not sure what's the best way to do this atm, have to think more about it :)

[anantshri]

I would suggest against any restructuring. I think the current structure is fine But ya agreed we need more detailing and description in this.

[sushi2k]

Agree with @anantshri. Let's do not restructure. Once we have the content we can still shift it around as we want.

[muellerberndt]

@anantshri I added some stuff from rootinspector and changed the static/dynamic analysis part which is now called "effectiveness assessment". There's still work to be done on how exactly this is going to work which will be documented in this extra chapter. I'll revisit this later when the rest of the reversing content is finished.