Unpacking ASPack-2.29 using Dynamic Analysis

ASPack is a Win32 executable file compressor which also protects the executable against basic Reverse Engineering. Although there are automated tools like IDA Pro's Universal Malware Unpacker or can probably be unpacked using techniques defined in BitBlaze Renovo, we analyzed ASPack protected executables using Dynamic Analysis particularly as an exercise for our upcoming training on Reverse Engineering and Malware Analysis at Nullcon 2012 Delhi.

Following analysis is based on Free version of ASPack 2.29.

ASPack-2.29 Generated Executable Overview

ASPack compresses each section of the input executable along with adding two of its own section: .aspack and .asdata - the former containing the decoder and loader code however it is currently not clear about the purpose of the later as it seem to be empty (SizeOfRawData = 0).

Section List for Original Executable

Section List for Packed Executable

Comparing the Section Listing of the original and packed executable above, following assumptions can be made:

• ASPack keeps the original sections intact including the section RVA however it sets the section mapping permission to RWX instead of the original R_X.
• ASPack adds two news sections - .aspack and .adata among which the purpose of .adata is unknown as it is empty.
• As understandable, the original entry-point is redirected to point somewhere within .aspack section.

Analysis Approach

The approach was conventional - start with Static Analysis to have a basic idea of the decoder logic and look for possible anti-debug or anti-diassambly technique and acquire enough knowledge to proceed with Dynamic Analysis. We needed to identify important code blocks like decoder loop, section mapping, control transfer to Original Entry Point (OEP) etc before we can proceed with automated unpacking.

Static Analysis

The entry point code in .aspack section in the packed executable uses a bunch of fake long and short jump op-codes (0xe9, 0xeb) to break the disassembler (Note: IDA 6.3 can detect such obfuscation technique and disassemble correctly without manual intervention). After little manual fix-up the code can be analyzed and IDA 5.0 (free) can build the Flow Graph correctly as shown below.

Three APIs as shown below in the disassembly were found to be resolved early in the loader code. Based on this logic, we made an assumption that those APIs will be used in order to decode and map sections and hence are perfect analysis points during Dynamic Analysis.

Dynamic Analysis

Phase1

We needed to verify that the decoded code is executed from its original location (as mapped by the PE Loader). Since our test executable was a GUI application (calc.exe) which inevitably calls GetMessageW, we set a breakpoint on the API and on breakpoint hit we could verify that the original code was decoded and execute from its original location only.

Phase2

Once it is verified that ASPack decoder decodes and execute original code in-place, we wanted to discover the decoder code block. For this we set a break-on-write (ba w4 addr-range in WinDBG) at the base address of the mapping containing the packed code.

Phase3

During Phase1 we noticed that the memory mapping of the decoded .text section is changed to R_X before execution from its original RWX permission as seen in the packed executable. From this we inferred that VirtualProtect must have been used before control is transferred to OEP.

Using this logic we were able to determine the exact point where ASPack loader transfers control to the OEP in the decoded .text section as shown below:

Little trial and error proved that ASPack loader does not seem to have any random or metamorphic component and hence this particular code above is always at an offset 0x420 from the base of .aspack section. The 0x00 above is patched with the computed OEP address at runtime.

Workflow for Automatic Unpacking

• Set breakpoint on entry point
• On breakpoint hit
• Set breakpoint on OEP Caller address (push)
• On breakpoint-hit
• Dump the PE
• Update entry point in PE Optional Header
• TODO: Re-construct IAT

The Tool

The tool is written using the wonderful Metasm Framework, without it a LOT of work would have been required. The core logic is as below:

The full code is available here.

Closing Note: ASPack is not really meant for executable protection as such, it is more of a compression system similar to UPX. For serious requirement, appropriate tools like ASProtect, Themida, VMProtect etc. should be considered.

Advertising:

We will be conducting a 2-days workshop on Reverse Engineering and Malware Analysis at Nullcon 2012 Delhi which includes topic as described above along with other interesting topics like Dynamic Binary Instrumentation, Binary Patch Analysis etc. If you are new to Reverse Engineering, we will try our best to equip you with the basics of x86 ASM and Win32 platform components so that you can benefit from open information available on the internet. Do check out if you are interested.

Reference

http://www.aspack.com/
http://metasm.cr0.org/
http://bitblaze.cs.berkeley.edu/

http://windbg.info/doc/1-common-cmds.html

Keystroke Logging within the Browser

During a recent PenTest, we had to exploit a typical Cross Site Scripting vulnerability in a Rich Internet Application which was making heavy use of Javascript and Ajax to present an almost Desktop like UI. The objective was to prove the severity of XSS vulnerabilities, as the client was not satisfied with a mere /XSS/ popup - even though so many examples exist on the open web.

The result of our effort was to show the client an almost real time keystroke logging by exploiting a Cross Site Scripting vulnerability in his application's console. Although there is a fairly stable Javascript Keylogger available here, we wrote our own as our requirement was quite specific, something as below:


The log transfer code is intentionally removed however it is trivial to transfer the data to any predefined location by injecting iframe or img tag or perhaps even with Ajax and CORS.

Although it is perhaps trivial to write a JavaScript Key Logger and in most cases probably it is unnecessary to use such payload as using an XSS bug a target user's session can itself be hijacked, however it might be useful in certain unconventional cases.

• Consider the case of Rich Internet Applications where the entire UX is Javascript driven and the page is never refreshed or re-loaded. Considering various near real-time use-cases like Chat, Message Ticker, Notification Message etc in the web console, it is sometime desirable to sniff user's activities which otherwise is not recorded by the application. In such a case, it might be useful to have a JS Keylogger payload handy for use with an XSS bug.
• Major browser plugins are written in Javascript and hence one cannot rule out the possibility of infecting plugins with malicious code. Perhaps this is particularly desirable for various banking trojans as a stealth alternative.
• Conventionally a keylogger for Win32 platform is written using the SetWindowsHookEx API. A defensive application such as an AV or an HIPS can reliably detect keyloggers at runtime by inspecting SetWindowsHookEx API. However if the objective is to log keystrokes on the browser only then it might be possible to use Form Grabbing like technique to inject malicious JS code by using eval like APIs.