A New Way to Detect Packers

Reverse engineering executables is always a very challenging procedure especially if the analyzed executable has been packed or encrypted.  I've been talking a lot about packers and unpackers (take a look to these posts here) but the technique I am going to show you is totally new respect to those already described.  As you might know the most difficult procedure of reversing a packed (or encrypted) executable is to find out the original entry point (OE). Again, there are tons of ways to figure out if an executable is packed or not (aka PEiD) but there is no a universal known way to unpack it. The following image shows PEiD in action.

PEID finds out that the executable has been packed with Aspack v2.12. Nowadays you might find specific unpackers (unpackers designed for a specific packing procedure)  but there is no way to have an ultimate universal unpacker. Here you can find many of those packers. YES, I know, there are universal unpackers too, but those unpackers are signature based, meaning that they are not able to unpack "new" packing procedure (algorithms), they must include the signature of every used algorithms. The following pictures shows one of my favorite Unpackers: Faster Universal Unpacker from RCE.

A group of the New Mexico Tech designed a visualization tool based on Entropy (system calls, oriented graphs and so on) called VERA (read more here, here and here).  By using this tool you are able to distinguish between packers / encryptors STUB and unpacked / decrypted code by simply analyzing the execution of the executable. The following image shows the notepad.exe (yes the one in WinXP) traced by PIN and visualized by VERA. I traced notepad.exe by fixing 2 minutes of execution here the result:

The blue label represents the Start address (which in this particular case corresponds to OE), yellow color means normal entropy, numbers in labels (you probably cannot see them because the image is too small) are the called addresses. The following image shows the same executable packet by using UPX. 

As you may see the are sections (calls to addresses) that have high entropy (meaning be packed or encrypted) represented with RED labels. This alerts us about the presence of a packer / encryptor. Where the is a continuously low entropy labels (purple) we can find the OE. This because the encryptor / packer STUB finished its job and unpacked / decrypted the executable code giving to the OE the control flow. The following image shows notepad.exe packed by BroExePacker.

In this case BroExePacker introduces a two levels of compression STUBs, you can easily distinguish them by looking at the red labels that are present in two points during the execution. This shows a typical two stage decompression. A first STUB decompress the function that decompress the real function who will decompress the original byte code (RED -PURPLE-RED-PURPLE). The OE is placed after the second RED labels. The following image shows the same executable (notepad.exe) compressed by the same BroExePacker but by using a different algorithm.

Again, we can easily discover that this executable has been packed, this time with one level STUB. The OE could be in a couple of positions. Experience will help a lot in finding the OE, but this Visualization tool considerably decrease the complexity of such operation. VERA could be integrated to IDA pro by installing an IDA Pro plugin making IDA Pro communicating to VERA through sockets. This integration makes a lot easier the interaction between the tracer (IDA Pro) and the visualization tool VERA. I  am not going to cover in this post how to integrate VERA with IDA, but I am rather cover how to use VERA and PIN in a very quick way. Once you download and  install VERA from its website ,  you will get the visualization tool (VERA) and a small installation of PIN.  PIN is the tracer, the one who will produce the  .trace file by executing the analyzed executable, the .trace file who will get VERA to elaborate  its diagram.  The following picture shows hot to run PIN with VERA template.

PIN is now running and tracing the analyzed executable. Let it running for a while (the time you decide) and then close the executable in a normal way (File -> Close, or whatever). Now opera VERA and click on Open. Select the file produced by PIN. Now VERA asks you about the original file and ask where to put its own graph file. The following image shows this process

Once you done with that, VERA will take a while and finally it will show you a graphic traced path. You will find more details on VERA and PIN manual. 

Summing up, I wanted to describe a new way to figure out if a executable has been packed or encrypted, and a new way to discover the Original Entry Point of the packed/encrypted executable. My experience in this field let me say that this is a great way to proceed and to learn about packers/encrypters.

Posted by Marco Ramilli at 2:26 AM

IDA Pro and VirusTotal Plugin

This morning I came across an interesting article from HexBlog titled: VirusTotal Plugin for IDA Pro. I took a look to the date, and actually it's not really new, but I believe it is still very actual. What a nice idea having the possibility to monitor your binary directly from VirusTotal ! If you are a malware writer this will increase your productively a lot, in fact you might test your binary on most of the known antivirus engines and if it is catch, dynamically you are able to modify it and resubmit it to antivirus engines for a second round of test. An of course you could follow on this way as many time as you like.

Lets see how to install the plugin:

1. You need to install on your platform simplejson (from here). It's a photon package for json ontology
2. You need IDAPython 1.5.1 (from here)
3. You need the plugin from here (BboeVt module) and VirusTotal plugin
4. Copy the BboeVt module to you Python site-package
5. Copy VirusTotal.py plugin to $IDA\plugins folder

Lets see hot to use it:

1. Run IDAPRO and open a database
2. invoke VirusTotal Plugin (Alt-F8)

That's it !

A huge thank you to hexblog folks !

Posted by Marco Ramilli at 12:19 AM

Antivirus Terminators

Antivirus terminators are specific malware able to terminate antivirus engines without the consciousness of the users in order to install themselves in the target system. This post is about specific techniques to terminate Antivirus.  Let describe what kind of terminator techniques could be used by common malware.

1. One of the most used technique, during the past years is the so called: "DebugActiveProcess". Its names comes from the Windows API used to achieve its goal. DebugActiveProcess API allows a generic process to attach itself to another process as a debugger. Debugging a process often means to control it. Since no controller has been implemented on Antivirus engine once an external process becomes its debugger it will crash immediately. Goal reached: Antivirus has been terminated!
2. Another way to terminate an Antivirus is through the Windows API  ZwUnmapViewOfSecion. This API unloads the described .dll. For example a process could unload important Antivirus .dll such as ntdll.dll. Once the Antivirus engine invokes a function wrapped on unloaded .dll it will crash. Goal reached: Antivirus has been terminated!
3. Another great trick is by getting the handle of an Antivirus engine. Let assume the Antivirus terminator call the Windows API OpenProcess passing to the function the Antivirus process Identification. Now Antivirus terminator can use APIs such as: NtTerminateProcess or ZwTerminateProcess to terminate the Antivirus engine at kernel level. Goal reached: Antivirus has been terminated!

1. Different techniques come from graphic user interfaces. Antivirus terminator can use the Windows API FindWindow to select the window to terminate. Through this API the terminator looks in the opened windows set for the exact window matching with the name of the Antivirus engine (such as: antivir, kaspersky, avguard, etc.. etc..). Once the terminator found the right window it terminates the Antivirus engine by sending messages such as WM_CLOSE or WM_QUIT through the respective SendMessage or PostMessage API. Goal reached: Antivirus has been terminated!
2. Another "graphic" way to terminate an Antivirus engine is by exploiting the function SendInput. Manipulating this API the terminator could stimulate mouse events clicking on the "close button". Through FindWindow API the terminator finds the desired icon, through SendInput it opens up the the desired window and finally it clicks on the close ("x") icon. Goal reached: Antivirus has been terminated!
3. Antivirus terminators could modify registry so that a NULL debugger is attached once the Antivirus engine starts its execution. For example by using ZwOpenKey and ZwSetValueKey the terminator could open a registry key and modify it to the desired value. Goal reached: Antivirus has been terminated!
4. Nonetheless the terminator could simply use the API TerminateThread to terminate some threads of an Antivirus engine. Again, Goal reached: Antivirus has been terminated!

These techniques are only some of the used techniques from malware writers, but they are still very used and effective.

Posted by Marco Ramilli at 9:40 AM

Windows Loader and ASLR on Binaries

Hi Folks, this morning I'd like to share a nice resource for analyzing ASLR on Windows Binaries. So far if you'd like to know if a given binary is currently using ASLR or not, you need to run it. You could run it through your favorite debugger (such as IDA or Olly ...) or by itself and later append to the run process an analyzer. But, obviously windows loader needs to know it before running the desired binary. So how does it work ? How does the loader know about ASLR on a given binary ?  If you are an avid reader of this blog you might had a chance to know answers to these questions ( here ). So what new about that ?  I've never found a static tool for that.

Summing up for newer readers, Widows Loader looks for a specific FLAG into the PE Header. In the PEHeader, specifically in the IMAGE_OPTIONAL_HEADER section there is a flag called DLLCharacteristics that defines many features for the executable during its loading time, 1 of them being ASLR.  If you take a closer look at the definition (you can find definition here) you might see the definition for DEP (NX bit) and for SEH too. 

Definition for IMAGE_OPTIONAL_HEADER, PEHEader section defining optional binaries features.

Myne-us wrote a simple ruby script which investigates through given binaries helping you in figuring out what "optional features" have been enabled on the passed binary. You can download the script here.  The script firstly loads the binary making the opportune controls over the PE format and later moves on the known offset checking bytes and filling on a main internal structure

Checking and moving to desired offset

Internal Structure

Personally I do like this simple script, it has been written in modular and very easy way. Pretty quick to upgrade with new features. I really would like to see a more complete static analysis from it, lets see if it will be uploaded ! ;) In the meantime it could be very useful to make static analysis over multiple files. Let assume you want to know how many binaries have ASLR or DEP enabled on your system, with current tools you need to open every binary dynamically and perform dinamic analysis. It would take forever. By using this simple script you might just cycle over every PEHeader and save output on a .text file ready to be analyzed from your favorite spreadsheet. Good Job !

Posted by Marco Ramilli at 1:36 AM

Breaking The linux Kernel SLOB Allocator

Today I suggest another interesting paper from security.com entitled "A Heap of Trouble: Breaking the Linux Kernel SLOB Allocator".  In this paper, Dan Rosenberg evaluates the implementation of the Linux kernel SLOB allocator to assess exploitability. He presents new techniques for attacking the SLOB allocator, whose exploitation has not been publicly described. These techniques will apply to exploitation scenar- ios that become progressively more constrained, starting with an arbitrary- length, arbitrary-contents heap overflow and concluding with an off-by-one NULL byte overflow.

The paper offers a nice background on Kernel Allocators, the following picture sums up the entire section

The paper follows on describing some different ways to compromise the linux kernel allocator, such as:

• Block Data Overwrite
• Free Pointer Overwrite

• Free Small Block Attack
• Block Growth Attack
• Little Endian Block Fragmentation Attack

• Big Endian Block Fragmentation Attack

The above pictures are taken from the original paper, each one represents the corresponding attack scenario. I decided to paste them here just to remember the main attack principles. Have a nice reading.

Posted by Marco Ramilli at 1:04 PM

Automotive Attack Surface

This morning I suggest this interesting paper titled: "Comprehensive Experimental Analyses of Automotive Attack Surfaces".  In their second paper autosec.org group analyze most of the possible attack vectors available on "last generation" automobiles. The following image shows, very well,  the amount of public interfaces in a modern cars.

Abstract :

Modern automobiles are pervasively computerized, and hence potentially vulnerable to attack. However, while previous research has shown that the internal networks within some modern cars are insecure, the associated threat model — requiring prior physical access — has justifiably been viewed as unrealistic. Thus, it remains an open question if automobiles can also be susceptible to remote compromise. Our work seeks to put this question to rest by systematically analyzing the external attack surface of a modern automobile. We discover that remote exploitation is feasible via a broad range of attack vectors (including mechanics tools, CD players, Bluetooth and cellular radio), and further, that wireless communications channels allow long distance vehicle control, location tracking, in-cabin audio exfiltration and theft. Finally, we discuss the structural characteristics of the automotive ecosystem that give rise to such problems and highlight the practical challenges in mitigating them.

While past researches, included the autosec.org first paper, focused on specific car vulnerabilities this paper tries to abstract vulnerabilities describing high level threats. In particular this research describes four vulnerability class such as:  Direct Physical,  Indirect Physical, short-range wireless and long-range wireless.

I like this paper, very easy to read and very entertaining. Nothing really innovative (at least from my persona point of view) but interesting to see how common "computer security" attacks could be applied to automobiles. I really hope they don't want to build their own testing methodology, I will hate to see another personal-and-specific security testing methodology. I rather hope they will learn/adopt common security testing methodologies.

Posted by Marco Ramilli at 9:19 AM

Today's threats.

A very nice map to fix some of the most important threats.

via

Posted by Marco Ramilli at 7:42 AM