[time-nuts] Z3805A flash dump.

Wed Apr 17 12:52:06 EDT 2013

On Wed, Apr 17, 2013 at 03:38:56PM +0000, Mark C. Stephens wrote:
> It is possible I didn't take the dump correctly, 
> or there is a problem with my burner. 

> I chose Binary when saving files.

That's always a good choice :)

> 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. 

Unlikely, otherwise I would not have been able to
reconstruct the (maybe?) partial data from your dumps.
(see the files I linked in the previous reply)

> 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?

I do not even know what ROM/Flash? chips are used
in this device, but from your reply I conclude that
they are socketed and you were able to read them
via some kind of EEPROM reader/burner?

If so, given that the 'reader' supports the chips
in question, I'd say your dumps are probably fine.

A good method is to dump each chip several times
(if possible in different ways) and compare the
results.

Assuming that everything was dumped correctly, it
might simply be that the device uses only a small 
portion of the ROM/Flash for PSOS (operating system)
and the rest for data storage or checksumming.

A schematic how the chips connect to the CPU might
sched some light on the data stored/used as might
more information about the involved components.

best,
Herbert

> -mark

> -----Original Message-----
> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at 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 at 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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.