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.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°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.

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.

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.

According to the "BIOS and Kernel developer's guide" for AMD NPT Family Fh, bit 7of 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 explainedbelow ; 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.

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.

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.

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

"Reverse engineering is something usually related to w32 environments wherethere is lot of non-free software and where the use of protections is moreextended 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 evadeanti-virus engines in order to detect sandboxes. This makes reverseengineering a double-edged sword..."

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

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.

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.

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.

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 toexamine a running Windows server because "it's acting funny." They don'tcare that you like Mac/Linux/BSD/Plan9 better, you need to look at it! Youare solemnly informed that this is system is mission critical and can onlybe rebooted if absolutely necessary. You must investigate whether any sortof compromise has taken place on the system, with minimal impact to themission. 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.

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)

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)

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)

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

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

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 sample2.mrxnet.idb : The IDA Pro database for Version 5.13.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

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.

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.