Welcome to TiddlyWiki created by Jeremy Ruston; Copyright © 2004-2007 Jeremy Ruston, Copyright © 2007-2011 UnaMesa Association
By now you have unpacked bserver.ex_ (and we'll assume you named the dump bserver.unpacked.ex_). The exe uses a DLL and this example will discuss:
*Identifying the use of the DLL
*Tracing back to the DLL drop site
*How to extract the DLL
*Brief analysis of the DLL
!Walk-through
<<slider chkExeToDll [[From Executable to DLL]] "From Executable to DLL" "">>
<<slider chkDllUnpacking [[DLL Unpacking]] "Unpacking the Dropped DLL" "">>
<<slider chkDllUnpacking [[Inside the bserver.exe Dropped DLL]] "Analyzing the Dumped DLL" "">>
While it's nearly a guarantee that malware will call on standard Windows ~DLLs to accomplish its goals, it is not uncommon for malware to use custom ~DLLs during execution. They may be used as libraries using the ''~LoadLibrary'' / ''~GetProcAddress'' approach, or they may be ''injected'', in which case it is common that the ~DLLMain function takes over and runs without further intervention.
Before we dive into the Malware, we need to have make sure we've got our toolbox handy and loaded with everything required for the task.
For starters, we need to choose a platform (hardware, Operating System, and software frameworks) and network architecture. Some factors to consider:
*OS typically targeted by Malware to be analyzed
*Risks to network
*Operating Costs
*Backup/Restore Capabilities
An email arrives in your inbox: “You have to check out this picture!” It came from your friends address, which you know and trust. It beckons you to open it. Maybe you weren’t fooled this time, but it’s likely at least one of the 50 other recipients couldn’t resist.
As we store more of our confidential information on our computers, from bank account credentials, to company secrets, the reward to risk ratio increases as has the number malware (malicious software) threats. While anti-virus and intrusion detection systems have improved over the years, nothing can substitute a skilled malware analyst when a business needs to understand and mitigate a network intrusion.
This class picks up where the Introduction to R.E. Fundamentals course left off, exploring how static RE techniques can be used to understand what a piece of malware does and how it can be removed.
!Authors and Acknowledgement
Original content by Matthew Briggs and Frank Poz
Updates Spring 2013 and 2014: Frank Poz
Contact: knowmalware (at) gmail {dot} com
!Usage
These materials were developed using [[Tiddly Wiki|http://www.tiddlywiki.com/]]. Some content is hidden to prevent accidental spoilers. In order to understand the thought process of Reverse Engineering, it is very useful to go into these exercises with a clean slate. Walk-throughs may be accessed at any time by removing escape markers (slash-percent open, percent-slash close) from tiddlers such as:
{{{
/% <- Remove this line
"Walk-through tab" "" [[Walk-through-location]]
Does nothing if opening escape is removed -> %/
}}}
!Course Goals
<<slider chkCourseGoals [[Course Goals]] "Expand/Collapse" "">>
!Licensing
All materials are licensed under a [[Creative Commons "Share Alike" license|http://creativecommons.org/licenses/by-sa/3.0/]].
The term triage comes from World War I when French doctors, overwhelmed with patients, had to decide which could survive given treatment, and which were lost. In incident resposne, analysts have to decide not only if an incident warrants attention, but what level of attention is needed. Responders may refer to malware analysis to make such decisions.
Triage tasks should be:
*Scriptable
*Consume minimal time and resources
*Logged
**Consider a database for storage and retrieval of results
*Network Analysis:
**Command and Control Protocol
**Encryption Keys
*Removing contamination
**Disk modifications (including files, boot sector)
**Registry
**Firmware
<<tabs chkAnalysisGoals
"Identification/Detection" "" [[Identification/Detection]]
"Aiding Incident Response" "" [[Aiding Incident Response]]
"Correlating Attacks" "" [[Correlating Attacks]]
>>
!How big is the function?
Use IDA's Graph Overview to get a sense of size.
!What functions does it call?
If the function has no calls, or only calls library functions, we consider this a leaf node. We should be able to get a sense of exactly what a leaf node does.
!!Library Functions
IDA identifies both dynamic (pink) and statically-linked (light blue) library functions. Statically-linked functions are contained entirely in the executable while dynamically-linked functions are called through pointers and available to the application at run-time. Regardless of which kind of library a function belongs to, information *should be documented making analysis unnecessary (e.g. printf writes a formatted string to STDOUT).
!What functions call it?
!Does it take arguments?
!Does it use local variables?
<<tabs chkAntiAnalysis
"Anti-Debug" "" [[Anti-Debug]]
"Timing Checks" "" [[Timing Checks]]
"Structured Exception Handling" "" [[Structured Exception Handling]]
"Anti-Dump" "" [[Anti-Dump]]
"Anti-VM" "" [[Anti-VM]] >>
See the [[Anti-Analysis Demo|Malware Unpacking: Anti-Analysis Demo]].
!Debugger Flags
Since there are legitmate reasons to detect a debugger (e.g. Debug Print), Windows leaves flags in each process that tell a process it's being debugged. Additionally, some API functions also reveal this information. Some examples:
*PEB!''~IsDebugged'' flag is a common check:
{{{
mov eax, fs:[30]
mov eax, [eax+2]
test eax, eax
jnz exit_debugger_detected
}}}
*kernel32!''~IsDebuggerPresent'' function
*ntdll!''~NtQueryInformationProcess'' with ''~ProcessInformationClass'' argument of ''7'' (''~ProcessDebugPort'')
{{{
NTSYSAPI NTSTATUS NTAPI NtQueryInformationProcess(
IN HANDLE ProcessHandle,
IN PROCESS_INFORMATION_CLASS ProcessInformationClass,
OUT PVOID ProcessInformation,
IN ULONG ProcessInformationLength,
OUT PULONG ReturnLength
);
}}}
!Thwarting Debugger Checks
At the most basic level, debugger checks can be evaded by ''altering debug flags or API return values'' in memory/registers. Some tools are provided to silently handle SOME of these checks for us:
* Ollydbg's plugin: Olly Advanced
* Immunity Debug's hidedebug.py Plugin can fool many common anti-debug checks
** http://code.google.com/p/muffi/source/browse/#svn%2Fbranches%2Fjms
* ~IDAStealth Plugin
** http://newgre.net/idastealth
!Exercise
If you have [[Practical Malware Analysis|Books]], check out Lab16-01.exe
{{ Image {
{{center{ [img(70%,)[tooltip|images/dropper.api_hooks.png]] }}}
}}}
One of the unusual behaviors of this unpacker is its API Hook option. If enabled, the unpacker hooks certain API calls (e.g. ~CreateFileA), replacing the function points of the API calls with pointers to functions bundled with the unpacking stub.
!Why Hook?
*Prevent protections from breaking the application
**When anti-dump (file locking) is enabled, this allows the protected process to access the file
*Overwrite hooks created by monitoring tools
!Bypass
A simple memory patch can be applied to integer stored at ''EBP + 406D35'', replacing a 1 with a zero (assuming this option has been selected).
Looking ahead in the code, we see a series of push/call sequences, and the calls are made through memory locations (API calls?).
{{ Image {
{{center{ [img(70%,)[tooltip|images/dropper.anti_dump.png]] }}}
}}}
!Memory Dump
The dump pane (below the assembler window) allows can help us inspect the pointers being accessed through EBP.
#Right-click inside the dump pane
#Choose Long -> ''Address with ASCII dump'' from the right-click menu
**This view wil display 4-byte integer values (Little Endian) and the ASCII representation
**It also displays call function identifiers when the integer value is a pointer to a function
#Jump to Expression (''~Ctrl-G'') ''EBP+406BED''
**You'll find that this location contains a pointer to ''~CreateFileA''
**The following location (''EBP+406BF1'') refers to ''~GetModuleFileNameA''
!Analyzing the parameters
The ~GetModuleFileNameA call pictured first takes two parameters (Remember, function arguments are pushed in reverse order):
#0 (zero) indicates we want the name to the current file
#DWORD PTR SS:[EBP+406E33] is a pointer where the file name will be stored
The ~CreateFileHandleA call pictured takes 7 parameters, but the most critical are the first and 3rd
*The file name stored in previous call is passed first
*The 3rd parameter is the dwShareMode, which is set to 0 (zero)
**dwShareMode of zero instructs the OS to prevent other processes from accessing the file
~OllyDump and other process dumping tools read the header of the executable file on disk to get the PE headers. By gaining exclusive access of the file, the unpacker has prevented dumpers from reading the file, resulting in failure.
#Load dropper.exe into into Immunity Debugger
**The entrypoint is a bit unusual. We see a call, and a jump into the middle of an instruction.
#Step into the first call
**esi gets the stack pointer
**eax gets top stack value (return pointer) from esi (lodsd)
**cl (ecx) gets 0xFF, an index/counter for the LOOPD {{ imageblock {
{{center{ [img(70%,)[tooltip|images/dropper.entry.png]]
Figure 1: The Entry Point and first decode loop. }}}
}}}
#Add breakpoint (f2) at 0x0040900C
#Run to the break (f9)
#Step past ret and jmp
##Note the similar call/loop structure, verify no exits to other code
#Add breakpoint (f2) at 0x00409027 and run (f9)
#And we face yet another loop (ecx=0x5f7 indicates a significant decode). Run until break again.
!Bumps in the road
We've decode a bunch of code, but it seems we've just begun. Why do I say this?
*The only unexplored code that has been decoded is 0x5f7 bytes long (a small fraction of the code file size)
*Imports haven't been resolved
Now the fun begins!
*We are faced with another SEH trap. Once again, we can break inside the exception handler {{ imageblock {
{{center{ [img(90%,)[tooltip|images/dropper.2nd_violation.png]]
Figure 1: EAX is initialized to 0 and then dereferenced. }}}
}}}
*This begins by accessing FS:[30] (the PEB), and then tests the 3rd byte (+2) to determine if it is not zero. {{ imageblock {
{{center{ [img(70%,)[tooltip|images/dropper.IsDebugged.png]]
Figure 2: Inside the 2nd Exception handler the PEB.IsDebugged flag is checked. }}}
}}}
**This is a common check for the PEB.IsDebugged flag. A common anti-debugging trick.
**We can use the hidedebug plugin {{ imageblock {
{{center{ [img(70%,)[tooltip|images/HideDebug.png]]
Figure 3: Hide Debug patches the process memory to remove debugger artifacts. }}}
}}}
*Now we can step past such blocks without a care
The next code segment is a bit more complex. We see:
*It has several references to from the FS register
**The code reads and writes FS:[0] ) (Head of the Structured Exception Handling chain)
**The memory reference ''DWORD PTR SS:[EBP+4066AD]'' becomes the new exception handler {{ codeblock {
{{{
EXCEPTION_CHAIN
}}}
}}}
*The code references memory at address ''DWORD PTR DS:[ECX]''(where ecx is zero), a common intentional exception {{ imageblock {
{{center{ [img(70%,)[tooltip|images/dropper.exception1.png]] }}}
}}}
*Generally the debugger intervenes when an exception occurs. This can cause us to lose our place and have to start over
*Press ~Ctrl-G to bring up the Jump by Expression dialog
**Enter EBP+4066AD into the box {{ imageblock {
{{center{ [img(70%,)[tooltip|images/dropper.seh1.png]] }}}
}}}
**This restores esp to its pre-exception state
**It removes the current exception handler from the chain
**It also adds 4 bytes to the stack pointer leaving the value that was push on line 0040907E.
**This leaves 00409094 on the stack for the return
*Jump to 00409094, place a breakpoint, and run to it
!Debugger Exception Configuration
Debuggers often allow the user to break on exceptions and (debugger takes control) or pass the exception to the application. In Immunity Debugger:
#Click the ''Options'' menu -> ''Debugging Options''
#Choose the ''Exceptions'' tab
#Check the boxes for any exceptions the application should handle
##If the exception is not listed, Click ''Add Range''
##Select the ''First exception in range''
##Select the ''Last exception in range'' to include
##Click OK
#Click OK
In dropper.EXE, the exceptions could be bypassed by ignoring ''Memory access violation'' exceptions.
*The handler accesses a CONTEXT struct (at SS:[EBP+10]) which contains CPU state at the time the exception occurred.
*EIP is read into EDX and EBP is subtracted from that.
*The resulting value is compared with 0x004062A0 {{ Image {
{{center{ [img(70%,)[tooltip|images/dropper.seh.context_obj.png]] }}}
}}}
*DS:[EAX+B0] receives 0x401000. Here the debugger repairs the register that caused the exception. EAX will be in 0x401000 on return from the handler.
*Control will return to faulting instruction.
~Anti-Virtual Machine techniques may be used by malware authors, although they must take into consideration their targets. If the target is a commodity home computer, it is more likely as they are less likely to be using virtual machines.
!~RedPill
Polycrypt was created at a time when VM Detection was a hot topic. Observe the following code in dropper.EXE after the first 3 decode loops have executed:
{{ imageblock {
{{center{ [img(70%,)[tooltip|images/dropper.redpill.png]]
Figure 1: An sidt instruction often indicates the Red Pill VM detection technique }}}
}}}*This is the (in)famous Red Pill reported by the invisiblethings blog years ago. It:
**executes the SIDT instruction (which returns the Interrupt Descriptor Table Address/Size)
**Checks that the IDT address is within a given range known to ~VMWare and ~VirtualPC.
**Aborts normal execution if check succeeds
*Results are unreliable in Multi-core processors as each core returns a different value, thus ~RedPill can result in false-positives
!Other methods
*~NoPill uses the SGDT instruction
*Other instructions exist (sldt, smsw, cpuid, etc) that have been exploited to "detect" ~VMs
*Searching for ~VMWare Tools Process and Files
Unpacking can require some trial and error. We often can make educated guesses as to where transitions from unpacker code to the application to speed up the process. If we scroll through the code, we eventually encounter the following:
{{ ImageBlock {
{{center{[img(70%,)[tooltip|images/dropper.possible_tail.png]]}}}
}}}
This is consistent with exit code, because it:
*Restores the base pointer
*Restores all registers and flags (popad, popfd)
*Sets up the return value with a push/return sequence
Oddly enough, the pushed value is 0. For now it appears this code returns to address 0 (zero), but if we create a breakpoint (ideally hardware) on the return (this will take some patience): {{ Image {
{{center{[img(70%,)[tooltip|images/dropper.unpacker_exit.png]]}}}
}}}
You'll notice the push instruction now has the value ''dropper.00401568'' in place of zero.
!Why was that so slow?
If you look at the log window, you'll notice lots of messages about int3 instructions being reached. As the unpacker decrypts the application code, EIP repeatedly reaches a lot of these int3 (0xCC), which causes a brief context switch to the debugger, causing a slow down. We can risk replacing the 0xCCs with NOP (0x90) instructions (at risk if the code is used in the decryption calculations), or we can let it run its course.
!OEP!
If we step past the return instruction, we'll find the following:
{{ Image {
{{center{ [img(70%,)[tooltip|images/dropper.oep_no_analysis.png]] }}}
}}}
The debugger has not yet diassembled this code, so we can force this with Ctrl-A:
{{ Image {
{{center{ [img(70%,)[tooltip|images/dropper.oep.png]] }}}
}}}
This looks good. Dump it with OllyDump, and if you're not sure, you can leave the debugger running while you take a look at things in IDA (and perhaps try to execute the dumped file).
* Accomplished be preventing access to files/memory
** ~CreateFileA with dwShareMode of 0 can prevent file access
* ~OllyDump must be able to read the .exe file headers to succeed
!Overview
* ~RedPill uses SIDT (a very uncommon instruction) to detect a VM
** ~VMs have to use a different Interrupt Descriptor Table address than the host system
* Other detections may search for VM software artifacts (e.g. ~VMware Tools)
!Exercise
If you have [[Practical Malware Analysis|Books]], check out Lab17-01.exe
* //Practical Malware Analysis// by Sikorski and Honig, 2012, http://nostarch.com/malware
* //The IDA Pro Book, 2nd Edition// by Chris Eagle, 2011, http://nostarch.com/idapro2.htm
*Attributed to Julius Caesar
*Uses an ordered alphabet and translates each letter by addition
**Caesar used an Add 3 ('A' becomes 'D')
*Wraps around at the end of the alphabet
**('X' -> 'A', 'Y' -> 'B', 'Z' -> 'C')
*Typical Software implementation is an Add of byte values (e.g. add al, 0x03)
{{center{ [img(50%,)[tooltip|images/800px-Caesar3.svg.png]]
Figure 1: Caesar Cipher using Add 3 }}}
Where available, examples have been included in parentheses:
* PDF (~CVE-2011-2462)
* Javascript in PDF (~CVE-2009-4324)
* ~MS-Office document (~CVE-2009-3129)
* Flash object (~CVE-2012-0754)
* Flash object in PDF (~CVE-2011-0611)
* Flash object in ~MS-Office document (~CVE-2012-0754, http://contagiodump.blogspot.com/2012/03/mar-2-cve-2012-0754-irans-oil-and.html)
* RTF (~CVE-2010-3333)
* Java (~CVE-2011-3521)
* Compiled HTML Help / CHM
*Shared Functions
*Common strings
**Domain Names
**IP Addresses
**Prompts
**Network Protocol
*PE Headers
**Imports
**Exports
**Section Names
*Compiler Detected
!How to set goals for analysis
!Static Analysis:
*Identify points of interest based on goals
*Understanding code flow
*Malware pattern recognition:
**API Call sequences
**Staging and Execution
**Persitence
**Encoding/string manipulation functions
**Command and Control
**Anti-Analysis:
***~Anti-Debugging Techniques
***Anti-Dump Techniques
***Anti-VM Techniques
**Shellcode
***PDF / ~JavaScript Deployment
!Debugging
*How breapoints work
**How they are exploited by anti-analysis
*Using plugins
*Dynamic Unpacking
!Development
*Scripting IDA
*Scripting Debuggers
*Using pefile for bulk analysis
*Signature Development
!Tool Proficiency
*IDA Pro
*~ImmDbg / ~OllyDbg
*CFF Explorer
<<tabs chkDlls
"About" "" [[About DLLs]]
"Execution" "" [[DLL Execution]]
"Example" "" [[A DLL Example]]
>>
!~DllMain
~DllMain is the entry-point function of a DLL, which is responsible for initialization of any global variables provided by the library. It is useful to know that when ~DllMain is called, the loader provides three arguments to this initialization function. The function prototype looks like this:
{{{
BOOL WINAPI DllMain(
__in HINSTANCE hinstDLL,
__in DWORD fdwReason,
__in LPVOID lpvReserved
);
}}}
The <<slider chkDllReason [[DllMain fdwReason Argument]] "fdwReason" "">> argument identifies for what reason the DLL was loaded.
!Exports
While malware ~DLLs often do their dirty work from ~DLLMain, the exports of the DLL shouldn't be overlooked. In IDA Pro they can be found in both the Exports window as well as the Entry Points dialog (which ''~Ctrl-E'' reveals) to provide quick access.
!Executing ~DLLs in a debugger
At times you may want to analyze a DLL in a debugger. IDA Pros debugger requires an executable to be designated for loading the DLL, while ~ImmDbg / ~OllyDbg come with an application which handles the DLL load.
It is also possible to treat the DLL like an executable. In your favorite PE editor (e.g. CFF Explorer), disable:
{{{
IMAGE_FILE_HEADER->Characteristics IMAGE_FILE_DLL flag (0x1000)
}}}
Remember that ~DllMain expects 3 arguments, so if the DLL is treated as in executable, the main function may try to access arguments that don't exist (as they are not available to an executable).
#open in CFF Explorer
**has no exports
***this means functionality should all be in main
#Change ~FileHeader -> Characteristics: Uncheck File is a DLL
#Click OK, and Save
#Open dll in ~ImmDbg
#Find tail jump, break and step
**NOTHING?!
#Restart
#Initial check is checking to see how the DLL was loaded
#Move origin to after jnz
#* or, single-step until jnz, then set ZF to 1
#Run to break
#Single Step to OEP
#dump
<<tabs tabClass
"About" "mouseover" [[Data Encoding: About]]
"Code Features" "mouseover" [[Data Encoding: Code Features]]
"Common Algorithms" "mouseover" [[Data Encoding: Algorithms]]
"Decoding" "mouseover" [[Data Encoding: Decoding]]
"Tools" "mouseover" [[Data Encoding: Tools]] >>
!Purpose
*Evading Detection
*Increase Analysis Complexity
!Oft Encoded Data
**Network Traffic
**Strings (e.g. ''Domain Name'', ''File Names'', ''Registry Keys'' )
**Payloads (Files and Shellcode)
!Common block/byte transformations:
*<<slider chkCaesarCipher [[Caesar Cipher]] "Caesar Cipher (Character/Bit Add)" "">>
*XOR and variations
** <<slider chkXorExample [[Data Encoding: XOR Example]] "Example" "">>
** <<slider chkXorExercise [[Data Encoding: XOR Exercise]] "Exercise" "">>
*<<slider chkBase64 [[Data Encoding: Base64]] "Base64" "">>
*<<slider chkEncryption [[Data Encoding: Encryption]] "Encryption" "">>
*<<slider chkCompression [[Data Encoding: Compression]] "Compression" "">>
*<<slider chkString [[Data Encoding: String]] "String Encoding" "">>
!String obfuscation:
The methods that can be used to obfuscation network traffic can also be used to obfuscate strings, files, or blocks of code.
There are other methods of hiding information in a binary. One method is via MOV instructions:
{{{
mov ecx, 0x400000
mov [ecx], 0x53 // 'S'
inc ecx
mov [ecx], 0x54 // 'T'
inc ecx
mov [ecx], 0x52 // 'R'
inc ecx
mov [ecx], 0x00
}}}
This sequence would put the ASCII string “STR” at the memory location 0x400000.
A variant of this is to construct the string via one or more PUSH instructions:
* PUSH 0x00525453
<<slider chkStringExercise [[Data Encoding: String Exercise]] "Exercise" "">>
*Used in legitimate network communication (e.g. ~MIME-encoded e-mail)
*Often characterized by presence of decoding dictionary or "alphabet" such as:
**~ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
**<<slider chkBase64Example1 [[Data Encoding: Base64 Example1]] "Example" "">>
**<<slider chkBase64Example2 [[Data Encoding: Base64 Example2]] "Example" "">>
**<<slider chkBase64Exercise [[Data Encoding: Base64 Exercise]] "Exercise" "">>
Walkthrough:
# Open ''~WEBC2-CLOVER_sample\~WEBC2-CLOVER_sample_065E63AFDFA539727F63AF7530B22D2F'' in IDA.
# Go to start of binary.
# Perform Binary Search (Alt+B) for “ABCDEFGHIJKLMNOP” (include double-quotes).
# Load binary into ~PEiD.
# Run the Krypto Analyzer plugin.
# Compare results of IDA search and ~PEiD analysis
Students should duplicate the steps above, first with the same binary show here, and then with ''~WEBC2-CSON_sample_A38A367D6696BA90B2E778A5A4BF98FD''. What's different about the ~WEBC2-CSON binary?
Walkthrough:
# Drag-n-drop ~WEBC2-CSON_sample_A38A367D6696BA90B2E778A5A4BF98FD onto the ''ida-ent.exe'' icon.
# Change //chunk size// to ''40'' and //max entropy// to ''5.97''.
# Double-click on the data section.
# Click the //Deep Analyze// button.
# Load ~WEBC2-CSON_sample_A38A367D6696BA90B2E778A5A4BF98FD into IDA and view the address identified via ida-ent.
#* this is a custom base64 alphabet
Use ''~Old2008-2010__A6C1595BD7B1A85C42FBD674460DC35D_iprinp.dl_'' to duplicate the process with ''~PEiD'' and ''ida-ent.exe''. What do you find?
!Common characteristics of encoding functions
*Loop
*reads AND writes data from memory
**Likely reads are from an address passed as a pointer function arg
**mov reg1, [reg2]; "...processing..."; mov [reg2], reg1; inc reg2;
**[ base + scale * index ] )
**esi / edi (lods, stos)
*Many xrefs (assuming many strings to encode / decode)
**Exception where all strings are processed at one time
**Enables us to quickly decode all strings by iterating over xrefs
* zlib (RFC 1950) sticks a header onto the compressed data, so seeing one of the following sequences of bytes at the start of a buffer could indicate that it is zlib compressed:
** x78 x9c
** x78 xda
** x78 x5e
** x78 x01
* <<slider chkZlibExample [[Data Encoding: Zlib Example]] "Example" "">>
As mentioned previously, there are many ways to encode strings with a binary. Sometimes, it’s easier to run the malware in a debugger and put a breakpoint immediately after the string is decoded. Other times, you’ll need to write your own script or program to decode the data.
There are multiple options for writing your own script. If you are working on ~MS-Windows, there is Immunity Debugger, ~PyDbg, and IDA Pro. The latest version of IDA Pro comes with ~IDAPython plugin built-in, which allows easy scripting of the debugger. It is also possible to extract the function from the malware and call it directly using C or ~PyEmu.
We will be using Immunity Debugger for the following example, as it is freely available and relatively simple to use.
<<slider chkDecodingExercise [[Data Encoding: Decoding Exercise]] "EXERCISE" "">>
<<slider chkScriptTheDecoding [[Data Encoding: Script the Decoding]] "WALKTHROUGH: Script the Decoding" "">>
Open ''nba_implant_exe'' in IDA and take a look at ~WinMain(). It appears that there is a reference to an encoded string in the first part of the function.
# Which function is the decode function?
# How many arguments does this function take?
# Where would we put a breakpoint to read the decoded string?
# This sample of malware is not preventing us from simply running the code from the start of ~WinMain(). However, assume that it is. How can we execute just the part of the code that decodes this string?
Walkthrough:
# Load 4a29d41dfda9cfcbcde4d42b4bbb00aa.ex_ into ~PEiD
# Run the Krypto Analyzer plugin
## Export
## To File
## IDC Script - Bookmarks and Comments
# Load the binary into IDA
# Load and run the previously saved IDC script
# Reload 4a29d41dfda9cfcbcde4d42b4bbb00aa.ex_ into ~PEiD and run the Krypto Analyzer plugin on it again.
# Load it into ida-ent.exe and perform steps as before, but with the .rdata section.
# Compare the results from ~PEiD and ida-ent.exe.
* DES
* AES
* Camellia
* ~RC4
* <<slider chkEncryptExercise [[Data Encoding: Encrypt Exercise]] "Exercise" "">>
* <<slider chkEncryptExample [[Data Encoding: Encrypt Example]] "Example" "">>
*mspmsnsv.dl_ (from contagiodump file “~CVE-2011-0611_2011-04-08_SWF-DOC_Disentangling Industrial ~Policy-Created Files.zip”)
*malware.exe from 4a29d41dfda9cfcbcde4d42b4bbb00aa.zip
*From http://contagiodump.blogspot.com/
**~WEBC2-CLOVER_sample_065E63AFDFA539727F63AF7530B22D2F
**~WEBC2-CSON_sample_A38A367D6696BA90B2E778A5A4BF98FD
* nba_implant_exe (~NetBot Attacker)
* Open notepad.exe
{{{
import immlib
def main(args):
imm = immlib.Debugger()
imm.setReg(“EIP”, 0x401046)
imm.setBreakpoint(0x401068)
imm.run()
}}}
* Save As “nba_decode_str.py”
* Copy to c:\program files\Immunity...\~PyCommands\
* Run Immunity Debugger
** Open nba_implant_exe
** Look at encoded string
** !nba_decode_str
** Look at decoded string
Check out [[Practical Malware Analysis|Books]]'s pp291-294 and Lab13-2 for more examples.
* ASCII
* Unicode
** ~UTF-16 (widechar in Windows is little-endian form of this)
** ~UTF-8
** ~UTF-32
# Load ''~WEBC2-UGX_sample_8462A62F13F92C34E4B89A7D13A185AD'' into IDA
# Look at the sub_406044() function
# What are the ASCII strings created in the above described manner?
#* What can you infer about this malware based on these strings?
Use these tools to identify different data encoding libraries. Scripting languages can be used to quickly decode strings (idc, python).
!Tools
* ~PEiD's KANAL plugin
* IDA Pro's ~FindCrypt2 plugin
* IDA Pro's Entropy plugin / tool
Using IDA and ''4a29d41dfda9cfcbcde4d42b4bbb00aa.ex_'':
# Search (~Alt-T) for ''xor'' with //find all instances//
# Which addresses are not simply clearing a register?
TIP: if you don't search with //find all instances//, then make sure you put the cursor at the start of the program, otherwise it won't search all the code.
Load ''mspmsnsv.dl_'' into IDA (this file is from contagiodump.blogspot.com)
# Which function contains the XOR loop?
# How does it differ from a simple, static, one-byte XOR loop?
# Load ~WEBC2-CLOVER_sample_065E63AFDFA539727F63AF7530B22D2F into ~PEiD
# Run Krypto Analyzer plugin
A disassembler is software that reads [[Machine Code]] and outputs [[Assembly]]. In Malware Analysis, a common scenario is to open a [[Microsoft Portable Executable|Portable Executable]] with IDA Pro, which provides a graphical interface that displays x86 assembly code.
{{{
#define DLL_PROCESS_DETACH 0
#define DLL_PROCESS_ATTACH 1
#define DLL_THREAD_ATTACH 2
#define DLL_THREAD_DETACH 3
}}}
!About
Manual unpacking of an executable, as performed in a debugger, leaves the analyst in a state of with the original entry point code in memory. Although further analysis could be performed in this state, the ideal case is to create a new file that can be analyzed in a disassembler.
IDA Pro has a memory dump feature. Although useful, the data is stored in a format that is unusable by other tools.
!Ollydump
A plug-in is available for Ollydbg called Ollydump which can:
# write a new executable from the unpacked data in memory
# change the OEP to one specified by the user
# attempt to reconstruct the imports table
!Other Tools
* ~ImpRec
* ~LordPE
* Windows XP built-in debugger: ntsd.exe
* ~WinDbg
* ~OllyDumpEx plugin for Ollydbg and Immunity (http://low-priority.appspot.com/ollydumpex/)
Generally used as a first pass attempt to understand a piece of software, Dynamic Analysis uses an ''Execute and Monitor'' approach to understand observable behavior, and in the case of malware, the ''Initial Indicators of Compromise''.
!Limitations
Dynamic Analysis is a task that is repeatable and is often automated to perform unattended analysis when the analysis resources are limited and volume of malware to analyze is high. In such cases, outcomes can be limited because the software being analyzed :
*requires input (e.g. stdin, command line arguments)
*has ~Anti-Analysis built-in
*delays execution
An automated Dynamic Analysis system needs to define its limits such as:
*run-time allowed for each piece of malware
*the software and patch levels available in the execution environment
*the capabilities of their monitoring tools
!Further leveraging Dynamic Techniques
Of course this form of analysis may be used after a deeper analysis, for example, to monitor command and control behavior and network communication. For instance, assume initial dynamic analysis completes with a netowrk beacon which is not replied to. Static analysis may reveal the communication protocol of the malware, and then use dynamic analysis to interact with it to tease out other behavior.
Prerequisites:
*Install Virtualization Software (e.g. ~VMware, Virtual Box) (Network VM)
*Install ~REMnux VM
*Create a Windows Virtual Machine (Analysis VM)
**Choose ~Host-Only Networking
**Install Tools and Applications
**Configure DNS to point to the IP Address of the ~REMnux VM
!Initializing the Analysis Environment
#''Boot the Network VM''
#''Start the network simulation tools''
##Open a terminal
##Type ''inetsim'' and hit enter
#Optional: Start Wireshark
##In a new terminal tab, run sudo wireshark (if prompted, default password in ~REMnux is malware).
##Start a Capture by click Capture -> Interfaces and selecting the interface of the ~Host-Only Network
##Start network simulation
At this point you are ready to capture network traffic from the malware, as long as it cooperates with the fake services provided by inetsim. It is recommended that you ''take a snapshot'' of the Network VM now.
#''Boot the Analysis VM''
#''Take a snapshot'' (baseline) of the Analysis VM
#''Copy the malware'' into the VM using one of the following methods:
**VM Shared Folders
**scp/ftp
**Removable Media (CD/usb)
#Optional: Execute any baseline analysis tools (e.g. ~RegShot)
#''Start monitoring services''
**From a command prompt run: ''capturebat.exe -c -n -l <log file name>''
***-c instructs capturebat to backup deleted (pre-delete) and modified (post-modifcation) files.
***-n instructs capturebat to capture network traffic (in non-promiscuous mode)
***-l instructs capturebat to write logged events to a file (instead of printing to stdout)
**Process Monitor (procmon.exe) can be used in place of capturebat
**Wireshark may be used if you choose not to use capturebat with -n
#''Execute the malware'' and go get a cup of coffee
**Choosing a run time is up to the analysts discretion
**It's like that most observable behavior occurs within the first minute
#''Halt monitoring tools'' saving output where necessary
**In the capturebat cmd window, hit q followed by enter
***Capture BAT creates a zip file containing a packet capture (pcap) and the modified files
#Optional: Run the second half of any baseline analysis tool for comparison against the first measurement
#''Copy the results'' including the capture bat log and zip
At this point you may wish to take a snapshot to continue analysis later. You can now ''revert to the baseline snapshot''.
*File Type
*File Hashes (e.g. md5, sha1)
*File Size
*~Anti-Virus detection
*Packer detection
# Open bserver.unpacked.ex_ in IDA
** Note ~CreateProcess
# Examine three user-defined functions
## first reads the current file (Discuss tracing name arg back to ~GetModuleHandleA)
## Second is string manip
## Third refers to a DLL and performs file operations (rb and Wb!)
# Put breakpoint on function
# F9 to begin
** Crash! What's up?!
** We are running the unpacked file, and it is reading itself...
# Add break on first user-defined function
# Restart
# Patch the name in memory to open the original file
# Start up Proc Mon
## filter on our process (srvr.exe.unpacked.exe)
## drop filtered events
## clear log
# Run to 2nd breakpoint
# Step Over
** We see c:\windows\system32\berzk.dll has been dropped
# Stop process
# Gather information
#* IAT
#* strings
#* dynamic analysis
# Identify function of interest
# Identify ~CALLs
# Identify algorithms and data structures
# Pseudo-code it!
#* if having trouble, draw the memory and CPU and map what happens at each instruction
# Rename function(s), argument(s), variable(s)
# Add comments
# GOTO 2
Less obtrusive than software bps, hardware breakpoints use the debug registers which can only be set in privileged mode (ring 0)
#User requests a hardware breakpoint at an address
**Uses the linear/virutal address assuming an OS that uses paging
**Can be local (this process only) or global (all processes)
#If available, the debugger sets a debug register (dr0-dr3)
#Once reached, a ''~Single-Step Exception'' occurs
#The debugger catches the exception and alerts the user
#The user may resume execution.
!!!Weakness
Code that runs in Ring 0, such as an exception handler, could clear or alter the debug register.
#User requests a software breakpoint at an address
#The debugger saves the byte at this address and replaces it with an 0xCC (int3)
#Once execution reaches the address, a ''Breakpoint Exception'' occurs
#The debugger catches the exception and alerts the user
**Conditonal breakpoints stop only when condition is met (e.g. eax == 0)
#Once instructed to resume, the original byte is written over the 0xCC
#The debugger single-steps, executing the instruction
#The original byte is saved again, and an 0xCC is placed at the address
!Side-effects
*Application code can search through memory for 0xCC
*Debugger overhead slows execution
**Timing checks can identify debugger
*Self-modifying code will assume 0xCC is the original content and read/modify/write it
<<tabs chkBpBasics
"How Software Breakpoints Work" "" [[How Software Breakpoints Work]]
"How Hardware Breakpoints Work" "" [[How Hardware Breakpoints Work]] >>
This example script colors some of the interesting instructions that may be indicators of anti-analysis techniques.
{{{
#include <idc.idc>
static main() {
auto start, end, addr, mnem, count, opnd, opnd1, opnd2;
start = SegStart( ScreenEA() );
end = SegEnd( ScreenEA() );
addr = start;
count = 0;
while( addr < end ) {
mnem = GetMnem( addr );
// Common VM detect instructions
if( mnem == "sidt" || mnem == "sgdt" || mnem == "sldt" || mnem == "smsw" || mnem == "str" ) {
Message( "%08x: Found %s\n", addr, mnem );
SetColor( addr, CIC_ITEM, 0x0088ff ); // orange
}
// Read Time Stamp Counter
if( mnem == "rdtsc" ) {
Message( "%08x: Found %s\n", addr, mnem );
SetColor( addr, CIC_ITEM, 0xff8800 ); // blue
}
// Exception Handling or other PEB/TEB access
opnd = "";
opnd1 = GetOpnd( addr, 0 );
opnd2 = GetOpnd( addr, 1 );
if( strstr( opnd1, "fs:" ) > -1 ) {
opnd = opnd1;
}
else {
if( strstr( opnd2, "fs:" ) > -1 ) opnd = opnd2;
}
if( opnd != "" ) {
Message( "%08x: Found %s\n", addr, opnd );
SetColor( addr, CIC_ITEM, 0xff8888 ); // purple
}
addr = NextHead( addr, BADADDR );
count = count + 1;
}
Message( "Processed %d instructions from %08x to %08x\n", count, start, end );
}
}}}
{{{
#include <idc.idc>
static main(void)
{
auto start, end, ptr;
auto key;
start = SelStart();
if( start == BADADDR ) return;
end = SelEnd();
if( end == BADADDR ) return;
end = end - 1;
key = AskLong(0, "Number to XOR selected area with:");
if( key == -1 ) return;
Message("XORing with 0x%x %d bytes starting at 0x%08x...",key, end-start+1, start);
for(ptr=start; ptr<=end; ptr++)
PatchByte(ptr, Byte(ptr) ^ key);
Message("done.\n");
}
}}}
There's no silver bullet to in malware detection. Malware authors spend a great deal of time in avoidance of pattern recognition. Despite the ease of defeating byte signatures, don't discount laziness and the fact that malware is going to have to perform certain behavior to be useful. Reuse of analysis results can save a great deal of time. The following can be used to identify 'known' malware:
*File Hashes (Full or Portion)
*Byte Signatures
*System Behavior
*Network Signatures
!!Hashes
Hashing algorithms receive a byte sequence (e.g. file content) and calculate a small (<100 byte), repeatable value that represents the sequence. Hashes provide a quick portable method for comparing a file with previously analyzed files. Other than full files, we may hash discrete file portions such as:
*PE Headers/Sections/Resources
*x86 Functions/Code Blocks
*PDF Streams
*Office Document Streams
!!Byte Signatures
Historically ~Anti-Virus engines and Intrusion Detection Systems (IDS) have detected malware and unwanted network traffic using byte signatures. Such signatures may cover code sequences, data constants, or both. They may allow flexibility using wildcards.
!!!Strengths
*Cheap
!!!Weaknesses
*Susceptible to minor changes such as code-reordering and twiddled bits
*At times results in false positives.
!!System Behavior
By monitoring the interactions between applications and the Operating System/Hardware, malicious software can be recognized. This can be done by:
*Comparing current system states with a baseline
*Monitoring API and System calls
!!Events
*I/O
**Disk writes/reads
**Network send/receive
*Process Management
**Creation
**~Inter-Process Communcation (IPC)
**Remote Procedure calls (RPC)
**Thread Injection
*Configuration
**Registry Modification
Using behavioral analysis for on a per event process would be very susceptible to false positives as malicious code often behaves similarly to legitimate code.
!!Network Signatures
As mentioned, byte signatures are used by IDS to detect malicious network traffic. This can be combined with trend analysis and pattern recognition of the types of connections made and the ports they are communicated over.
/***
|Name|ImageSizePlugin|
|Source|http://www.TiddlyTools.com/#ImageSizePlugin|
|Version|1.2.3|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|adds support for resizing images|
This plugin adds optional syntax to scale an image to a specified width and height and/or interactively resize the image with the mouse.
!!!!!Usage
<<<
The extended image syntax is:
{{{
[img(w+,h+)[...][...]]
}}}
where ''(w,h)'' indicates the desired width and height (in CSS units, e.g., px, em, cm, in, or %). Use ''auto'' (or a blank value) for either dimension to scale that dimension proportionally (i.e., maintain the aspect ratio). You can also calculate a CSS value 'on-the-fly' by using a //javascript expression// enclosed between """{{""" and """}}""". Appending a plus sign (+) to a dimension enables interactive resizing in that dimension (by dragging the mouse inside the image). Use ~SHIFT-click to show the full-sized (un-scaled) image. Use ~CTRL-click to restore the starting size (either scaled or full-sized).
<<<
!!!!!Examples
<<<
{{{
[img(100px+,75px+)[images/meow2.jpg]]
}}}
[img(100px+,75px+)[images/meow2.jpg]]
{{{
[<img(34%+,+)[images/meow.gif]]
[<img(21% ,+)[images/meow.gif]]
[<img(13%+, )[images/meow.gif]]
[<img( 8%+, )[images/meow.gif]]
[<img( 5% , )[images/meow.gif]]
[<img( 3% , )[images/meow.gif]]
[<img( 2% , )[images/meow.gif]]
[img( 1%+,+)[images/meow.gif]]
}}}
[<img(34%+,+)[images/meow.gif]]
[<img(21% ,+)[images/meow.gif]]
[<img(13%+, )[images/meow.gif]]
[<img( 8%+, )[images/meow.gif]]
[<img( 5% , )[images/meow.gif]]
[<img( 3% , )[images/meow.gif]]
[<img( 2% , )[images/meow.gif]]
[img( 1%+,+)[images/meow.gif]]
{{tagClear{
}}}
<<<
!!!!!Revisions
<<<
2011.09.03 [1.2.3] bypass addStretchHandlers() if no '+' suffix is used (i.e., not resizable)
2010.07.24 [1.2.2] moved tip/dragtip text to config.formatterHelpers.imageSize object to enable customization
2009.02.24 [1.2.1] cleanup width/height regexp, use '+' suffix for resizing
2009.02.22 [1.2.0] added stretchable images
2008.01.19 [1.1.0] added evaluated width/height values
2008.01.18 [1.0.1] regexp for "(width,height)" now passes all CSS values to browser for validation
2008.01.17 [1.0.0] initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.ImageSizePlugin= {major: 1, minor: 2, revision: 3, date: new Date(2011,9,3)};
//}}}
//{{{
var f=config.formatters[config.formatters.findByField("name","image")];
f.match="\\[[<>]?[Ii][Mm][Gg](?:\\([^,]*,[^\\)]*\\))?\\[";
f.lookaheadRegExp=/\[([<]?)(>?)[Ii][Mm][Gg](?:\(([^,]*),([^\)]*)\))?\[(?:([^\|\]]+)\|)?([^\[\]\|]+)\](?:\[([^\]]*)\])?\]/mg;
f.handler=function(w) {
this.lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = this.lookaheadRegExp.exec(w.source)
if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
var floatLeft=lookaheadMatch[1];
var floatRight=lookaheadMatch[2];
var width=lookaheadMatch[3];
var height=lookaheadMatch[4];
var tooltip=lookaheadMatch[5];
var src=lookaheadMatch[6];
var link=lookaheadMatch[7];
// Simple bracketted link
var e = w.output;
if(link) { // LINKED IMAGE
if (config.formatterHelpers.isExternalLink(link)) {
if (config.macros.attach && config.macros.attach.isAttachment(link)) {
// see [[AttachFilePluginFormatters]]
e = createExternalLink(w.output,link);
e.href=config.macros.attach.getAttachment(link);
e.title = config.macros.attach.linkTooltip + link;
} else
e = createExternalLink(w.output,link);
} else
e = createTiddlyLink(w.output,link,false,null,w.isStatic);
addClass(e,"imageLink");
}
var img = createTiddlyElement(e,"img");
if(floatLeft) img.align="left"; else if(floatRight) img.align="right";
if(width||height) {
var x=width.trim(); var y=height.trim();
var stretchW=(x.substr(x.length-1,1)=='+'); if (stretchW) x=x.substr(0,x.length-1);
var stretchH=(y.substr(y.length-1,1)=='+'); if (stretchH) y=y.substr(0,y.length-1);
if (x.substr(0,2)=="{{")
{ try{x=eval(x.substr(2,x.length-4))} catch(e){displayMessage(e.description||e.toString())} }
if (y.substr(0,2)=="{{")
{ try{y=eval(y.substr(2,y.length-4))} catch(e){displayMessage(e.description||e.toString())} }
img.style.width=x.trim(); img.style.height=y.trim();
if (stretchW||stretchH) config.formatterHelpers.addStretchHandlers(img,stretchW,stretchH);
}
if(tooltip) img.title = tooltip;
// GET IMAGE SOURCE
if (config.macros.attach && config.macros.attach.isAttachment(src))
src=config.macros.attach.getAttachment(src); // see [[AttachFilePluginFormatters]]
else if (config.formatterHelpers.resolvePath) { // see [[ImagePathPlugin]]
if (config.browser.isIE || config.browser.isSafari) {
img.onerror=(function(){
this.src=config.formatterHelpers.resolvePath(this.src,false);
return false;
});
} else
src=config.formatterHelpers.resolvePath(src,true);
}
img.src=src;
w.nextMatch = this.lookaheadRegExp.lastIndex;
}
}
config.formatterHelpers.imageSize={
tip: 'SHIFT-CLICK=show full size, CTRL-CLICK=restore initial size',
dragtip: 'DRAG=stretch/shrink, '
}
config.formatterHelpers.addStretchHandlers=function(e,stretchW,stretchH) {
e.title=((stretchW||stretchH)?this.imageSize.dragtip:'')+this.imageSize.tip;
e.statusMsg='width=%0, height=%1';
e.style.cursor='move';
e.originalW=e.style.width;
e.originalH=e.style.height;
e.minW=Math.max(e.offsetWidth/20,10);
e.minH=Math.max(e.offsetHeight/20,10);
e.stretchW=stretchW;
e.stretchH=stretchH;
e.onmousedown=function(ev) { var ev=ev||window.event;
this.sizing=true;
this.startX=!config.browser.isIE?ev.pageX:(ev.clientX+findScrollX());
this.startY=!config.browser.isIE?ev.pageY:(ev.clientY+findScrollY());
this.startW=this.offsetWidth;
this.startH=this.offsetHeight;
return false;
};
e.onmousemove=function(ev) { var ev=ev||window.event;
if (this.sizing) {
var s=this.style;
var currX=!config.browser.isIE?ev.pageX:(ev.clientX+findScrollX());
var currY=!config.browser.isIE?ev.pageY:(ev.clientY+findScrollY());
var newW=(currX-this.offsetLeft)/(this.startX-this.offsetLeft)*this.startW;
var newH=(currY-this.offsetTop )/(this.startY-this.offsetTop )*this.startH;
if (this.stretchW) s.width =Math.floor(Math.max(newW,this.minW))+'px';
if (this.stretchH) s.height=Math.floor(Math.max(newH,this.minH))+'px';
clearMessage(); displayMessage(this.statusMsg.format([s.width,s.height]));
}
return false;
};
e.onmouseup=function(ev) { var ev=ev||window.event;
if (ev.shiftKey) { this.style.width=this.style.height=''; }
if (ev.ctrlKey) { this.style.width=this.originalW; this.style.height=this.originalH; }
this.sizing=false;
clearMessage();
return false;
};
e.onmouseout=function(ev) { var ev=ev||window.event;
this.sizing=false;
clearMessage();
return false;
};
}
//}}}
|CssClass|k
|!Key(s)|!Command|
|!F2|Insert Software Breakpoint|
|!F7|Step-Into Current Instruction|
|!F8|Step-Over Current Instruction|
|!F9|Run (until break/exception)|
|!~Ctrl-G|Jump to expression|
|!*|Go to origin (EIP)|
|!Ctrl-*|Set origin (EIP)|
|!~Ctrl-A|Analyze Code|
Our dump should maintain the DLL "unsetting" we did for the packed DLL so if clean dump, we can execute it
#Load into IDA
**Note the jumps at and around entry (~DllMain)
**Visual studio Incremental Link Option (/INCREMENTAL) causes this (thunks for author's functions)
#Click ~DllMain jmp address
**Note several disconnected graphs
**Goofy IDA analysis is a result of function thunks
#Delete function
#Step back to thunks
#Scroll up to first thunk
#Recreate functions with script
{{{
auto start, end, a, xref;
start = 0x10001005;
end = 0x100010AF;
for( a = start; a < end; a = a + 5 ) {
xref = Rfirst( a );
MakeFunction( xref, BADADDR );
Message( "%08x: Made function\n", xref );
}
}}}
** Note: If you try to execute there is an exception loading ~RtlRestoreLastWin32Error
*** ~OllyDump "screwed up". It wasn't aware of a Forward from kernel32 to ntdll
# Open DLL in CFF Explorer
# Find ~RtlRestoreLastWin32Error
# Change name to: ~SetLastError
** Should run properly now
{{ left {
[[About This Course]]
Course Content
#[[Prerequisites Review]]
#[[Analysis Goals]]
#[[Triage|Triage]]
#[[Malware Lab]]
#[[Analysis Methods|Methods of Malware Analysis]]
#[[Execution/Persistence|Malware Execution and Persistence ]]
#[[Data Encoding]]
#[[How a Debugger Works]]
#[[Malware Unpacking]]
#[[Network Communication]]
#[[DLL Analysis]]
#[[Anti-Analysis]]
#[[Shellcode Analysis]]
Resources
[[ImmDbg Shortcuts|Immunity Debug Shortcuts]]
[[IDC: Color Script|IDC Script: Coloring Unusual Instructions]]
[[IDC: XOR Selection|IDC Script: XOR Selection]]
[[pefile: PE Section Frequency]]
[[pefile: DLL ROR 13 Lookup]]
[[Books]]
RE Course
[[Generic RE Algorithm]]
[[Analyzing a Function]]
[[Where to begin?]]
[[References]]
}}}
<<tabs chkPersistence
"About" "" [[Malware Persistence: About]]
"Goals" "" [[Malware Persistence: Analysis Goals]]
"Launch" "" [[Malware Persistence: Droppers, Downloaders, and Injectors]]
"Code Injection Continued" "" [[More Code Injection]]
>>
<<tabs chkMalwareLab
"About" "" [[About Malware Lab Design]]
"Physical vs. Virtual" "" [[Physical vs. Virtual]]
>>
Often malware is packaged up into a tool akin to an installer which may use any of the many windows methods for code execution amd persistence. Some common forms are:
*''Dropper'': Writes a file contained within the dropper to common execution paths (e.g. c:\Windows\system32) and executes it
*''Downloader'': Retrieves a file from an server
*''Injector'': - Writes code directly into another process (e.g. explorer.exe) and creates a new thread in that process.
!Persistence
Once malicious code is executed, it's common to establish persistence in order to allow the malware to restart after a reboot, crash, or process kill. Windows has many options for automatic code execution including:
*Startup folder in the Start Menu
*run registry keys
**e.g. ''HKLM\SOFTWARE\Microsoft\Windows\~CurrentVersion\Run''
*Services
*Active Setup/Installed Components
**allowing per user-customization of startup events
*DLL ~Load-Order exploitation
*Scheduled Tasks
Try running the ~SysInternals/Microsoft [[AutoRuns|http://technet.microsoft.com/en-us/sysinternals/bb963902]] tool to see a more comprehensive list.
Ultimately we want to understand how the code executes on reboot (assuming it does), but more specifically we want to
*Find the Payload of the launcher
*Identify ''Registry Keys'' used
*Track malicious ''code injection'' into other processes
*Determine if a ''Mutex'' is used
**A mutex is used to prevent duplicate processes
**Might be leveraged to search a network for infections
!Payload Launch Vehicles
!!Droppers
Droppers very often copy themselves to another location and behave differently once in their expected location (e.g. C:\Windows\system32). Other possibilities are:
*Global variables in the data or code sections
*Binary data in the ''Resource Section (RSRC)'' of the
!!Downloaders
Downloads may use a variety of network functions and protocols to retrieve their payloads, and may even use encryption or chunk modification/reordering to fool Intrusion Detection Systems (IDS). Some common Network libraries and functions used are:
*<<slider chkWinsock2Funcs [[Winsock2 Functions]] "Winsock2 (ws2_32.dll)" ">>
*<<slider chkWinInetFuncs [[WinInet Functions]] "WinInet (wininet.dll)" ">>
*<<slider chkUrlmonFuncs [[Urlmon Functions]] "URL Monikers (urlmon.dll)" ">>
!!Injectors
Malicious processes can stick out like a sore thumb. Even the cleverly named processed like scvhost.exe are noticeable to the well trained analyst. DLL Injection is less noticeable, and shellcode injection is even more stealthy, though the calls to perform it may raise alarms as it is unusual behavior. They include:
*~OpenProcess
*~VirtualAllocEx
*~WriteProcessMemory
*~CreateRemoteThread
This may be preceded by calls to the following functions used to ''iterate the running process'' in order to locate a target (e.g. explorer.exe):
*~CreateToolhelp32Snapshot
*~Process32First
*~Process32Next
<<tabs tabClass
"About" "mouseover" [[Malware Unpacking: About]]
"Categories" "mouseover" [[Malware Unpacking: Categories]]
"Tools" "mouseover" [[Malware Unpacking: Tools]]
"Automated Unpacking" "mouseover" [[Malware Unpacking: Automated]]
"Manual Unpacking" "mouseover" [[Malware Unpacking: Manual]]
"Dumping Unpacked Code" "" [[Dumping Unpacked Code]]
"Exercise" "mouseover" [[Malware Unpacking: Exercise]]
>>
!Background
*Packers were first created at a time when network bandwidth expensive
*UPX was a cheap way to obscure identifiable strings form ~Anti-Virus
*As an added bonus, it increases the complexity of analysis
*Packers progressed to Executable Protectors which use additional ~Anti-Analysis tricks
!Packing Process
*Packers parse the executable's headers
*Code and data is compressed/encrypted/encoded at a block level (e.g. PE section, function, string)
*A new executable is created with the encoded data and modified headers
*An unpacking program (stub) is inserted into the new file and the Entry Point points to it
!The Unpacking Stub
*The code and data is decoded
*Executable loader functions generally performed by the OS are emulated
**Import functions are resolved assuming the packer encoded them
*Execution is transferred to the original applications code
!Detecting Packers
*Packed applications tend to have a higher level of entropy because compressed data tends to lack structure
** def.- a measure of "randomness" or lack of structure in a file
**Mandiant's Red Curtain detects entropy and malformity in executable files revealing a "Threat Score"
*Unusual Section Names
*Open in Debugger / Disassembler:
**Ollydbg and IDA Pro often identifies
Anti-debugging tricks leverage the abnormal execution of debugged applications. Examples of such behavior are:
*Slower than normal execution
*Presence of Breakpoints
*OS debugger flags and API calls
*Interrupt/Exception Behavior
See: [[How a Debugger Works]]
!Unpacking dropper.EXE
Open up ~PEiD and drag dropper.EXE into the ~PEiD window. A signature has detected:
{{{
PolyCrypt PE 2005.06.01 -> JLab Software
}}}
The packer appears to be a bit dated, but it uses tricks that are still relevant today.
<<tabs chkAntiDebug
"Getting Started" "" [[Anti-Debug: Getting Started]]
"Exception! FS:[0]" "" [[Anti-Debug: SEH Part 1]]
"Debug Flags" "" [[Anti-Debug: IsDebugged!]]
"More SEH" "" [[Anti-Debug: SEH Part 2]]
"A Bad Pill" "" [[Anti-Debug: VM Detection]]
"Anti-Dump" "" [[Anti-Debug: Anti-Dump]]
"API Hooks" "" [[Anti-Debug: API Hooks]]
"Wrapping Up" "" [[Anti-Debug: Wrapping Up]]
>>
Automated unpacking is possible in some cases, but such a procedure will have a fixed set of instructions and rules. As a result, automated unpacking is unlikely to work on every packer.
Some heuristics that might be used to detect that a unpacking stub has completed, and the original entry point (OEP) has taken over include:
* Execution of memory regions that are written to
* Transfer of code execution from one memory region to another
* Execution of start-up API functions
** ~LoadLibrary and ~GetProcaddress loop
** ~GetCommandLine
** ~GetModuleHandle
** ~GetVersion
!Extension
Extra packer code is executed
*compressor: reduce original data's size
**common: aPLib (FSG, , LZMA, NRV/UPX)
**others: JCALG1, BriefLZ, LZMAT
*protector: makes reverse engineering harder
**countermeasures:
***anti-debugging: IsDebuggerPresent, ...
***anti-virtualization: detect VmWare, ...
***anti-dumping: erase header in memory...
***anti tampering, via checksums
****common: rolling checksum, CRC32, md5, sha1, adler, md4
****others: Tiger, Whirlpool, md4, adler
*cryptor: crypts original data
**common: bitwise operators (XOR/ROL/...), LCG, RC4, Tea
**others: DES, AES, Blowfish, Trivium, IDEA, ElGamal
!Transformation
The original code is rewritten
*virtualizer: turns original code into virtual code with embedded virtual machine
*mutater: alters code — same instruction set and architecture, but modified:
**reflowing
**oligomorphism
!Extra Features
*bundler: file dropping, with API hooking (to make a multi-file program run as single file)
!References
http://reverseengineering.stackexchange.com/questions/1779/what-are-the-different-types-of-packers
https://corkami.googlecode.com/files/packers.pdf
!Example / Exercise
# ''bserver.ex_''
#* What is the OEP?
#* Which libraries are loaded for the unpacked IAT?
#* What encoding algorithm is being used?
For more examples / exercises, check out [[Practical Malware Analysis|Books]] Lab18-01, Lab18-03, and Lab18-05.
At times automated unpacking may not succeed, OR unpacking may occur in stages interlaced with the software's core code execution. In such cases, you may have to break out your favorite Debugger and Disassembler.
! Unpacker Tail Transitions
* often (not always) found at the end of unpacking code
* Usually comes in one of the following forms:
** jump immediate (jmp 0401234)
*** Jumps generally take 1 byte operand, while transitions from unpackers to application code require a larger operand (e.g. 4 bytes)
***** A call could be used in place of a jump
** push / ret
*** A push followed by a return is fishy as the pushed value becomes the return address
*** The unpacker may have a constant or set a register that it jumps to
** pusha / popa
*** Not a transition technique, but usually used for restoring registers to entry-point state
*** Hardware Breakpoint on one of the saved registers may halt debugger just before transition to OEP
**** View ESP in dump, select one of the 4 byte aligned values, and set bp (f2)
! When a tail jump is unidentifiable, attempt to locate OEP by a section hop
* Generally code resides in single section of the PE file.
* Hops between sections are unusual and occur often in the transition from unpacker stubs to application code
* ~OllyDump automates the search for such a hop and attempts to break when found
! Beware of self-modifying code
* How Software Breakpoints work
** Debugger stores a copy of the byte at the breakpoint address
** This byte is replaced with 0xCC
** When the address is reached, the debugger swaps in the original byte
* How self-modifying code works
** A byte or block is read from memory
** Optional transformations are applied
** The byte is written (original location or elsewhere)
* Self-modify reads may read wrong (0xCC) byte
* Self-modify writes may overwrite breakpoints
* Use Hardware breakpoints when possible (4 in 32-bit)
! Breaking on common events
* Debuggers often allow breaking on Library Load/Unload
** Packers often end with a series of ~LoadLibrary / ~GetProcAddress calls
* Could set a breakpoint on common start-up functions
** ~GetCommandLineA, ~GetVersion
** Catch is they have to be loaded and available for break
* Identify
** Mandiant's Red Curtain
** ~PEiD
* Disassemble / Debug
** IDA Pro
** ~OllyDbg
** Immunity
<<tabs tabClass
"Dynamic Analysis" "" [[Dynamic Analysis]]
"Dynamic Analysis Example" "" [[Dynamic Analysis Example]]
"Static Analysis" "" [[Static Analysis]]
>>
!Code Injection:
*Build a Payload Buffer
**Often reads directly out of data our resource
**May be code, but possibly a string
*Select a target process
**May be a search for a paritcular process name (e.g. explorer.exe)
*Create or access a memory region in the target process
**Write the payload to this region (~WriteProcessMemory)
*Create a thread in the target process (~CreateRemoteThread)
**Requires a target process, address to start execution, and pointer to parameters
**start address often a location in the payload, though at times an API location
***~LoadLibrary for DLL Injection
!Intercepting:
*Could replace entry byte with 0xCC (INT 3/breakpoint)
*Could alter the process injected into.
**Debugging notepad is much more stable than debugging explorer.exe!
*May wish to start process in a suspended state
Shell Code Analysis:
*Common characteristics:
**Position Independent (works "at any address")
***Could dump code to a file for later analysis in disassembler
**Encoded and begins with a decoding loop
**Searches for library functions, loading libraries when necessary
Understanding a remote access tool (RAT) is all about understanding its network communication. All ~RATs are broken into two pieces, an implant, which is placed on the compromised system, and a controller, which the intruder uses to control the implant. The network communication is then one of four types:
* the implant requesting a command / action
* the controller providing a command / action
* the implant responding to the given command / action
* keep-alives or "pings"
!Example
Using nba_implant_exe, find the function that calls the recv() API and view it graphically using
* ''View'' -> ''Graphs'' -> ''Flow chart'',
* or simply ''F12''.
This is one example of command-code processing, involving a jump table.
Another example is a series of if..else statements, which could look like the following:
{{{
push 0
push 0x20
push offset buf
push socket
call recv
cmp [buf], 1
jz 0x401ded
cmp [buf], 2
jz 0x401eff
cmp [buf], 3
jz 0x401fed
jmp 0x401ace
}}}
This block of code calls the recv() function and then tests the first byte of the buffer for specific values, jumping to specific functionality for each value.
For extra credit, what rookie programming mistake is in the previous block of code?
* Direct TCP or UDP connection
* Tunneled over HTTP or HTTPS
* Tunneled over E-mail
* Tunneled over DNS
* Tunneled over Instant Messenger
Is something accessing the resources section? Use CFF Explorer to check it out.
Use nba_implant_exe to answer the following questions:
# Which API functions are used to “send” and “recv” data?
# Are you sure? Look for calls to ~LoadLibraryA and revise your previous answers.
# Take a look at the call to recv(). What can you say about the packets that it receives?
This is a thought exercise rather than a hands-on.
When malware uses recv() and send() for network communication, it has control over the exact bytes that are sent in the payload of the TCP or UDP packets. When malware uses ~URLDownloadToFile, it lets the local IE instance choose which HTTP headers are sent over the network and in which order.
What other API calls can be used for network communication, and how do they affect what is seen on the network? Look at the arguments to the API calls. Put another way, for each API call, what does the malware author have control over, and what not?
* SSH/Apache/~MS-SQL/etc vulnerability
* SQL injection
* E-mail with attachment or URL
** Webmail vs Corporate
* Drive-by download
!Isn't dynamic analysis easier?
Dynamic analysis could yield a C2 callback, or insight into the C2 protocol, and takes much less knowledge of Assembly than does Static analysis. But what if the malware waits for thirty minutes before it starts beaconing? What if it is virtual machine aware? What if it waits until a specific user-controlled process is running before it attempts any outgoing connections?
!How to find the networking code
Refer to [[the previous Downloaders section|Malware Persistence: Droppers, Downloaders, and Injectors]] (or if you have [[Practical Malware Analysis|Books]], p313), which lists common API calls that any ~MS-Windows program, including malware, might use for network communication. The simplest thing to do is to load your malware with IDA and look through the ''Imports'' table for any functions that you know are used in network communication, such as send() and recv().
<<slider chkEx3 [[Net Comm: Exercise 3]] "Exercise 1" "">>
<<slider chkEx4 [[Net Comm: Exercise 4]] "Exercise 2" "">>
Creating low false positive, low false negative signatures can be difficult.
The best indicators come from ''hard-coded, static strings'' in the malware. For example, when the C2 is tunneled over HTTP and is using a unique ~User-Agent string, the string can be turned into a simple NIDS signature.
When there are no strings that would yield a low false positive signature, attributes of the C2 can sometimes be used to create effective, though higher false positive, signatures.
<<slider chkEx1 [[Net Comm: Indicators Examples]] "Examples:" "">>
<<slider chkEx2 [[Net Comm: Indicators Warning]] "WARNING: Know where your signatures will be used!" "">>
<<slider chkEx2 [[Net Comm: Indicators Encryption]] "Don’t give up if the C2 is encrypted." "">>
Depending on the chosen encryption algorithm or implementation, a reasonable signature is still possible. For example, if the attacker is using ~RC4, has embedded the key in the malware itself, and the pre-encrypted C2 has well-defined fields that are NULL padded, you can pick an offset into the data that you know will always be NULL bytes before encryption and compute their encrypted values. Then a simple NIDS signature can be used to test for those specific bytes at the chosen offset.
* Constant packet size
** 5 successive packets within a flow have “dsize: 1234;”
* Specific range of size for the HTTP requested resource
** urilen: 128<>160,raw;
* Specific data encoding, like base64 (see p320)
** pcre:”/([a-zA-Z0-9+\/=]{4})+/”
For example, HTTP communication through a proxy can change the headers or the requested resource depending on which side of the proxy the signature is implemented. Pre-proxy means the requested resource is a full URL, with protocol and domain name. Post-proxy means possible additional headers added by the proxy, such as ''~X-Forwarded-For'' or ''Via''.
!Goals for this section
# Identify functions responsible for network communication.
# Introduce the concept of good network signatures.
!Purpose of networking code in malware
* <<slider chkRecon [[Net Comm: Recon]] "Reconnaissance examples" "">>
* <<slider chkExploit [[Net Comm: Exploit]] "Exploit Delivery examples" "">>
* <<slider chkC2 [[Net Comm: C2 examples]] "Command and Control (C2) examples" "">>
!How to detect
If the intruder uses a specific tool, technique, or procedure, then it is likely possible to fingerprint
!Command and Control
While each of the listed purposes of networking code offers an opportunity to detect and prevent an intrusion, we will focus on remote access tool (RAT) analysis in our examples and exercises.
* Ping sweeps
* Port scanning
* Open mail relay scanning
* E-mail communication testing
* Social media analysis
<<tabs tabClass
"Introduction" "mouseover" [[Net Comm: Introduction]]
"Finding the Code" "mouseover" [[Net Comm: Finding the Code]]
"Command and Control (C2)" "mouseover" [[Net Comm: C2]]
"Indicators" "mouseover" [[Net Comm: Indicators]] >>
!~Bare-Metal vs. Virtualized Analysis
!Network Security/Isolation
The most critical requirement for a malware analysis lab is that it does not impact critical infrastructure. Analysts must understand the risks their collections and analysis procedures pose to their networks. Malware may be capable of infecting neighboring machines.
*~Bare-Metal Options
**~Stand-Alone Computer
**~Air-Gapped Network
**Additional hardware (e.g. firewall) to reduce risk of infection
*Virtual Machine
**Remove, Disconnect, or Disable Virtual Network Interface
**~Host-Only Network
***Be aware of services listening on this Host OS
***Can disable the host connection to this network
!Backup/Restore
Malware analysis should begin with a baseline (clean) state which can be compared against the state after malware has executed. This calls for a backup and restore capability.
*Physical
**Disk image backup and restore (e.g. Norton Ghost)
*Virtual
**Snap-shots: Rapid save and restore of state
!Choosing the right environment
Based on the requirements described above, Virtualization provides the ideal environment for malware analysis, but the following drawbacks should be considered:
*Malware may change behavior if a VM is detected.
*Virtualization platform may increase due to vulnerabilities.
!Architecture
* mnemonic
* operand
* opcode
* static vs dynamic linking
* general purpose registers
* special purpose registers
** flags
* little vs big endian
** byte vs bit
* ASCII vs UNICODE strings
* stack
* heap
A good reference for additional details is Chapter 4 of [[Practical Malware Analysis|Books]]
!Programming
* control flow statements
** if
** loops
* global vs local variables
* structures
* classes
* calling conventions
** parameters
** return value
** stack frame
* libraries and API calls
A good reference for additional details is Chapter 6 of [[Practical Malware Analysis|Books]]
!PE files
* EP
* IAT
* Exports
* EXE vs DLL
* sections
** common section names (.text, .rdata, .data, .rsrc, more on pp21-22 of [[Practical Malware Analysis|Books]])
!IDA
* common windows
* graph view(s)
* ''x'' - cross-references
* ''g'' - go to address / address in register / expression
* ''Alt-t'' - string search
* ''Alt-b'' - binary data search
* ''u'' - undefine selection / current location
* ''p'' - create procedure / function starting at current location
* ''Alt-p'' - edit current function (change start/end, etc.)
* ''F2'' - set software breakpoint
* ''F9'' - run / debug
* ''F7'' - step into
* ''F8'' - step over
!Debugging
* Step
** Step Into vs Step Over
* Breakpoints
** Software vs hardware
** on-execute vs on-access
REMnux is a distribution of Ubuntu Linux courtesy of Lenny Zeltser which in itself is a malware analysis lab filled with common malware analysis tools. It best serves static analysis and network simulation.
Information and download at: http://zeltser.com/remnux/
# using ~ImpRec
#* https://www.corelan.be/index.php/2011/12/01/roads-iat/
# new, improved ~OllyDump: ~OllyDumpEx
#* http://www.woodmann.com/collaborative/tools/index.php/OllyDumpEx
# win32 Egg Hunt shellcode, in 33 bytes
#* http://blog.oxff.net/posts/Win32%20Egg%20Search%20Shellcode%2C%2033%20bytes-h3pt3hrmtzwfqq3rctcq.html
# explanation of overlays
#* http://www.sunbelt-software.com/ihs/alex/vb07_paper.pdf
# Olly 2 Immunity plugin converter
#* http://bob.droppages.com/Projects
#** fix plugins
# revert_and_split function, good reference for which kernel32 functions fwd to ntdll
#* http://malwarecookbook.googlecode.com/svn/trunk/malware.py
# Malware and Unpacking Framework for ~ImmDbg
#* http://code.google.com/p/muffi/
# Woodman RCE Tool Library
#* http://www.woodmann.com/collaborative/tools/index.php/Category:RCE_Tools
# ~OpenRCE
#* http://www.openrce.org/
# Lenny Zeltser's security related cheat sheets
#* http://zeltser.com/cheat-sheets/
# //Scientific but Not Academical Overview of Malware ~Anti-Debugging, ~Anti-Disassembly, and ~Anti-VM Technologies// by Branco, et. al.
#* http://media.blackhat.com/bh-us-12/Briefings/Branco/BH_US_12_Branco_Scientific_Academic_WP.pdf
Also, check out these [[Books]].
<<tabs tabClass
"About" "mouseover" [[Shellcode Analysis: Introduction]]
"Extraction" "mouseover" [[Shellcode Analysis: Extraction]]
"Analysis" "mouseover" [[Shellcode Analysis: Analysis]]
"Egg Hunt" "mouseover" [[Shellcode Analysis: Egg Hunt]]
"Exercises" "mouseover" [[Shellcode Analysis: Exercise]]
"Summary" "mouseover" [[Shellcode Analysis: Summary]] >>
When analyzing the shellcode itself, it helps to know a basic loading technique that relies on the fact that kernel32.dll is always loaded into the memory space of an ~MS-Windows process [http://blog.harmonysecurity.com/2009_08_01_archive.html]. The shellcode must find kernel32.dll in memory and then identify the locations of any API calls it wants to use from the DLL. ~LoadLibraryA can be used to then load additional ~DLLs and access other ~APIs. This is explained quite well in [[Practical Malware Analysis|Books]], so if you have the book, refer to Figure 19-1 on p414 and Listing 19-6 on p419.
EXAMPLE:
# A walk through the previously extracted shellcode from ~CVE-2007-5659_PDF__9BC1735453963E33EA1857CC25AA5A19_SurveyOnObamapdf.pdf=
Shellcode sometimes needs to drop additional malware on the system. To do this, it will either download the additional malware, or it will decode the additional drop file(s) from the initial infection vector, i.e. the PDF or DOC. If the additional files are embedded in the same file that the shellcode was embedded, then the shellcode will need to find the additional file(s) somehow. This search for additional embedded malicious object(s) is called the ''Egg Hunt''.
There are various techniques to an Egg Hunt, but the most common is to obtain an open handle to the file on disk or to the memory space of the process that has already loaded the file. The shellcode then searches for a unique byte sequence that identifies the start of the additional embedded malicious object(s). Often this is a four-byte sequence, which is easier to include in minimalist shellcode and often unique enough for a single file or process' memory.
# Reproduce extracting shellcode and analysis using the previous Example.
# ADVANCED: Duplicate process with ''~CVE-2009-4324_PDF_43CB55861B7FCF1DFB6968C9EF110BCC_Aug2010.pdf='', from contagiodump.blogspot.com, using provided additional resources
#* ASCII table printout
#* kernel32 exports hashes database,
#* xor.idc script
Chapter 19 from [[Practical Malware Analysis|Books]] provides a detailed explanation of typical shellcode techniques and provides a helpful debugging utility. It also provides suggestions for how to identify shellcode blobs (pp423-424). However, it does not describe how to extract the shellcode from the various containers, so we will show you here. This one topic could be a whole course itself (which gives me an idea!), so we will only be looking at ~Javascript-in-a-PDF for the example and for the lab.
We will extract shellcode from ''~CVE-2007-5659_PDF__9BC1735453963E33EA1857CC25AA5A19_SurveyOnObamapdf.pdf='' using the following process:
!Old Way
# pdf-parser -fw FILENAME > outfile.txt
# Look for Javascript object(s)
# pdf-parser -fw -o ~OBJECT_ID FILENAME > outfile.txt
# Analyze output and identify shellcode part
# Malzilla
## Misc Decoders tab, right-click in empty box, Load From File outfile.txt
## reduce to shellcode string, without double-quotes
## Click Button: ~UCS2 To Hex
## Click Button: Hex To File
##* save as ''shellcode.dump''
# Sometimes you'll need to dynamically construct the shellcode string using Malzilla
## Decoder tab, right-click in top empty box, Load From File outfile.txt
## reduce to the Javascript needed to create shellcode string(s)
## add to the end of the block a ''document.write(unescape(''shellcode_var''));''
## click ''Run script'' button
## right-click in lower box, Save to File, save as ''shellcode.dump''
## ''BEWARE'' null bytes in the shellcode, as they will cause the document.write output to be truncated
# load in IDA, cursor on first byte, mark as ''C''ode
!New Way
# ~PDFStreamDumper
# Load -> Pdf File
# View objects list in left-side box
#* Tools -> About Listview Colors
# choose object of interest (click on it to select)
#* to export as-is: Right-click object number in left-side box -> Save Raw Stream
#* to deal with ~JavaScript...
#*# click on object in left-side box, to select it
#*# click ~Javascrip_UI (in the menubar)
#*# modify ~JavaScript so that you remove the exploit line(s) and just have a variable that contains the shellcode
#*# add to the end of the ~JavaScript box (replacing ~VAR_NAME): ''tb.writeFile("C:\\shellcode.bin",~VAR_NAME)''
#*# click the Run button
Shellcode is a small segment of code that is often used by software exploits as payload. Shellcode:
*is typically position independent
*generally begins with a series of literal or functional nop instructions
*most likely loads the API functions it requires
*might be written repeatedly to the heap to increase success rate (Heap Spray)
*can often be found in the following <<slider chkExploitFileTypes [[Common Exploit File Types]] "Exploited File Types" "">>
*May be nested in objects or files stored in the delivery file (e.g. PDF with ~JavaScript or Flash)
*Shellcode objects may be encoded (e.g. PDF ~FlateEncoded streams)
!Purpose
Shellcode is generally use in the first stage of an attack. It often delivers and executes a payload which then does the bulk of the dirty work. First stage shellcode will come in one of two forms:
!Downloaders
//Downloader// shellcode attempts to retrieve and execute a malware file requiring Internet access at time of exploitation.
!Droppers
//Dropper// shellcode extracts and executes a file contained within the exploit file. The shellcode often has to decode this payload. Though no network connection is required, this provides more information for detection and analysis.
/%!File Formats
Shellcode can come in all sorts of ways. The simplest for us is when it arrives in a fully executable format. But this is not always the case. Sometimes it is embedded in a PDF as Javascript within a (de)~FlateEncoded stream. Sometimes it is embedded in a Flash object, which itself is embedded in an ~MS-Office document. In order to find shellcode, sometimes you have to first decode its container.
Shellcode can often be found in the following <<slider chkExploitFileTypes [[Common Exploit File Types]] "Exploited File Types" "">>.
!Droppers and Downloaders
It used to be that an intruder could exploit a system through direct interaction, where the exploit either works or does not work immediately after the would-be intruder sends the exploit. This used to allow an intruder's shellcode to be simply what its namesake implies, code that spawns immediately spawns an interactive shell on the compromised system. However, the trend towards client-side exploitation has changed this model.
An intruder can no longer tell exactly when his or her exploit will be executed. So instead of sitting around all day waiting for a connection, shellcode has become a means of either //downloading// or //dropping// additional malware, most often being a remote access tool (RAT).
//Downloaders// are shellcode that attempts to download additional malware and install it on the system, thus requiring Internet access at time of exploitation.
//Droppers// extract, and often decode, additional malware from the initial exploit file itself. This has the benefit of not requiring Internet access at time of exploitation, but it provides network defenders with the additional even if the exploit was not successful.%/
# The new hotness is file format exploitation
# Many file formats allow embedded objects and numerous encoding types
# Identify, extract, and decode potential exploitation objects using tools specific to the file format
# From that point, most shellcode follows these basic mechanics:
## find kernel32 in memory
## find ~LoadLibraryA
## build the shellcode-equivalent of an IAT
## ''drop'' an embedded payload or ''download'' additional malware
Static (code) Analysis refers to any investigation of software without execution of it. This can be as simple as collecting meta-data (e.g. file size, file magic, md5 hash) for [[Triage]] or as detailed as analyzing every byte for its meaning.
!Uses
*<<slider chkFileMetaData [[File Meta Data]] "File Meta Data Collection" "">>
*Finding Dependencies ([[Imports]])
*String Analysis
*Code Analysis
!Pros
*"Unlimited" access to software capabilities and configuration
*No infection to clean
!Cons
*Requires deep tool knowledge
*Time Consuming
!Deeper Analysis
Execution does not guarantee that all code paths are followed as software may require a specific environment or inputs to leverage its capabilities. For example, a Bot may do nothing but open a listening socket if you execute it; but if you investigate the code within the executable, you'll find it can list files, execute commands, and send requests to remote hosts (perhaps for a Denial of Service attack).
!!Disassembly
Such analysis requires a [[Disassembler]], and though there are several available, IDA Pro is one of the most popular, if not the industry standard, and will be discussed throughout the course.
*Can be identified by reads/writes to FS:[0]
*This is the beginning of the Thread Environment Block (TEB), first member of which is ''~PEXCEPTION_REGISTRATION_RECORD ~ExceptionList'' {{ CodeBlock {
{{{
typedef struct _EXCEPTION_REGISTRATION_RECORD
{
PEXCEPTION_REGISTRATION_RECORD Next;
PEXCEPTION_DISPOSITION Handler;
} EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD;
}}}
}}}
**This points the the beginning of the structured exception handler list
*Be aware of intentional exceptions, for example: {{ CodeBlock {
{{{
xor eax, eax
mov [eax], ecx
}}}
}}}
*Debuggers can be configured to pass exceptions to the debuggee
/*{{{*/
* html .tiddler {height:1%;}
body {font-size:.75em; font-family:arial,helvetica; margin:0; padding:0;}
h1,h2,h3,h4,h5,h6 {font-weight:bold; text-decoration:none;}
h1,h2,h3 {padding-bottom:1px; margin-top:1.2em;margin-bottom:0.3em;}
h4,h5,h6 {margin-top:1em;}
h1 {font-size:1.35em;}
h2 {font-size:1.25em;}
h3 {font-size:1.1em;}
h4 {font-size:1em;}
h5 {font-size:.9em;}
hr {height:1px;}
a {text-decoration:none;}
dt {font-weight:bold;}
ol {list-style-type:decimal;}
ol ol {list-style-type:lower-alpha;}
ol ol ol {list-style-type:lower-roman;}
ol ol ol ol {list-style-type:decimal;}
ol ol ol ol ol {list-style-type:lower-alpha;}
ol ol ol ol ol ol {list-style-type:lower-roman;}
ol ol ol ol ol ol ol {list-style-type:decimal;}
.txtOptionInput {width:11em;}
#contentWrapper .chkOptionInput {border:0;}
.externalLink {text-decoration:underline;}
.indent {margin-left:3em;}
.outdent {margin-left:3em; text-indent:-3em;}
code.escaped {white-space:nowrap;}
.tiddlyLinkExisting {font-weight:bold;}
.tiddlyLinkNonExisting {font-style:italic;}
/* the 'a' is required for IE, otherwise it renders the whole tiddler in bold */
a.tiddlyLinkNonExisting.shadow {font-weight:bold;}
#mainMenu .tiddlyLinkExisting,
#mainMenu .tiddlyLinkNonExisting,
#sidebarTabs .tiddlyLinkNonExisting {font-weight:normal; font-style:normal;}
#sidebarTabs .tiddlyLinkExisting {font-weight:bold; font-style:normal;}
.header {position:relative;}
.header a:hover {background:transparent;}
.headerShadow {position:relative; padding:4.5em 0 1em 1em; left:-1px; top:-1px;}
.headerForeground {position:absolute; padding:4.5em 0 1em 1em; left:0; top:0;}
.siteTitle {font-size:3em;}
.siteSubtitle {font-size:1.2em;}
#mainMenu {position:absolute; left:0; width:16em; text-align:right; line-height:1.6em; padding:1.5em 0.5em 0.5em 0.5em; font-size:1.1em;}
#sidebar {position:absolute; right:3px; width:16em; font-size:.9em;}
#sidebarOptions {padding-top:0.3em;}
#sidebarOptions a {margin:0 0.2em; padding:0.2em 0.3em; display:block;}
#sidebarOptions input {margin:0.4em 0.5em;}
#sidebarOptions .sliderPanel {margin-left:1em; padding:0.5em; font-size:.85em;}
#sidebarOptions .sliderPanel a {font-weight:bold; display:inline; padding:0;}
#sidebarOptions .sliderPanel input {margin:0 0 0.3em 0;}
#sidebarTabs .tabContents {width:15em; overflow:hidden;}
.wizard {padding:0.1em 1em 0 2em;}
.wizard h1 {font-size:2em; font-weight:bold; background:none; padding:0; margin:0.4em 0 0.2em;}
.wizard h2 {font-size:1.2em; font-weight:bold; background:none; padding:0; margin:0.4em 0 0.2em;}
.wizardStep {padding:1em 1em 1em 1em;}
.wizard .button {margin:0.5em 0 0; font-size:1.2em;}
.wizardFooter {padding:0.8em 0.4em 0.8em 0;}
.wizardFooter .status {padding:0 0.4em; margin-left:1em;}
.wizard .button {padding:0.1em 0.2em;}
#messageArea {position:fixed; top:2em; right:0; margin:0.5em; padding:0.5em; z-index:2000; _position:absolute;}
.messageToolbar {display:block; text-align:right; padding:0.2em;}
#messageArea a {text-decoration:underline;}
.tiddlerPopupButton {padding:0.2em;}
.popupTiddler {position: absolute; z-index:300; padding:1em; margin:0;}
.popup {position:absolute; z-index:300; font-size:.9em; padding:0; list-style:none; margin:0;}
.popup .popupMessage {padding:0.4em;}
.popup hr {display:block; height:1px; width:auto; padding:0; margin:0.2em 0;}
.popup li.disabled {padding:0.4em;}
.popup li a {display:block; padding:0.4em; font-weight:normal; cursor:pointer;}
.listBreak {font-size:1px; line-height:1px;}
.listBreak div {margin:2px 0;}
.tabset {padding:1em 0 0 0.5em;}
.tab {margin:0 0 0 0.25em; padding:2px;}
.tabContents {padding:0.5em;}
.tabContents ul, .tabContents ol {margin:0; padding:0;}
.txtMainTab .tabContents li {list-style:none;}
.tabContents li.listLink { margin-left:.75em;}
#contentWrapper {display:block;}
#splashScreen {display:none;}
#displayArea {margin:1em 17em 0 16em;}
.toolbar {text-align:right; font-size:.9em;}
.tiddler {padding:1em 1em 0;}
.missing .viewer,.missing .title {font-style:italic;}
.title {font-size:1.6em; font-weight:bold;}
.missing .subtitle {display:none;}
.subtitle {font-size:1.1em;}
.tiddler .button {padding:0.2em 0.4em;}
.tagging {margin:0.5em 0.5em 0.5em 0; float:left; display:none;}
.isTag .tagging {display:block;}
.tagged {margin:0.5em; float:right;}
.tagging, .tagged {font-size:0.9em; padding:0.25em;}
.tagging ul, .tagged ul {list-style:none; margin:0.25em; padding:0;}
.tagClear {clear:both;}
.footer {font-size:.9em;}
.footer li {display:inline;}
.annotation {padding:0.5em; margin:0.5em;}
* html .viewer pre {width:99%; padding:0 0 1em 0;}
.viewer {line-height:1.4em; padding-top:0.5em;}
.viewer .button {margin:0 0.25em; padding:0 0.25em;}
.viewer blockquote {line-height:1.5em; padding-left:0.8em;margin-left:2.5em;}
.viewer ul, .viewer ol {margin-left:0.5em; padding-left:1.5em;}
.viewer table, table.twtable {border-collapse:collapse; margin:0.8em 1.0em;}
.viewer th, .viewer td, .viewer tr,.viewer caption,.twtable th, .twtable td, .twtable tr,.twtable caption {padding:3px;}
table.listView {font-size:0.85em; margin:0.8em 1.0em;}
table.listView th, table.listView td, table.listView tr {padding:0 3px 0 3px;}
.viewer pre {padding:0.5em; margin-left:0.5em; font-size:1.2em; line-height:1.4em; overflow:auto;}
.viewer code {font-size:1.2em; line-height:1.4em;}
.editor {font-size:1.1em;}
.editor input, .editor textarea {display:block; width:100%; font:inherit;}
.editorFooter {padding:0.25em 0; font-size:.9em;}
.editorFooter .button {padding-top:0; padding-bottom:0;}
.fieldsetFix {border:0; padding:0; margin:1px 0px;}
.zoomer {font-size:1.1em; position:absolute; overflow:hidden;}
.zoomer div {padding:1em;}
* html #backstage {width:99%;}
* html #backstageArea {width:99%;}
#backstageArea {display:none; position:relative; overflow: hidden; z-index:150; padding:0.3em 0.5em;}
#backstageToolbar {position:relative;}
#backstageArea a {font-weight:bold; margin-left:0.5em; padding:0.3em 0.5em;}
#backstageButton {display:none; position:absolute; z-index:175; top:0; right:0;}
#backstageButton a {padding:0.1em 0.4em; margin:0.1em;}
#backstage {position:relative; width:100%; z-index:50;}
#backstagePanel {display:none; z-index:100; position:absolute; width:90%; margin-left:3em; padding:1em;}
.backstagePanelFooter {padding-top:0.2em; float:right;}
.backstagePanelFooter a {padding:0.2em 0.4em;}
#backstageCloak {display:none; z-index:20; position:absolute; width:100%; height:100px;}
.whenBackstage {display:none;}
.backstageVisible .whenBackstage {display:block;}
/*}}}*/
/* text alignments */
.left
{ display:block;text-align:left; }
.center
{ display:block;text-align:center; }
.center table
{ margin:auto !important; }
.right
{ display:block;text-align:right; }
.justify
{ display:block;text-align:justify; }
.indent
{ display:block;margin:0;padding:0;border:0;margin-left:2em; }
.floatleft
{ float:left; }
.floatright
{ float:right; }
.valignTop, .valignTop table, .valignTop tbody, .valignTop th, .valignTop tr, .valignTop td
{ vertical-align:top; }
.valignBottom, .valignBottom table, .valignBottom tbody, .valignBottom th, .valignBottom tr, .valignBottom td
{ vertical-align:bottom; }
.clear
{ clear:both; }
.wrap
{ white-space:normal; }
.nowrap
{ white-space:nowrap; }
.hidden
{ display:none; }
.show
{ display:inline !important; }
.span
{ display:span; }
.block
{ display:block; }
.relative
{ position:relative; }
.absolute
{ position:absolute; }
/* font sizes */
.big
{ font-size:14pt;line-height:120% }
.medium
{ font-size:12pt;line-height:120% }
.normal
{ font-size:9pt;line-height:120% }
.small
{ font-size:8pt;line-height:120% }
.fine
{ font-size:7pt;line-height:120% }
.tiny
{ font-size:6pt;line-height:120% }
.larger
{ font-size:120%; }
.smaller
{ font-size:80%; }
/* font styles */
.bold
{ font-weight:bold; }
.italic
{ font-style:italic; }
.underline
{ text-decoration:underline; }
/* plain list items (no bullets or indent) */
.nobullets li { list-style-type: none; margin-left:-2em; }
/* vertical tabsets - courtesy of Tobias Beer */
.vTabs .tabset {float:left;display:block;padding:0px;margin-top:.5em;min-width:20%;}
.vTabs .tabset .tab {display:block;text-align:right;padding:2px 3px 2px 7px; margin:0 1px 1px 0;}
.vTabs .tabContents {margin-left:20%;max-width:80%;padding:5px;}
.vTabs .tabContents .tabContents {border:none; background:transparent;}
/* multi-column tiddler content (not supported in Internet Explorer) */
.twocolumns { display:block;
-moz-column-count:2; -moz-column-gap:1em; -moz-column-width:50%; /* FireFox */
-webkit-column-count:2; -webkit-column-gap:1em; -webkit-column-width:50%; /* Safari */
column-count:2; column-gap:1em; column-width:50%; /* Opera */
}
.threecolumns { display:block;
-moz-column-count:3; -moz-column-gap:1em; -moz-column-width:33%; /* FireFox */
-webkit-column-count:3; -webkit-column-gap:1em; -webkit-column-width:33%; /* Safari */
column-count:3; column-gap:1em; column-width:33%; /* Opera */
}
.fourcolumns { display:block;
-moz-column-count:4; -moz-column-gap:1em; -moz-column-width:25%; /* FireFox */
-webkit-column-count:4; -webkit-column-gap:1em; -webkit-column-width:25%; /* Safari */
column-count:4; column-gap:1em; column-width:25%; /* Opera */
}
/* page breaks */
.breakbefore { page-break-before:always; }
.breakafter { page-break-before:always; }
/* show/hide browser-specific content for InternetExplorer vs. non-IE ("moz") browsers */
*[class="ieOnly"]
{ display:none; } /* hide in moz (uses CSS selector) */
* html .mozOnly, *:first-child+html .mozOnly
{ display: none; } /* hide in IE (uses IE6/IE7 CSS hacks) */
/* borderless tables */
.borderless, .borderless table, .borderless td, .borderless tr, .borderless th, .borderless tbody
{ border:0 !important; margin:0 !important; padding:0 !important; }
.widetable, .widetable table
{ width:100%; }
/* thumbnail images (fixed-sized scaled images) */
.thumbnail img { height:5em !important; }
/* stretchable images (auto-size to fit tiddler) */
.stretch img { width:95%; }
/* grouped content */
.outline
{ display:block; padding:1em; -moz-border-radius:1em;-webkit-border-radius:1em; border:1px solid; }
.menubox
{ display:block; padding:1em; -moz-border-radius:1em;-webkit-border-radius:1em; border:1px solid; background:#fff; color:#000; }
.menubox .button, .menubox .tiddlyLinkExisting, .menubox .tiddlyLinkNonExisting
{ color:#009 !important; }
.groupbox
{ display:block; padding:1em; -moz-border-radius:1em;-webkit-border-radius:1em; border:1px solid; background:#ffe; color:#000; }
.groupbox a, .groupbox .button, .groupbox .tiddlyLinkExisting, .groupbox .tiddlyLinkNonExisting
{ color:#009 !important; }
.groupbox code
{ color:#333 !important; }
.borderleft
{ margin:0;padding:0;border:0;margin-left:1em; border-left:1px dotted; padding-left:.5em; }
.borderright
{ margin:0;padding:0;border:0;margin-right:1em; border-right:1px dotted; padding-right:.5em; }
.borderbottom
{ margin:0;padding:1px 0;border:0;border-bottom:1px dotted; margin-bottom:1px; padding-bottom:1px; }
.bordertop
{ margin:0;padding:0;border:0;border-top:1px dotted; margin-top:1px; padding-top:1px; }
/* scrolled content */
.scrollbars { overflow:auto; }
.height10em { height:10em; }
.height15em { height:15em; }
.height20em { height:20em; }
.height25em { height:25em; }
.height30em { height:30em; }
.height35em { height:35em; }
.height40em { height:40em; }
/* compact form */
.smallform
{ white-space:nowrap; }
.smallform input, .smallform textarea, .smallform button, .smallform checkbox, .smallform radio, .smallform select
{ font-size:8pt; }
/* stretchable edit fields and textareas (auto-size to fit tiddler) */
.stretch input { width:99%; }
.stretch textarea { width:99%; }
/* compact input fields (limited to a few characters for entering percentages and other small values) */
.onechar input { width:1em; }
.twochar input { width:2em; }
.threechar input { width:3em; }
.fourchar input { width:4em; }
.fivechar input { width:5em; }
/* text colors */
.white { color:#fff !important }
.gray { color:#999 !important }
.black { color:#000 !important }
.red { color:#f66 !important }
.green { color:#0c0 !important }
.blue { color:#99f !important }
/* rollover highlighting */
.mouseover
{color:[[ColorPalette::TertiaryLight]] !important;}
.mouseover a
{color:[[ColorPalette::TertiaryLight]] !important;}
.selected .mouseover
{color:[[ColorPalette::Foreground]] !important;}
.selected .mouseover .button, .selected .mouseover a
{color:[[ColorPalette::PrimaryDark]] !important;}
/* rollover zoom text */
.zoomover
{ font-size:80% !important; }
.selected .zoomover
{ font-size:100% !important; }
/* [[ColorPalette]] text colors */
.Background { color:[[ColorPalette::Background]]; }
.Foreground { color:[[ColorPalette::Foreground]]; }
.PrimaryPale { color:[[ColorPalette::PrimaryPale]]; }
.PrimaryLight { color:[[ColorPalette::PrimaryLight]]; }
.PrimaryMid { color:[[ColorPalette::PrimaryMid]]; }
.PrimaryDark { color:[[ColorPalette::PrimaryDark]]; }
.SecondaryPale { color:[[ColorPalette::SecondaryPale]]; }
.SecondaryLight { color:[[ColorPalette::SecondaryLight]];}
.SecondaryMid { color:[[ColorPalette::SecondaryMid]]; }
.SecondaryDark { color:[[ColorPalette::SecondaryDark]]; }
.TertiaryPale { color:[[ColorPalette::TertiaryPale]]; }
.TertiaryLight { color:[[ColorPalette::TertiaryLight]]; }
.TertiaryMid { color:[[ColorPalette::TertiaryMid]]; }
.TertiaryDark { color:[[ColorPalette::TertiaryDark]]; }
.Error { color:[[ColorPalette::Error]]; }
/* [[ColorPalette]] background colors */
.BGBackground { background-color:[[ColorPalette::Background]]; }
.BGForeground { background-color:[[ColorPalette::Foreground]]; }
.BGPrimaryPale { background-color:[[ColorPalette::PrimaryPale]]; }
.BGPrimaryLight { background-color:[[ColorPalette::PrimaryLight]]; }
.BGPrimaryMid { background-color:[[ColorPalette::PrimaryMid]]; }
.BGPrimaryDark { background-color:[[ColorPalette::PrimaryDark]]; }
.BGSecondaryPale { background-color:[[ColorPalette::SecondaryPale]]; }
.BGSecondaryLight { background-color:[[ColorPalette::SecondaryLight]]; }
.BGSecondaryMid { background-color:[[ColorPalette::SecondaryMid]]; }
.BGSecondaryDark { background-color:[[ColorPalette::SecondaryDark]]; }
.BGTertiaryPale { background-color:[[ColorPalette::TertiaryPale]]; }
.BGTertiaryLight { background-color:[[ColorPalette::TertiaryLight]]; }
.BGTertiaryMid { background-color:[[ColorPalette::TertiaryMid]]; }
.BGTertiaryDark { background-color:[[ColorPalette::TertiaryDark]]; }
.BGError { background-color:[[ColorPalette::Error]]; }
Execution in debuggers, virtual machines, and emulators have overhead that can slow processing; a delay which can be detected.
* ''~GetTickCount'' or ''~QueryPerformanceCounter'' calls
* ''RDTSC'' instructions (Read Time Stamp Counter)
** They generally come in pairs, followed by a comparison:
{{{
rdtsc
mov ebx, eax
... some measured code ...
rdtsc
sub eax, ebx
cmp eax, ... some tick count ...
jg detected_debugger
}}}
See the <<slider chkIdcColoring [[IDC Script: Coloring Unusual Instructions]] "Unusual Instruction Coloring Script example" "" >>
<<tabs tabClass
"About" "mouseover" [[About Triage]]
"Tasks" "mouseover" [[Triage Tasks]] >>
Common malware triage tasks include:
*File hashing (md5sum, sha1sum, ssdeep, sdhash)
*File type identification
*Packer/Compiler Identification (~PEiD)
*Entropy Analysis (Mandiant Red Curtain, IDA Entropy plugin/tool)
*strings
*Signature/AV Scan
**Clam AV
**Yara
*PE Header Analysis
*Simple dynamic analysis
*~URLDownloadToFile
*~URLDownloadToCacheFile
[[Urlmon Reference|http://msdn.microsoft.com/en-us/library/ms775150(v=vs.85).aspx]]
IDA loads the address pointed to by AddressOfEntryPoint in the PE Headers. Where do we go from here?
Ask yourself:
*What do I know about the application already?
**Outputs
**Inputs
**Functionality
*What am I looking for?
**Strings (e.g. output, packet content)
**Functionaltiy
**Control Structures
***Loops
***Conditional Statements
*~InternetOpen
*~InternetOpenUrl
*~InternetConnect
*~InternetReadFile
*~InternetWriteFile
*~HTTPOpenRequest
[[WinInet Reference|http://msdn.microsoft.com/en-us/library/windows/desktop/aa385331%28v=vs.85%29.aspx]]
*~WSAStartup
*htons
*getaddrinfo
*socket
*connect
*send
*recv
*~WSACleanup
[[Winsock2 Reference|http://msdn.microsoft.com/en-us/library/windows/desktop/ms740673%28v=vs.85%29.aspx]]
from pprint import pprint
import sys, pefile
def ROR(x, n, bits = 32):
mask = (2L**n) - 1
mask_bits = x & mask
return (x >> n) | (mask_bits << (bits - n))
def ROL(x, n, bits = 32):
return ROR(x, bits - n, bits)
def ror_hash( name, n ):
result = 0
for c in name:
result = ROR( result, n, 32 )
result += ord( c )
return result
def ror_13_hash( name ):
return ror_hash( name, 13 )
def get_api_hash_lookup( dll_name, hash_func ):
# Create a PE instance, parsing the library file
dll = pefile.PE( dll_name )
lookup = {}
count = 0
# Loop through the DLL's exports
for e in pe.DIRECTORY_ENTRY_EXPORT.symbols:
# Calculate the function name's hash
api_hash = hash_func( e.name )
lookup[ api_hash ] = e.name
print e.name, ": ", api_hash
count += 1
print count
return lookup
# Receive a DLL name from command-line
dll_name = sys.argv[0]
# Generate a a function name/ hash lookup table using the common ROR 13 hash method
dll_lookup = get_api_hash_lookup( dll_name, ror_13_hash )
# Print the lookup table
pprint( dll_lookup )
{{{
import pefile
from glob import glob
sec_names = {}
# Loop through all system32 exe files
for f in glob( 'c:\\windows\\system32\\*.exe'):
try:
# Create a PE instance, parsing the executable
pe = pefile.PE( f )
# Loop through each section
for s in pe.sections:
# Append the file to a dictionary keyed by section name
if sec_names.has_key( s.Name ):
sec_names[ s.Name ].append( f )
else:
sec_names[ s.Name ] = [ f ]
except:
print "Invalid file: ", f
# A lambda function to create a sort key
len_sort = lambda x: len( sec_names[ x ] )
sorted_names = sorted( sec_names.keys(), key=len_sort, reverse=True )
# print the section names and their frequencies in descending order
for k in sorted_names:
print "% 8s: %d" % ( k, len( sec_names[ k ] ) )
}}}