NeXT Computers Forum Index NeXT Computers
Log in to check your private messagesLog in to check your private messages

Log inLog in  RegisterRegister

Profile  Search  Memberlist  FAQ  Usergroups
PROM Checksum Calculation Repost

Post new topic   Reply to topic    NeXT Computers Forum Index -> Black Hardware
View previous topic :: View next topic  
Author Message

Joined: 27 Dec 2005
Posts: 29

PostPosted: Tue Dec 27, 2005 7:50 pm    Post subject: PROM Checksum Calculation Repost Reply with quote

Thought I'd repost the important info found on calculating the Checksum for the Next PROMs. I saved the text from the fourm.
Can't remember who had the original discovery. Please chime in and take credit, if you are registered yet.

Original post:

When people start charging $100 USD to burn an EPROM itís time to do a little investigating. All joking aside, I figured out how to calculate the NeXT ROM checksum. I had never played much with checksums before, so hereís how I stumbled through it:

I started with the example that Andreas posted at the beginning of this thread. The checksum consists of eight hexadecimal numbers. Since each number is represented by four bits, that means itís a 32-bit checksum ( 4 x 8 ). At this point a few assumptions have to be made. Since this isnít cryptography, I assumed that NeXT more than likely used a standard checksum algorithm. The algorithm also had to be available during the mid-to-late 1980ís. So that narrows the field a bit. As I understand it, checksums are calculated based on static data strings, so the checksum itself canít be part of the string. This means the data string lies before or after the checksum. Since the data after the checksum is identical in the two example ROMís, this means the data string lies before the checksum. That makes sense since the mac address is also located there. I had no knowledge or desire to calculate checksums, so I Googled for a checksum calculator. I found a Java based calculator called Jacksum. It can be downloaded here:

I tried different combinations of algorithms and data strings. I finally hit pay dirt when I calculated a crc-32 checksum of the example ROM data string starting with the beginning of the file and ending with hex address 15 (just before the checksum starts). This is the first 44 hexadecimal digits of the file. Using the first ROM that Andreas posted above, I entered the following at the command line:

Jacksum.bat -a crc32 -X -q 040004000100001E00000F015F730000000000000000

The Ėa option defines the algorithm, the ĖX option returns an uppercase hexadecimal checksum, and the Ėq option specifies the hexadecimal data string to be computed. With the above command line data, Jacksum returned the correct checksum: CE 0D 9A 06. I then tried the second ROM that Andreas posted:

Jacksum.bat -a crc32 -X -q 040004000100001E00000F01662A0000000000000000

Jacksum returned the correct checksum: 84 1A C4 D9.

My next step (no pun intended) was to compare the data strings of different ROM versions, so I loaded v65 and v66 into a hex editor. Except for the mac address, the data strings before the checksum are the same. So, this tells me that to upgrade your ROM using your old mac address, you simply have to load the new ROM into a hex editor and overwrite the mac address and checksum with the data from your old ROM version. Computing a new checksum is probably not necessary. But if you want peace of mind, you can use the above procedure to verify the checksum. I havenít looked at v71 against v74, but Iím assuming the same is true for them. I havenít tried to burn a new EPROM with this method yet, so use this information at your own risk. Sorry for the long post, hope this sheds a little light on the subject.

My comments:

The technique works and has been check on Cube and Slab machine PROM dumps. It will be useful in changing the MAC address on a machine and for reviving machines with dead boot PROMs.

I used the crc32 utility
and hextedit version 2.0 beta on a wintel platform to verify.
Turbo Color Slab, Tadpole P1000G and SS5
Back to top
View user's profile Send private message
Site Admin

Joined: 22 Oct 2005
Posts: 422
Location: Littleton, Colorado USA

PostPosted: Wed Dec 28, 2005 12:57 pm    Post subject: Reply with quote

Hi gborgns,

Andreas found the mac address in the code, and that was the difficult part. I looked for the address in the ROM code about a year ago and couldnít locate it. He may still have the screen shot of his hex editor posted online. Canít remember who confirmed that there was a checksum, but I wouldnít have known that if I saw it. Iím the one who stumbled through the calculation process.
I still haven't burned an EPROM with the code and tested it in black hardware. I donít know much about erasing the old code and whether that can be done with a burner or light.

Last edited by Nitro on Tue Jan 03, 2006 11:25 pm; edited 1 time in total
Back to top
View user's profile Send private message

Joined: 27 Dec 2005
Posts: 356
Location: Germany

PostPosted: Tue Jan 03, 2006 2:34 pm    Post subject: Reply with quote

Just for the archive:

Pictures about the Offsets and how to calculate via Hex-editors:

Back to top
View user's profile Send private message

Joined: 15 Apr 2006
Posts: 716
Location: Hong Kong

PostPosted: Sat Apr 15, 2006 5:20 pm    Post subject: Dumping the roms... Reply with quote

I was wondering, if its possible to read the roms from within nextstep? I know that on a x86 unix you can

dd if=/dev/mem of=rom bs=1 skip=0xf0000 count=64*1024

From what I gather from the netbsd source the next rom is at 0x01000000

from nextstepmemorymap.h

#define NEXT_P_EPROM_BMAP (NEXT_SLOT_ID+0x01000000)
#define NEXT_P_EPROM_SIZE (128 * 1024)

but when I do this

dd if=/dev/mem of=rom bs=1 skip=0x01000000 count=128*1024

I seem to get gibberish. Or is the next rom encrypted? Im at a loss here..
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    NeXT Computers Forum Index -> Black Hardware All times are GMT - 7 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2017 phpBB Group