TERM PAPER

ON
CSE 318

TOPIC: DISASSEMBLER

SUBMITTED TO: SUBMITTED BY:

MS. N. PRIYANKA GUNJA KUMARI
R.NO.-RB1801A10
REG.NO.-10810231

TABLE OF CONTENTS
• Abstract
• Introduction
• System Requirements
 Memory
 Input devices
 Output devices
 Software
 Input
 Memory
 Disk sectors
 Disk boot files
 Binary load files
• Output
 Screen
 Printer
 Disk
 Cassette
• Working
• Unrecognized instructions
• Examples of disassemblers
• Disassembler issues
 Separating code from data
 Lost information
• Conclusion
• Flow chart of disassembler
• References
ABSTRACT

A “disassembler” is a well
recognized computer system
program. It translates machine
language into assembly language,
the inverse operation of
an assembler. Disassembler
differs from a decompiler, which
targets a high level
language rather than an assembly
language. Disassembly, the
output of a disassembler, is often
formatted for human-readability
rather than suitability for input to
an assembler, making it
principally a reverse-
engineering tool.

KEYWORDS:
DISK SECTORS
DISK BOOT FILES
BINARY LOAD FILES
CASSETTE
IDA 3.7
IDA Pro Freeware
PVDasm
diStorm64
 if quant>100 if
A001>100
goto bigorder goto R002
INTRODUCTION print "end" print "end"
stop stop

A disassembler unassembles the

compiled executable into
assembly language statements. A DISASSEMBLER 6502 was
good disassembler will show the written for the hardcore
logic between various sections of assembler language programmer
code, comment on code, pull out who is seldom happy with an
the visible ASCII strings, and existing piece of software. When
separate the program between the no source code is available,
instructions and stored data modifying machine language
(often a disassembler’s most programs can be extremely
confounding task). difficult.
DISASSEMBLER 6502 creates
It is a software that converts source code from machine
machine language back into language that can be modified,
assembly language. Since there is reassembled, and executed.
no way to determine the human
thinking behind the logic of the
instructions, the resulting
assembly language routines and
variables are named and
numbered sequentially (A001,
A002, etc.). Disassembled code
can be very difficult to maintain
in its original state; however, the
code can be manually renamed SYSTEM
for future maintenance. REQUIREMENTS:
Hypothetical Hypothetical
MEMORY: 24k minimum and
Human-Written Machine-
48k desirable.
Created
Assembler Code
INPUT DEVICES: Keyboard
Disassembler Code
and one or more disk drives.

start in quant R001 in A001

OUTPUT DEVICES: Screen
and one disk drive. A second
disk drive or cassette drive is
needed for machine-readable
output of disk boot files or large
disassemblies. Double density
can be very beneficial.
SOFTWARE: An
assembler/editor is required if
you wish to reassemble the
output. DISASSEMBLER 6502
output has been tested on the
ATARI ASSEMBLER/EDITOR
cartridge and MAC/65 from
Optimized Systems Software.
INPUT: Input to the disassembler
can be from the following
sources:
MEMORY - Any range of
memory addresses from 0 to
$FFFF can be disassembled.
Addresses can be entered in
either decimal or hex (e.g. 100 or
$64).
DISK SECTORS - Any range of
sector numbers from 1 to 720 can
be disassembled. Sector numbers
may be entered in either decimal
or hex. The last three bytes of a
DOS format sector are control
bytes. They contain the directory
entry number, next sector number
and number of bytes used in the
sector. Options are available to
disassemble sectors including or
excluding these control bytes.
DISK BOOT FILES - By simply
placing the disk in the specified
drive after disk boot option
selection, any boot file on that
disk will be disassembled. This
does not work on double density
disks. The ATARI operating
system initialization code only
supports double density disk boot
in half sectors. Caution - Many
times the disk boot file is simply
a loader to load the remainder of
the program. Use the sector
disassembly option to
disassemble the remainder of the
program once it has been
determined what sectors are
being loaded.
BINARY LOAD FILES -
DISASSEMBLER 6502 will
disassemble any DOS 2.0 or
OS/A+ Version 2 format binary
load file. Compound structures
are also supported.
OUTPUT:
There are four output options
available for DISASSEMBLER
6502. Any one or more in
combination can be used. You
may continue to select options
until the <RETURN> key is
pressed. At that time remaining
information may be obtained and
disassembly begun.
SCREEN - Output is directed to
the screen editor. A line of
output includes the hex machine
instruction, the 6502 assembler
language instruction, and the hex
address of the instruction.
PRINTER - Output is directed to
the printer. You will be
prompted for an optional page
heading to be printed at the top of
each page. A line of output
includes the hex instruction, the
line sequence number (as it
would appear on a disk output
file), the assembler instruction
and the hex address of the
instruction.
DISK - Output is directed to a
specified disk file. The output is
in LIST format and includes a
line sequence number, assembler
instruction, and hex address. The
file can be entered into the
assembler/editor for modification
and reassembly. Since most
assemblers can only assemble
about 1800-2100 lines of
instructions, the output is put into
multiple files of 1600 lines or
less. This allows room for
modifications. An extender of
X01 - Xnn is appended to the file
name. All of the output files can
be reassembled as a unit by using
the .INCLUDE facility and/or
disk assembly facility which are
available in many good
assemblers. They can also be
assembled separately and
combined using the binary save
feature of DUP.SYS. A 1600
line file will use from 120 to 150
single density disk sectors. Thus
an empty disk can hold two files.
Double density disks have double
the capacity.
CASSETTE - Output is directed
to a cassette recorder in the same
format as that directed to disk.
The files are also split into 1600
line files. This will require most
of one side of a sixty minute
cassette.
WORKING:
Disassembler only disassembles
object code that is present in
memory (ROM Included), the
first menu allows us to load the
code from some external Sources.
Select the option by pressing the
number key. Except for binary
disk files, which contain their
own load addresses, all load
options require that you specify a
starting address for the load. The
program asks if we wish to use a
string. If we don't, then just press
return, and input the address.
Any free ram, including page six,
can be used. If we need to reserve
low memory, do that before
loading the basic program. The
device spec is optional.
Disassembler uses d1: as a
default. Disk files may be either
data files (handy for those weird
character strings) or regular
binary files. Multi-stage binary
loads will ask for permission to
poke the bytes. When the entire
file has been read, input the
starting address for disassembly.
Data reads data statements, which
should be entered after
disassembler has been loaded.
Make sure the line numbers are
above 1540. The program will
read the whole block, poking
bytes starting at the first address
specified. Keyboard lets us type
in programs directly. Typing 999
back up five bytes to correct
typos. Any minus number starts
the disassembly. Once the screen
is full, select an option from the
menu by pressing the appropriate
letter key.
C (or return) continues
disassembly inline.
N shifts to a new address (Ex: to
check a jump instruction).
P dumps the current screen to the
printer (the screen is turned off
for this and all other I/O to speed
things up).
E goes to the exit menu. From
this menu,
R starts over from the original
starting address.
M goes back to the top menu.
Q Ends the program.
S writes a source file! First
choice is whether to write a
regular source file, or a byte file,
which is used for text, tables, and
such. Files may be written to the
printer. Input p or p: for a
filename. A line count option is
provided for those with single
sheet printers. If using
continuous feed, input something
like 10000 at the prompt. When
the count is reached, the program
will halt and beep to signal that
it's waiting for a key press to
continue. Disk files are in listed
format, so they can be entered
into asm/ed, mac/65, or any other
line oriented assembler which
uses standard opcodes. Line
numbers correspond to addresses,
so if you see a 'jmp 1608', you
can’ list 1608' to see what's there.
No .org address is included in the
file. Once you have the file, don't
renumber it until you've provided
labels for all the appropriate
references.
UNRECOGNIZED
INSTRUCTIONS:
If an Opcodes is encountered that
is not recognized as a valid 6502
opcodes, a .BYTE instruction is
generated. Up to three
unrecognizable characters will be
included in a single .BYTE
record. A BRK instruction ($00)
most often occurs as a data byte
rather than an instruction. The
disassembler treats binary zeros
as a .BYTE character.
Since data bytes that are valid
opcodes cannot be distinguished
by a disassembler as data bytes,
they will be interpreted as
instructions. The logic flow of
the program should indicate
which of these instructions are
actually data bytes. This
misinterpretation of data bytes
will not prevent the reassembled
program from looking just like
the original.
EXAMPLES
OF DISASSEMBLERS:
Any interactive debugger will
include some way of viewing the
disassembly of the program being
debugged. Often, the same
disassembly tool will be
packaged as a standalone
disassembler distributed along
with the debugger. For
example, objdump, part of GNU
Binutils, is related to the
interactive debugger gdb.
 IDA 3.7: A DOS GUI
tool that behaves very
much like IDA Pro, but is
considerably more
limited. It can
disassemble code for the
Z80, 6502, Intel 8051,
Intel i860, and PDP-11
processors, as well as x86
instructions up to the 486.
 IDA Pro: It is the most
popular disassembler for
tracing malware. It has a
fantastic GUI and feature
set, and it supports most
Windows executable
types, including EXE,
NE, and PE files. It
automatically detects the
data and code portions of
a program. It will auto-
comment code, show
graphical relationships
between code jumps,
document local variables,
and automatically
recognize the standard
library functions
generated by popular C
compilers. The purchase
cost includes a year of
free e-mail support and
updates. Its feature set
and popularity have
resulted in a broad
community to support
questions, active plug-in
development, and training
classes.
 library for IA-32 and
intel64 architectures
(coded in C and usable in
various languages: C,
Python, Delphi,
PureBasic, WinDev,
masm, fasm, nasm,
GoAsm).
 HT Editor: An analyzing
disassembler for Intel x86
instructions. The latest
version runs as a console
GUI program on
Windows, but there are
versions compiled for
An IDA Pro logic Linux as well.
diagram  Texe: is a Free, 32bit
disassembler and
windows PE file analyzer.
 diStorm64: diStorm is an
 ILDASM: It is a tool open source highly
contained in the .NET optimized stream
Framework SDK. It can disassembler library for
be used to disassemble PE 80x86 and AMD64.
files containing Common
Intermediate  PE Explorer: Another
Language code. great disassembler
 OllyDbg: It is a 32-bit commercial alternative is
assembler level analyzing PE Explorer. Like IDA
debugger Pro (but with fewer
 PVDasm: It is a Free, features), it is very
Interactive, Multi-CPU Windows-friendly and
disassembler. easy to navigate. It
 SIMON: a extracts APIs, shows
test/debugger/animator dependencies, pulls out
with integrated dis- code sections, and
assembler for Assembler, disassembles compiled
COBOL and PL/1. programs into commented
 BeaEngine: BeaEngine is code dumps.
a complete disassembler
Figure below shows PE Explorer
disassembling Netlog1.exe
(renamed Netlog1.vir). As we
can see, it offers a thorough look
at the PE file structure and all of
the resources in the file, and tells
us just about every little detail we
could possibly want to know
about a PE file.
Separating Code from
Data
The problem wouldn't be as
difficult if data were limited to
the .data section of an executable
and if executable code was
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).

PE Explorer disassembing
Netlog1.exe

DISASSEMBLER
ISSUES:

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.
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, to reduce the need for
decisions to be made about the
nature of the code. 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 Rice's
theorem 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
All text-based 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. 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 then it can
be ever harder to determine what
is going on.

CONCLUSION
Assembly language source
code generally permits the use
of constants and
programmer comments. These
are usually removed from the
assembled machine code by the
assembler. If so, a disassembler
operating on the machine code
would produce disassembly
lacking these constants and
comments; the disassembled
output becomes more difficult for
a human to interpret than the
original annotated source code.
Some disassemblers make use of
the symbolic
debugging information present in
object files such as ELF.
The Interactive
Disassembler allows the human
user to make up mnemonic
symbols for values or regions of
code in an interactive session:
human insight applied to the
disassembly process often
parallels human creativity in the
code writing process.
Flow chart of disassembler
REFERENCES:

http://www.ebook-search-engine.com/disassembler-ebook-doc.html
http://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Deco
mpilers
http://www.answers.com/topic/disassembler
http://www.digitalmars.com/ctg/obj2asm.html
http://www.heaventools.com/PE_Explorer_disassembler.html