Jump to content
Tuts 4 You

Reverse Code Engineering

55 files

  1. Tracing Delphi MessageBox

    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!

    77 downloads

    0 comments

    Submitted

  2. Visual Basic Tricks

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

    64 downloads

    0 comments

    Submitted

  3. When Memory Management Goes Bad

    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.

    25 downloads

    0 comments

    Submitted

  4. Win32 Reverse Engineering Cheat-Sheet

    A x86/Win32 reverse engineering cheat-sheet.

    99 downloads

    0 comments

    Submitted

  5. Writing a WinRAR Key Logger

    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.

    41 downloads

    0 comments

    Submitted

  6. Reversing C++

    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.

    77 downloads

    0 comments

    Submitted

  7. Reversing J2ME Applications

    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.

    26 downloads

    0 comments

    Submitted

  8. Reversing MFC Applications

    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.

    70 downloads

    0 comments

    Submitted

  9. Reversing Microsoft Visual C++

    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.

    88 downloads

    0 comments

    Submitted

  10. Reversing of a Protection Scheme Based on Drivers Sandboxie

    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.

    25 downloads

    0 comments

    Submitted

  11. The NTkrnl Journal Volume 1 (Issue 1-2)

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

    26 downloads

    0 comments

    Submitted

  12. Theories and Methods of Code-Caves

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

    39 downloads

    0 comments

    Submitted

  13. Reversers Guide to Python

    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.

    70 downloads

    0 comments

    Submitted

  14. Reversing a Frozen Python Executable

    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]

    35 downloads

    0 comments

    Submitted

  15. Reversing and Exploiting Apple Firmware Update

    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.

    26 downloads

    0 comments

    Submitted

  16. Reversed Compilation Techniques

    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.

    42 downloads

    0 comments

    Submitted

  17. Point Events in Delphi Executables

    In the last weeks our companions Lisa Alquimista (Arapumk) they delighted us with MiniDE, a decompiler for Delphi executables that is able to obtain addresses of all the events of a program. MiniDE allows us to generate .MAP files that we will be able to import into OllyDbg with plugins like MapConv or GODUP, in order to add comments and/or labels with the names of the events.

    If we add the events information in the form of comments and/or labels we will see that it is much more simple to understand the operation of the program, and what matters more is, cracking it is much more comfortable.

    38 downloads

    0 comments

    Submitted

  18. Preventing Reverse Engineering of Native and Managed Programs

    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.

    24 downloads

    0 comments

    Submitted

  19. Principled Reverse Engineering of Types in Binary Programs

    A recurring problem in security is reverse engineering binary code to recover high-level language data abstractions and types. High-level programming languages have data abstractions such as buffers, structures, and local variables that all help programmers and program analyses reason about programs in a scalable manner. During compilation, these abstractions are removed as code is translated down to operations on registers and one globally addressed memory region. Reverse engineering consists of "undoing" the compilation to recover high-level information so that programmers, security professionals, and analyses can all more easily reason about the binary code.

    In this paper we develop novel techniques for reverse engineering data type abstractions from binary programs. At the heart of our approach is a novel type reconstruction system based upon binary code analysis. Our techniques and system can be applied as part of both static or dynamic analysis, thus are extensible to a large number of security settings. Our results on 87 programs show that TIE is both more accurate and more precise at recovering high-level types than existing mechanisms.

    25 downloads

    0 comments

    Submitted

  20. Qt Reverse Engineering

    I was asked a couple months ago by a friend of mine to “tweak†a software protection. As I went in to it, I found the protection scheme very interesting as it involved a couple of cross platforms based engines interacting together to serve as anti-hacking security licensing system. One was Qt, the other being JavaScript. It was the second time that I came against a Qt based software. The first time thought, I just used the basic cracking skills every reverser uses with Windows GDI apps. But this time I needed to go deeper to understand the cross VM interactions, and a bigger understanding of the Qt framework was needed, so, I engaged into searching for more info on the subject. The results were quite poor, except for an article by Daniel Pistelli, who now works at Hex Rays (coincidence that IDA has been reassembled using this framework?).

    Besides his article, not much on the subject of reversing Qt code seemed to be around. Since then I was faced with a fair amount of Qt applications, even Portuguese ones, so I decided to post my thoughts on the subject, and build a tutorial for the 4th version of Qt.

    33 downloads

    0 comments

    Submitted

  21. Reverse Engineering by Crayon

    Recent advances in hypervisor based application profilers have changed the game of reverse engineering. These powerful tools have made it orders of magnitude easier to reverse engineer and enabled the next generation of analysis techniques. We will also present and release our tool VERA, which is an advanced code visualization and profiling tool that integrates with the Ether Xen extensions. VERA allows for high-level program monitoring, as well as low-level code analysis. Using VERA, we'll show how easy the process of unpacking armoured code is, as well as identifying relevant and interesting portions of executables. VERA integrates with IDA Pro easily and helps to annotate the executable before looking at a single assembly instruction. Initial testing with inexperienced reversers has shown that this tool provides an order of magnitude speedup compared to traditional techniques.

    27 downloads

    0 comments

    Submitted

  22. Reverse Engineering Drivers for Safety and Portability

    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.

    31 downloads

    0 comments

    Submitted

  23. Reverse Engineering is Reverse Forward Engineering

    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.

    27 downloads

    0 comments

    Submitted

  24. Reverse Engineering of Binary Device Drivers with RevNIC

    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.

    21 downloads

    0 comments

    Submitted

  25. Reverse Engineering of Data and Binary Files

    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.

    42 downloads

    0 comments

    Submitted


×
×
  • Create New...