Title: PROM Checksum Calculation Repost
Post by: gborgns on December 27, 2005, 08:50:12 PM
Post by: gborgns on December 27, 2005, 08:50:12 PM
Thought I'd repost the important info found on calculating the Checksum for the Next PROMs. I saved the text from the openstep.se 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:
http://www.jonelo.de/java/jacksum/index.html
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
http://www.codeguru.com/Cpp/Cpp/algorithms/checksum/article.php/c5103
and hextedit version 2.0 beta on a wintel platform to verify.
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:
http://www.jonelo.de/java/jacksum/index.html
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
http://www.codeguru.com/Cpp/Cpp/algorithms/checksum/article.php/c5103
and hextedit version 2.0 beta on a wintel platform to verify.
Title: PROM Checksum Calculation Repost
Post by: Nitro on December 28, 2005, 01:57:18 PM
Post by: Nitro on December 28, 2005, 01:57:18 PM
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.
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.
Title: PROM Checksum Calculation Repost
Post by: Andreas on January 03, 2006, 03:34:19 PM
Post by: Andreas on January 03, 2006, 03:34:19 PM
Just for the archive:
Pictures about the Offsets and how to calculate via Hex-editors:
Pictures about the Offsets and how to calculate via Hex-editors:
Title: Dumping the roms...
Post by: neozeed on April 15, 2006, 07:20:13 PM
Post by: neozeed on April 15, 2006, 07:20:13 PM
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..
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..