Reverse Engineering 6802 based project
RAJ BHALLA
Does anyone have any ideas/suggestions experience in reverse engineering a
6802 based project. I have the dissembled source that I plan on going thru
and try to make sense out of it. I have the hardware schematics and a
general idea of what the hardware does. Are there any tools (free or
otherwise that I can use).
Any comments will be genuinely appreciated.
Ivan Link
On 9 Mar 1998 22:13:12 GMT, "RAJ BHALLA"
<RAJ_BHA...@racalcomm.com0101> wrote:
Sounds like you are almost there anyway. If you have the schematic,
its just a case of working out what the program code actually does.
I hope however that you are not doing this for a commercial purpose,
as disassembling / copying / storing someone elses program code for
rev-eng would be a breach of copyright. You and/or your company could
find youself in court if the origional manufacturer was so inclined.
Also, erm you have just admitted it on public record (see above)
The law on this does vary from country to country, in the UK just
connecting a logic analyser to a micro's full address and data busses
is not a good idea if you want to be legaly 'clean'
I have nothing against re-eng, (done some myself) but if you are going
to do it, be either very careful (work through a solicitor) , or very
quiet ;-)
Good luck
----------------------------------------------------
Ivan Link
Waverider Systems.
Spam Killer, Please remove JUNK to reply.
Paul E. Bennett
In article <01bd4ba8$90c720c0$2983...@RBHALLA.ORACLE>
RAJ_BHA...@racalcomm.com0101 "RAJ BHALLA" writes:
> Does anyone have any ideas/suggestions experience in reverse engineering a
> 6802 based project. I have the dissembled source that I plan on going thru
> and try to make sense out of it. I have the hardware schematics and a
> general idea of what the hardware does. Are there any tools (free or
> otherwise that I can use).
>
>
> Any comments will be genuinely appreciated.
Ingenuity and imagination are usually better than most automated tools in
this respect. I have done this sort of thing before without the aid of a
circuit schematic but a reasonable idea of what functional behaviour the
device exhibited. However, I was on that occasion to deal with the real
source code in a foreign language with quite cryptic comments. Might as
well have been the plain disassembly.
Other exerience (with equipment I knew the function and circuit of) was
the disassembly and fault finding for a 80186 based device. This included
resolving a compiler bug in addition to finding the programmers error.
Would it be worth someone elses effort to pick the bones on this one for
you (for a set fee of course). If all the circuits are in electronic form
and you have an electronic copy of the disassembled source I can have one
of my crew go through it. What would be returned would be a reasonable
description of the software as implemented, including any user interface
details discovered, and a fully commented listing.
We are presuming that you own the rights to the equipment concerned of
which we would expect your written assurance.
--
Paul E. Bennett ................... <p...@transcontech.co.uk>
Transport Control Technology Ltd. <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861 <enq...@transcontech.co.uk>
Going Forth Safely
Spehro Pefhany
RAJ BHALLA <RAJ_BHA...@racalcomm.com0101> wrote:
> Does anyone have any ideas/suggestions experience in reverse engineering a
> 6802 based project. I have the dissembled source that I plan on going thru
> and try to make sense out of it. I have the hardware schematics and a
> general idea of what the hardware does. Are there any tools (free or
> otherwise that I can use).
If you have _detailed_ data sheets on all the chips, all that you seem to
be missing is a big pot of coffee. You might want to interactively run the
disassembler as you figure out what is code and what is data, since the
6802 allows mixing the two.
As someone else said, please obey copyright laws and ethics guidelines so
those of us that do this kind of work get properly compensated and our
lawyers stay lean.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany "The Journey is the reward"
sp...@interlog.com
Fax:(905) 332-4270 (small micro system devt hw/sw + mfg)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Scott Stevens
In article <01bd4ba8$90c720c0$2983...@RBHALLA.ORACLE>, "RAJ BHALLA"
>Does anyone have any ideas/suggestions experience in reverse engineering a
>6802 based project. I have the dissembled source that I plan on going thru
>and try to make sense out of it. I have the hardware schematics and a
>general idea of what the hardware does. Are there any tools (free or
>otherwise that I can use).
>
>
>
>
much about how an embedded design works from reading code, albeit somebody
else's poorly commented code or a disassembly. If you hang a logic analyzer
across the address bus, you can capture the processor's activity to find out
where the processor is spending the most of it's time in memory. If you can't
afford a logic analyzer, but are of a hardware bent (as I obviously am) you
can make a "poor man's logic analyzer" of sorts out of a pair of 8 bit D/A
converters. You just hook the appropriate address lines to data-in lines on
the DAC, and hook the outputs of the DACs one to X and Y of an oscilloscope
running XY mode (no sweep). You will see displayed on the screen a dynamic
"tracing" of where the controller is spending it's time, with brighter
"squiggles of light" where it's spending most of it's time. You need to
connect the appropriate address lines to the right DAC pins and get a feel for
which region of the 'bitmap' of the scope display represents what area in
memory. It's handy and it can show you when the processor is darting off to
particular areas of memory for short periods of time.
Sometimes a few minutes dynamic analysis with a real logic analyzer, or this
'hack' of a logic analyzer can tell you more than hours of code analysis. It
certainly helps prevent you from dwelling too long on rarely-used regions of
the code.
>
Jeff Sampson
Scott Stevens wrote:
>
> In article <01bd4ba8$90c720c0$2983...@RBHALLA.ORACLE>, "RAJ BHALLA"
> <RAJ_BHA...@racalcomm.com0101> wrote:
> >Does anyone have any ideas/suggestions experience in reverse engineering a
> >6802 based project. I have the dissembled source that I plan on going thru
> >and try to make sense out of it. I have the hardware schematics and a
> >general idea of what the hardware does. Are there any tools (free or
> >otherwise that I can use).
> >
> >
> >Any comments will be genuinely appreciated.
> >
> >
> Do you have access to a logic analyzer?
[Description of using logic analyser and a dynamic display was deleted.]
I use the following for any type of CPU.
Assuming you have a disassembly and schematics, identify address ranges for the
ROM and RAM from the schematic. Identify any external I/O device addresses from
the schematic. If either of these are done with a PAL or PLD, you will have
problems and need the logic analyser that Scott Stevens mentions.
Next I go to the code and replace the I/O addresses in the disassembly with a
name you will identify as the I/O devices. Use a search/replace to do this.
Mainly you need the memory addresses to do the disassembly, but you already have
that. Next identify the interrupt points in the code and label them as such.
This shows you where execution will take place for each interrupt. Also any
special memory locations associated with internal I/O devices. (I don't think
the 6802 has much, if any)
Next I isolate the blocks of code in the program. If you find an unconditional
jump instruction, put a blank line after it because the code stops at that
point. Do the same think with a return instruction. Any code following these
statements are new entry points and need labels assigned. When you identify what
a routine does, create a label name for it and do the search/replace to update
the code. Put comments in as you go.
Depending how smart your disassembler is, it may do some of this for you.
Then just grind through the code until you get it figured out. Reassemble the
code occasionally to make sure you haven't inadvertently changed it. Hopefully
it is a small ROM. :-)
--
Jeff Sampson Minneapolis, MN, USA
(Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers)
jsam...@pobox.com jsam...@citilink.com
http://www.pobox.com/~lcd_info