Saturday, December 8, 2012

Fighting a Userland Rootkit

Rootkit is a piece of software that alters basic OS functions in purpose of hiding its’ deeds. The rootkit is not necessarily a part of a malware, but it sure always smells like one. To alter the OS behavior from inside, kernel code (ring0) is required. In the WIndows world it means three things:

  1. The developer must be well trained in art of code writing, because kernel code is considered harder to develop.
  2. The user better have a certificate to sign his code, I recommend the Realtek private certificate for the job.
  3. A good understanding of the so-called Patch Guard mechanism, that is especially made to fight rootkits of that kind.

These requirements and more, have pushed the ill-trained rootkit developers back to userland.
The userland rootkit achieves its purpose by hooking the Win32 APIs. To explain that, lets consider an example in which a userland rootkit is installed on a system. Lets say that the main executable of the rootkit is named kitty.exe and it is stored in the system32 folder. Now the user uses explorer to look at the files found under system32 folder, and somehow he doesn’t see any kitty.exe file. What happened here? No, it is not a black voodoo magic, it is simply a hook that is set on the kerenl32.dll API FindFirstFile API that filters out the kitty.exe file from the results.
So what can we do to fight this sea monster if we can’t even see it? The FindFirstFile API implemented in the kernel32.dll is a function that utilizes the lower level undocumented ntdll API called NtQueryDirectoryFile, and few others. We can write a dir command that uses the low level API to query the content of the folder. Though it is possible that the rootkit is one step ahead of us, and is actually hooking the low level API.
Lets consider what the NtQueryDirectoryFile API is doing. If one disassembles the NtQueryDirectoryFile API, he would find that it doesn’t do much besides putting some magic number in the EAX register and jumping into a specially crafted address in memory which is called the sysgate (usally 0x7ffe0300). The special address contains the single opcode of "sysenter". The magic number in EAX, is called the system service id, which is a unique number for a system function. The sysenter opcode is the portal that takes the execution from userland to kernelland. So no matter what kind of hooking is done in userland, nothing can affect the code execution that is to follow the execution of sysenter.
Writing a tool that uses the syscalls directly without going through ntdll or kernel32 is possible, but very  unrecommended, as the system services are undocumented in Windows, and it is a bit more complicated than what is done in Linux systems. Nevertheless, I’m sure someone has  already done it, so please, do share if you have any knowledge of such.
One might say that using the syscalls directly is a great overhead for the task. If so, lets examine the boundaries of the userland rootkit before we proceed, to see if we have any other way to fight it. An attempt to look for the process in the Taskmanager or Sysinternals Process Explorer could fail simply because the APIs those tools are using are found in kernel32.dll and therefore can be hooked. The files and reg keys could be hidden in the same way, and so can any other kind of system query.
Most debuggers used on Windows platform use the Win32 debug api. Debuggers like that are ollydbg, IDA and my very own NativDebugging python scripts all use the debug API. For a userland rootkit it is easy to fool such debuggers, it can hook the OpenProcess API not allowing the debugger to attach to the rootkit process, it can change the results of ReadProcessMemory to reflect incorrect memory queries or it can simply hide itself from the processes list.
Therefore all of our tools are just useless in the battle against the userland rootkit. We are left with two options:

  1. Use kernel debugger such as Windbg.
  2. Undo the hooking of the rootkit to regain the power of our arsenal.

Kernel debugging, is a big cannon to fight a small fish but it would work. I’ll explain the second option using my NativDebugging Python module and Python.
There are 4 steps to this option:

  1. Inject into a target process a new copy of ntdll.dll with a different name (ntcopy.dll in my case).
  2. Parse the exports table of the NtDll.dll
  3. Enumerate all the other loaded modules
  4. Redirect any import from ntdll.dll to CopyDll.dll.

Note that I’m not trying to fight the rootkit directly, but to clean a single process that would later let me kill the rootkit in a more fashionable manner. The rootkit might also block the debug APIs in general, what would require few changes to the NativDebugging system, to use the system services directly.
To make this blog post shorter, I’ll redirect the curious readers to the source code of the script that does all of the above:
To manipulate the import / export of modules I’ve created a PE pattern that is found at:
more about patterns can be found in my presentation of “Looking Into The Eyes of The Bits”

More references:
My NativDebugging python module:
Installed by “python install
More about PE structure


Monday, October 1, 2012

Problems with software reverse engineering

A dark times to us all reverse engineers, especially the software kind. During my ~ten years of practice in the area, I’ve found out that today we have less tools for the task than what we had five years ago. Sure, nowadays IDA has a decompiler and some kind of a Python integration, but we all miss tools that served us for so long such as SoftICE and the Zynamics bindiff.
In this blog post I would like to tell my humble opinion on the subject.
Lets say a person, who I’ll refer to as the user, is given a one million pages long book (Font size 7). The user is being asked the simple question of “Does Alice ever meet Bob in this story?”. The user can read all million pages or die trying, in order to answer the question. But if the user had a digital copy of the book he could have searched for all of the places in the book where the word Alice and the word Bob are found not more than two pages apart. If the user had a Python interface to all the information found in the book, he could have used RegExp or some kind of lexical Python modules to maybe look for the word “meet” in all variations such as “meeting”, “met” or so on. Moreover, he could have found a way to figure out if there is a nickname for Alice such as “The Bitch”, and to automatically add this nickname to the search.
The way I see it, the current status of software reverse engineering is much closer to the hard copy book search task, than the digital one, and much further away from a decent Python interface.

The most commonly used tool IDA is giving the user a huge textual dump of disassembly, with some basic blocks, functions and higher level of understanding, where the highest level it gets is with the decompiler in which the user gets a C like code to read. I agree that it is easier to read C code than Opcodes but not by far. The user would never be able to read all the text for even the simplest program such as the Ms-Minesweeper. To produce this kind of text dump IDA had to had some kind of “understanding” of what each and every opcode is doing. I call this “opcoding doing” the opcode side effects. For instance, the side effects of the “ADD EAX, EBX” opcode would be reading EBX, EAX and writing to EAX and EFLAGS. IDA got this precious knowledge of side effects but it doesn’t let the user access it. I think this is the biggest point of failure in the understanding of what reverse engineering should look like.
Lets consider an example of creating a crack for a simple serial protected tool. The approach usually is of using a debugger to break on some known related API such as the GetDlgItemTextA or MessageBoxA to get to the point where the username is read or a wrong key message is displayed. Replacing this part of the task with a search of all functions in the code that are one or two steps away from both of these APIs, slicing with all the functions that contain the XOR opcode with two different operands, and some other characteristics relevant only to those kind of functions, would most likely produce a very short list of potential functions. When analyzing the functions, it is probably using many other functions that the user doesn’t care about, while only few of them are relevant to the serial validation. Displaying a list of all functions that are accessible from a certain function and filtering only the ones that might make an access to the buffer that is pointed by EDI or so, would make the job of the reverser much more effective.
The text of the opcodes is hardly ever what the reverser really cares about, he just wants to know what are the side effects of a function are, whether it changes EAX or not, whether it makes a copy of the buffer or not. The decompiled code is nice, but considering the fact that it’s not possible to recompile this code, why write it in C and not as an equations or list of arithmetic operations.
The reversing tool should be a much dummer tool that just creates the access point to as much information as available, the analysis should be done later on with scripts and plugins. The analysis that is done on a malware is not the same one that is done on a DRM product and is not the same one that is done on recovering algorithm.
However, putting all that aside, we have to have undo functionality. The lack of the undo function in IDA represents not only the fact that the tool is incomplete, it represents the fact that tool was made with small projects in mind, while sometimes the reversing work is something that is done over a long period of time. Symantec, Kaspersky and others told it took them a few months work of more than one reverser to get a basic understanding of the Stuxnet, which as far as I know, had very little anti-debugging tricks to it. IDA is not made for collaboration or long time research.

I would love to hear more opinions about this subject, and what people think should be done about it.


Saturday, May 26, 2012

Cheating the Android

Yarr everybody,

Long time since my last post, and today I’m returning to an old subject that I like very much. Cheating in games. And this time Android games.
I include in this post a small tutorial about patching an Android application, followed with introducing a big problem I’m facing in my attempts to cheat in various games. If you are already familiar with the technique of patching Android apps you can skip straight to the last paragraph where I talk about the problematic aspects of it. I would love to hear any comments the readers might have about my methods or any tips and tricks that might make the process easier to endure.

The Tutorial part:
I would walk you through the following steps:

  1. Getting the binary
  2. Unpacking, Disassembly and Decompiling it
  3. Finding a good place to patch
  4. Patching
  5. Repacking, ReSigning and ReInstalling the app
  6. Having fun

Setting up:
For these tasks you are going to need a rooted Android device (In some cases the emulator could do), and the standard ADK tools installed.
First enable the USB debugging from the Settings->Applications->Development menu, and connect to the computer with a USB cable. Now check the connection using the “adb devices” command. If the ADB can’t find the device, recheck the cable, the drivers and the adb.
Tip for those of you who use a Samsung Android device: the fastest way to get the right drivers is by installing the SamsungKies.

Step 1 Getting the binary
To get the binary of the application in target, you can simply search the right APK under  /data/app where usually APKs are stored. Or you can:
Run the application

  • Connect to the device with adb
  • Run “adb shell”
  • Run “su” (If needed)
  • Run “ps” to find the process id.
  • Run “ls -la /proc/PROCESS_ID/fd” and search in the long list of file descriptors for the apk file.
  • Pull the file from the device using the “adb pull” command.

Step 2 Unpacking, Disassembly and Decompiling it
For this step we will get to know not one but three tools to work with APKs
1. apktool
2. dex2jar
3. jd
The apktool would be used to unpack the apk file into its inner components. Using the command “apktool d APK_FILE OUTPUT_DIR”,  you can produce a directory with all of the components that makes the APK including a dir called smali that contains disassembly of the Dalvik bytecode. The smali files are text files that can be edited to make a patch. The directory can be repacked into an APK simply with the command “apktool b CONTENT_DIR OUTPUT_APK”.
Another tip: If you are facing any trouble during the repacking, you can try to unpack with “-r” flag “apktool d -r APK_FILE OUTPUT_DIR”, to leave the resources untouched, sometimes, the source to many problems is the resources. If you are not trying to deface the application don’t bother solving these problems.
The 2nd and 3rd tools are used to produce a decompiled, more readable code, and they are not a must for patching. The principle, is to open the APK file with a standard unzip tool, find the classes.dex file in it, use the dex2jar tool to convert the dex to a jar file, and decompile the jar with the Java decompiler.

Step 3 Finding a good place to patch
Now you’ve got lots of decompiled Dalvik code, use your reverse engineering talent to find a good cozy spot for your patch, or any other kind of cheats you would like. Note that some applications use a native arm code combined with the Dalvik code, which is usually found under the lib subfolder and could be disassembled with IDA pro as a ELF ARM (LE) binary.

Step 4 Patching
Patching, either by changing a smali file or by patching a lib file. Note, that the smali code is not the most familiar assembly, but I find it very intuitive and easy to understand.

Step 5 Repacking, ReSigning and ReInstalling the app
Repack using the apktool: “apktool b CONTENT_FOLDER OUTPUT_APK”. Now if you try to install the APK you just made, you would most probably get an error code that says “INSTALL_PARSE_FAILED_NO_CERTIFICATES”. In that case what you need to do is to use the signapk tool found at to sign the apk, you can use the sample certificate and key that are shipped with the tool.

Step 6 Having fun
Have fun.

The big problem:
Now if one would follow the exact steps trying to patch a game such as DrawSomething he would soon find out that most of the code is not in the Java nor in the native ARM binary. Instant the interesting part is found in another binary file called DrawSomethingFree.s3e, which is a binary file of the Marmalade SDK. Marmalade is a platform for developers to create games for both iOS and Android at the same time.
If one would try to decompile the Templerun game he would soon find a very similar story written in Mono for android. Mono is a C# like SDK for developing applications for both iOS and Android. Now this makes no sense, C# is a language made by Microsoft mostly optimized for Windows x86 platforms, why adapt it to Android, which handles Java like code naturally, is there really a benefit in C# coding style over Java? And if so is it worth the effort and the overhead of making a new VM to execute CLI code on Android?
Researching even further, I found out that there are awfully lots of such cross platform SDKs running everything from C to Lua including Python and Javascript. Each of them required understanding a new unknown homemade file type with new kind of bytecode encoding of some kind of imitation of a standard language.
I’m looking for any help from people on researching and understanding these files and how to disassemble and patch them for the better good.
So if anyone knows anything about the internals of any of the following:

  • Widgetpad
  • Whoop
  • RhoMobile
  • Shiva3d
  • SIO2
  • Unity
  • Corona
  • PhoneGap
  • Titanium Mobile
  • cocos2d-x
  • Edgelib
  • Moai
  • Mono
  • MoSync
  • Mominis
  • Marmalade
  • Simple DriectMedia Layer

I would be more than happy to learn more about it. And if anyone knows of any other cross platform environment, please let me know, as I’m trying to make some knowledge base about them.