Non-6502 ROM used for software key?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Non-6502 ROM used for software key?

Ethan Dicks
Hi, All,

I was dumping ROMs and EPROMs this weekend (including my ROM Rabbit
which I finally tracked down again!) and in one 8032, I found an
oddball.  The chip has no markings - even the manufacturer's stamps on
the bottom have been filed off.  The machine has application-specific
labels stuck to the front faces of the keys (where graphics symbols
would be on a graphic keyboard) but I have no other information on
this computer - it's likely I picked it up from a University Surplus
sale 25 years ago.

I know nonsense ROMs have been used as software keys, but this is
*not* the standard 2022 Visicalc key ROM.  It does not appear to be
6502 code and there are no strings of any informational significance
buried in it.  I'm happy to send it around, but for a teaser, here's a
few lines of the hexdump.

000002 aa 55 02 00 29 13 2b 0b 05 00 29 11 2b 11 1b 0b
000012 09 00 70 2a 3d 25 17 28 41 c8 2a 3d 24 16 25 3f
000022 84 48 20 30 50 2a 3d 41 2c 2a 1c d4 11 10 16 06
000032 16 07 11 0f 7b 51 16 2c 17 2c 31 84 05 25 ff 94
000042 f6 30 84 23 2c 41 8e 2c 20 10 f0 94 e1 4a 51 4b


The closest thing to any sort of coherent string might be a command
letter list late in the dump...

$   4   2   6   /   -   )   9   +   0   .   ,   *   :   E   G   C   A
 H   F   D   B   >   &   %

I suppose this could be some sort of embedded firmware where the
designers swapped a data line or two for layout then convolved the ROM
contents to match, but I think it's more likely to be code for a
different processor architecture.

Any ideas?

-ethan

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Segher Boessenkool
Hi!

On Mon, Mar 26, 2018 at 11:38:00AM -0400, Ethan Dicks wrote:
> 000002 aa 55 02 00 29 13 2b 0b 05 00 29 11 2b 11 1b 0b
> 000012 09 00 70 2a 3d 25 17 28 41 c8 2a 3d 24 16 25 3f
> 000022 84 48 20 30 50 2a 3d 41 2c 2a 1c d4 11 10 16 06
> 000032 16 07 11 0f 7b 51 16 2c 17 2c 31 84 05 25 ff 94
> 000042 f6 30 84 23 2c 41 8e 2c 20 10 f0 94 e1 4a 51 4b

> I suppose this could be some sort of embedded firmware where the
> designers swapped a data line or two for layout then convolved the ROM
> contents to match, but I think it's more likely to be code for a
> different processor architecture.
>
> Any ideas?

It looks like an ibm pc rom?


Segher

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

David Wood-2
The endianness would be reversed as apparently its 55 aa according to the linked article.

On Mon, Mar 26, 2018 at 2:57 PM, Segher Boessenkool <[hidden email]> wrote:
Hi!

On Mon, Mar 26, 2018 at 11:38:00AM -0400, Ethan Dicks wrote:
> 000002 aa 55 02 00 29 13 2b 0b 05 00 29 11 2b 11 1b 0b
> 000012 09 00 70 2a 3d 25 17 28 41 c8 2a 3d 24 16 25 3f
> 000022 84 48 20 30 50 2a 3d 41 2c 2a 1c d4 11 10 16 06
> 000032 16 07 11 0f 7b 51 16 2c 17 2c 31 84 05 25 ff 94
> 000042 f6 30 84 23 2c 41 8e 2c 20 10 f0 94 e1 4a 51 4b

> I suppose this could be some sort of embedded firmware where the
> designers swapped a data line or two for layout then convolved the ROM
> contents to match, but I think it's more likely to be code for a
> different processor architecture.
>
> Any ideas?

It looks like an ibm pc rom?


Segher


Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

MiaM
Den Mon, 26 Mar 2018 16:38:55 -0400 skrev David Wood
<[hidden email]>:
> The endianness would be reversed as apparently its 55 aa according to
> the linked article.

An 8-bit ROM wouldn't have to deal with endianess.

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Michał Pleban
In reply to this post by Ethan Dicks
Hello!

Ethan Dicks wrote:

> I suppose this could be some sort of embedded firmware where the
> designers swapped a data line or two for layout then convolved the ROM
> contents to match, but I think it's more likely to be code for a
> different processor architecture.

I would suggest downloading a disassembler which can handle multiple
architectures (such as IDA) and throw the binary at it to see if one of
the architectures produces a meaningful disassembly.

> I'm happy to send it around, but for a teaser, here's a
> few lines of the hexdump.

Why does the dump start at 0002 not 0000?

Regards,
Michau.



Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Anders Carlsson
Michał Pleban wrote:

> I would suggest downloading a disassembler which can handle multiple
> architectures (such as IDA) and throw the binary at it to see if one of
> the architectures produces a meaningful disassembly.

Assuming it really is X86 code, I tried one of many online disassemblers
yesterday. While I don't understand much of X86 assembly code, it
generated a rather obscure listing with what seems to be lots of far
references and strange constants. It might very well be the case, or a
false positive that the AA 55 (or rather 55 AA) happens to be a BIOS
signature.

Perhaps the application in Ethan's 8032 actually uses a good part of the
ROM for data constants rather than just being a software key/dongle, so
those values would be hand picked?

If it is code from another source, I would rather think in terms of 8080
or Z80 than 8086, given that the X86 didn't really become popular until
the 8032 was on the end of its commercial lifetime.

While I haven't tried it, I found a tool called DASMx (not to be
confused with the cross-assembler called DASM). This one supposedly will
take a binary file and tries to disassemble it for a wide range of CPUs
of the time. I can name a few missing from the list, but the majority of
the ones that are relevant seem to be there.

http://myweb.tiscali.co.uk/pclare/DASMx/

Best regards

Anders Carlsson


Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Ethan Dicks
In reply to this post by Michał Pleban
On Tue, Mar 27, 2018 at 7:40 AM, Michał Pleban <[hidden email]> wrote:
> Ethan Dicks wrote:
>
>> ... I think it's more likely to be code for a
>> different processor architecture.
>
> I would suggest downloading a disassembler which can handle multiple
> architectures (such as IDA) and throw the binary at it to see if one of
> the architectures produces a meaningful disassembly.

I don't recognize IDA as a product name.  I've tried a couple of
web-based disassemblers to no success yet.

> Why does the dump start at 0002 not 0000?

Because the first two bytes are the load address (being a save file
from a PET).  I shaved them off so my disassembly attempts didn't try
to treat them as part of the instruction stream.

-ethan

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Anders Carlsson
Ethan Dicks wrote:

> I don't recognize IDA as a product name.

I believe Michał refers to this commercial product, which starts at 739
USD for the most basic license!!

https://www.hex-rays.com/products/ida/order.shtml

Seems a little excessive to spend so much money to determine if an
anonymous ROM chip contains code or just random data.

Best regards

Anders Carlsson



Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Ethan Dicks
On Tue, Mar 27, 2018 at 9:21 AM, Anders Carlsson
<[hidden email]> wrote:
> Ethan Dicks wrote:
>
>> I don't recognize IDA as a product name.
>
> I believe Michał refers to this commercial product, which starts at 739 USD
> for the most basic license!!

That would be why.

> Seems a little excessive to spend so much money to determine if an anonymous
> ROM chip contains code or just random data.

No doubt!

-ethan

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Gerrit Heitsch
In reply to this post by MiaM
On 03/27/2018 01:33 AM, Mia Magnusson wrote:
> Den Mon, 26 Mar 2018 16:38:55 -0400 skrev David Wood
> <[hidden email]>:
>> The endianness would be reversed as apparently its 55 aa according to
>> the linked article.
>
> An 8-bit ROM wouldn't have to deal with endianess.

Yes, it would.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Spiro Trikaliotis
In reply to this post by Anders Carlsson
Hello,

* On Tue, Mar 27, 2018 at 03:21:08PM +0200 Anders Carlsson wrote:

> Ethan Dicks wrote:
>
> > I don't recognize IDA as a product name.
>
> I believe Michał refers to this commercial product, which starts at 739 USD
> for the most basic license!!
>
> https://www.hex-rays.com/products/ida/order.shtml
>
> Seems a little excessive to spend so much money to determine if an anonymous
> ROM chip contains code or just random data.

IDA was available in free variants some years ago. That is, an older
version than available at that moment was available.

There were restrictions, however, in that the number of CPUs were
limited, or the length of the disassembly was limited, or such. However,
if one looks for it, you might find them (called idafree*, with a
version number where I have the "*").

As far as I know, IDA stopped this habbit because there were too many
pirated versions available. Because of this, they also stopped the
student's offer they had once.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Peter Bortas
On Tue, Mar 27, 2018 at 10:18 PM, Spiro Trikaliotis
<[hidden email]> wrote:

> Hello,
>
> * On Tue, Mar 27, 2018 at 03:21:08PM +0200 Anders Carlsson wrote:
>> Ethan Dicks wrote:
>>
>> > I don't recognize IDA as a product name.
>>
>> I believe Michał refers to this commercial product, which starts at 739 USD
>> for the most basic license!!
>>
>> https://www.hex-rays.com/products/ida/order.shtml
>>
>> Seems a little excessive to spend so much money to determine if an anonymous
>> ROM chip contains code or just random data.
>
> IDA was available in free variants some years ago. That is, an older
> version than available at that moment was available.

It's still there. The latest version is just a month or so old. And
IDE is an extremely competent interactive dissassembler.

https://www.hex-rays.com/products/ida/

> There were restrictions, however, in that the number of CPUs were
> limited, or the length of the disassembly was limited, or such. However,
> if one looks for it, you might find them (called idafree*, with a
> version number where I have the "*").

The big limit has always been on the available CPU modules. The
$700+/year starter version works if you want to do ARM32, ia32 and
MC68k for example, but if you want x64, ARM64, MIPS or Sparc you need
the Pro version.

https://www.hex-rays.com/products/ida/processors.shtml

If your buissiness pays for IDA then go for it. If not it's worth
checking the cheaper alternatives even if they are currently less
capable:

* radare2 with the Cutter UI, completely Free and OSS:
https://github.com/radareorg/cutter
    Do not try the radare2 without the GUI unless you already enjoy
using "vi" and would like something more complicated.

* Binary Ninja, fearly new low price commercial venture with a better
UI than IDA but less sofisticated and no where near as many CPU
modules yet: https://binary.ninja/
    My current favourite, has a great API and is easily extendably with Python.

> As far as I know, IDA stopped this habbit because there were too many
> pirated versions available. Because of this, they also stopped the
> student's offer they had once.

They still release the free version, and just this year they have been
better at updating it because of pressure from Binary Ninja. With the
limited number of CPU modules available in the free version it's not
particularly useful though.

Regards,
--
Peter Bortas

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Segher Boessenkool
In reply to this post by Spiro Trikaliotis
On Tue, Mar 27, 2018 at 10:18:24PM +0200, Spiro Trikaliotis wrote:

> IDA was available in free variants some years ago. That is, an older
> version than available at that moment was available.
>
> There were restrictions, however, in that the number of CPUs were
> limited, or the length of the disassembly was limited, or such. However,
> if one looks for it, you might find them (called idafree*, with a
> version number where I have the "*").
>
> As far as I know, IDA stopped this habbit because there were too many
> pirated versions available. Because of this, they also stopped the
> student's offer they had once.

There is a freeware version as well these days:

https://hex-rays.com/products/ida/support/download_freeware.shtml

  * no commercial use is allowed
  * lacks all features introduced in IDA > v7.0
  * lacks support for many processors, file formats, debugging etc...
  * comes without technical support

(binaries for MS Windows, Linux, and Mac).


Segher

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Anders Carlsson
In reply to this post by Anders Carlsson
I wrote:

> DASMx [..] will take a binary file and tries to disassemble it for a
> wide range of CPUs
>
> http://myweb.tiscali.co.uk/pclare/DASMx/

It turns out to be a (freely downloadable) Windows command line tool
rather than an online web based tool, and handles the following
architectures:

RCA 1802, 1805
Signetics 2650
MOS 6502
Rockwell 65C00, 65C29, 65C02, 65C102, 65C112
Hitachi 6301, 6303, 63L05, 6305
Motorola 6800, 6801, 6802, 6803, 6805, 68HC05, 68HC705, 6808, 6809
Intel 8048, 8051, 8080, 8085
Sharp LR35902 (Nintendo GameBoy specific)
Zilog Z80, National Semiconductor NSC800
Microchip PIC16F83, PIC16F84

One has to run it once for each architecture and it will overwrite the
LST file it generates. At first I had to compile Ethan's bytes back to a
binary file but that was an easy task thanks to the "other" DASM.

As a layman casting one eye at the generated disassembly for processors
I don't really have a clue about, the data set doesn't seem to make
sense when disassembled as either of the above architectures. Someone
else might want to double check.

For that matter, perhaps the extracted chunk is data and code is to be
found later in the ROM? No, I don't feel the urge to investigate beyond
this point.

Best regards

Anders Carlsson


Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

William Levak
In reply to this post by Ethan Dicks
On Mon, 26 Mar 2018, Ethan Dicks wrote:

> Hi, All,
>
> I was dumping ROMs and EPROMs this weekend (including my ROM Rabbit
> which I finally tracked down again!) and in one 8032, I found an
> oddball.  The chip has no markings - even the manufacturer's stamps on
> the bottom have been filed off.  The machine has application-specific
> labels stuck to the front faces of the keys (where graphics symbols

What do the key labels say?

> would be on a graphic keyboard) but I have no other information on
> this computer - it's likely I picked it up from a University Surplus
> sale 25 years ago.
>
> I know nonsense ROMs have been used as software keys, but this is
> *not* the standard 2022 Visicalc key ROM.  It does not appear to be
> 6502 code and there are no strings of any informational significance
> buried in it.  I'm happy to send it around, but for a teaser, here's a
> few lines of the hexdump.
>
> 000002 aa 55 02 00 29 13 2b 0b 05 00 29 11 2b 11 1b 0b
> 000012 09 00 70 2a 3d 25 17 28 41 c8 2a 3d 24 16 25 3f
> 000022 84 48 20 30 50 2a 3d 41 2c 2a 1c d4 11 10 16 06
> 000032 16 07 11 0f 7b 51 16 2c 17 2c 31 84 05 25 ff 94
> 000042 f6 30 84 23 2c 41 8e 2c 20 10 f0 94 e1 4a 51 4b
>
>
> The closest thing to any sort of coherent string might be a command
> letter list late in the dump...
>
> $   4   2   6   /   -   )   9   +   0   .   ,   *   :   E   G   C   A
> H   F   D   B   >   &   %
>
> I suppose this could be some sort of embedded firmware where the
> designers swapped a data line or two for layout then convolved the ROM
> contents to match, but I think it's more likely to be code for a
> different processor architecture.

IBM ROMs were always clearly marked.  Early Apple computers had the
markings ground off.  Apple IIs used a 6502.  Early Macs used the 68000.

[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org

smf
Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

smf
In reply to this post by Gerrit Heitsch
Right

http://thestarman.pcministry.com/asm/mbr/AA55H.html

However that is a signature at the end of the boot sector on disk, this
is right at the start of the rom.

On 27/03/2018 16:34, Gerrit Heitsch wrote:

> On 03/27/2018 01:33 AM, Mia Magnusson wrote:
>>
>> An 8-bit ROM wouldn't have to deal with endianess.
>
> Yes, it would.
>
>  Gerrit
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Michał Pleban
Hello!

smf wrote:

> However that is a signature at the end of the boot sector on disk, this
> is right at the start of the rom.

A Google search brought me there:

http://www.smspower.org/forums/1403-ColecoOffTopicCardHeader

They talk about ROMs having AA 55 as the first bytes, maybe that's a
pointer?

Regards,
Michau.


Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

MiaM
In reply to this post by smf
Den Wed, 28 Mar 2018 09:38:08 +0100 skrev smf <[hidden email]>:

> On 27/03/2018 16:34, Gerrit Heitsch wrote:
> > On 03/27/2018 01:33 AM, Mia Magnusson wrote:
> >>
> >> An 8-bit ROM wouldn't have to deal with endianess.
> >
> > Yes, it would.
>
> Right
>
> http://thestarman.pcministry.com/asm/mbr/AA55H.html
>
> However that is a signature at the end of the boot sector on disk,
> this is right at the start of the rom.

That article shows inconsistent behavior as the DOS DEBUG example byte
swaps even single bytes, while the Linux nasm example only byte swaps
words and not bytes, as (imho) expected.

But no matter what it's not something an 8-bit wide rom should have to
deal with. For example there is no byte swapping when converting
between various file formats for eprom programmers, and of course the
contents of strings (with 8-bit chars) aren't byte swapped.


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

smf
Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

smf
On 29/03/2018 16:34, Mia Magnusson wrote:
> But no matter what it's not something an 8-bit wide rom should have to
> deal with. For example there is no byte swapping when converting
> between various file formats for eprom programmers, and of course the
> contents of strings (with 8-bit chars) aren't byte swapped.

When the 8088/6502/z80/(any little endian cpu) store the 16 bit value
$aa55 will store it in an 8 bit rom as $55 $aa

I regularly deal with roms that aren't mapped 1:1. Data and address
lines can be swapped to simplify the routing on the pcb, which saves
money and they can also be inverted. If you invert A0 then you will see
similar effects to a 16 bit rom with the wrong endian.

Finding ASCII in old roms is unusual, when so many systems (including
commodore) stored text in a different scheme. One system I have been
working on lately has $00-$09 as the digits "0"-"9" and $0a-$23 are the
characters "A"-"Z" (which makes outputting hex really simple). Then it
gets crazy as $2e-$48 are the letters "e"-"z" but characters with
descenders ("g"/"j"/"p"/"q"/"y") take up two characters each. Then
$49-$56 have the rest of the letters ("a"-"d") plus accented versions of
"a"/"e"/"o"/"u".

As there is zero context for where the rom comes from & we don't have
the entire rom, then cutting down on what is possible is right next to
impossible.



Reply | Threaded
Open this post in threaded view
|

Re: Non-6502 ROM used for software key?

Ethan Dicks
On Fri, Mar 30, 2018 at 3:05 AM, smf <[hidden email]> wrote:
> Finding ASCII in old roms is unusual, when so many systems (including
> commodore) stored text in a different scheme.

I wouldn't say "unusual", but certainly ASCII isn't the *only* way to
represent characters.

> As there is zero context for where the rom comes from & we don't have the
> entire rom, then cutting down on what is possible is right next to
> impossible.

The ROM comes out of a CBM 8032 but I have no idea who installed it or
when except "before 1990".  As for the entire contents, I'm happy to
share it, but I didn't want to spam the list with a 4K hexdump.  I'm
not trying to make this hard.  I agree more can be learned or at least
guessed with the entire dump, but to my trained
reverse-engineering-eyes, there are no sections of the dump that have
more structure than any other.

-ethan

12