Yes, I already found some links to sourcecode. However, it seems that all those links got invalidated due to either a content move or policy change. (not sure which reason is true)
I also already had the idea that even a simple fs utility source could be sufficient for my needs.
Sorry to say, as for the qnx sources the same seems to be true for all fs utilities
Ok, I know that byte 5-8 in the superblock are the only candidates for the checksum.
(all the other changes to the superblock I can explain if I copy a new file to the fs)
Further, no crc32 (as we are talking about 4 bytes just crc32 algorithms came into focus) run over any potion of the superblock (implemented a program that tries out all “sliding window” byte lengths) resulted in a match.
So tomorrow I will extend the test by including a “brute-force” 2^32 “pre-initialization” of those 4 bytes and compare the crc32 outcome to that specific superblock crc32.
Yes, of course, I will end up with a match. But I have plenty superblocks on the shelve (easy to create a new one by just copying or deleting a file)
Let’s see if I will come to a match across multiple superblocks …
Next idea is that maybe an xor is applied after crc32 calculation. (that would make it easy for appliance creators to do a “slight” modification at that step)
So I will also write a piece of source code to check 2^32 combinations of potential xor candidates. In that case I am perfectly sure that I >have< get a match. (otherwise I’ve got a different problem with my source code…)
Again, If that xor value will match for different superblocks it will be a winner
So … let’s see how good the actual “protection” is …