Sounds like the kind of feature that's normally employed to ensure that downloads are uncorrupted; think MD5 or the like. Because of the way checksums are computed (though the specifics of this are kind of a black box to me), if the file is different than expected it generates a different checksum. Apparently your organ knows (either pre-computed internally or located in another file) what the checksum should be, and your modifications cause a different value. Since you have another tweaked OS that works, the checksum is probably stored in another file you've got; change that (the expected checksum) to whatever the checksum of your modified startup file is, and it may work. Or it may be that the checksum is pre-computed, and the other guys just knew what the checksumming algorithm was and were able to craft a message / adjust the file in other ways to maintain the original checksum. This would be fairly hard to do unless the checksumming algorithm were very simple.
Of course, like I said, I'm not knowledgeable of the exact implementation of these sorts of algorithms, so I could be wrong. But it sounds reasonable enough for me. I'd say your best bet would be to try and contact the folks who tweaked the other OS and ask them to share some of their secrets. Or look for a file that lists what the expected checksums are.
(I recently had to do modify a binary file to get a certain [not illegal] piece of software to install; its checksum was based on the length of the file. That's about as simple as it could get, but since your working on an embedded platform without much need for hack-proof security, I suppose that would be a viable implementation.)
|