New or Updated Items - RCE Knowledge (including sub-categories)

Item Updated: Anti-Anti Dump and Nonintrusive Tracers

Listed in categories: Windows Anti Reversing Articles, Windows Internals Articles, Windows Unpacking Articles

Most recent release date:

Description:
"A novel method to manage new anti-dump buffer-based protections used by latest protectors as AsProtect SKE, Armadillo etc (sources included)"

Item Added: The "Ultimate" anti debugging reference

Listed in categories: Windows Anti Reversing Articles, Windows Protection Technique Articles

Most recent release date:
2004

Description:
A debugger is probably the most commonly-used tool when reverse-engineering (a disassembler tool such as the Interactive DisAssembler (IDA) being the next most common). As a result, anti-debugging tricks are probably the most common feature of code intended to interfere with reverse-engineering (and anti- disassembly constructs being the next most common). These tricks can simply detect the presence of the debugger, disable the debugger, escape from the control of the debugger, or even exploit a vulnerability in the debugger. The presence of a debugger can be inferred indirectly, or a specific debugger can be detected. Disabling or escaping from the control of the debugger can be achieved in both generic and specific ways.

What follows is a selection of the known techniques used to detect the presence of a debugger, and in some cases, the defences against them.

Item Updated: Super-secret debug capabilities of AMD processors !

Listed in categories: X86 Internals Articles

Most recent release date:
June 12, 2014

Description:
Secret debugging extensions in AMD K7 processors
************************************************
Here unveiled by Czerno - Mail : <me AT czerno.tk>
Original article : December, 2010. This revision : June, 2014.
Reason for revision : contents made more accurate, shorter and hopefully, clearer.

Copyleft (c) Czerno. Please keep attribution where it belongs.

The author shall not be held responsible for any errors or inaccuracies, blah-blah...

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Click the "more details" button or link downpage to view additional notes!
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°


°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Very important : you can help! Yes, YOU!

- By doing your own trial of the features and contacting us over any errors/inaccuracies/complements you find!
We want to assert, in particular, whether the features we found in Athlon-XP are present, possibly modified, in the newer generations of AMD CPUs.
- By updating debuggers, plugins and toolz so they can make full use of the new features.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

_Summary_ :

AMD K7 (Athlon-XP, etc.) processors have included some firmware-based debugging features that expand beyond standard, architecturally defined capabilities of X86. For some reason though, AMD has been tightly secretive about these features; their existence was first inferred by us after considering a list of undocumented MSRs found on CBID's page (URL, cf. notes below).

Herein we uncover the outcome of our experiments, in the hope it may be useful to software developers, & possibly included in future debuggers, debugger plug-ins or other tools.

I call the new capabilities "expanded", since the term "debug extensions" is already used to refer to other features in Pentium and later processors.

Author can be contacted by email, or PM, or on the reversing forum.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

_New MSRs_ :

Four undocumented machine specific registers (MSR) are involved in the expanded
debug facilities. These MSRs are "password" protected against casual access :
read/write access (RDMSR/WRMSR) to the registers is granted only if EDI holds
the correct password value, viz. EDI=9C5A203A. Otherwise, GPF exception occurs.

_Control_ @ C001_1024 , useful width: 8 bits
_Data_Match_ @ C001_1025 , width: 32
_Data_Mask_ @ C001_1026 , width: 32
_Address_Mask_ @ C001_1027 , width: 12 bits.

All four registers are zeroed upon processor reset.

Security considerations : As the features are controlled by MSRs whose access is restricted to code executed in "ring zero", their existence is generally not considered a security risk. However a malicious BIOS or OS driver could certainly make creative use of the features with some disturbing consequences against nsuspecting users.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

Let's examine the _Control Register_ first :

According to the "BIOS and Kernel developer's guide" for AMD NPT Family Fh, bit 7
of this register enables an external "hardware debug tool" connected to our processor using the JTAG bus. Such (expensive, professional) tool is not considered herein.

The BIOS guide further says bits 6-0 are "reserved, should be zero".
We found that on the K7 (Athlon XP), we can put bits 1-0 to good use, as explained
below ; we have not found any effect for bits 6-2, consequently we left them aside.

We shall henceforth be discussing the use of undocumented bits 1-0 of the Control register, leaving all other bits null.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

_Operational details_

The operation of breakpoint *BP0* (using DR0) is enhanced as will be described.
Breakpoints BP1 to BP3 are _not_ affected.

Breakpoint *BP0* _is_ modified, being further conditionned by the contents of the new MSRs in addition to legacy DR7. The features *cannot be switched off* : as soon as the address in DR0 is validated by setting DR7 bits 0 and/or 1, it behaves as will be explained, there is no further enabling bit.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

1) The Mask MSRs :

The "Address_Mask" qualifies the Address in DR0, while "Data_Mask" qualifies the "Data_Match" MSR.

In both masks, bits which are _set_ (=1) mean "don't care", don't look at the
corresponding bit when doing compares.

A mask value of all zeroes thus is asking for exact match.
Conversely, with a data mask of all ones, comparisons will always succeed.

The Address_Mask _should_ be a string of zeroes terminated by (zero or more) ones,
in other words a power of two minus one.

Address_Mask is only twelve bits wide, hence the largest allowable address mask : 00000FFF, matches 4096 page-aligned, consecutive memory (or I/O port) addresses.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

2) The Address_Mask:

It is used *unconditionally* for all three types of BP : instruction execution,
memory or IO data access.

A null mask, which is the default, in effect switches address expansion off, mimicking legacy breakpoint behavior.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

3) Instruction breakpoints (DR7 type =0):

Are triggered by instruction execution at _any_ address matching DR0 under Address_Mask.

Control_ MSR has no effect (should be zero).
Data_Match and Data_Mask are not used for this type of breakpoints.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

4) Memory & I/O Data breakpoint (DR7 types 1,3 and 2):

The Addres_mask is applied to DR0 address, for monitoring 1 up to 4096 consecutive bytes.

- Case: *Control = 0* (legacy), no additional check is performed. For memory access, Break occurs either on Write only, or on All_Access, selected by the legacy breakpoint "type" bits in DR7 (bite 17-16).
Data_Match and data_mask not used (should be zero).


- For the next three cases, Data compare is always done : to in effect disable it, one must use a Data_Mask of all ones (meaning : don't care).

- Case: *Control = 2* : Breaks occur on WRITE/OUT only. Even if the DR7 type is RW,
breaks never happen on Read. Traps on Data_Match.

- Case *control = 3* : same as Control = 2 , except the data condition is reversed,
i.e. Traps on Data_NON_Match.

- Case: *Control = 1* : break on Data_Match, on WRITE/OUT only, at ANY address!
Thus Address (DR0) and Address_Mask are ignored in this case (should be zero).

Reminder: I/O breakpoints require CR4 bit 3 (DE) set.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

Knowledge wants to be free !

Item Updated: Cryptexec: next-generation runtime binary encryption

Listed in categories: Linux Anti Reversing Articles, Linux ELF Articles, Linux Internals Articles

Most recent release date:
2005

Description:
1 Introduction
2 OS- and hardware-assisted tracing
3 Userland tracing
3.1 Provided API
3.2 High-level description
3.3 Actual usage example
3.4 XDE bug
3.5 Limitations
3.6 Porting considerations
4 Further ideas
5 Related work
5.1 ELFsh
5.2 Shiva
5.3 Burneye
5.4 Conclusion
6 References
7 Credits
A Appendix: source code
A.1 crypt_exec.S
A.2 cryptfile.c
A.3 test2.c

"What is binary encryption and why encrypt at all? For the answer to
this question the reader is referred to the Phrack#58 [1] and article
therein titled "Runtime binary encryption". This article describes a
method to control the target program that doesn't does not rely on
any assistance from the OS kernel or processor hardware. The method
is implemented in x86-32 GNU AS (AT&T syntax). Once the controlling
method is devised, it is relatively trivial to include on-the-fly
code decryption."

Item Updated: Manual binary mangling with radare

Listed in categories: Linux Anti Reversing Articles, Linux ELF Articles, Linux Internals Articles, Linux Protection Technique Articles, Linux Tool Articles

Most recent release date:
November 6, 2009

Description:
1 - Introduction
1.1 - The framework
1.2 - First steps
1.3 - Base conversions
1.4 - The target

2 - Injecting code in ELF
2.1 - Resolving register based branches
2.2 - Resizing data section
2.3 - Basics on code injection
2.4 - Mmap trampoline
2.4.1 - Call trampoline
2.4.2 - Extending trampolines

3 - Protections and manipulations
3.1 - Trashing the ELF header
3.2 - Source level watermarks
3.3 - Ciphering .data section
3.4 - Finding differences in binaries
3.5 - Removing library dependencies
3.6 - Syscall obfuscation
3.7 - Replacing library symbols
3.8 - Checksumming

4 - Playing with code references
4.1 - Finding xrefs
4.2 - Blind code references
4.3 - Graphing xrefs
4.4 - Randomizing xrefs

5 - Conclusion
6 - Future work
7 - References
8 - Greetings

"Reverse engineering is something usually related to w32 environments where
there is lot of non-free software and where the use of protections is more
extended to enforce evaluation time periods or protect intellectual (?)
property, using binary packing and code obfuscation techniques.

These kind of protections are also used by viruses and worms to evade
anti-virus engines in order to detect sandboxes. This makes reverse
engineering a double-edged sword..."

Item Added: DEX EDUCATION 201 ANTI-EMULATION

Listed in categories: Android Anti Reversing Articles

Most recent release date:

Description:
This is actually in continuance to http://www.woodmann.com/collaborative/knowledge/index.php/Dex_Education:_Practicing_Safe_Dex
The previous article is about Anti-Reversing against some of the Android Malware Analysis tools.
This paper is about Anti-Emulation for Android.

Item Added: Dex Education: Practicing Safe Dex

Listed in categories: Android Anti Reversing Articles

Most recent release date:

Description:
This is probably the first public publication on how Tim deconstruct some of the intricacies of the dex file format and analyze how some of the Android tools parse and manage the dex format. Along the way he observed a number of easily exploitable functionality, documenting specifically why they fail and how to fix them. A proof of concept tool - APKfuscator - that shows how to exploit these flaws.
It introduces some of the basic Anti-Reversing against some of the Android tools that Malware Analyst use to analyse Android Malware.

You can find his POC here.
https://github.com/strazzere/APKfuscator

Item Added: Portable Executable File Format – A Reverse Engineer View

Listed in categories: Windows Internals Articles

Most recent release date:
January 2006

Description:
This tutorial aims to collate information from a variety of sources and present it in a way which is accessible to beginners. Although detailed in parts, it is oriented towards reverse code engineering and superfluous information has been omitted.

Item Added: Introduction To Reverse Engineering Software

Listed in categories: Generic Malware Analysis Tutorials, Generic Reversing Technique Tutorials, Generic Tool Tutorials, Windows Malware Analysis Tutorials

Most recent release date:
June 16, 2011

Description:
This is a 2 days worth of class materials that you can use to teach your own classes.

--

Throughout the history of invention curious minds have sought to understand the inner workings of their gadgets. Whether investigating a broken watch, or improving an engine, these people have broken down their goods into their elemental parts to understand how they work. This is Reverse Engineering (RE), and it is done every day from recreating outdated and incompatible software, understanding malicious code, or exploiting weaknesses in software.

In this course we will explore what drives people to reverse engineer software and the methodology and tools used to do it.

Topics include, but are not limited to:
•Uses for RE
•The tricks and pitfalls of analyzing compiled code
•Identifying calling conventions
•How to navigate x86 assembly using IDA Pro
•Identifying Control Flows
•Identifying the Win32 API
•Using a debugger to aid RE
•Dynamic Analysis tools and techniques for RE

During the course students will complete many hands on exercises.

Introduction to x86 and Life of Binaries (both available at http://opensecuritytraining.info/Training.html) are prerequisites for this class.

This class will serve as a prerequisite for a later class specifically on malware analysis.

Item Added: Rootkits: What they are, and how to find them

Listed in categories: Generic Malware Analysis Tutorials, Generic Protection Technique Tutorials, Generic Reversing Technique Tutorials, Windows Internals Tutorials, Windows Malware Analysis Tutorials, Windows Tool Tutorials

Most recent release date:
September 21, 2011

Description:
This is a 2 day class which is freely available to watch. You can also take the materials and use them to teach your own classes.

--

Introductory Intel x86, Intermediate Intel x86, and Life of Binaries (all available at http://opensecuritytraining.info/Training.html) are strongly recommended to be taken before of this class.

Rootkits are a class of malware which are dedicated to hiding the attacker’s presence on a compromised system. This class will focus on understanding how rootkits work, and what tools can be used to help find them.

This will be a very hands-on class where we talk about specific techniques which rootkits use, and then do labs where we show how a proof of concept rootkit is able to hide things from a defender. Example techniques include
•Trojaned binaries
•Inline hooks
•Import Address Table (IAT) hooking
•System Call Table/System Service Descriptor Table (SSDT) hooking
•Interrupt Descriptor Table (IDT) hooking
•Direct Kernel Object Manipulation (DKOM)
•Kernel Object Hooking (KOH)
•IO Request Packet (IRP) filtering
•Hiding files/processes/open ports
•Compromising the Master Boot Record (MBR) to install a “bootkit”

The class will help the student learn which tools to use to look for rootkits on Windows systems, how to evaluate the breadth of a tool’s detection capabilities, and how to interpret tool results.

This class is structured so that students are given a homework to detect rootkits *before* they have taken the class. This homework is given in the context of the following scenario:

“You, being the only ‘security person’ in the area, have been called in to
examine a running Windows server because "it's acting funny." They don't
care that you like Mac/Linux/BSD/Plan9 better, you need to look at it! You
are solemnly informed that this is system is mission critical and can only
be rebooted if absolutely necessary. You must investigate whether any sort
of compromise has taken place on the system, with minimal impact to the
mission. What do you do? What DO you DO?”

The homework is then for the student to use any means at their disposal to write up answers to the following questions: “What malicious changes were made to the system?”, “What tools did you use to detect the changes?”, “How can you remove the changes?”. The students’ answers are then anonymized and shared with the rest of the class afterwards, so that they can see how others approached the problem, and learn from their techniques. The anonymization of the homework before distribution is important so that students know that even though they don’t know, and aren’t expected to know, anything about the area yet, their entry will not be judged by other students.

Item Added: The Life of Binaries

Listed in categories: Generic Malware Analysis Tutorials, Generic Protection Technique Tutorials, Generic Reversing Technique Tutorials, Linux ELF Articles, Windows Internals Tutorials, Windows Malware Analysis Tutorials, Windows Reversing Technique Tutorials, Windows Tool Tutorials, Windows Unpacking Tutorials

Most recent release date:
September 6, 2011

Description:
This is a 2 day class which is freely available to watch. You can also take the materials and use them to teach your own classes.

--


Topics include but are not limited to:
• Scanning and tokenizing source code.
• Parsing a grammar.
• Different targets for x86 assembly object files generation. (E.g. relocatable vs. position independent code).
• Linking object files together to create a well-formed binary.
• Detailed descriptions of the high level similarities and low level differences between the Windows PE and Linux ELF binary formats. (NOTE: we didn't get to this in the class where the video was recorded, but the materials are in the slides)
• How an OS loads a binary into memory and links it on the fly before executing it.

Along the way we discuss the relevance of security at different stages of a binary’s life, from the tricks that can be played by a malicious compiler, to how viruses really work, to the way which malware “packers” duplicate OS process execution functionality, to the benefit of a security-enhanced OS loader which implements address space layout randomization (ASLR).

Lab work includes:
• Manipulating compiler options to change the type of assembly which is output
• Manipulating linker options to change the structure of binary formats
• Reading and understanding PE files with PEView
• Reading and understanding ELF files with Readelf (NOTE: we didn't get to this in the class where the video was recorded, but the materials are in the slides)
• Using WinDbg and/or GDB to watch the loader dynamically link an executable
• Using Thread Local Storage (TLS) to obfuscate control flow and serve as a basic anti-debug mechanism
• Creating a simple example virus for PE
• Analyze the changes made to the binary format when a file is packed with UPX
• Using the rootkit technique of Import Address Table (IAT) hooking to subvert the integrity of a program’s calls to external libraries, allowing files to be hidden.

Knowledge of this material is recommended, but not required, for future classes such as Rootkits, but is required for reverse engineering. (Both also at http://opensecuritytraining.info/Training.html)

Item Added: Intermediate Intel x86: Architecture, Assembly, Applications, & Alliteration

Listed in categories: Generic Malware Analysis Tutorials, Generic Reversing Technique Tutorials, Windows Internals Tutorials, Windows Malware Analysis Tutorials, X86 Internals Tutorials

Most recent release date:
July 15, 2011

Description:
This is a 2 day class which is freely available to watch. You can also take the materials and use them to teach your own classes.

--

Building upon the Introductory Intel x86 class, this class goes into more depth on topics already learned, and introduces more advanced topics that dive deeper into how Intel-based systems work.

Topics include, but are not limited to:

•Physical and virtual memory and how a limited amount of physical memory is represented as much more virtual memory through a multilevel paging system. We will also talk about memory segmentation.
•The hardware basis for kernel versus userspace separation and how software transitions between the two. This portion answers the question of why does x86 have 4 “rings”, with ring 0 being the most privileged, and ring 3 being the least.
•Hardware and software interrupts, and how they are the basis for debugging.
•Input/Output instructions and how these allow the CPU to talk to peripherals.

Example applications include showing how hardware and memory mechanisms are used for software exploits, anti-debug techniques, rootkit hiding, and direct hardware access for keystroke logging.

This material includes labs on:
•Using WinDbg to perform kernel debugging on a virtual machine (which is equally applicable for debugging a real machine.)
•Using a custom WinDbg plugin to examine the Local (memory segment) Descriptor Table (LDT), and Global (memory segment) Descriptor Table (GDT) in order to understand how Windows sets memory segment ranges and permissions for userspace and kernel space.
•Using WinDbg and the !pte command to understand how Windows organizes its paging structures which map physical memory to virtual memory.
•Investigating where exactly the XD/NX bit is set in order to make memory as non-executable (which Microsoft calls Data Execution Prevention (DEP)), to prevent some types of exploits from succeeding.
•Using the Read Timestamp Counter (RDTSC) instruction to profile code execution time. Also, using a profile of code execution time to change a program’s behavior in the presence of a debugger (e.g. executing different code if the code appears to have been stopped at a breakpoint.)
•Printing information about task state segments, which hold information that is used to find the kernel stack when an interrupt occurs.
•Watching what does and doesn’t change when a software interrupt is used to transfer control from userspace to kernel.
•Reading the Interrupt Descriptor Table (IDT) and understanding the security implications of changes to it.
•Understanding how RedPill uses the IDT in order to detect that a system is virtualized.
•Having a process read its own memory when a software breakpoint is set, in order to see how a debugger will change memory to set the breakpoint but hide the change from the user.
•Watch how hardware-based breakpoints manipulate dedicated debug registers.
•Using port input/output to access the backdoor communications channel that VMWare uses in order to send copy/paste, mouse movement, and other events in and out of a VM.
•Using port I/O in order to talk directly to the PS2 keyboard controller in order to sniff keystrokes or flash keyboard LEDs.

Knowledge of this material is strongly encouraged for future classes such as Rootkits. (offered at http://opensecuritytraining.info/Training.html)

Item Added: Introductory Intel x86: Architecture, Assembly, Applications, & Alliteration

Listed in categories: Generic Malware Analysis Articles, Generic Reversing Technique Tutorials, X86 Internals Tutorials

Most recent release date:
June 27, 2011

Description:
This is a 2 day class which is freely available to watch. You can also take the materials and use them to teach your own classes.

--

Intel processors have been a major force in personal computing for more than 30 years. An understanding of low level computing mechanisms used in Intel chips as taught in this course serves as a foundation upon which to better understand other hardware, as well as many technical specialties such as reverse engineering, compiler design, operating system design, code optimization, and vulnerability exploitation.

25% of the time will be spent bootstrapping knowledge of fully OS-independent aspects of Intel architecture. 50% will be spent learning Windows tools and analysis of simple programs. The final 25% of time will be spent learning Linux tools for analysis.

This class serves as a foundation for the follow on Intermediate level x86 class. It teaches the basic concepts and describes the hardware that assembly code deals with. It also goes over many of the most common assembly instructions. Although x86 has hundreds of special purpose instructions, students will be shown it is possible to read most programs by knowing only around 20-30 instructions and their variations.

The instructor-led lab work will include:

* Stepping through a small program and watching the changes to the stack at each instruction (push, pop, call, ret (return), mov)
* Stepping through a slightly more complicated program (adds lea(load effective address), add, sub)
* Understanding the correspondence between C and assembly control transfer mechanisms (e.g. goto in C == jmp in ams)
* Understanding conditional control flow and how loops are translated from C to asm(conditional jumps, jge(jump greater than or equal), jle(jump less than or equal), ja(jump above), cmp (compare), test, etc)
* Boolean logic (and, or, xor, not)
* Logical and Arithmetic bit shift instructions and the cases where each would be used (shl (logical shift left), shr (logical shift right), sal (arithmetic shift left), sar(arithmetic shift right))
* Signed and unsigned multiplication and division
* Special one instruction loops and how C functions like memset or memcpy can be implemented in one instruction plus setup (rep stos (repeat store to string), rep mov (repeat mov)
* Misc instructions like leave and nop (no operation)
* Running examples in the Visual Studio debugger on Windows and the Gnu Debugger (GDB) on Linux
* The famous "binary bomb" lab from the Carnegie Mellon University computer architecture class, which requires the student to do basic reverse engineering to progress through the different phases of the bomb giving the correct input to avoid it “blowing up”. This will be an independent activity.


Knowledge of this material is a prerequisite for future classes such as Intermediate x86, Rootkits, Exploits, and Introduction to Reverse Engineering (all offered at http://opensecuritytraining.info/Training.html)

Item Updated: X86 Disassembly Using C and Assembly Language

Listed in categories: Generic Reversing Technique Articles

Most recent release date:
January 14, 2008

Description:
About
This book is about the disassembly of x86 machine code into human-readable assembly, and the decompilation
of x86 assembly code into human-readable C or C++ source code. Some topics covered will be common to all
computer architectures, not just x86-compatible machines.

Coverage
This book is going to look in-depth at the disassembly and decompilation of x86 machine code and assembly
code. We are going to look at the way programs are made using assemblers and compilers, and examine the way
that assembly code is made from C or C++ source code. Using this knowledge, we will try to reverse the
process. By examining common structures, such as data and control structures, we can find patterns that enable
us to disassemble and decompile programs quickly.

Item Added: Firmware reversing : Netgear DG834PN

Listed in categories: Linux Reversing Technique Articles

Most recent release date:
August 17, 2011

Description:
This short blogpost describes a technique used to identify the structure of a firmware image (an aDSL router in this case) and how to extract and mount its filesystem.

Item Added: Pinczakko's guide to Award BIOS reverse engineering

Listed in categories: X86 Internals Tidbits

Most recent release date:
2010

Description:
1. Foreword
2. Prerequisite
2.1. PCI BUS
2.2. ISA BUS
3. Some Hardware Peculiarities
3.1. BIOS Chip Addressing
3.2. Obscure Hardware Port
3.3. "Relocatable" Hardware Port
3.4. Expansion ROM Handling
4. Some Software Peculiarities
4.1. Call Instruction Peculiarity
4.2. Retn Instruction Peculiarity
5. Our Tools of Trade
5.1. What do we need anyway?
5.2. Intro to IDA Pro Techniques
5.2.1. Introducing IDA Pro
5.2.2. IDA Pro Scripting and Key Bindings
6. Award BIOS File Structure
6.1. The Compressed Components
6.2. The Pure Binary Components
6.3. The Memory Map In The Real System (Mainboard)
7. Disassembling the BIOS
7.1. Bootblock
7.1.1. "Virtual Shutdown" routine
7.1.2. Chipset_Reg_Early_Init routine
7.1.3. Init_Interrupt_n_PwrMgmt routine
7.1.4. Call To "Early Silicon Support" Routine
7.1.5. Bootblock Is Copied And Executed In RAM
7.1.6. Call to bios decompression routine and the jump into decompressed system bios
7.1.6.1. Enable FFF80000h-FFFDFFFFh decoding
7.1.6.2. Copy lower 128KB of BIOS code from ROM chip into RAM
7.1.6.3. Disable FFF8_0000h-FFFD_FFFFh decoding
7.1.6.4. Verify checksum of the whole compressed BIOS image
7.1.6.5. Look for the decompression engine
7.1.6.6. Decompress the compressed BIOS components
7.1.6.6.a. The format of the LZH level-1 compressed bios components
7.1.6.6.b. The location of various checksums
7.1.6.6.c. The key parts of the decompression routine
7.1.6.7. Shadow the BIOS code
7.1.6.8. Enable the microprocessor cache then jump into the decompressed system BIOS
7.2. System BIOS a.k.a Original.tmp
7.2.1. Entry point from "Bootblock in RAM"
7.2.2. The awardext.rom and Extension BIOS Components (lower 128KB bios-code) Relocation Routine
7.2.3. Call to the POST routine a.k.a "POST jump table execution"
7.2.4. The "segment vector" Routines
7.2.5. "chksum_ROM" Procedure
7.2.6. Original.tmp Decompression Routine for The "Extension_BIOS Components"
7.2.7. Microcode Update Routine
8. Rants and Raves
9. Closing

Item Added: Stuxnet's Rootkit (MRxNet) into C++

Listed in categories: Windows Malware Analysis Articles

Most recent release date:
January 28, 2011

Description:
This project is to convert mrxnet.sys into readable C++ source code very similar to the equivalent native code in mrxnet.sys sample .

Copyrights:
-----------
These Files (except mrxnet.sys) were created by Amr Thabet and coyrighted (c) by him

Files:
------
1.mrxnet.sys : The rootkit sample
2.mrxnet.idb : The IDA Pro database for Version 5.1
3.main.c : The main source code of mrxnet.sys rootkit sample (created by reversing manually of mrxnet.sys with only IDA Pro)
4.FastIo.c : The FastIoDispatch (you could ignore this part

The others are used for compiling the source code

Notes:
------
The source code is 95% similar to the real rootkit but that doesn't mean it should work exactly like mrxnet.sys as it still contain bugs and need to be fixed

Item Added: Binary Auditor Crackmes/Reversemes

Listed in categories: Generic Reversing Technique Crackmes, Windows Reversing Technique Crackmes

Most recent release date:

Description:
The archive of the now defunct binary-auditor website. As far as I know, this is the most recently uploaded compilation. Included in the archive is the beginner guide.

Item Updated: Undocumented trick : Direct access to Physical Memory on AMD K7

Listed in categories: X86 Internals Articles

Most recent release date:

Description:
GenericIA32 Intel architecture does not provide for direct access to *physical* memory addresses in paged, protected mode. On Athlon XP and similar AMD K7 processors, however, the undocumented MSR _C0010115_ opens a read/write window into physical memory, available in all modes at CPL zero.

For more details, please see my blog (URL below).

The Forum has a discussion of whether this trick is a theoretical vulnerability.

Item Updated: PDF - Vulnerabilities, Exploits and Malwares

Listed in categories: Generic Reversing Technique Articles, Generic Reversing Technique Tutorials, Generic Tool Articles, Generic Tool Tutorials

Most recent release date:
November 24, 2010

Description:
In this startup tutorial, Dhanesh explains how to use basic PDF analysis tools such as PDFAnalyzer in dissecting the exploit code from malicious PDF files in simple steps with illustrative screenshots.

Highlights of the Article:

* Throws light on usage of PDF analysis tools such as PDFAnalyzer
* Demonstrates malware analysis of real PDF samples
* Describes in detail dissecting of the exploit code from PDF structures.