It is possible I didn't take the dump correctly, or there is a problem with my burner. I chose Binary when saving files. Perhaps, the other possibility is those flash chips aren't the actual firmware, just storage. The actual firmware (program) flash chip could be located elsewhere. However, that would seem a bit strange to me, why socket transient memory and not the actual program itself? How should I have taken the flash dumps?
-mark -----Original Message----- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Herbert Poetzl Sent: Thursday, 18 April 2013 12:43 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Z3805A flash dump. On Wed, Apr 17, 2013 at 08:31:49AM +0000, Mark C. Stephens wrote: > I have dumped the 4 flash ROMS from my latest Z3805A but I can't make > head nor tail of the contents. > I am thinking the flash are interleaved. Interleaving makes sense for performance reasons and usually happens at bit or byte level, but I'm not (yet) convinced that the data was dumped correctly. > http://www.vk2hmc.net/blog/wp-content/uploads/2013/04/z3805-flash.rar Assuming that the Z3801A and Z3805A ROM contents is somewhat similar (1x512k = 4x128k), let's take a look at the entropy of the data: $ cat z3801a.bin | xz --stdout | wc -c 110020 $ cat z3805-*.bin | xz --stdout | wc -c 60436 This rough estimate on the amount of non redundant data shows that the z3801a ROM contains almost twice as much data than the z3805 ROM dumps together. $ for n in z3805-*.bin; do xz --stdout $n | wc -c; done 25108 30724 24712 22812 This shows that the data is almost evenly distribute between the four dumps, so some kind of interleaving is obviously present and none of the files are purely random or contain just padding or similar like: $ dd if=/dev/urandom bs=1k count=128 | xz --stdout | wc -c 131140 $ dd if=/dev/zero bs=1k count=128 | xz --stdout | wc -c 152 Now looking at the data itself, it is simple to see that there is a positional redundancy present: $ for n in z3805-*.bin; do xxd -g 1 $n | head -1; done 0000000: 6f ff 00 05 04 05 00 05 10 05 00 05 28 05 00 05 o...........(... 0000000: 6f 10 00 05 04 fe 00 05 10 00 00 05 28 50 00 05 o...........(P.. 0000000: 6f a0 00 05 04 00 00 05 10 42 00 05 28 42 00 05 o........B..(B.. 0000000: 6f 00 00 05 04 ff 00 05 10 00 00 05 28 05 00 05 o...........(... Columns 1, 3, 4, 5, 7, 8, 9 ... are all equal, only the columns 2, 6, 10, 14 ... contain different values across the files, which basically means that 3 out of 4 bytes are completely identical between the 4 dumps. (this is, where I think something might have gone wrong with the dumps :) Anyway, extracting the data from the columns where the dumps actually differ gives the following data [1]: $ xxd col.data | head -4 0000000: ff10 a000 05fe 00ff 0500 4200 0550 4205 ..........B..PB. 0000010: 0510 0000 05b4 1105 0510 0000 05b4 0005 ................ 0000020: 0510 1100 05b4 0005 0510 0000 05b4 1105 ................ 0000030: 1310 0000 05b4 0005 0510 1100 05b4 0005 ................ Comparing this with the dump from z3801a ROM: $ xxd z3801a.bin | head -4 0000000: 0010 fffe 0000 0550 0010 05b4 0010 05b4 .......P........ 0000010: 0010 05b4 0010 05b4 0010 05b4 0010 05b4 ................ 0000020: 0010 05b4 0010 05b4 0010 05b4 0010 05b4 ................ 0000030: 0010 05b4 0010 05b4 0010 05b4 0010 05b4 ................ Suggests that there is some kind of reordering required to get the similar structure present in the hardware vector table. The following mapping seems to do the trick: Pick every odd byte from the data and switch every two resulting bytes, or as pseudocode: for (n = 0; n < 2; n++) { for (i = 0; i < dlen; i += 4) { j = i/2; split[n][j + 0] = data[i + n + 2]; split[n][j + 1] = data[i + n + 0]; } } The resulting data [2] seems to contain meaningful strings and binary code similar to the z3801a ROM: $ strings split.data | grep psos >@(#)$Header: psos.S,v 1.4 95/01/11 15:27:21 jacob Exp $ @(#)$Header: psos_indep.h,v 1.5 95/03/24 15:24:19 da oe uxn d >@(#)$Header: psos.S,v 1.4 95/01/11 15:27:21 jacob Exp $ @(#)$Header: psos_indep.h,v 1.5 95/03/24 15:24:19 da oe uxn d HTH, Herbert [1] http://vserver.13thfloor.at/Stuff/VARIOUS/Z3805/col1.data [2] http://vserver.13thfloor.at/Stuff/VARIOUS/Z3805/split1.data > I can't see any strings that make sense like the Z3801A flash. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
