Read Flash-Dumps

Read Flash-Dumps

[Peter Keel]

Hello. 

I got an Igel-Terminal, which features an M-systems DiskOnAChip 2000.
Now I got these flash-images from an ftp and want to modify them 
before putting them into the flash; preferably on another machine
(without flash). 

So how do I do a loopack-mount of the files? I tried several 
filesystems, but that doesn't seem to work. Also, nftl doesn't 
even appear in /proc/filesystems. 

Thanks
Peter
-- 
"Any good Unix security engineer can clean up any Unix box. But I'm not 
 sure there are people even within Microsoft who know how to clean up 
 an NT box." -- Michael Zbouray

Re: Read Flash-Dumps

[David Woodhouse]

killer@discordia.ch said:
>  I got an Igel-Terminal, which features an M-systems DiskOnAChip 2000.
> Now I got these flash-images from an ftp and want to modify them
> before putting them into the flash; preferably on another machine
> (without flash). 

I'm not sure what form those flash-images are in. They may be a similar 
dump to the one you'd get from the 'nanddump' program, in which case you 
could write it back with the 'nandwrite' program and the MTD drivers.


killer@discordia.ch said:
>  Also, nftl doesn't  even appear in /proc/filesystems. 

It would appear as a block device. But last time I knew, I believe Igel were
shipping the M-Systems binary-only driver statically linked into their 
kernel in violation of the GPL. In that case, you're on your own.

Can you show me the contents of /proc/devices?

--
dwmw2

Re: Read Flash-Dumps

[dr john halewood]

On Wednesday 09 May 2001 18:01, Peter Keel wrote:
>
> So how do I do a loopack-mount of the files? I tried several
> filesystems, but that doesn't seem to work. Also, nftl doesn't
> even appear in /proc/filesystems.
>
IIRC the igel box uses minix filesystems mounted on top of the NFTL so you 
don't access the flash layer directly. (It also uses the M-Systems proprietry 
driver, which isn't suprising as Igel wrote it)

mount file.img /mnt -t minix -o loop  should do the trick.
I think the igel box has 4 minix partitions on the DoC.

cheers
john

Re: Read Flash-Dumps

[Peter Keel]

* on the Wed, May 09, 2001 at 06:58:09PM +0100, David Woodhouse was blubbering:
> 
> killer@discordia.ch said:
> >  93 nftl 
> 
> You're running the GPL'd drivers, then. Interesting - where did this kernel 
> come from?

Compiled it. Anyway, that's not the Igel. That one's the Igel:

Block devices:                                                                  
 2 fd                                                                           
59 fl                                                                           
62 flashdisk

fdisk -l /dev/fla
Disk /dev/fla: 16 heads, 2 sectors, 999 cylinders
Units = cylinders of 32 * 512 bytes
Device     Boot    Start       End    Blocks   Id  System
/dev/fla1   *        1         999    15983    83  linux  

However:

cat /etc/fstab
# device                directory       type    options         freq pass

/dev/igf1               /               minix   defaults        1       1
/dev/igf2               /usr            minix   defaults        0       0
/dev/igf3               /usr3           minix   defaults        0       0
/dev/igf4               /usr4           minix   defaults        0       0
/proc                   /proc           proc    defaults        0       0

though mount reports:
/dev/igf1 on / type minix (rw)
/proc on /proc type proc (rw)
/dev/igf2 on /usr type ext2 (rw)
/dev/igf3 on /usr3 type ext2 (rw)

> Can you test the hypothesis that the image you have is a hard drive image? 

The ones I mentionned first aren't. They're the update-files from 
ftp.igel.de.

> Take a copy and run 'sfdisk blah.image'. What does it do?

sfdisk fla.img 
Warning: fla.img is not a block device
Disk fla.img: cannot get size
Disk fla.img: cannot get geometry

Disk fla.img: 0 cylinders, 0 heads, 0 sectors/track
Old situation:
Warning: The first partition looks like it was made
  for C/H/S=*/16/2 (instead of 0/0/0).
For this listing I'll assume that geometry.
Units = cylinders of 16384 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls   #blocks   Id  System
 fla.img1   *      0+    998     999-    15983   83  Linux
 fla.img2          0       -       0         0    0  Empty
 fla.img3          0       -       0         0    0  Empty
 fla.img4          0       -       0         0    0  Empty

This one with the image of the whole flash. With the so-called 
/dev/fla1 I get nothing, but those /dev/igf's have to be there 
somewhere. It looks like /dev/fla1 contains some bootloader
00000000   EB 48 90 00  00 00 87 01  00 00 46 6C  61 73 68 20  .H........Flash 
00000010   4C 69 6E 75  78 20 42 6F  6F 74 20 56  65 72 73 69  Linux Boot Versi 
00000020   6F 6E 20 30  2E 39 39 00  43 6F 70 79  72 69 67 68  on 0.99.Copyrigh
00000030   74 20 28 43  29 20 31 39  39 36 2D 31  39 39 39 20  t (C) 1996-1999 
00000040   49 47 45 4C  20 47 6D 62  48 00 8C C8  2E 03 06 06  IGEL GmbH.......
About until 00001CF0, then follows a series of 0x00 and then
at 00004000 follows the directory-index of the small rw-partition,
and shortly thereafter (00004150) its contents. 
After that, from 00010000 on, no idea ;) Garbage. 
Judging from some Errormessage in the bootloader, 
"The boot/system partition is not of type CROMDISK !" I'd say
this is compressed.

Still interested in my little reverse-engineering Igel? ;-) 

Cheers
Peter
-- 
"Any good Unix security engineer can clean up any Unix box. But I'm not 
 sure there are people even within Microsoft who know how to clean up 
 an NT box." -- Michael Zbouray

Re: Read Flash-Dumps

[Peter Keel]

* on the Wed, May 09, 2001 at 06:18:05PM +0100, dr john halewood was blubbering:
> On Wednesday 09 May 2001 18:01, Peter Keel wrote:
> >
> > So how do I do a loopack-mount of the files? I tried several
> > filesystems, but that doesn't seem to work. Also, nftl doesn't
> > even appear in /proc/filesystems.
> >
> IIRC the igel box uses minix filesystems mounted on top of the NFTL so you 
> don't access the flash layer directly. (It also uses the M-Systems proprietry 
> driver, which isn't suprising as Igel wrote it)

Wrapup. 

Its Flash has the following structure:
/dev/fla contains the whole flash. In the following order:
    00000000-000003FF	something which "file" identifies as 
			linux-kernel. contains a valid partition-table, 1kB. 
    00000400-000020FB	The bootloader. It can decompress the compressed
			part of the filesystems. ca. 8kb. 
    000020FC-000043FF	Empty. 0x00, ca. 8kb. Seems to belong to
			the bootloader. 
    00004400-000103FF	Writeable area. is 48 kb. filesystem unknown
			but looks primitive. two utilities (each 7kb) 
			in /bin know how to handle that. 
    00010400...		Compressed and readonly. Contains:
	/dev/igf1	/-filesystem. ext2, 20 MB
	/dev/igf2	/usr-filesystem, ext2
	/dev/igf3	/usr3-filesystem, ext2
	/dev/igf4	(possibly)
    looks like it's realised with some kind of a loop-mount
    filesystem (probably called cromfs) which decompresses on 
    the fly. I tried with cramfs, but either this isn't the same
    or more likely, I haven't found the right start of the file.

Cheers
Peter
(Doh, 15kbit executable, seems possible with objdump...)

Re: Read Flash-Dumps

[David Woodhouse]

Ah. I suspect you're also seeing the Igel compressed loopback block device 
thingy. The wet piece of string which connects the office to the outside 
world is particularly bad tonight, so I can't stand the pain of looking 
through my mail archives there for more details. Google is your friend.

--
dwmw2