2020. 3. 2. 15:53ㆍ카테고리 없음
$ echo '1 2' llvm-mc -disassemble -triple=x8664-apple-darwin9addl%eax, (%rdx)$ echo '0x0f 0x1 0x9' llvm-mc -disassemble -triple=x8664-apple-darwin9sidt (%rcx)$ echo '0x0f 0xa2' llvm-mc -disassemble -triple=x8664-apple-darwin9cpuid$ echo '0xd9 0xff' llvm-mc -disassemble -triple=i386-apple-darwin9fcosotool OS X's object file displaying tool. Edb A cross platform x86/x86-64 debugger. Disassembler Issues As we have alluded to before, there are a number of issues and difficulties associated with the disassembly process. The two most important difficulties are the division between code and data, and the loss of text information.Separating Code from Data Since data and instructions are all stored in an executable as binary data, the obvious question arises: how can a disassembler tell code from data? Is any given byte a variable, or part of an instruction?The problem wouldn't be as difficult if data were limited to the.data section (segment) of an executable (explained in a later chapter) and if executable code were limited to the.code section of an executable, but this is often not the case. Data may be inserted directly into the code section (e.g. Jump address tables, constant strings), and executable code may be stored in the data section (although new systems are working to prevent this for security reasons).
AI programs, LISP or Forth compilers may not contain.text and.data sections to help decide, and have code and data interspersed in a single section that is readable, writable and executable, Boot code may even require substantial effort to identify sections. A technique that is often used is to identify the entry point of an executable, and find all code reachable from there, recursively. This is known as 'code crawling'.Many interactive disassemblers will give the user the option to render segments of code as either code or data, but non-interactive disassemblers will make the separation automatically. Disassemblers often will provide the instruction AND the corresponding hex data on the same line, shifting the burden for decisions about the nature of the code to the user. Some disassemblers (e.g.
Ciasdis) will allow you to specify rules about whether to disassemble as data or code and invent label names, based on the content of the object under scrutiny. Scripting your own 'crawler' in this way is more efficient; for large programs interactive disassembling may be impractical to the point of being unfeasible.The general problem of separating code from data in arbitrary executable programs is equivalent to the halting problem. As a consequence, it is not possible to write a disassembler that will correctly separate code and data for all possible input programs.
Reverse engineering is full of such theoretical limitations, although by all interesting questions about program properties are undecidable (so compilers and many other tools that deal with programs in any form run into such limits as well). In practice a combination of interactive and automatic analysis and perseverance can handle all but programs specifically designed to thwart reverse engineering, like using encryption and decrypting code just prior to use, and moving code around in memory.Lost Information User defined textual identifiers, such as variable names, label names, and macros are removed by the assembly process. They may still be present in generated object files, for use by tools like debuggers and relocating linkers, but the direct connection is lost and re-establishing that connection requires more than a mere disassembler. Especially small constants may have more than one possible name. Operating system calls (like DLLs in MS-Windows, or syscalls in Unices) may be reconstructed, as their names appear in a separate segment or are known beforehand. Many disassemblers allow the user to attach a name to a label or constant based on his understanding of the code.These identifiers, in addition to comments in the source file, help to make the code more readable to a human, and can also shed some clues on the purpose of the code.
Without these comments and identifiers, it is harder to understand the purpose of the source code, and it can be difficult to determine the algorithm being used by that code. When you combine this problem with the possibility that the code you are trying to read may, in reality, be data (as outlined above), then it can be even harder to determine what is going on. Another challenge is posed by modern optimising compilers; they inline small subroutines, then combine instructions over call and return boundaries. This loses valuable information about the way the program is structured.Decompilers Akin to Disassembly, Decompilers take the process a step further and actually try to reproduce the code in a high level language.
Frequently, this high level language is C, because C is simple and primitive enough to facilitate the decompilation process. Decompilation does have its drawbacks, because lots of data and readability constructs are lost during the original compilation process, and they cannot be reproduced. Since the science of decompilation is still young, and results are 'good' but not 'great', this page will limit itself to a listing of decompilers, and a general (but brief) discussion of the possibilities of decompilation.Decompilation: Is It Possible?
has related information atIn the face of optimizing compilers, it is not uncommon to be asked 'Is decompilation even possible?' To some degree, it usually is. Make no mistake, however: an optimizing compiler results in the irretrievable loss of information. An example is in-lining, as explained above, where code called is combined with its surroundings, such that the places where the original subroutine is called cannot even be identified. An optimizer that reverses that process is comparable to an artificial intelligence program that recreates a poem in a different language. So perfectly operational decompilers are a long way off.
At most, current Decompilers can be used as simply an aid for the reverse engineering process leaving lots of arduous work.Common Decompilers Hex-Rays Decompiler Hex-Rays is a commercial decompiler. It is made as an extension to popular IDA-Pro disassembler. It is currently the only viable commercially available decompiler which produces usable results. It supports both x86 and ARM architecture.
DCC DCC is likely one of the oldest decompilers in existence, dating back over 20 years. It serves as a good historical and theoretical frame of reference for the decompilation process in general (Mirrors: ).
As of 2015, DCC is an. Some of the latest changes include fixes for longstanding memory leaks and a more modern Qt5-based front-end. RetDec The Retargetable Decompiler is a freeware web decompiler that takes in ELF/PE/COFF binaries in Intel x86, ARM, MIPS, PIC32, and PowerPC architectures and outputs C or Python-like code, plus flow charts and control flow graphs. It puts a running time limit on each decompilation. It produces nice results in most cases. Reko a modular open-source decompiler supporting both an interactive GUI and a command-line interface.
Its pluggable design supports decompilation of a variety of executable formats and processor architectures (8-, 16-, 32- and 64-bit architectures as of 2015). It also supports running unpacking scripts before actual decompilation. It performs global data and type analyses of the binary and yields its results in a subset of C. C4Decompiler C4Decompiler is an interactive, static decompiler under development (Alpha in 2013). It performs global analysis of the binary and presents the resulting C source in a Windows GUI. Context menus support navigation, properties, cross references, C/Asm mixed view and manipulation of the decompile context (function ABI).
Boomerang Decompiler Project Boomerang Decompiler is an attempt to make a powerful, retargetable decompiler. So far, it only decompiles into C with moderate success.
Blender Software
Reverse Engineering Compiler (REC) REC is a powerful 'decompiler' that decompiles native assembly code into a C-like code representation. The code is half-way between assembly and C, but it is much more readable than the pure assembly is. Unfortunately the program appears to be rather unstable. ExeToC ExeToC decompiler is an interactive decompiler that boasted pretty good results in the past. Snowman Snowman is an open source native code to C/C decompiler. Supports ARM, x86, and x86-64 architectures. Reads ELF, Mach-O, and PE file formats.
Forensic Image Enhancement Software Free
Reconstructs functions, their names and arguments, local and global variables, expressions, integer, pointer and structural types, all types of control-flow structures, including switch. Has a nice graphical user interface with one-click navigation between the assembler code and the reconstructed program. Assume ds = cs, e.g like in boot sector code start: call write; push message's address on top of stack db ' Hello, world ', 0 dh, 0 ah, 00 h; return point ret; back to DOS write proc near pop si; get string address mov ah, 0 eh; BIOS: write teletype wloop: lodsb; read char at ds:si and increment si or al, al; is it 00h? Jz short wexit int 10 h; write the character jmp wloop; continue writing wexit: jmp si write endp end startA macro-assembler like TASM will then use a macro like this one. write macro message call write db message db 0 write endmFrom a human disassembler's point of view, this is a nightmare, although this is straightforward to read in the original Assembly source code, as there is no way to decide if the db should be interpreted or not from the binary form, and this may contain various jumps to real executable code area, triggering analysis of code that should never be analysed, and interfering with the analysis of the real code (e.g. Disassembling the above code from 0000h or 0001h won't give the same results at all).However a half-decent tool with possibilities to specifiy rules, and heuristic means to identify texts will have little trouble.32 bit CPU code Most 32-bit CPUs use the ARM instruction set.Typical ARM assembly code is a series of subroutines, with literal constants scattered between subroutines.The for subroutines is pretty easy to recognize.A brief list of disassemblers.
'an assembler where the elements opcode, operands and modifiers are all objects, that are reusable for disassembly.' For 8080 8086 80386 Alpha 6809 and should be usable for Pentium 8051. includes open-source tools to disassemble code for many processors including x86, ARM, PowerPC, m68k, etc. Several virtual machines including java, msil, etc., and for many platforms including Linux, BSD, OSX, Windows, iPhoneOS, etc.
IDA, the ( ) can disassemble code for a huge number of processors, including ARM Architecture (including Thumb and Thumb-2), ATMEL AVR, INTEL 8051, INTEL 80x86, MOS Technologies 6502, MC6809, MC6811, M68H12C, MSP430, PIC 12XX, PIC 14XX, PIC 18XX, PIC 16XXX, Zilog Z80, etc., part of the GNU binutils, can disassemble code for several processors and platforms. ↑Jim Turley.2002.Mark Hachman.2002.' Although Intel and AMD receive the bulk of attention in the computing world, ARM’s embedded 32-bit architecture. Has outsold all others.' .Tom Krazit.' ARM licensed 1.6 billion cores in 2005'.2006.: reverse engineering challenges.
'A Challengers Handbook' by Caesum has some tips on reverse engineering programs in JavaScript, Flash Actionscript (SWF), Java, etc. the Open Source Institute occasionally has reverse engineering challenges among its other brainteasers. The Program Transformation wiki has a, and discusses disassemblers, decompilers, and tools for translating programs from one high-level language to another high-level language.