Reverse engineering is a very broad term. On high end it includes design recovery and on the other end --
recompilation and disassembly. But the essence
of all this different activities is understanding of a particular program when something is
missing (design documentation, source code, etc.). Actually it might be useful to distinguish 'reverse engineering in the small"
from "reverse engineering on the large", like we distinguish "programming in the small" and " programming in the large". Design recovery
and program renovation is generally connected with research on programming understanding, while lower level reverse engineering activities
(decompilation and disassembly) are more connected with compiler design and machine architecture
In the United States, once you own a copy of a program, you can back it up, compile it, run it, and even modify it as
necessary, without permission from the copyright holder. See
17 USC 117 According to the CONTU Final Report, which is generally interpreted by the courts as legislative history, "the right
to add features to the program that were not present at the time of rightful acquisition'' falls within the owner's rights of modification
under section 117.
What does all this mean? Once you've legally downloaded or bought a program, you can can run it, you can modify it,
you can distribute your patches for other people to use. If you think you need a license from the copyright holder, you've been bamboozled
by Microsoft. As long as you're not distributing the software, you have nothing to worry about unless you are trying to defeat some
protection mechanism in the original software. Please browse my Copyright issues
for more information.
IMHO we need to support public interests against current abuse. If you own a website please consider joining
opposition to copyright extentions,
No Cense, or other similar opposition group.
UCITA didn't even make the Federal Trade Commission happy.
The other threat to reverse engineering is from pseudo scientists, for example all those "object-oriented no matter
what" zealots, who does not understand the difference between programming-in-the-large and programming-in-the small ;-). There
is a lot of pseudoscience papers and even books on the problem of modernization of existing software system and a small army of successful
sellers of snake oil makes good money selling more or less useless (and sometimes outright harmful) methodologies. There was a big splash
of their activity related to Y2K problem, but now it's over. Actually all this Y2K efforts has one positive side effect: along with
snake oil some useful research was conducted and some useful tools were polished and/or developed due to the huge money influx to the
area at this time (see for example Open Directory
- Computers Software Year 2000 Products).
Actually reverse engineering is more about understanding the product than an attempt to produce a clone benefiting from
the original code. Documentation to many software products is notoriously bad, source code is unavailable or too expensive to obtain
and if you need to develop a product that interfaces to such software package reverse engineering is your only option. In this page
I mainly try to help the latter category of developers.
Please note that I am no longer involved in the research in this area and many links below can be dead or outdated.
Dr. Nikolai Bezroukov
Step 1: Allocate physical or virtual systems for the analysis lab
A common approach to examining malicious software involves infecting a system with the malware specimen and then using the appropriate
monitoring tools to observe how it behaves. This requires a laboratory system you can infect without affecting your production environment.
The most popular and flexible way to set up such a lab system involves virtualization software, which allows you to use a single
physical computer for hosting multiple virtual systems, each running a potentially different operating system. Free virtualization
software options include:
Running multiple virtual systems simultaneously on a single physical computer is useful for analyzing malware that seeks to interact
with other systems, perhaps for leaking data, obtaining instructions from the attacker, or upgrading itself. Virtualization makes
it easy to set up and use such systems without procuring numerous physical boxes.
Another useful feature of many virtualization tools is the ability to take instantaneous snapshots of the laboratory system. This
way, you can record the state of the system before you infect it, and revert to the pristine environment with a click of a button
at the end of your analysis.
If using virtualization software, install as much RAM into the physical system as you can, as the availability of memory is arguably
the most important performance factor for virtualization tools. In addition, having a large hard drive will allow you to host many
virtual machines, whose virtual file systems typically are stored as files on the physical system's hard drive.
Because malware may detect that it's running in a virtualized environment, some analysts prefer to rely on physical, rather than
virtual, machines for implementing laboratory systems. Your old and unused PCs or servers can make excellent systems for your malware-analysis
lab, which usually doesn't need high-performing CPUs or highly redundant hardware components.
To allow malware to reach its full potential in the lab, laboratory systems typically are networked with each other. This helps
you observe the malicious program's network interactions. If using physical systems, you can connect them with each other using an
inexpensive hub or a switch.
Step 2: Isolate laboratory systems from the production environment
You must take precautions to isolate the malware-analysis lab from the production network, to mitigate the risk that a malicious
program will escape. You can separate the laboratory network from production using a firewall. Better yet, don't connect laboratory
and production networks at all, to avoid firewall configuration issues that might allow malware to bypass filtering restrictions.
If your laboratory network is strongly isolated, you can use removable media to bring tools and malware into the lab. Consider
using write-once media, such as DVDs , to prevent malicious software from escaping the lab's confines by writing itself to a writable
removable disk. A more convenient option is a USB key that includes a physical write-protect switch.
Some malware-analysis scenarios benefit from the lab being connected to the internet. Avoid using the production network for such
connectivity. If possible, provision a separate, and usually inexpensive, internet connection, perhaps by dedicating a DSL or Cable
Modem line to this purpose. Avoid keeping the lab connected to the internet all the time to minimize the chance of malware in your
lab attacking someone else's system on the internet.
If virtualizing your lab, be sure to keep up with security patches released by the virtualization-software vendor. Such software
may have vulnerabilities that could allow malware to escape from the virtual system you infected and onto the physical host. Furthermore,
don't use the physical machine that's hosting your virtualized lab for any other purpose.
Step 3: Install behavioral analysis tools
Before you're ready to infect your laboratory system with the malware specimen, you need to install and activate the appropriate
monitoring tools. Free utilities that will let you observe how Windows malware interacts with its environment include:
- File system and registry monitoring: Process
Monitor with ProcDOT offer a powerful way to observe how local processes read, write,
or delete registry entries and files. These tools can help you understand how malware attempts to embed into the system upon infection.
- Process monitoring: Process Explorer
and Process Hacker replace the built-in Windows Task Manager, helping you
observe malicious processes, including local network ports they may attempt to open.
- Network monitoring: Wireshark is a popular network sniffer, which can observe
laboratory network traffic for malicious communication attempts, such as DNS resolution requests, bot traffic, or downloads.
- Change detection: Regshot is a lightweight tool for comparing
the system's state before and after the infection, to highlight the key changes malware made to the file system and the registry.
Behavioral monitoring tools can give you a sense for the key capabilities of malicious software. For further details about its
characteristics, you may need to roll up your sleeves and perform some code analysis.
Step 4: Install code-analysis tools
Examining the code that comprises the specimen helps uncover characteristics that may be difficult to obtain through behavioral
analysis. In the case of a malicious executable, you rarely will have the luxury of access to the source code from which it was created.
Fortunately, the following free tools can help you reverse compiled Windows executables:
- Disassembler and debugger: OllyDbg and
IDA Pro Freeware can parse compiled Windows
executables and, acting as disassemblers, display their code as assembly instructions. These tools also have debugging capabilities,
which allow you to execute the most interesting parts of the malicious program slowly and under highly controlled conditions,
so you can better understand the purpose of the code.
- Memory dumper: Scylla and
OllyDumpEx help obtain protected code located in the lab system's memory
and dump it to a file. This technique is particularly useful when analyzing packed executables, which are difficult to disassemble
because they encode or encrypt their instructions, extracting them into RAM only during run-time.
Step 5: Utilize online analysis tools
To round off your malware-analysis toolkit, add to it some freely available online tools that may assist with the reverse engineering
process. One category of such tools performs automated behavioral analysis of the executables you supply. These applications look
similar at first glance, but use different technologies on the back end. Consider submitting your malware specimen to several of
these sites; depending on the specimen, some sites will be more effective than others. Such tools include:
You can see a longer list of free automated malware analysis services
that can examine compiled Windows executables.
Another set of potentially useful online tools provides details about websites that are suspected of hosting malicious code. Some
of these tools examine the sites you specify in real time; others provide historical information. Consider submitting a suspicious
URL to several of these sites, because each may offer a slightly different perspective on the website in question:
You can see a longer list of free on-line tools for looking up a potentially
With your initial toolkit assembled, start experimenting in the lab with malware you come across on the web, in your e-mail box,
on your systems, and so on. There are several "cheat sheets" that can help you in this process, including:
Begin analysis with the tools and approaches most familiar to you. Then, as you become more familiar with the inner workings of
the malware specimen, venture out of your comfort zone to try other tools and techniques. The tools I've listed within each step
operate virtually identically. Since they're all free, you should feel free to try them all. You'll find that one tool will work
better than another, depending on the situation. And with time, patience, and practice, you will learn to turn malware inside out.
For additional tips and resources, see my article
How to Get Started With Malware Analysis
and check out the Reverse-Engineering
Malware course I teach at SANS Institute
Authors of this course created the following cheat sheets to summarize some of the concepts and tools useful for
You can also get a sense for malware analysis approaches explored in this course by looking at the following resources:
This course is a part of SANS' comprehensive Digital Forensics and Incident Response (DFIR) curriculum.
Learn more about our DFIR courses and free resources. Take your learning beyond
the classroom. Explore our DFIR site network for additional resources related to the subject matter of this course.
wiredmikey writes "Security startup CrowdStrike has launched
CrowdRE, a free platform that allows security researchers and
analysts to collaborate on malware reverse engineering. CrowdRE is adapting the collaborative model common in the developer world
to make it possible to
engineer malicious code more quickly and efficiently. Collaborative reverse engineering can take two approaches, where all the
analysts are working at the same time and sharing all the information instantly, or in a distributed manner, where different people
work on different sections and share the results. This means multiple people can work on different parts simultaneously and the results
can be combined to gain a full picture of the malware. Google is planning to add CrowdRE integration to BinNavi, a graph-based reverse
engineering tool for malware analysis, and the plan is to integrate with other similar tools. Linux and Mac OS support is expected
soon, as well."
January 13, 2012 | Slashdot
Sparrowvsrevolution writes "At the Shmoocon security conference later this month, Danny Quist plans to demo a new three-dimensional
version of a tool he's created called Visualization of Executables for Reversing and Analysis, or VERA, that
maps viruses' and worms' code into intuitively visible models.
Quist, who teaches government and corporate students the art of reverse engineering at Los Alamos National Labs, says he hopes
VERA will make the process of taking apart and understanding malware's functionality far easier.
VERA observes malware running in a virtual sandbox and identifies the basic blocks of commands it executes. Then those chunks
of instructions are color-coded by their function and linked by the order of the malware's operations, like a giant, 3D flow chart.
Quist provides a sample video showing a model of a section of the Koobface worm."
An interesting static byte code analyzer for Java
Structure101 for Java parses your byte code and creates an implementation model of
all the dependencies mapped up through the compositional hierarchy. It does this at a rate of mega-SLOCs per minute. You can
browse the model and view dependency diagrams at any level - method, class, package or jar. (More...)
We consider structure to be important through the life of an application - not just something that gets fixed in an expensive 'Big
Bang'. At the same time, we realize that many of our customers only begin looking at structure when they get the feeling it is out
...Structure101TM, currently available for Java only, is designed for live,
evolving, imperfect, real projects, where ongoing development must continue. We have focused on making sense of large, difficult
code-bases. Structure101 lets you keep a lid on the structural complexity so that it doesn't get any worse, and
enables you to gradually streamline the structure while still working to hard delivery schedules.
We have been doing structure since 1999. The core engine of Structure101, the Higraph, is on its 3rd incarnation,
lightning fast and massively scalable. It is our passion to continually find new ways to understand and control structure - to make
It is very common for packages and classes to outgrow themselves. Big fat packages or classes tend to be difficult
to work with because they lack the structure that helps to guide human understanding. Structure101 helps by
letting you view even very large dependency graphs of the package or class contents. To help further, Structure101
can perform an Auto-partition on the graph, to reveal the hidden, inherent structure. As well has helping
you understand what you've got, seeing the inherent structure may help you to decide how to add structure by creating sub-packages
This page is about how the
Post-It Fix-Up principle works out in practical
program code in Forth. For the impatient:
jump to the downloads
Applying the Post-It Fix-Up principle to a
8086 assembler led to the discovery of problems
that had to be solved. It turns out that some types of fixups better be considered not relative to the start of the instruction,
but relative to the end. Otherwise there would be diffent fixups for e.g. byte/cell indication (B| X|), dependant on the length
of the opcode. It is still there in the fig-forth
version of the opcodes, such as B| W| besides B1| and W1| . So a new class of fixup, the "fix up's from behind"
or reverse fixups were added. It turned out that other fixup's are not needed for the Intel, up to the Pentium. Other processors
require fixup's with build in data. These so called data fixups are needed for the 6809 and the DEC Alpha.
A program was added that generates a PostScript file
with the first byte opcodes for 8080 as well as
8086 , and the
80386 , a so called quick reference card. Comparing
that to Intels documentation led to the discovery of one more bug. I had to redesign the opcodes, so other people could have trouble
using this beast without such a reference card and the `SHOW: MOV|SG,' that lists all forms allowed for the move segment instruction.
- Into the House of Logic
- Should Reverse Engineering Be Illegal?
- Reverse Engineering Tools and Concepts
- Approaches to Reverse Engineering
- Methods of the Reverser
- Writing Interactive Disassembler
- Decompiling and Disassembling Software
- Decompilation in Practice: Reversing
- Automatic, Bulk Auditing for Vulnerabilities
- Writing Your Own Cracking Tools
- Building a Basic Code Coverage Tool
Most previously published case studies in architecture recovery have been performed on statically linked software
systems. Due to the increase in use of middleware technologies, such as CORBA, and OOP concepts, such as polymorphism, there is an
opportunity and a need to analyze architectures of these dynamically linked systems. This paper presents the results of software
architecture extraction of the Nautilus file manager, which employs CORBA in its implementation. A combination of existing static
analysis and use-case modeling architecture recovery techniques was used with the expectation of complex but complete architecture
extraction of a system such as Nautilus. We have found that this combined approach named Dynamo-1 presented in this paper provided
successful focused architecture recovery and guidance for the future work in complete architecture recovery of dynamically linked
Keywords: Nautilus, GNOME, program comprehension
one of the best legal paper on the subject. Highly recommended.
Contains a beta version of DisC - Decompiler for TurboC
and a small intro to the problem of decompilation using Intel assembler fragments of small C programs as an example.
Compare to Decompilation of Binary Programs - dcc. See
Decomlilation and Decompilers Page
An article on PlanetIT.com
discusses a court ruling that establishes the reverse-engineering of hardware and software as legal, under the "fair use" umbrella.
What ramifications does this have in the industry? Can I reverse-engineer MS Word and write a word processor that can read and save
|Well, that clears that up, then.
by Anoriymous Coward on Sunday February 04, @03:14PM EST (#18)
(User #257749 Info)
|I'm confused. Possibly so is the author of this article. He seems to imply
that UCITA is a pending piece of federal legislation, rather than state legislation. As it is, UCITA appears to be dead and
buried in most states (hooray!).
He draws a line between the Reimerdes and Connectix cases by quoting that Reimerdes "didn't have a right to the DVD". Did he
steal it? More confusion.
Anyway, it seems the 9th Circuit gets overturned all the time, so I wouldn't get too hopeful about this being a positive sign.
|Re:Well, that clears that up, then.
by edwardames (edwardames at hotmail dot
com) on Sunday February 04, @08:57PM EST (#166)
(User #157809 Info)
|That assertion by the journalist also took me aback for a second. I have
no doubt the software industry would likely try to get legislation through Congress to "correct" a court ruling such as this
one, but that's just my suspicion. UCITA, though it would impact cases like the one in the story, certainly has nothing to
do with the U.S. Congress. UCITA's going through the legislatures, even if it is going slowly.
Despite your opinion of the current status of UCITA, I think that it is far from dead. Take
a look at this map to see where UCITA lobbying activities
are underway. Check out anti-UCITA ucita.com. and pro-UCITA
ucitaonline.com. It's still an issue that has to be followed or it'll
take us all by surprise one day, by becoming the law of the land.
|Reverse Engineering file formats
by Pedrito (firstname.lastname@example.org)
on Sunday February 04, @03:28PM EST (#31)
(User #94783 Info)
|I reverse engineered quite a few MS file formats (see my out-of-print book
Undocumented Windows File Formats) and never had any hassles from MS regarding the reverse engineering.
In fact, MS tried to hire me to provide them with the specs for one of their file formats. Apparently the author of the code
never documented the file format. MS had released specs for it, but they were completely wrong.
After being told by several friends that MS was notorious for delaying payment with contractors, I asked for half the money
up-front. They refused and I never did the work.
But I digress. I reverse engineered a number of file formats that were "proprietary" Microsoft files. If they're going to go
after anyone for it, surely they would have gone after me since I was publishing them left and right in magazines and my book.
I've figured ever since then that MS must have known that the whole thing about reverse engineering in their licenses must
You can also look at all the work Andrew Schulman and Matt Pietrek did reverse engineering Windows code and the PE file format
and neither of them ever got hassled either, as far as I know.
-- "Suppose you were an idiot. And suppose you were a member of congress. But I repeat myself." - Mark Twain
|DeCSS Reverse Engineering? No proof
by joneshenry on Sunday February 04, @03:44PM EST (#47)
(User #9497 Info)
|I urge everyone who thinks that DeCSS was reverse engineering to actually
read materials such as the
transcript of Johansen's testimony. There is simply no evidence that DeCSS was the product of legitimate reverse engineering.
Not just once but twice anonymous information was contributed to crack the problem in a form that does not resemble what one
would get from treating the system as a black box. Johansen testified: "Yes, I believe the CSS authentication had been posted
anonymously in Assembler language on the Internet, and Derek Fawcus had picked that up and rewritten it in C language and posted
it on his website." Note the word "Assembler". Johansen also testified that he was given further information from a complete
stranger on IRC. On the Livid-dev mailing list on Saturday, October 02, 1999 Eric Smith had posted: "The specific issue WRT
the CSS code is that the x86 code was apparently simply ripped out of a working commerical implementation (which was presumably
copyrighted)" to which Derek Fawcus had replied "Well I guess it might have been, but I don't _know_ that." (Fawcus went on
to explain how he had "worked to understand the algorithm underlying the x86 code.") Why the developers didn't run away as
fast as they could once there were questions is something I cannot understand. Didn't anyone learn from previous examples such
as Compaq's reverse engineering of the IBM PC BIOS? Compaq set up their reverse engineering effort so that at every stage they
could prove the source of information using engineers whom they could assert did not have prior exposure to IBM IP.
|Drivers (Score:2, Insightful)
by tzoompy on Sunday February 04, @09:19PM EST (#171)
(User #312872 Info)
|A lot of the *nix drivers are done by reverse-engineering. I know of a couple
of Linmodem driver projects that started with a copy of the binary of the corresponding Winmodem. Reverse engineering applied
in the purpose of getting hardware specs out of the driver is OK with most of the driver companies. The Win/Lin modem manufacturers
care mostly about the SP processing algorithms rather than the DSP specs. The problem with reverse engineering for these modems
is that together with the hardware specs, there is sufficient information about what SP algorithm they are using that a sufficienly
knowledgeable person can reverse engineer everything out of their driver.
[Dec 18, 2000] Clipper and FoxPro decompilation
This little 16bit DOS program generates a ".afs" of any ".8bf" file compiled by
the Filter Factory of Adobe Photoshop (PC version only).
[Sept 15, 2000] Java decompilers
The wonderful ferroconcrete world we live in has more lawyers than rats. There are patents underlying the most
obvious software designs (yes, a simple lawsuit showing prior art will defeat three quarters of them, but I for one won't spend my
life savings on them, and companies with pockets that are deep enough prefer not to invalidate competitors patents for fear of getting
Patent issues aside, there's the legal debate about licenses. If we (the Open Source developers) cannot put our
legal squabbles aside (my license is more free than yours -- no, mine is), how would anyone expect to put big business to put theirs
aside? Beside ego, they've got shareholders to take into account.
I've been mighty impressed with IBM's venture into the Open Source arena. I think they've taken the boldest steps
of all. It's not just half-baked Java stuff (with tremendous investments behind them) or stuff without direct revenue potential (like
jfs, which they couldn't sell as long as competitors think their mouse trap is better). If you search for "IBM Visual Data Explorer"
on www.ibm.com, you'll get a price list with a rather hefty price tag (and if you dig deeper, you'll find an impressive array of
Fortune 500 companies and research institutes that paid those prices and got their moneys worth). If you look at
opendx.org, you'll see the same software, free. The stuff is awesome!
Whatever their motivation, I rate IBM highly for its commitment to Open Source. It's a rather stunning move, given
their revenue streams and the fact that they spearheaded the move from free to paid-for software eons ago.
"Our tools help developers understand, document, and maintain impossibly large or complex amounts
of source code."
Reverse engineering is a powerful tool that allows innovators to improve upon someone else's design
or make compatible products.
Or ... reverse engineering is a way for freeloaders to gain unauthorized access to proprietary products
and infringe upon someone's intellectual property rights.
Either way you look at it, keep in mind that some forms of software reverse engineering are restricted
by legal rules of contract and copyright law.
Last month Mattel (MAT)
filed a lawsuit against two software programmers,
alleging both copyright and software license violations.
Mattel and its subsidiary, Microsystems Software Inc., filed documents in Massachusetts federal
court claiming that software programmers from Sweden and Canada reverse-engineered its CyberPatrol Internet filtering software. According
to Mattel, the programmers then created a utility known as "cphack.exe" or "CP4break.zip" that allows people to see a list of those
sites considered off-limits by CyberPatrol.
Mattel said that by reverse engineering CyberPatrol, "developing source code and binaries to bypass"
CyberPatrol's protections, and then posting the utilities on the Internet, the programmers had violated Mattel's copyrights and the
terms of the CyberPatrol license.
Last Friday, the court hearing this case agreed that Mattel's claims have merit, and issued a temporary
restraining order prohibiting the distribution of cphack.exe and CP4break.zip.
SecurityFocus.com: The Fine Print in UCITA
(Mar 17, 2000)
Cyber Patrol sues codebreakers (the AP story is *wrong*)
(Mar 16, 2000)
Wired: Furor Over Virginia E-Biz Law [UCITA] (Mar 16, 2000)
SJ Mercury/AP: Software filter firm sues hackers (Mar 16,
SJ Mercury: Greed undermines benefits of digital technology
(Mar 05, 2000)
ZDNet: Hollywood's war on open source (Feb 28, 2000)
Freshmeat: The Dangers of UCITA (Feb 24, 2000)
osOpinion: Cronus Overthrown: a perspective on CSS and SDMI
(Feb 07, 2000)
UPDATED: Richard Stallman -- Why We Must Fight UCITA (Feb
Arne Flones -- The Digital Millenium Copyright Act: A Corporate
Bully Bludgeon (Jan 25, 2000)
Copyright Office: Exemption to Prohibition on Circumvention of
Copyright Protection Systems... (Jan 21, 2000)
Linux Journal: Copyright Strikes Back (Nov 23, 1999)
objdump-beautifier is a Perl script to make objdump output more useful. It traces function calls and
jumps, locates string constants, removes leading zeroes, and corrects objdump's annoying habit of making negative numbers positive.
But when it comes to reverse engineering, Nebergall says a prohibition in a shrink-wrap license would probably
be binding under UCITA. In the absence of UCITA, according to software engineer and lawyer Cem Kaner, "No court has ever upheld a
ban on reverse engineering for mass-market software."
Like other provisions in UCITA, a prohibition could be overturned by law. But current law is not too strong. The
flagship copyright law of the decade, the 1998 Digital
Millennium Copyright Act, permits reverse engineering "for achieving interoperability." Sounds good; if Corel wants to create
a word processing product that accepts .DOC files, that's all for the benefit of interoperability, isn't it?
But an aggrieved company could plausibly claim that reverse-engineered products constitute competition, not just
interoperability-so a prohibition on reverse-engineering might stand. And as Kaner
points out, reverse engineering has many legitimate purposes
that might be squelched by a shrink-wrap license.
Reverse engineering raises many of the same questions as the
user interface or "look-and-feel" copyright suits ten
years ago. Both issues raise the questions of what is the true intellectual property in software, and how important it is to promote
new innovations or competition in comparison to protecting earlier innovations. Where your sympathies fall will determine whether
you think UCITA is fair.
Design Recovery involves the examination of legacy code in order to reconstruct design decisions taken by the original
implementors. Artifacts in both the source code and in executable images are examined and analyzed. Software tools are necessary
because such systems are often very large and the goal is the understanding of significant global and diffuse features of that code.
In partnership with the IBM Centre for Advanced Studies,
the University of Toronto, the University of Victoria, and McGill
University, the group is developing novel tools and techniques that will leverage the human learning process when applied to the
understanding of legacy source.
A prototype tool (ART for Analysis of Redundancy in Text) based on exact matching of text has successfully identified
useful structural information in a 40 MB source tree and has demonstrated a potential to scale up to 500 MB. Work is underway on
integrating the tools of the research partners to produce a system with a shared repository, visualization tools, and access to a
major commercial tool.
Andys Binary Folding Editor is primarily designed for structured browsing, although it also provides minimal editing
facilities. This program is designed to take in a set of binary files, and with the aid of an initialisation file, decode and display
the definitions (structures or unions) within them. BE is particularly suited to displaying non-variable length definitions within
the files. This makes examination of known file types easy, and allows rapid and reliable navigation of memory dumps. BE is often
used as the data navigation half of a debugger.
[July 25, 1999] cgvg
Tools for convenient grepping through code. cgvg is a pair of Perl scripts ("cg" and "vg") which act as wrappers
for find and grep. The main idea is to act as a temporary replacement for cscope until there is a good GPLed cscope available. "cg"
does the grep through code, storing the info in a text file in the user's home directory, and "vg" lets the user open on editor at
the line in the file where a particular match was found. Some features include color highlighting, human-readable output, resizing
to screen width, support for many editors, etc.
May 08, 1999
Converts a program's source code to syntax highlighted HTML , 15:02 stable: 0.6.2 - devel: none license: Freeware
[July 17, 1999] legdoc is
a perl script to document C source file trees.
It uses tags often found in legacy C code to provide documentation for the same. It can either convert a list of named files or
an entire directory. The documentation will be stored in index.html.
[Dec 30, 2001] The Law & Economics
of Reverse Engineering by Prof. Pamela Samuelson. -- one of the best legal paper on the subject.
Highly recommended. See also Professor
[Dec 28, 2001] Decompilation page and link to a decompiler
by Satish Kumar. Contains a beta version of DisC - Decompiler for
TurboC and a small intro to the problem of decompilation using Intel assembler fragments of small C programs as an example.
See Decomlilation and Decompilers Page
The Law & Economics of Reverse Engineering
by Prof. Pamela Samuelson. -- one of the best legal paper on the subject. Highly
recommended. [Dec 30, 2001]
- Techniques for Software Renovation
by Michael B. Siff
Software renovation is the process of introducing new features---including polymorphism,
objects, and encapsulation---into existing software systems while preserving the original functionality of the system. The goal of
software renovation is to improve the efficiency of development, maintenance, and comprehension. The research described in this thesis
focuses on three software-renovation techniques:
- Generalization: The identification and subsequent transformation of program components
that operate on a particular type of input into polymorphic program components that operate on a wide array of inputs.
- Modularization: The clustering of associated data types and functions with the intent
of encapsulating the types and function into distinct classes or modules.
- Physical subtyping: The identification of relationships among data types based on the
representation of the types in memory with the intent of generating inheritance hierarchies.
The techniques described in the thesis are aimed particularly at the problem of transforming legacy
C programs into C++ programs that make use of C++'s advanced features---most notably classes, templates, inheritance, and virtual
functions. Some aspects of this work apply specifically to the C-to-C++ problem; however, most aspects apply to almost any language.
(Click here to access
- Reports of theme
Interactive Software Development and Renovation -- several reports. some titles look very interesting, for example:
- The Problem of Reverse Engineering by Cem Kaner Published
in Software QA Magazine, 1998
Many people misunderstand the nature of reverse engineering. Those misunderstandings shape corporate policies and
legislation. As I've spoken to working software developers (especially and including testers) about Article 2B, I've been surprised
to discover that we are as likely to misunderstand the breadth and importance of reverse engineering as the lawyers. (Article 2B
is a 273-page proposed revision to the Uniform Commercial Code that will govern all software-related contracts. For more information,
see my website, www.badsoftware.com, or my new book, Bad Software, which has a
detailed appendix on 2B).
Originally, I presented material on reverse engineering at a conference on Article 2B for lawyers at UC Berkeley.
That led to additional talks and to a paper for lawyers (Kaner, 1998). This paper is not about the legal issues of reverse engineering.
And, though I mention Article 2B (as the key current effort to ban reverse engineering), this paper is not about Article 2B. The
reverse engineering debate will go on even if we kill 2B. Rather, I have four objectives with this paper.
- First, to make you aware of a debate whose resolution will affect your work (you probably do reverse engineering
quite often, and you might not like it if that gets banned).
- Second, to suggest some ways that you can articulate your concerns. (Your company might be one of the ones
pushing for a ban on reverse engineering. Maybe you should explain what this would cost them if they succeed.)
- Third, to appeal to you for examples. I wrote this paper out of my own personal experiences. They're good examples,
but there are better ones. A longer collection of good examples might carry a lot of influence.
- And finally, to solicit criticism from you. I'm going to make these arguments again and again and again and
again. If there are holes or unfairnesses, I'd like to know about them. For that reason, even though I have adapted this paper
from the one that I wrote for lawyers (cutting out legal arguments), I've left my descriptions of engineering issues largely intact.
- [ June 25, 1999] Collberg's Publications -- good
- Recent Publications of Yih-Farn Robin Chen
- A.Buchsbaum, Y. Chen, H. Huang, E. Koutsofios, J. Mocenigo, A. Rogers, M. Jankowsky, S. Mancoridis,
"Enterprise Navigator: A System for Visualizing and Analyzing Software Infrastructures", to appear in IEEE Software.
- Y. Chen, F. Douglis, H. Huang, K. Vo "TopBlend:
An Efficient Implentation of HtmlDiff in Java", to appear in the WebNet2000 Conference, San Antonio, Texas, November
2000. Also available as AT&T Labs - Research Technical Report TR00.5.2.
- H. Rao, Y. Chen, M. Chen, "A Proxy-Based Web Archiving
Service", Middleware Symposium, Portland, Oregon, July, 2000.
- J. Korn, Y. Chen, E. Koutsofios, "Chava: Reverse
Engineering and Tracking of Java Applets", Proceedings of the Sixth Working Conference on Reverse Engineering,
pp. 314-325, Atlanta, October, 1999.
- S. Mancoridis, B.S.Mitchell, Y.Chen, E.Gansner.,
"Bunch: A Clustering Tool for the Incremental Maintenance
of the Structure of Software Systems", Proceedings of the 1999 International Conference on Software Maintenance,
Oxford, England, August, 1999.
- P. Devanbu, Y-F. Chen, E. Gansner, H. Muller, J. Martin,
"Chime: Customizable Hyperlink Insertion and Maintenance
Engine for Software Engineering Environments", Proceedings of the 21st International Conference on Software Engineering,
pp.473-482, Los Angeles, May 1999.
- UQCS Cristina Cifuentes' Publications
- Todd Proebsting
- Reverse Engineering the LEGO RCX
- ristina Cifuentes' Publications
- Todd Proebsting: Report on Toba
See also Softpanorama Copyright Links
DIGITAL Technical Journal - Differential Testing
for Software -- technique useful in reverse engineering. In case you reimplementation is "almost" complete it can be tested against
etalon by feeding to both randomly modified test cases -- difference in behaviors can lead to interesting insights. IMHO especially
useful in case of reimplementation of Microsoft Office suit...
Application Note -- Software Test Tools Considered Harmful
A failure to synchronize during playback causes the test recording to abort and typically signals that the application has changed
in a way that the test has detected. The problem is that in some cases, when the application hasn't changed, the failed test would
imply that it had incorrectly. Too many such false-negative results would tend to lead to the view that the test suite is unreliable.
Testing Strategies and Methods
-- The Reengineering Forum
is an industry association to encourage combined industry/research review of the state of the art and the state of the practice in
reengineering of software, systems, and business processes. It is a meeting place for key people in the reengineering and reverse
engineering fields: developers, researchers, and leading-edge users.
WCRE The Working Conference on Reverse Engineering (WCRE) is the premier research conference on the theory
and practice of recovering information from existing software and systems. WCRE explores innovative methods of extracting the many kinds
of information that can be recovered from software, software engineering documents, and systems artifacts, and to examine innovative
ways of using this information in system renovation and program understanding. WCRE proceedings are available from IEEE Computer Society
(phone +1-714-821-8380 or +1-800-CS-BOOKS; email@example.com). See
CS Press Catalog site.
- May 1993 - Baltimore, Maryland (with the Intl Conf on Software Engineering)
- Jul 1995 - Toronto, Ontario, Canada (with the Intl Workshop on CASE).
- Nov 1996 - Monterrey, California, USA (with the Intl Conf on Software Maintenance ).
WCRE '96- Abstracts
- Oct 1997 - Amsterdam, The Netherlands
4th WCRE Information Page
- Oct 1998 - Honolulu, Hawaii, USA (with the Automated Software Engineering Conf)
WCRE '98 - Working Conf on Reverse Engineering
- Oct 1999 - Atlanta, Georgia, USA
6th Working Conference on Reverse Engineering (WCRE
- WCRE '99 - Call For Papers
- Nov 2000 - Brisbane, Queensland, Australia
- Oct 2001 - Stuttgart, Germany
- Neil Aggarwal
- Cornelia's Boldyreff
- Giampiero Caprino
- Cristina Cifuentes
- Christian Collberg
- Arie van Deursen
- Jean-Marie Favre
- Bookmarks for Jean-Marie Favre
"A Flexible Approach to Visualize Large
ICSE Workshop on Software Visualization,
Toronto, Canada, May 2001
R. Sanlaville, J.J. Auffret
"Reverse Engineering a Large Component-based
European Conf. on Software Maintenance and Reengineering, (CSMR'2001), pp. 95-104,
Lisboa, Portugal, March 2001
International Workshop on Program Comprehension (IWPC'97)
Deadborn (Michigan), May 1997
- Douglas Low
- Todd Proebsting
- Clark Thomborson
- Paul M. Týma
- H. P. Van Vliet (RIP)
The Last but not Least Technology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP)
in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified: March 12, 2019