Mar 19, 2016

Analyzing Malicious Documents

This cheat sheet outlines tips and tools for reverse-engineering malicious documents, such as Microsoft Office (DOC, XLS, PPT) and Adobe Acrobat (PDF) files.


General Approach

1.       Locate potentially malicious embedded code, such as shellcode, VBA macros or JavaScript.
2.       Extract suspicious code from the file.
3.       If relevant, disassemble and/or debug shellcode.
4.       If relevant, deobfuscate and examine JavaScript, ActionScript, or VB macro code.
5.       Understand next steps in the infection chain.


Microsoft Office Binary File Format Notes

Structured Storage (OLE SS) defines a file system inside the binary Microsoft Office file.
Data can be “storage” (folder) and “stream” (file).
Excel stores data inside the “workbook” stream.
PowerPoint stores data inside the “PowerPoint Document” stream.
Word stores data inside various streams.


Tools for Analyzing Microsoft Office Files

OfficeMalScanner locates shellcode and VBA macros from MS Office (DOC, XLS, and PPT) files.
MalHost-Setup extracts shellcode from a given offset in an MS Office file and embeds it an EXE file for further analysis. (Part of OfficeMalScanner)
Offvis shows raw contents and structure of an MS Office file, and identifies some common exploits.
Hachoir-urwid can navigate through the structure of binary Office files and view stream contents.
Office Binary Translator converts DOC, PPT, and XLS files into Open XML files (includes BiffView tool).
pyOLEScanner.py can examine and decode some aspects of malicious binary Office files.
FileHex (not free) and FileInsight hex editors can parse and edit OLE structures.


Useful MS Office Analysis Commands

OfficeMalScanner file.doc scan brute
Locate shellcode, OLE data, PE files in file.doc
OfficeMalScanner file.doc info
Locate VB macro code in file.doc (no XML files)
OfficeMalScanner file.docx inflate
Decompress file.docx to locate VB code (XML files)
MalHost-Setup file.doc out.exe 0x4500
Extract shellcode from file.doc’s offset 0x4500 and create it as out.exe


Adobe PDF File Format Notes

A PDF File is comprised of header, objects, cross-reference table (to locate objects), and trailer.
“/OpenAction” and “/AA” (Additional Action) specifies the script or action to run automatically.
 “/Names”, “/AcroForm”, “/Action” can also specify and launch scripts or actions.
“/JavaScript” specifies JavaScript to run.
 “/GoTo*” changes the view to a specified destination within the PDF or in another PDF file.
 “/Launch” launches a program or opens a document.
“/URI” accesses a resource by its URL.
“/SubmitForm” and “/GoToR” can send data to URL.
“/RichMedia” can be used to embed Flash in PDF.
“/ObjStm” can hide objects inside an Object Stream.
Be mindful of obfuscation with hex codes, such as “/JavaScript” vs. “/J#61vaScript”. (See examples)


Tools for Analyzing Adobe PDF Files

PDFiD identifies PDFs that contain strings associated with scripts and actions.
PDF-parser and Origami’s pdfwalker examine the structure and decode contents of PDF files.
Origami’s pdfextract and Jsunpackn’s pdf.py extract JavaScript from PDF files.
PDF Stream Dumper combines many PDF analysis tools under a single graphical user interface.
Peepdf and Origami’s pdfsh offer an interactive command-line shell for examining PDF files.
PDF X-RAY Lite creates an HTML report containing decoded PDF file structure and contents.
SWF mastah extracts SWF objects from PDF files.
Pyew includes commands for examining and decoding structure and content of PDF files.


Useful PDF Analysis Commands

pdfid.py
file.pdf
Locate script and action-related strings in file.pdf
pdf-parser.py
file.pdf
Show file.pdf’s structure to identify suspect elements
pdf-parser.py
--object id
file.pdf
Display contents of object id in file.pdf. Add “--filter --raw” to decode the object’s stream.
pdfextract
file.pdf
Extract JavaScript embedded in file.pdf and save it to file.dump.
pdf.py
file.pdf
Extract JavaScript embedded in file.pdf and save it to file.pdf.out.
swf_mastah.py –f file.pdf
–o out
Extract PDF objects from file.pdf into the out directory.


Additional PDF Analysis Tools

Malzilla and SpiderMonkey can help deobfuscate JavaScript embedded in malicious PDF files.
Wepawet, Jsunpack, VirusTotal and sandbox tools can analyze some aspects of malicious PDF files.
ExeFilter can filter scripts from Office and PDF files.


References



Authored by Lenny Zeltser with feedback and contributions from Pedro Bueno, Frank Boldewin, and Didier StevensCreative Commons v3 “Attribution” License for this cheat sheet version 2.
This and other malware analysis topics are covered in Lenny’s Reverse-Engineering Malware (REM) course, which he teaches at SANS Institute—for details visit 
LearnREM.com.

CreateProcess Function

Creates a new process and its primary thread. The new process runs in the security context of the calling process.
If the calling process is impersonating another user, the new process uses the token for the calling process, not the impersonation token. To run the new process in the security context of the user represented by the impersonation token, use the CreateProcessAsUser or CreateProcessWithLogonW function.

Syntax

BOOL WINAPI CreateProcess(
  _In_opt_    LPCTSTR               lpApplicationName,
  _Inout_opt_ LPTSTR                lpCommandLine,
  _In_opt_    LPSECURITY_ATTRIBUTES lpProcessAttributes,
  _In_opt_    LPSECURITY_ATTRIBUTES lpThreadAttributes,
  _In_        BOOL                  bInheritHandles,
  _In_        DWORD                 dwCreationFlags,
  _In_opt_    LPVOID                lpEnvironment,
  _In_opt_    LPCTSTR               lpCurrentDirectory,
  _In_        LPSTARTUPINFO         lpStartupInfo,
  _Out_       LPPROCESS_INFORMATION lpProcessInformation
);

Parameters

lpApplicationName [in, optional]
The name of the module to be executed. This module can be a Windows-based application. It can be some other type of module (for example, MS-DOS or OS/2) if the appropriate subsystem is available on the local computer.
The string can specify the full path and file name of the module to execute or it can specify a partial name. In the case of a partial name, the function uses the current drive and current directory to complete the specification. The function will not use the search path. This parameter must include the file name extension; no default extension is assumed.
The lpApplicationName parameter can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous. For example, consider the string "c:\program files\sub dir\program name". This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:
c:\program.exe files\sub dir\program name
c:\program files\sub.exe dir\program name
c:\program files\sub dir\program.exe name
c:\program files\sub dir\program name.exe
If the executable module is a 16-bit application, lpApplicationName should be NULL, and the string pointed to by lpCommandLine should specify the executable module as well as its arguments.
To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.
lpCommandLine [in, out, optional]
The command line to be executed. The maximum length of this string is 32,768 characters, including the Unicode terminating null character. If lpApplicationName is NULL, the module name portion of lpCommandLine is limited to MAX_PATH characters.
The Unicode version of this function, CreateProcessW, can modify the contents of this string. Therefore, this parameter cannot be a pointer to read-only memory (such as a const variable or a literal string). If this parameter is a constant string, the function may cause an access violation.
The lpCommandLine parameter can be NULL. In that case, the function uses the string pointed to by lpApplicationName as the command line.
If both lpApplicationName and lpCommandLine are non-NULL, the null-terminated string pointed to by lpApplicationName specifies the module to execute, and the null-terminated string pointed to by lpCommandLine specifies the command line. The new process can use GetCommandLine to retrieve the entire command line. Console processes written in C can use the argc and argv arguments to parse the command line. Because argv[0] is the module name, C programmers generally repeat the module name as the first token in the command line.
If lpApplicationName is NULL, the first white space–delimited token of the command line specifies the module name. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin (see the explanation for the lpApplicationName parameter). If the file name does not contain an extension, .exe is appended. Therefore, if the file name extension is .com, this parameter must include the .com extension. If the file name ends in a period (.) with no extension, or if the file name contains a path, .exe is not appended. If the file name does not contain a directory path, the system searches for the executable file in the following sequence:
  1. The directory from which the application loaded.
  2. The current directory for the parent process.
  3. The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
  4. The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
  5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  6. The directories that are listed in the PATH environment variable. Note that this function does not search the per-application path specified by the App Paths registry key. To include this per-application path in the search sequence, use the ShellExecute function.
The system adds a terminating null character to the command-line string to separate the file name from the arguments. This divides the original string into two strings for internal processing.
lpProcessAttributes [in, optional]
A pointer to a SECURITY_ATTRIBUTES structure that determines whether the returned handle to the new process object can be inherited by child processes. If lpProcessAttributes is NULL, the handle cannot be inherited.
The lpSecurityDescriptor member of the structure specifies a security descriptor for the new process. If lpProcessAttributes is NULL or lpSecurityDescriptor is NULL, the process gets a default security descriptor. The ACLs in the default security descriptor for a process come from the primary token of the creator.
Windows XP:  The ACLs in the default security descriptor for a process come from the primary or impersonation token of the creator. This behavior changed with Windows XP with SP2 and Windows Server 2003.
lpThreadAttributes [in, optional]
A pointer to a SECURITY_ATTRIBUTES structure that determines whether the returned handle to the new thread object can be inherited by child processes. If lpThreadAttributes is NULL, the handle cannot be inherited.
The lpSecurityDescriptor member of the structure specifies a security descriptor for the main thread. If lpThreadAttributes is NULL or lpSecurityDescriptor is NULL, the thread gets a default security descriptor. The ACLs in the default security descriptor for a thread come from the process token.
Windows XP:  The ACLs in the default security descriptor for a thread come from the primary or impersonation token of the creator. This behavior changed with Windows XP with SP2 and Windows Server 2003.
bInheritHandles [in]
If this parameter TRUE, each inheritable handle in the calling process is inherited by the new process. If the parameter is FALSE, the handles are not inherited. Note that inherited handles have the same value and access rights as the original handles.
dwCreationFlags [in]
The flags that control the priority class and the creation of the process. For a list of values, see Process Creation Flags.
This parameter also controls the new process's priority class, which is used to determine the scheduling priorities of the process's threads. For a list of values, see GetPriorityClass. If none of the priority class flags is specified, the priority class defaults to NORMAL_PRIORITY_CLASS unless the priority class of the creating process is IDLE_PRIORITY_CLASS or BELOW_NORMAL_PRIORITY_CLASS. In this case, the child process receives the default priority class of the calling process.
lpEnvironment [in, optional]
A pointer to the environment block for the new process. If this parameter is NULL, the new process uses the environment of the calling process.
An environment block consists of a null-terminated block of null-terminated strings. Each string is in the following form:
name=value\0
Because the equal sign is used as a separator, it must not be used in the name of an environment variable.
An environment block can contain either Unicode or ANSI characters. If the environment block pointed to by lpEnvironment contains Unicode characters, be sure that dwCreationFlags includes CREATE_UNICODE_ENVIRONMENT. If this parameter is NULL and the environment block of the parent process contains Unicode characters, you must also ensure that dwCreationFlags includes CREATE_UNICODE_ENVIRONMENT.
The ANSI version of this function, CreateProcessA fails if the total size of the environment block for the process exceeds 32,767 characters.
Note that an ANSI environment block is terminated by two zero bytes: one for the last string, one more to terminate the block. A Unicode environment block is terminated by four zero bytes: two for the last string, two more to terminate the block.
lpCurrentDirectory [in, optional]
The full path to the current directory for the process. The string can also specify a UNC path.
If this parameter is NULL, the new process will have the same current drive and directory as the calling process. (This feature is provided primarily for shells that need to start an application and specify its initial drive and working directory.)
lpStartupInfo [in]
A pointer to a STARTUPINFO or STARTUPINFOEX structure.
To set extended attributes, use a STARTUPINFOEX structure and specify EXTENDED_STARTUPINFO_PRESENT in the dwCreationFlags parameter.
Handles in STARTUPINFO or STARTUPINFOEX must be closed with CloseHandle when they are no longer needed.
Important  The caller is responsible for ensuring that the standard handle fields in STARTUPINFO contain valid handle values. These fields are copied unchanged to the child process without validation, even when the dwFlags member specifies STARTF_USESTDHANDLES. Incorrect values can cause the child process to misbehave or crash. Use the Application Verifier runtime verification tool to detect invalid handles.
lpProcessInformation [out]
A pointer to a PROCESS_INFORMATION structure that receives identification information about the new process.
Handles in PROCESS_INFORMATION must be closed with CloseHandle when they are no longer needed.

Return value

If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Note that the function returns before the process has finished initialization. If a required DLL cannot be located or fails to initialize, the process is terminated. To get the termination status of a process, call GetExitCodeProcess.

Remarks

The process is assigned a process identifier. The identifier is valid until the process terminates. It can be used to identify the process, or specified in the OpenProcess function to open a handle to the process. The initial thread in the process is also assigned a thread identifier. It can be specified in the OpenThread function to open a handle to the thread. The identifier is valid until the thread terminates and can be used to uniquely identify the thread within the system. These identifiers are returned in the PROCESS_INFORMATION structure.
The name of the executable in the command line that the operating system provides to a process is not necessarily identical to that in the command line that the calling process gives to the CreateProcess function. The operating system may prepend a fully qualified path to an executable name that is provided without a fully qualified path.
The calling thread can use the WaitForInputIdle function to wait until the new process has finished its initialization and is waiting for user input with no input pending. This can be useful for synchronization between parent and child processes, because CreateProcess returns without waiting for the new process to finish its initialization. For example, the creating process would use WaitForInputIdle before trying to find a window associated with the new process.
The preferred way to shut down a process is by using the ExitProcess function, because this function sends notification of approaching termination to all DLLs attached to the process. Other means of shutting down a process do not notify the attached DLLs. Note that when a thread calls ExitProcess, other threads of the process are terminated without an opportunity to execute any additional code (including the thread termination code of attached DLLs). For more information, see Terminating a Process.
A parent process can directly alter the environment variables of a child process during process creation. This is the only situation when a process can directly change the environment settings of another process. For more information, see Changing Environment Variables.
If an application provides an environment block, the current directory information of the system drives is not automatically propagated to the new process. For example, there is an environment variable named =C: whose value is the current directory on drive C. An application must manually pass the current directory information to the new process. To do so, the application must explicitly create these environment variable strings, sort them alphabetically (because the system uses a sorted environment), and put them into the environment block. Typically, they will go at the front of the environment block, due to the environment block sort order.
One way to obtain the current directory information for a drive X is to make the following call: GetFullPathName("X:", ...). That avoids an application having to scan the environment block. If the full path returned is X:\, there is no need to pass that value on as environment data, since the root directory is the default current directory for drive X of a new process.
When a process is created with CREATE_NEW_PROCESS_GROUP specified, an implicit call to SetConsoleCtrlHandler(NULL,TRUE) is made on behalf of the new process; this means that the new process has CTRL+C disabled. This lets shells handle CTRL+C themselves, and selectively pass that signal on to sub-processes. CTRL+BREAK is not disabled, and may be used to interrupt the process/process group.

Security Remarks

The first parameter, lpApplicationName, can be NULL, in which case the executable name must be in the white space–delimited string pointed to by lpCommandLine. If the executable or path name has a space in it, there is a risk that a different executable could be run because of the way the function parses spaces. The following example is dangerous because the function will attempt to run "Program.exe", if it exists, instead of "MyApp.exe".
  LPTSTR szCmdline = _tcsdup(TEXT("C:\\Program Files\\MyApp -L -S"));
        CreateProcess(NULL, szCmdline, /* ... */);
If a malicious user were to create an application called "Program.exe" on a system, any program that incorrectly calls CreateProcess using the Program Files directory will run this application instead of the intended application.
To avoid this problem, do not pass NULL for lpApplicationName. If you do pass NULL for lpApplicationName, use quotation marks around the executable path in lpCommandLine, as shown in the example below.
  LPTSTR szCmdline[] = _tcsdup(TEXT("\"C:\\Program Files\\MyApp\" -L -S"));
        CreateProcess(NULL, szCmdline, /*...*/);

Examples

For an example, see Creating Processes.

Requirements

Minimum supported clientWindows XP [desktop apps only]
Minimum supported serverWindows Server 2003 [desktop apps only]
Header
WinBase.h on Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 (include Windows.h);
Processthreadsapi.h on Windows 8 and Windows Server 2012
Library
Kernel32.lib
Kernel32.dll
Unicode and ANSI namesCreateProcessW (Unicode) and CreateProcessA (ANSI)

See also

CloseHandle
CreateProcessAsUser
CreateProcessWithLogonW
ExitProcess
GetCommandLine
GetEnvironmentStrings
GetExitCodeProcess
GetFullPathName
GetStartupInfo
OpenProcess
Process and Thread Functions
PROCESS_INFORMATION
Processes
SECURITY_ATTRIBUTES
SetErrorMode
STARTUPINFO
STARTUPINFOEX
TerminateProcess
WaitForInputIdle


[source: Microsoft MSDN]

Process Creation Flags (CreateProcess function)


The following process creation flags are used by the CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, and CreateProcessWithTokenW functions. They can be specified in any combination, except as noted.


Constant/valueDescription
CREATE_BREAKAWAY_FROM_JOB
0x01000000
The child processes of a process associated with a job are not associated with the job.
If the calling process is not associated with a job, this constant has no effect. If the calling process is associated with a job, the job must set the JOB_OBJECT_LIMIT_BREAKAWAY_OK limit.
CREATE_DEFAULT_ERROR_MODE
0x04000000
The new process does not inherit the error mode of the calling process. Instead, the new process gets the default error mode.
This feature is particularly useful for multithreaded shell applications that run with hard errors disabled.
The default behavior is for the new process to inherit the error mode of the caller. Setting this flag changes that default behavior.
CREATE_NEW_CONSOLE
0x00000010
The new process has a new console, instead of inheriting its parent's console (the default). For more information, see Creation of a Console.
This flag cannot be used with DETACHED_PROCESS.
CREATE_NEW_PROCESS_GROUP
0x00000200
The new process is the root process of a new process group. The process group includes all processes that are descendants of this root process. The process identifier of the new process group is the same as the process identifier, which is returned in the lpProcessInformation parameter. Process groups are used by the GenerateConsoleCtrlEvent function to enable sending a CTRL+BREAK signal to a group of console processes.
If this flag is specified, CTRL+C signals will be disabled for all processes within the new process group.
This flag is ignored if specified with CREATE_NEW_CONSOLE.
CREATE_NO_WINDOW
0x08000000
The process is a console application that is being run without a console window. Therefore, the console handle for the application is not set.
This flag is ignored if the application is not a console application, or if it is used with either CREATE_NEW_CONSOLE or DETACHED_PROCESS.
CREATE_PROTECTED_PROCESS
0x00040000
The process is to be run as a protected process. The system restricts access to protected processes and the threads of protected processes. For more information on how processes can interact with protected processes, see Process Security and Access Rights.
To activate a protected process, the binary must have a special signature. This signature is provided by Microsoft but not currently available for non-Microsoft binaries. There are currently four protected processes: media foundation, audio engine, Windows error reporting, and system. Components that load into these binaries must also be signed. Multimedia companies can leverage the first two protected processes. For more information, see Overview of the Protected Media Path.
Windows Server 2003 and Windows XP:  This value is not supported.
CREATE_PRESERVE_CODE_AUTHZ_LEVEL
0x02000000
Allows the caller to execute a child process that bypasses the process restrictions that would normally be applied automatically to the process.
CREATE_SEPARATE_WOW_VDM
0x00000800
This flag is valid only when starting a 16-bit Windows-based application. If set, the new process runs in a private Virtual DOS Machine (VDM). By default, all 16-bit Windows-based applications run as threads in a single, shared VDM. The advantage of running separately is that a crash only terminates the single VDM; any other programs running in distinct VDMs continue to function normally. Also, 16-bit Windows-based applications that are run in separate VDMs have separate input queues. That means that if one application stops responding momentarily, applications in separate VDMs continue to receive input. The disadvantage of running separately is that it takes significantly more memory to do so. You should use this flag only if the user requests that 16-bit applications should run in their own VDM.
CREATE_SHARED_WOW_VDM
0x00001000
The flag is valid only when starting a 16-bit Windows-based application. If the DefaultSeparateVDM switch in the Windows section of WIN.INI is TRUE, this flag overrides the switch. The new process is run in the shared Virtual DOS Machine.
CREATE_SUSPENDED
0x00000004
The primary thread of the new process is created in a suspended state, and does not run until the ResumeThread function is called.
CREATE_UNICODE_ENVIRONMENT
0x00000400
If this flag is set, the environment block pointed to by lpEnvironment uses Unicode characters. Otherwise, the environment block uses ANSI characters.
DEBUG_ONLY_THIS_PROCESS
0x00000002
The calling thread starts and debugs the new process. It can receive all related debug events using the WaitForDebugEvent function.
DEBUG_PROCESS
0x00000001
The calling thread starts and debugs the new process and all child processes created by the new process. It can receive all related debug events using the WaitForDebugEvent function.
A process that uses DEBUG_PROCESS becomes the root of a debugging chain. This continues until another process in the chain is created with DEBUG_PROCESS.
If this flag is combined with DEBUG_ONLY_THIS_PROCESS, the caller debugs only the new process, not any child processes.
DETACHED_PROCESS
0x00000008
For console processes, the new process does not inherit its parent's console (the default). The new process can call the AllocConsole function at a later time to create a console. For more information, see Creation of a Console.
This value cannot be used with CREATE_NEW_CONSOLE.
EXTENDED_STARTUPINFO_PRESENT
0x00080000
The process is created with extended startup information; the lpStartupInfo parameter specifies a STARTUPINFOEX structure.
Windows Server 2003 and Windows XP:  This value is not supported.
INHERIT_PARENT_AFFINITY
0x00010000
The process inherits its parent's affinity. If the parent process has threads in more than one processor group, the new process inherits the group-relative affinity of an arbitrary group in use by the parent.
Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP:  This value is not supported.




[source: Microsoft MSDN]

Intel x86 JUMP Reference Chart



InstructionDescriptionsigned-nessFlagsshort
jump
opcodes
near
jump
opcodes
JOJump if overflowOF = 1700F 80
JNOJump if not overflowOF = 0710F 81
JSJump if signSF = 1780F 88
JNSJump if not signSF = 0790F 89
JE
JZ
Jump if equal
Jump if zero
ZF = 1740F 84
JNE
JNZ
Jump if not equal
Jump if not zero
ZF = 0750F 85
JB
JNAE
JC
Jump if below
Jump if not above or equal
Jump if carry
unsignedCF = 1720F 82
JNB
JAE
JNC
Jump if not below
Jump if above or equal
Jump if not carry
unsignedCF = 0730F 83
JBE
JNA
Jump if below or equal
Jump if not above
unsignedCF = 1 or ZF = 1760F 86
JA
JNBE
Jump if above
Jump if not below or equal
unsignedCF = 0 and ZF = 0770F 87
JL
JNGE
Jump if less
Jump if not greater or equal
signedSF <> OF7C0F 8C
JGE
JNL
Jump if greater or equal
Jump if not less
signedSF = OF7D0F 8D
JLE
JNG
Jump if less or equal
Jump if not greater
signedZF = 1 or SF <> OF7E0F 8E
JG
JNLE
Jump if greater
Jump if not less or equal
signedZF = 0 and SF = OF7F0F 8F
JP
JPE
Jump if parity
Jump if parity even
PF = 17A0F 8A
JNP
JPO
Jump if not parity
Jump if parity odd
PF = 07B0F 8B
JCXZ
JECXZ
Jump if %CX register is 0
Jump if %ECX register is 0
%CX = 0
%ECX = 0
E3



Conditional Branching Processor Flags

OF (Overflow)
1 -- result is outside signed-number range
0 -- otherwise
CF (Carry)
Carry out of (borrow into) high-order bit.
1 -- result is outside unsigned-number range
0 -- otherwise
SF (Sign)
High-order bit of result.
1 -- negative signed number.
0 -- positive signed number.
ZF (Zero)
1 -- result = 0
0 -- otherwise


Reverse Engineering Cheat Sheet

Good reference material is a must when it comes to digital forensics and reverse engineering.

Here is a great reference / cheat sheet for reversing that I found on r00ted.com.


Welcome


dirty mug

Welcome and if you reading this, you’ve somehow found the first (and hopefully not the last) post in this little blog. Malreveng is stands for “malware reverse engineering” and with all of the insane talent out there, this is merely a humble attempt to contribute something to the dfir/re community. The purpose of this blog is simple. To share information related to digital forensics
and malware reversing such as – examination techniques, forensic analysis tips, malware exploration, cool analysis tools, and anything else that i think will be interesting to others in the field or those just wanting to learn. So, as time allows, i will take this one post at a time and hope someone out there gets some benefit from it – one day.