From the previous posts i have showed all of you three different approach to solve owasp crackme level 1 problem. Now it's time to level up the challenge! lets try to solve the owasp crackme LEVEL 2 !
To solve this level the first few steps is same with the level 1, you need to get the java source code using reverse engineer tool (procyon, fernflower or enjarify) in order to know the flow of the application in deeper manner. Once you got the code go to the Mainactivity.java (located in /sg/vantagepoint/ folder) file to see the main execution of the program like the figure below.
if you take a look there are two function inside the Mainactivity.java. Inside the onCreate function it is same with the 1st challenge it has a debugging and root checking to prevent user for tamper with program execution and second function is the verify function that check with user input with the secret string. The second function using the "a" method from the "m" class to check with the user input if the user input the correct string it will show correct banner and if its wrong string it will wrong banner. (it is pretty basic tho!)
Now if you scroll little bit, you found the initialization of the m class and system.loadlibrary() function like the figure above. hmmm lets cut to the main event so we don't waste any more time, long story short i try to investigate the CodeCheck file (where the m class is created) and got me nothing. But system.loadlibrary() did shed some light to me.
according to the java documentation The
" java.lang.Runtime.loadLibrary(String filename) method loads the dynamic library with the specified library name. A file containing native code is loaded from the local file system from a place where library files are conventionally obtained " so i assume that the application used this library "foo" to check the code.
Android store runtime library in the lib folder inside its .apk file. you can just straight unzip the original apk file and go to the lib folder. Now! if you open the lib folder you will face with multiple directory based on the processor that the library can run (such as ARM and X86_64). You can choose any folder based on the processor type that you are capable to "understand" it because after this we need to reverse engineer the library. In this post i'm more comfortable with X86_64 because i have never read the ARM command
There is one library called "libfoo.so" (.so stands for shared object it is one of the most common executable type in ELF file). To reverse engineer the library i use the radare2 tools because it is more interactive rather than GDB tho.
Second there is a function that is "obviously" used to check the our inputted string ("CodeCheck_bar"). Now! go to the function and list all of the instruction like the figure below.
as you can see from the figure above the strncmp used in this function and take a look at the highlighted instruction. At the above highlighted the radare was able to decode the hex code to the string and give us the string "Thanks_for_all_t" this could be the secret string but apparently it only show half of it. The other half (highlighted one) is failed to decode by the radare2, so we need to decode it by ourselves.
follow the above command and list the instruction again with "pdf" command. The above command told the radare to recursively decode the hex code in memory 0x0000114a 0x00001152 and 0x00001159
wallaaa we get the secret string! but hold on it is kinda strange right ? its like the word is in reverse order. Well the answer is simple It is because the library used the Little Endian format. So if we put it together in one string it will show as "Thanks for all the fish"
That's all folks next we gonna try to solve this challenge using one of the famous tools for reverse engineering which is "frida"
Comments
Post a Comment