Reverse Code Engineering
56 files
-
Spoofing Disks Serial Number Staticly - Part 2
By Exists4All
In this tutorial we are mainly trying to analyze WIndows internals and learn about Hard disks more. These methods by no means are enough to bypass modern kernel anti cheats. There are lots of ways to track modifications and get DiskSerials later. For example Vanguard anti-cheat will start before most drivers and will track all the HWIDs before even spoofing them with these outdated methods. However, this is a good opportunity to learn the basics and develop more advanced spoofers by merging new methods and tools with it.
20 downloads
0 comments
Submitted
-
Writing a WinRAR Key Logger
By Teddy Rogers
In this tutorial I will show how to write a WinRAR key logger. This key logger is different from other key loggers that are available on the net in the sense that it does not require any installation or starting any background hidden process/services that hijacks the keyboard and listens for key presses. This key logger is also not truly a key logger. It only logs password typed on the "Enter password" dialog box as shown below.
244 downloads
0 comments
Submitted
-
Win32 Reverse Engineering Cheat-Sheet
By Teddy Rogers
A x86/Win32 reverse engineering cheat-sheet.
456 downloads
0 comments
Submitted
-
When Memory Management Goes Bad
By Teddy Rogers
Case study of memory management in cmd.exe. Article describes some bad programming pratices that are used in cmd.exe and possible workarounds that can be done with some reverse engineering knowledge.
116 downloads
0 comments
Submitted
-
Visual Basic Tricks
By Teddy Rogers
Some people thinking crack the visual basic programs it difficult but in truth not difficult and through cracking many of visual basic programs accumulation for me some experience in cracking this quality of programs and let's start with the first example...
223 downloads
0 comments
Submitted
-
Tracing Delphi MessageBox
By Teddy Rogers
This tutorial will explain how to use the Execute Till User Code function to trace MessageBoxes in Delphi, which is a little different than other programming languages. I try to explain it in a way beginners can understand it!
I hope you will enjoy this tutorial, and that will come in handy once!
332 downloads
0 comments
Submitted
-
Theories and Methods of Code-Caves
By Teddy Rogers
Since many have read my tutorial on basic memory hacking and got stuck on the creation of code-caves, I've decided to make a short follow-up on some code-cave techniques where I'll explain the WHYs and the HOWs.
Archive also contains "Theories and methods of memory hacking".
168 downloads
0 comments
Submitted
-
The NTkrnl Journal Volume 1 (Issue 1-2)
By Teddy Rogers
Inject the code to Windows Application
It might be that you want to comprehend the ways a virus program injects its procedure in to the interior of a portable executable file and corrupts it, or you are interested in implementing a packer or a protector for your specific intention to encrypt the data of your Portable Executable (PE) file. This article is committed to represent a brief intuition to the performance which is done by EXE tools or some kind of mal-wares.
You can employ the source code of this article to create your custom EXE builder. It could be used to make an EXE protector in the right way, or with a wrong intention, to pullulate a virus. However, my purpose of writing this article has been to gaze on the first application, so I will not be responsible for the immoral usage of these methods.
The .NET File Format
The standards of the .NET format are public, you can find them on Microsoft and in your .NET SDK (look after "Partition II Metadata.doc"), but they are intended to be more like a reference, not really a guide. So, the truth is that a description of the format can be useful. I mean, there's a huge difference between having the WinNT.h and having the full explanation of its structures and stuff. The documentation given by Microsoft has some explanations, but a lot of passages aren't very clear at all. Of course, it's required that you know quite well the PE File Format. If that's not the case, you should start with that first, otherwise you won't be able to make heads or tails of this article. A little warning: I'm not going to explain how to use the libraries given by Microsoft to access the .NET format; I'm going to explain the format itself. This article is based on the Framework 2.0.
.NET Manifest Resources
This article is about the internal format of .NET Manifest Resources (or better the ".resources" files contained in it). I don't know if the code can be useful to you or not (probably not), but I like to write about undocumented stuff. In fact, this article is nothing sensational, I just wrote it 'cause I haven't found any documentation about this subject on the net, not even in the .NET MetaData specifics: Partition II MetaData.doc.
Some time ago I wrote a PE Editor called CFF Explorer ('cause I needed to) with the support for .NET MetaData, since there wasn't such a tool. The only tool I could find was Asmex (which you can find on codeproject), but the problem with that tool is that you cannot modify the MetaData fields and, moreover, it relies still on the .NET Framework. And I don't say this to criticize Asmex, which is surely useful, but because I needed something different. Anyway I wrote a resource viewer for the PE Editor and wanted to show the MetaData resources as well. So, in order to do that, avoiding to use an external .NET Assembly, I had to analyze the Manifest Resource format.
The .NET File Format (continued...)
Inject the code to Windows Application (continued...)
120 downloads
0 comments
Submitted
-
Reversing of a Protection Scheme Based on Drivers Sandboxie
By Teddy Rogers
Sometime happens to fall into an interesting protection which reveals to be nicely implemented and nice to describe into a tutorial. This time is the turn of SandBoxie, a program that has an nice protection schema. I thought it could have been useful to reverse and document in a tutorial, mostly because I used a lot a combination of OllyDbg and IDA Debugger.
This time I preferred using IDA as much as possible to understand the code and then OllyDbg only to verify the assumptions done. This method of investigation is usually very common when you have to analyze malware, but also very handy, because IDA allows saving of reversing sessions, code editing, name changing taking advantages from both and so on.
I need reversing instruments that could be frozen at any time (I have very few and scattered spare time): I usually run the dynamic sessions with OllyDbg on a VMWARE virtual PC which I can freeze at anytime and the analysis sessions with IDA (which can also be closed and started again later for another session).
As usual there are cracks and keygens too for this program around the net and this tutorial will not create many troubles than those already created by someone else.
Moreover it will then be the occasion to deeper dig the IDA functionalities in combination with OllyDbg, I will try to be as much clear as possible, for everyone.
130 downloads
0 comments
Submitted
-
Reversing Microsoft Visual C++
By Teddy Rogers
Microsoft Visual C++ is the most widely used compiler for Win32 so it is important for the Win32 reverser to be familiar with its inner working. Being able to recognize the compiler-generated glue code helps to quickly concentrate on the actual code written by the programmer. It also helps in recovering the high-level structure of the program.
In part I of this 2-part article (see also: Part II: Classes, Methods and RTTI), I will concentrate on the stack layout, exception handling and related structures in MSVC-compiled programs. Some familiarity with assembler, registers, calling conventions etc. is assumed.
Terms:
Stack frame: A fragment of the stack segment used by a function. Usually contains function arguments, return-to-caller address, saved registers, local variables and other data specific to this function. On x86 (and most other architectures) caller and callee stack frames are contiguous.
Frame pointer: A register or other variable that points to a fixed location inside the stack frame. Usually all data inside the stack frame is addressed relative to the frame pointer. On x86 it's usually ebp and it usually points just below the return address.
Object: An instance of a (C++) class.
Unwindable Object: A local object with auto storage-class specifier that is allocated on the stack and needs to be destructed when it goes out of scope.
Stack UInwinding: Automatic destruction of such objects that happens when the control leaves the scope due to an exception.
There are two types of exceptions that can be used in a C or C++ program.
SEH exceptions (from "Structured Exception Handling"). Also known as Win32 or system exceptions. These are exhaustively covered in the famous Matt Pietrek article[1]. They are the only exceptions available to C programs. The compiler-level support includes keywords __try, __except, __finally and a few others.
C++ exceptions (sometimes referred to as "EH"). Implemented on top of SEH, C++ exceptions allow throwing and catching of arbitrary types. A very important feature of C++ is automatic stack unwinding during exception processing, and MSVC uses a pretty complex underlying framework to ensure that it works properly in all cases.
In the following diagrams memory addresses increase from top to bottom, so the stack grows "up". It's the way the stack is represented in IDA and opposite to the most other publications.
318 downloads
0 comments
Submitted
-
Reversing MFC Applications
By Teddy Rogers
MFC Programs seems to be the mainstream of Win32 GUI programming these days, other than QT applications that are rapidly gaining popularity recently. A few days ago, I suddenly got interested in embedded system reversing but was confronted by the task to reverse an application that uploads the firmware image to the embedded system. As expected, the application was MFC, and I was a bit taken back. I wasn't that confident in MFC reversing.
I've seen many people (including me) reverse MFC applications in the same way as reversing pure Win32 API applications. Put breakpoints on certain APIs, search for a target string, search for a certain constant, etc etc. There is no problem with that. The same principles used in non-MFC app reversing can also be applied to MFC apps except.
Except you can't find the Window Procedure within the application. Window Procedures are like the root function of where all the messages are processed, and when you know where it's located, you can always track down your target in a root to descendant kind of approach. It may take more time than the start from a certain function, string etc. approach, but when the later approach may sometimes make you get lost in a labyrinth of code and functions, the formal usually never goes wrong.
The problem is, all the WndProc code is managed by the MFC framework, and the framework gives a slight twist to it to make it work in a different process than what we already know about Window Procedures. The principles are the same, but the structure is a little bit different, and the Message dispatcher code is no longer handled by the programmer. The question is, where is that code and what does it look like? And how could we use it to our advantage?
That will be the main focus of this tutorial, and I will start with showing the usual approach, and point out the problems that may occur in certain situations.
941 downloads
0 comments
Submitted
-
Reversing J2ME Applications
By Teddy Rogers
I wrote this tutorial so that absolute beginners who want to learn reversing j2me applications quickly without going to some hardcore brain busting.
This tutorial contains 2 parts, the introduction and the reversing part.
146 downloads
0 comments
Submitted
-
Reversing C++
By Teddy Rogers
As reverse engineers, it is important that we are able to understand C++ concepts as they are represented in disassemblies and of course, have a big picture idea on what are the major pieces (classes) of the C++ target and how these pieces relate together (class relationships). In order to achieve this understanding, the reverse engineer must able to (1) Identify the classes (2) Identify relationships between classes (3) Identify class members. This paper attempts to provide the reader information on how to achieve these three goals. First, this paper discusses the manual approach on analyzing C++ targets in order to retrieve class information. Next, it discusses ways on how to automate these manual approaches.
378 downloads
0 comments
Submitted
-
Reversing and Exploiting Apple Firmware Update
By Teddy Rogers
The security posture of a computer can be adversely affected by poorly-designed devices on its USB bus. Many modern embedded devices permit firmware to be upgraded in the field and the use of low-cost microcontrollers in these devices can make it difficult to perform the mathematical operations needed to verify a crypto-graphic signature. The security of many of these upgrade mechanisms is very much in question. For a concrete example, we describe how to tamper with a firmware upgrade to the Apple Aluminum Keyboard. We describe how an attacker can subvert an off-the-shelf keyboard by embedding into the firmware malicious code which allows a rootkit to survive a clean re-installation of the host operating system.
107 downloads
0 comments
Submitted
-
Reversers Guide to Python
By Teddy Rogers
Python has to be one of the more interesting languages I've seen. Its syntax is clear and easy to pick up. It is multi-platform. It is optimized per platform so it is very fast. In fact, in many ways it is a better choice than Java. Developers seem to be afraid to make commercial applications in python, and go with Oracle instead. They assume that since it is OSS, it will be easier to crack. Don't get me wrong, every python app I have ever cracked was a one byte fix, but that cannot be blamed on the language. Note that obfuscation is available, but I have yet to see in it use. This language has been around for 20 years, and its usage is bound to continue to increase.
Those familiar with reversing Java, .Net, or VB P-code apps will feel right at home with Python. One thing to note is that Python has no decompiler yet. Luckily, Python byte-code is very readable. We will get to that in a bit.
227 downloads
0 comments
Submitted
-
Reversing a Frozen Python Executable
By Teddy Rogers
This document presents a way to reverse engineer frozen python executables.
We all at some point of time have reversed native compiled application like the ones generated from Visual C++, Delphi etc, but reversing frozen python executable presents a new challenge and the area in this field is not yet fully explored.
So this document is going to explore some of those and the way we can proceed in such a situation.
[This whole tutorial is for learning purposes only and any other unethical use is strongly discouraged]
168 downloads
0 comments
Submitted
-
Reversed Compilation Techniques
By Teddy Rogers
Techniques for writing reverse compilers or decompilers are presented in this thesis. These techniques are based on compiler and optimization theory, and are applied to decompilation in a unique way; these techniques have never before been published.
A decompiler is composed of several phases which are grouped into modules dependent on language or machine features. The front-end is a machine dependent module that parses the binary program, analyzes the semantics of the instructions in the program, and generates an intermediate low-level representation of the program, as well as a control flow graph of each subroutine. The universal decompiling machine is a language and machine independent module that analyzes the low-level intermediate code and transforms it into a high-level representation available in any high-level language, and analyzes the structure of the control ow graph(s) and transform them into graphs that make use of high-level control structures. Finally, the back-end is a target language dependent module that generates code for the target language.
Decompilation is a process that involves the use of tools to load the binary program into memory, parse or disassemble such a program, and decompile or analyze the program to generate a high-level language program. This process bene ts from compiler and library signatures to recognize particular compilers and library subroutines. Whenever a compiler signature is recognized in the binary program, all compiler start-up and library subroutines are not decompiled; in the former case, the routines are eliminated from the nal target program and the entry point to the main program is used for the decompiler analysis, in the latter case the subroutines are replaced by their library name.
The presented techniques were implemented in a prototype decompiler for the Intel i80286 architecture running under the DOS operating system, dcc, which produces target C programs for source .exeor .com les. Sample decompiled programs, comparisons against the initial high-level language program, and an analysis of results is presented in Chapter 9. Chapter 1 gives an introduction to decompilation from a compiler point of view, Chapter 2 gives an overview of the history of decompilation since its appearance in the early 1960s, Chapter 3 presents the relations between the static binary code of the source binary program and the actions performed at run-time to implement the program, Chapter 4 describes the phases of the front-end module, Chapter 5 describes data optimization techniques to analyze the intermediate code and transform it into a higher-representation, Chapter 6 de nes control structure transformation techniques to analyze the structure of the control ow graph and transform it into a graph of high-level control structures, Chapter 7 describes the back-end module, Chapter 8 presents the decompilation tool programs, Chapter 9 gives an overview of the implementation of dcc and the results obtained, and Chapter 10 gives the conclusions and future work of this research.
174 downloads
0 comments
Submitted
-
Preventing Reverse Engineering of Native and Managed Programs
By Teddy Rogers
One of the important aspects of protecting software from attack, theft of algorithms, or illegal software use is eliminating the possibility of performing reverse engineering. One common method used to deal with these issues is code obfuscation. However, it is proven to be ineffective. Code encryption is a much more effective means of defying reverse engineering, but it requires managing a cryptographic key available to none but the permissible users. The thesis presents a system for managing cryptographic keys in a protected environment and supporting execution of encrypted code. The system has strong security guarantees. In particular, the cryptographic keys are never stored on the target machine, but rather delivered to it from a remote server, upon a successful verification of its authenticity. The keys and the decrypted instructions are protected by a thin hypervisor at all times. The system allows the encryption and execution of both native and Java code.
During native code execution, the decrypted instructions are inaccessible to a potentially malicious code. This is achieved by either preventing execution of any other code or by protecting the memory region containing the decrypted instructions during their execution.
Java programs, unlike native programs, are not executed directly by the processor, but are interpreted (and sometimes compiled) by the Java Virtual Machine (JVM). Therefore, the JVM will require the cryptographic key to decrypt the encrypted portions of Java code, and there is no feasible way of securing the key inside the JVM. The thesis proposes to implement a Java bytecode interpreter inside the secure environment, governed by a thin hypervisor. This interpreter will run in parallel to the standard JVM, both cooperating to execute encrypted Java programs.
118 downloads
0 comments
Submitted
-
Reverse Engineering Techniques - Part 1
By Teddy Rogers
The whole tutorial is about playing with a target and implementing new things into it. The tutorial is not for newbies, you must know how the tools given in this tutorial works. The entire article is based on exploring the calibre of a reverse engineer. Reverse engineering is an art; how to analyse and play with the target and find out other possibilities which you can implement. Sometimes targets are so challenging you can't even imagine. The target I am going to use in this tutorial is a simple crackme by Nemo.
227 downloads
0 comments
Submitted
-
Reverse Engineering Self-Modifying Code Unpacker Extraction
By Teddy Rogers
An important application of binary-level reverse engineering is in reconstructing the internal logic of computer malware. Most malware code is distributed in encrypted (or "packed") form; at runtime, an unpacker routine transforms this to the original executable form of the code, which is then executed. Most of the existing work on analysis of such programs focuses on detecting unpacking and extracting the unpacked code. However, this does not shed any light on the functionality of different portions of the code so obtained, and in particular does not distinguish between code that performs unpacking and code that does not; identifying such functionality can be helpful for reverse engineering the code. This paper describes a technique for identifying and extracting the unpacker code in a self-modifying program. Our algorithm uses offline analysis of a dynamic instruction trace both to identify the point(s) where unpacking occurs and to identify and extract the corresponding unpacker code.
159 downloads
0 comments
Submitted
-
Reverse Engineering of Real-Time Assembly Code
By Teddy Rogers
Much legacy real-time code is written in assembly language. Such code is often crafted to meet stringent time and space requirements so the high-level intent of the programmer may have been obscured. The result is code that is difficult to maintain and reuse. In this paper we present a tool for reverse engineering of real-time Z86 assembly code, together with a tool for validation of the output. Our experimental results are for a suite of commercial micro-controllers. For those benchmarks, our tool does the bulk of the reverse-engineering work, leaving just a few undisciplined uses of machine code to be handled manually. Our tool is designed to preserve programmer intent to the largest extent possible. Thus, the reverse engineered program is easier to understand and maintain than the original.
139 downloads
0 comments
Submitted
-
Reverse Engineering of Data and Binary Files
By Teddy Rogers
The analysis of computer files poses a difficult problem for security researchers seeking to detect and analyze malicious content, software developers stress testing file formats for their products, and for other researchers seeking to understand the behavior and structure of undocumented file formats. Traditional tools, including hex editors, disassemblers and debuggers, while powerful, constrain analysis to primarily text based approaches. In this paper, we present design principles for file analysis which support meaningful investigation when there is little or no knowledge of the underlying file format, but are flexible enough to allow integration of additional semantic information, when available. We also present results from the implementation of a visual reverse engineering system based on our analysis. We validate the efficacy of both our analysis and our system with case studies depicting analysis use cases where a hex editor would be of limited value. Our results indicate that visual approaches help analysts rapidly identify files, analyze unfamiliar file structures, and gain insights that inform and complement the current suite of tools currently in use.
175 downloads
0 comments
Submitted
-
Reverse Engineering of Binary Device Drivers with RevNIC
By Teddy Rogers
This paper presents a technique that helps automate the reverse engineering of device drivers. It takes a closed-source binary driver, automatically reverse engineers the driver's logic, and synthesizes new device driver code that implements the exact same hardware protocol as the original driver. This code can be targeted at the same or a different OS. No vendor documentation or source code is required.
Drivers are often proprietary and available for only one or two operating systems, thus restricting the range of device support on all other OSes. Restricted device support leads to low market viability of new OSes and hampers OS researchers in their efforts to make their ideas available to the "real world" Reverse engineering can help automate the porting of drivers, as well as produce replacement drivers with fewer bugs and fewer security vulnerabilities.
Our technique is embodied in RevNIC, a tool for reverse engineering network drivers. We use RevNIC to reverse engineer four proprietary Windows drivers and port them to four different OSes, both for PCs and embedded systems. The synthesized network drivers deliver performance nearly identical to that of the original drivers.
109 downloads
0 comments
Submitted
-
Reverse Engineering is Reverse Forward Engineering
By Teddy Rogers
Reverse Engineering is focused on the challenging task of understanding legacy program code without having suitable documentation. Using a transformational forward engineering perspective, we gain the insight that much of this difficulty is caused by design decisions made during system development. Such decisions "hide" the program functionality and performance requirements in the final system by applying repeated refinements through layers of abstraction, and information-spreading optimizations, both of which change representations and force single program entities to serve multiple purposes. To be able to reverse engineer, we essentially have to reverse these design decisions. Following the transformational approach we can use the transformations of a forward engineering methodology and apply them "backwards" to reverse engineer code to a more abstract specification. Since most existing code was not generated by transformational synthesis, this produces a plausible formal transformational design rather than the original authors' actual design. A byproduct of the transformational reverse engineering process is a design database for the program that then can be maintained to minimize the need for further reverse engineering during the remaining lifetime of the system. A consequence of this perspective is the belief that plan recognition methods are not sufficient for reverse engineering. As an example, a small fragment of a real-time operating system is reverse-engineered using this approach.
122 downloads
0 comments
Submitted
-
Reverse Engineering Drivers for Safety and Portability
By Teddy Rogers
Device drivers today lack two important properties: guaranteed safety and cross-platform portability. We present an approach to incrementally achieving these properties in drivers, without requiring any changes in the drivers or operating system kernels. We describe RevEng, a tool for automatically reverse-engineering a binary driver and synthesizing a new, safe and portable driver that mimics the original one. The operating system kernel runs the trusted synthetic driver instead of the original, thus avoiding giving untrusted driver code kernel privileges. Initial results are promising: we reverse-engineered the basic functionality of network drivers in Linux and Windows based solely on their binaries, and we synthesized safe drivers for Linux. We hope RevEng will eventually persuade hardware vendors to provide verifiable formal specifications instead of binary drivers; such specifications can be used to automatically synthesize safe drivers for every desired platform.
123 downloads
0 comments
Submitted
-
Download Statistics
2,119
Files246
Comments894
Reviews