New Mobile Doctor for Free

Dear Doctors,
For all you, who bought (or Buy) our AppStore Application 'Mobile Doctor'  until 30 May 2012,

we offer you for FREE the new version of the Mobile Doctor.

Please send us the receipt of your buy and we will send you the FULL APPLICATION WITHOUT ANY CHARGE.

Also we found 3 negative reviews of the mobile Doctor out of more than 150 unit sold. Please contact us to resolve your problems or satisfy your requests. Our goal is Zero dissatisfied customers.

Vergas Dimitris

dvergas@advent.com.gr

Read More

Reverse Engineering - Android APK

There's nothing really complex about this post. In the past I've always maintained that reversing is kind of tough; and that's true if its an EXE,DLL etc. But in the case of an Android application; it really is very easy.

While all this information is already there, here is a very short blog post summarizing how you get from APK to Source. I used a Vuln app available here; but you can use anything really. Here goes:

1. Extract the APK to a folder. Its just a Zip file so any archiving program should do; I use the inbuilt Ubuntu GUI archiving tool.

2. Rename the folder to something like original_helloworld. That's because we will play around with all the files inside  and it might be nice to have an original copy somewhere to look at when needed.

3. Look at the file AndroidManifest.xml. It'll open in a Text editor but its largely binary; hence unreadable. Use Apktool to decode this XML file as well as every other XML file in the APK. You can get it from http://code.google.com/p/android-apktool/. Download the main apktool package (contains a JAR) and the platform specific one as well (contains the apktool binary). Run apktool . It'll run and give you all the XML files totally decoded; so you can now read them.

4. You now want to recover code. All code is in classes.dex. Think of Dex as Android Byte code which is reversible to Java Byte Code....which eventually is reversible
to Java code. So we first 'dedex'. You can either use the output of apktool above; which after running gives you its output in a folder called 'smali'. A slightly more
 'easy to read' format is given by dedexer though (less spaces; cleaner output) available at http://dedexer.sourceforge.net. You use it as follows to 'dedex' classes.d
ex - java -jar ddx1.22.jar -d /opt/Android/vulnapps/Tmp_test_apps/InsecureBankDeDexed /opt/Android/vulnapps/Tmp_test_apps/InsecureBank.apk_FILES/classes.dex. Look inside InsecureBankDeDexed for the output. So in a nutshell, after we DeDex we get Android Byte code.

5. Once you have Android byte code; since Android code 'looks' very much like Java, you can convert Android byte code to Java byte code. Use dex2jar downloaded from
http://code.google.com/p/dex2jar/ and run it as follows ./dex2jar.sh ../../vulnapps/Tmp_test_apps/InsecureBank.apk. This results in a JAR file getting created in the d
irectory where the APK is already present. The JAR file contains all the JAVA class files; namely the Java byte code - something that you get once you compile your Jav
a code.

6. The last step is to convert your Java byte code into actual Java code. You need something called a Java decompiler for this. You can download one called the Jd-Gui from here - http://java.decompiler.free.fr/?q=jdgui. Once its downloaded, unzip the JAR and store all its class files in a single folder like JavaClassFiles. Launch JD-GUI and select 1 class file. Save the source. Repeat for each class file [Painful I know :(]. You now have all the source code and can do some static analysis on the code :). There's probably some cooler way to decompile all the class files in a folder; but I won't dig too deep into that just now.

Largely this presentation was where I got almost everything from. Will write more when I do some static analysis.

Read More

Market app - Android 2.2

Was doing a test on an Android app (first ever ;)) and was trying to install an app which was available on Android market. As it turns out, the emulator doesn't have the app pre-installed. So I followed instructions here. That largely works except that despite following everything the app vanishes the next time around. So after more digging I came up on this thread which provided the missing piece. I'll sum it up quickly.

--- You need to edit files on the emulator which will prevent the emulator from checking if its a valid phone or not
--- You need to upload the packages for the Market app and the GoogleServicesFramework as those are not shipped
--- You can do both of the above only if you have WRITE access to the emulator's system directory.

So far everything is covered by Varun's blog. The 1 point which he hasn't made clear is that once you've pushed all your changes to build.prop, uploaded the 2 apps mentioned above and deleted SdkSetup.apk you have to sync your changes and save the temp image in which all these changes are made.

Think of it in this way..all the changes you make are temporary and made in a file /tmp/android-. The filename starts with emulator. Once you're done making your changes save this file somewhere. Shut the emulator down. Now rename the saved file to system.img and copy it into ~/.android/avd/.avd. Now boot the emulator. It should work.

I've said nothing new frankly. If you use Varun's post and the post on the XDA forums together, you will be able to do this. However I was stuck for quite a while here, so thought a few guys would benefit by me linking the two together :)

Read More

Blogging elsewhere for a bit

I've been blogging at Infosec Institute (a little :)) and on the TeamMentor development blog (a lot) ... so that's why this isn't as updated with my experiences. Do peek at my work at II or on TeamMentor if you're interested in knowing what I am up to :)

Read More

Olly - Hit trace..finding code flow

Many a time we come across malware which is extremely confusing and has lots of JMP and CALL statements. It becomes very difficult to find out what exactly the malware is doing; if you use a purely manual technique..and you start seeing stars after a while. At least I did :)

So to help you understand the control flow better you can use something called a Hit Trace in Olly. Here is how you can best use a Hit Trace:-

a) Load the executable into Olly. You'll have to use 2.01; I couldn't find this in Olly 1.10.

b) Till what point in the code, do you want to understand code flow? Identify that point and set a breakpoint there using F2.

c) Once you've set the breakpoint, navigate to Trace - Run hit trace. This will automatically run the malware until the breakpoint that you had set earlier.

d) If there's some anti debug measures or the process simply exits before your breakpoint...you won't be able to see the Hit Trace at all. However, if the program is still active, you should see a little red dot to the left of each assembly instruction. This just says....'This instruction has been run at least once'.

You will notice a lot of gaps in between the 'red dot' lines. That is because those instructions were never triggered at all. You'll see this specially in cases of JMP instructions.

There's another feature called 'Run Trace' in Olly and the way to use that to identify code flow is to Log to File and then study the log.

Or lastly (as far as I know) you can set breakpoints and then use the 'Trace Over/Into and Animate over/Into) to step into and over code interactively using the '+' and '-' keys to go forward or back.

But the Hit Trace is quite neat and it offers a very nice option to identify control flow. Until next time ...bye :)

Read More

EXE dependencies - Read from PEB

I was trying to understand where executables load all their dependencies from. So for example: When I load up minesweeper (winmine.exe) there are a host of additional DLLs that are loaded up as well. That's fine as there are functions inside each of those DLLs that winmine uses. What was interesting to find out though, was how the list of those DLLs was built in the first place. Where did the OS loader look...into the process..to find out 'what else to load'?

So I loaded up winmine.exe in Olly, Dep Walker and a few other tools to get an understanding of 'what all' was loaded. Once that was done I read up a little about the PE header to understand where dependencies are accessed from. In PE terminology, these are called imports. It turned out there was a Data Directory for the Import Table. So i thought; lets read the import table; that should give me a list.

So I wrote a little bit of Python code [after learning Python from Google's Python class ;)] to read the IMPORT TABLE from the PE header. This did give me quite a few DLLs but it still did not tally with what Olly was displaying.

The next thing I did was to modify my code to be recursive. So...

--- Load EXE. Get dependent DLLs from import table.
--- Load 1st DLL from previous list. Get its dependent DLLs. Add to list.
--- Load 2nd DLL from previous list. Get its dependent DLLs. Add to list.

And so on... until all dependencies were resolved.This was doubtlessly an improvement as I was closer to what was displayed in Olly [Alt+E]. It still wasn't complete though.

Then I read some more, read how Dependency Walker works, asked on Woodmann and re-read a few sections from Xeno Kovah's Life Of Binaries class. Turns out there are somethings called Delayed Imports. These aren't loaded statically at load time; like the Import table but only when a particular function needs to be called..later on...at runtime.

So I modified the code a little to recursively get all the DELAYED IMPORTS too. This would have been enough but it gave me a huge huge list which contained much much more than what Olly ever showed me :). So obviously this wasn't efficient either and it was something else.

So as usual when I'm stuck I bug the nice guys on Woodmann and I'm rarely disappointed. This time was no exception and I was pointed in the direction of something called a PEB.

The PEB or the Process Environment Block is apparently the only "part" (very loosely used) of a process that is in User Mode. Everything else is in Kernel mode. So if you want to find out every DLL that an EXE depends upon; its best to query the PEB instead of doing all that stuff I did earlier :)

I want to quickly touch upon the structure of the PEB before I finish this post. To look at the entire structure of the PEB you can visit this link. You need to query the PEB_LDR_DATA structure to get the list of Loaded DLLs. Here is an article that I found quite useful while I was learning stuff about all this.

And lastly..here is the complete thread of my discussion on Woodmann, if at all you are interested :).

Read More

Links - All recent articles

I've been primarily writing for Infosec Institute these days; so there's very few updates on my blog. I could duplicate stuff here; but that's not of much use to me or anyone :). So if you're interested in what I'm writing about, do take a look here.

Read More