17 Apr
2018
17 Apr
'18
11:27 a.m.
On Tue, Apr 17, 2018 at 11:06 AM, Richard Sheppard via cctalk
<cctalk at classiccmp.org> wrote:
<random comment on firmware checksums>
A while ago someone asked about dumping contents of the firmware
EPROMs from a DECserver 200 where the pair of EPROMs were soldered in
place. I used a method of doing that which didn't require desoldering
the EPROMs to read them on a device programmer. I wanted to verify the
correctness of what I managed to dump and by disassembling and
inspecting sections of the firmware I found that the firmware was
running a standard CRC32 checksum on itself during its initialization.
I was able to run the CRC32 algorithm on what I dumped and verified
that it match the checksum that was stored in the EPROM data, and that
was sufficient to convince myself that the dump was correct.
But the interesting part of all of that is when I looked further at
the disassembled firmware it appeared that after it calculated the
CRC32 checksum and compared it against the expected result, it
completely ignored whether or not the checksum actually matched the
expected result. Seemed odd. Later I acquired another DECserver 200
with the same firmware version in socketed EPROMs. Just for curiosity
sometime I should try altering the checksum and verify that it really
doesn't matter.
</random comment on firmware checksums>
Lastly, I
wonder if there might be some kind of checksum check to prevent tampering. Is there a
common way this is handled in 8085 world? Or is it entirely programmer dependent?
One approach that <may> be doable for you is if you have a good ROM with a known
checksum, make your changes then calculate the difference between the new and the original
checksum and make another change somewhere innocuous to bring the checksum back to the
original value. "Innocuous" may be the trick - perhaps some text string you
don't care about, copyright notice etc. or maybe there is an empty area in the EPROM
you could stick a byte.
Richard Sheppard