Skip to main content

#!#!#! smali is drinking rootbeer !#!#!#

HEY GUYS WHATS UP

its 7 am in the morning the weather is good, why don't we just drink root beer. JK i don't drink beer, sorry!

so most of you probably have heard about rooting in android right? it is a method to obtain root access of the device, obtain root access inside the device means we can do basically anything inside it including customizing the ROM etc

so to summarize it rooting is just like privilege escalation but in android

but right now i am not going to talk about rooting but contrary i will talk about detecting rooting devices by this awesome android library called "rootbeer" and we are going to reverse engineer it and compile it again to bypass the checking by editing the "smali"

AWESOME SO LETS GET STARTED

well identifying rooting device is not really that hard once you grasp few tricks of it, it is really simple you just have to check value or configuration that suppose to be inside the unrooted device and compare it with the rooted device once you have that fat checklist you are good to go to create your own method.

Some checklist that i got:

  1. check installed package that are use in rooted device such as:
    • superuser.apk
    • com.noshufou.android.su
    • com.thirdparty.superuser
    • eu.chainfire.supersu
    • som.ramdroid.appquarantine
    • cyanogenmod.superuser (locate in com.android.settings)
  2. check the directory permission:(is the following directory is writable)
    •  /data
    • /
    • /system
    • /sys
    • /etc
    • /dev
    • /system/bin
    • /system/sbin
    • /system/xbin
    • /sbin
    • /proc
  3. check default file and configuration 
    • checking the build tag config
      • ~# cat /system/build.prop | grep ro.build.tags (if the build tags is gone it means is rooted)
      • ~# ls -l /etc/security/otacerts.zip (if the certs is not there it means the ROM is custom)
wow that is much of checking you have to do, it would be very hard if you coding it each of the function from the scratch and not to mention debugging the code. so i find this really cool library called "rootbeer"

link: https://github.com/scottyab/rootbeer

RESPECT! to the developer

to use this put the following line into your gradle build dependency:

dependencies {
    compile 'com.scottyab:rootbeer-lib:0.0.7'
}
 
 
to use the method of the library is pretty straightforward most of the function is in boolean value so you just have to use the method in if statement and determine what will you do next.

here is the simple code i use for my application:

the following code will show if the device is rooted with certain condition to be check, the function that checking root is check_root()


 the usage of the method is pretty clear to use as depicted above. you can get the code in my github:

link: https://github.com/acaciaworld80/mobile-coding-security/blob/master/root_checker.java

so i'm going to install the android app inside my rooted samsung phone for the sake of POC

so you might be thinking that the result is going to be all TRUE since it's obviously rooted, well not exactly, example taking from the rootbeer github:

Note that sometimes the isRooted() method can return a false positive. This is often because the manufacturer of the device rom has left the busybox binary. This alone doesn't mean that the device is rooted

now that we can conclude that some of binary configuration that is identified to be only reside in rooted device can lead to false positive result. because some of them configuration is from the manufacturer and don't consider as root so it is recommended to use other of the checking

ok so we successfully implement the code, so how do you bypass the checking ?

simple tho, you just have to reverse engineer the application -> modified the smali code -> repackaged the apps -> sign the app -> install it again



for the sake of the simplicity lets tamper with one of the detection, i choose the detectkeys method



1. reverse engineer the application = use apktool to decode the application to smali bytecode or you can use backsmali both of them is okay but i prefer to use apktool.


after i done reverse engineer the application i go to the com directory and represented with bunch of smali file. but lets just focus on MainActivity.smali file


you can open the file with any text file editor, in here i use nano text editor



reading smali instruction is not really difficult it just require little practice in smali all of the equivalent android code will be mapped to their smali instruction according to their line position in source code (mark with red rectangle)

in line 37 in my source code(yours might be different) it represent the condition checking if statement for the presence of production keys


if(rootchecker.detectTestKeys()){ //line 37


if the condition is not meet it will jump to the cond0 line 44 which is another if statement for checking potentially dangerous apps that indicate root device in the package directory


if(rootchecker.detectPotentiallyDangerousApps()){ // line 44


to bypass the checking of the root we just have to make the condition of the if statement to jump to another statement achieve this:




i declare one more boolean variable that contain true value (the first red rectangle) and i change the if instruction to, if the production keys is presence which is going to return true and i match it with my new boolean variable and if the value is equal it will jump to another condition. (the second red rectangle)

.line 36
const v1,1

means i create one new line between line 35 and 37, create boolean variable that contain true value

 if-eq v2,v1, :cond_0

i change the if statement at the line 37 from if-eqz(means equals zero) to if-eq (means equal). if-eq take two parameter to be compared is the two value is same it will jump to the cond_0

because the value that will return by the function detectTestKeys is true it will jump to another if statement.


check the below link to get more list of smali instruction it helps me a lot to

after editing the smali instruction build the package again with apktool and sign the apk with your own keystore


after that just install the application wala we bypass the first checking, the same concept could be bypass to bypass the rest of the condition.



so that's the end of this blog thank you have a good day :D





 



Comments

Popular posts from this blog

Having fun analyzing nginx log to find malicious attacker in the net (ง'̀-'́)ง (day 37)

  What makes you sleepless at night? is it because of a ghost or scary stories? is it because you have an important meeting tomorrow? or is it because you have an exam? For me, what keeps me up all night is that I keep thinking about what happens to a website that I just created, is it safe from an attacker (certainly not) or did I missing some security adjustments that lead to vulnerability? well I'm not the best secure programmer in the world, I'm still learning and there is a big possibility that I can make a mistake but for me, a mistake can be a valuable investment to myself or yourself to be better so from this idea, I want to know more about what attackers casually do when attacking a website. Here in this post, I'm going to show you how I analyzed attack to the website that I have permission to design and also some interesting findings that I could get from the analysis Background: All of this analysis comes from the traffic that is targeted to th

Utilize Pwntools for crafting ROP chain :') (day 69)

who doesn't like pwntools? it is a very versatile tool and can be customized according to our need using the python script but did you need to know that pwntools itself can help us to automatically craft a rop chain for us? so in this post, I will show you how to make rop chain less painful and make pwntools do all the heavy lifting. To demonstrate this I will use the binary challenge callme 64 bit from ropemporium link: https://ropemporium.com/challenge/callme.html Crashing the app: Like any other exploitation process, we need to crash the program by generating a long string pattern to determine the offset. based on the information from the above figure we can see that we required to provide 40 bytes of offset Fun stuff: now this where the fun stuff began write the following python script: as in the guideline of the challenged said we need to chain the function call by first to call the callme_one function, callme_two function and then callme_three funct

WriteUp PWN tarzan ROP UNICTF ಠ_ಠ (day 61)

So in this post, I'm going to talk about how to solve the Tarzan pwn challenge from UNICTF 2019. Back in the day when the competition is still going I couldn't finish it and don't have any clue to solve this but this time I was able to finish it :) Also in this post, we will be going to be heavily focused on how to utilize pwntools to construct a ROP chain. If you kinda confused about my explanation in this post you can refer to this following youtube video, link: https://www.youtube.com/watch?v=gWU2yOu0COk I build the python script based on this video Ok, let's get started! In this challenge, you will get two binary first go with tarzan and libc-2.29.so by providing .so file it tell us what version library that the target machine is using this could help us to do ROP chain. first, we run the Tarzan binary to get the basic idea of the program work and as you can see it just show you some text, newline and when you try to input something it doesn't gi