I´ve only tried to decompress the image and not mount it. I think that if you can decompress to a directory, make changes and recreate a valid image then you can do everything you need (mounting the image is a more easy way, but I´m a newbie in too many things to attack this option.
Actual state:
A very simple modification to the cramfs.h file from the diskutil package let you decompress the ro.fs.v5 without problem.
The package can be found in
http://packages.debian.org/es/sid/util-linux and download the sources.
The modification is in the i-node definition section
#define CRAMFS_MODE_WIDTH 16
#define CRAMFS_UID_WIDTH 16
#define CRAMFS_SIZE_WIDTH 24
#define CRAMFS_GID_WIDTH 8
#define CRAMFS_NAMELEN_WIDTH 24
#define CRAMFS_OFFSET_WIDTH 32
/*
* Reasonably terse representation of the inode data.
*/
struct cramfs_inode {
u32 mode:16, uid:16;
/* SIZE for device files is i_rdev */
u32 size:24, gid:8;
/* NAMELEN is the length of the file name, divided by 4 and
rounded up. (cramfs doesn't support hard links.) */
/* OFFSET: For symlinks and non-empty regular files, this
contains the offset (divided by 4) of the file data in
compressed form (starting with an array of block pointers;
see README). For non-empty directories it is the offset
(divided by 4) of the inode of the first file in that
directory. For anything else, offset is zero. */
u32 unknown:8, namelen:24;
u32 offset:32;
};
I don´t know the sense of the unknown field.
The root.fs.v5 has another problem. There is a file with excess of pointers to blocks (exactly 8192). The cramfs format is
Header: Information about the file, number of files, blocks,...
I-node zone:Structured data with i-nodes followed for name of files/directories. The i-nodes contain the offset to the file data.
Data zone: Every file has
1) a number of pointers (file size / page_size +1 aprox.) pointing the next byte after the last data of this block
2) the data for every block
In the root.fs.v5 image I've found that the /root/adobe has a special format. In the buggins 20091005 the inode states a size of 2423580 so 592 pointers are needed, but in offset+592*4 there are more pointers. The real data starts in offset+592*4+8192*4. Moreover the last teorical block of the adobe file has a decompressed size of 4096 bytes but to complete the file only last 1800 (or so) bytes, and the 8192th block has the right decompressed size to finish the adobe file. So if the adobe file has 592 pointers you can find in the file
p1 p2 p3 ... p591 p592 p1+ ... p8192+ where
p1 to p591 and p8192+ are for adobe file
p592 to p8191+ create a file non described in the inode structure and a decompressed size about 32MB. This file is identified as data by "file -s" command. I´ve checked two firmwares and this file is different.
The root.fs.v5 has a padding after the data zone; the data are padded with 00 to 4096 bytes round, and the file to a size of 0x730000 bytes is FF padded.
Unresolved questions:
¿Is there mistakes in the inode estimated structure?
¿What is the 32 MB file? ¿why is inserted in the adobe file? ¿Is it really needed?
Waiting for your ideas.
Regards
Qbspin