This seems to do the dive data descrambling right for both files I have
access to. Except it uses a hardcoded (different) offset for the two.
I have yet to figure out how to automatically detect the offset itself
properly, so you have to compile for the right file.
I'll figure it out, but I'm committing this as a reasonable point in the
process.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It turns out the odd "different CAN files have different header offsets"
came from the fact that the decode block was different lengths, and I
had not picked the correct place to start - and instead had found two
different places that were at different offsets due to the decode block
length differences.
This fixes that up, and it looks like the dive header is correctly
descrambled (but what the data *means* is unclear, although there is now
an ASCII date and time visible, so at least one part of it is pretty
obvious).
The actual dive data unscrambling is still different for the two
test-files I have to play with, I do not know why.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This descrambles at least parts of the header data. Some of it has the
same pattern of data 4kB apart, it may be that there is a dive hiding in
there too (ie what I currently call a "header" may in fact be a header
_plus_ a dive).
But the 4kB thing may well be an artifact of the crazy scrambling code
itself. Who knows what kind of chunking the Cochran Analyst
"encryption" uses.
As with the dive data, there seems to be some offset differences between
different CAN files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
So this descrambles all the dives in *one* of my cochran test files. I
still don't know what the dive data *means*, but it's not a random
jumble of bytes any more: there are very clear patterns.
However, the magic offsets that work for that particular CAN file are
not generic, because they don't work for another. So there is some
magic dynamic decoding that I don't know about. There is probably more
decode information in the initial decode block, over and beyond just the
scrambling bytes.
(The scrambling array is 234 bytes starting at 0x40001, but the first
actual *dive* data starts at 0x45e03, so there's tons of unknown stuff
in the file even outside the dives themselves)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Just do the hex-dump in the program, and print all the results to
standard output. Avoid the need to do 'od' by hand etc to see what
happens when you play with the decoder.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's broken, and currently only writes out a debug output file per dive.
I'm not sure I'll ever really be able to decode the mess that is the
Cochran ANalyst stuff, but I have a few test files, along with separate
depth info from a couple of the dives in question, so in case this ever
works I can at least validate it to some degree.
The file format is definitely very intentionally obscured, though.
Annoying. It's not like the Cochran software is actually all that good
(it's really quite a horribly nasty Windows-only app, I'm told).
Cochran Analyst is very much not the reason why people would buy those
computers. So Cochran making their computers harder to use with other
software is just stupid.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
