Custom Sylvania ROM development

[vio]

You can find such a table in the u-boot (Universal Boot Loader) package (u-boot-1.3.2/lib_generic/crc32.c). The second CRC field is computed with all data included in the entries section, till the end of the file, including any padding in between. Then you set this value into the second CRC field, set the first field to zero, and compute the first field using the header data only, from the beginning, and up to include the second CRC field. Hope this helps.

This is great! I can't wait to get on my computer and try it out! (I'm out for the weekend, damn!) How did you get that source file, btw? I was under the impression that the u-boot loader it pretty device-specific.
If you could post the file or a link to the sources, that would be great.

 

[xavim]

Sure, this is the link I followed: SourceCode < U-Boot < DENX, the file is lib_generic/crc32.c. Greetings.

 

[vio]

Sure, this is the link I followed: SourceCode < U-Boot < DENX, the file is lib_generic/crc32.c. Greetings.

Thanks a lot! From the code I was able to get the polynomial value and to build a similar algorithm. I checked it only with one file so far, but the values looks right.
In case anybody wonders, the algorithm was a normal CRC calculation
- POLYNOMIAL: EDB88320
- Initial value: FFFFFFFF
- Final XOR value: FFFFFFFF

The "data" part is, as xavim explained, the whole file minus the first 32 bytes. It's CRC value is stored in bytes 28-31. The "header" part is formed by the first 32 bytes from the file. It's CRC value is stored in bytes 24-27 (this CRC value is calculated by setting bytes 28-31 to the "data" CRC and setting the bytes 24-27 to 0).

I will update the editor application according with this info, now we should be able to compile a valid IUS file from several image files.

 

[lorenii]

Just got my tablet(s) back from DG and FYI:

Model SYNET7LP
Droid ver: DG2.20
Kern ver: 2.6.32.9 neville@neville-desktop#16
HWID: 11.2.0.6

there was an update available, so I clicked on it. After a few seconds I got the message:

update package demaged (sic)!
press power key for 7 sec. to reboot!

The other unit is taking the download and is @ 50%.

 

[lorenii]

Update is Firmware Ver: 11.2.0.6.2.0
Linux: 2.6.23.9

 

[vio]

So, crazy days at work, but I managed to update the editor application with the CRC calculation, which is now performed automatically when file content changes.
The only fields that must be filled manually now are version and BMagic number (which I don't think it can be automatically extracted).

I think I can say that my initial goal was fulfilled - I have an automatic way to break the IUS file in components and put it back again.

I'm not sure what's next, and this is where you guys are coming . Should I continue developing the editor? Do you find it useful? What feature would you like to see next?

One idea would be to go deeper, get inside each image and automate extraction/injection of files - at least for SYSTEM and RAMDISK partitions. Any other ideas?

 

[cfrockit]

I think I can say that my initial goal was fulfilled - I have an automatic way to break the IUS file in components and put it back again.

Congratulations! Given this devices lack of a Recovery menu/option this is a great effort you have undertaken and accomplished.

I'm not sure what's next, and this is where you guys are coming . Should I continue developing the editor? Do you find it useful? What feature would you like to see next?

One idea would be to go deeper, get inside each image and automate extraction/injection of files - at least for SYSTEM and RAMDISK partitions. Any other ideas?

I'll jump in first as I often/always do and suggest if we can repack a custom system.img removing some of the unused stock applications, updating Busybox, rooting, and adding Market would be another great project.

dsixda's HTC Android Kitchen works perfectly to unyaffs the system.img and preserves the links and permissions however, it's repacked images can only be applied using the update.zip Recovery method. If we could utilize this tool or a similar tool to extract the /system folder from the system.img and then customize and repack the image to be inserted in IusEdit_0.41 to create an working file to update the tablet with a custom image would be another step forward to custom firmware.

 

[vio]

Sounds interesting... I'll have to take a closer look to the kitchen tools first to see what's already done.

So far, I know that system.img is a yaffs2 partition dump, gzipped and with a 64 bytes header added to it. Extraction part should be easy to implement - just drop the header, gunzip the remaining part and run the patched "unyaffs-4k" algorithm over it.

Do you know how to repack extracted files? I've found some directions that suggest using a simple tar/zip archive - I assume that's the "update.zip Recovery method" you mention. Let me know if there's something I'm missing.

If there is no other way, we'll probably have to go the long way around and try to recreate the system.img from the extracted files. Creating a yaffs2 partition should be (relatively) easy - if kitchen cannot do it I've found a tool that can - yaffs2utils. Gzip part is also easy to implement - I'll probably find a simple component that already does this. The tricky part will be, again, the header structure - we'll have to crack that too, as we did with the IUS files before.

So, for now, I'll start getting information - feel free to drop with any piece of info you think it's useful, I certainly can use any help on this one.

 

[vio]

Finally got a few free hours and I had time to start analysis of the system image files. There are some promising founds so far, the header structure seems simpler than the IUS file header.

First, we start with what we already know: the "system" image size is multiple of 512 bytes, since this is how IUS files are organized. That means there will be some "wasted" bytes at the end of the image. We also know that the image is started with a 64 byte long header. The actual image is a compressed (gzipped yaffs partition).

So, the general structure of a "system.img" file would be:

    --------------------
  0 |                  |
    |    Header        |  
 63 |                  |
    |------------------|
 64 |                  |
    | Compressed image |
    |                  |
    |------------------|
 .  |                  |
 .  |     0-padding    |
 .  |                  |
x512--------------------

The 64-byte header has only 32 bytes worth of info, the last 32 are starting with "Android" string, followed by padding with "00" bytes until the end.
Following the discoveries from the IUS file header, we can assume for the start that the data is organized in 4-byte entries.

Bytes  Field                Value                   Comment
-----  -------------------- ----------------------- -------
 0- 3  Marker?(constant)    27 05 19 56
 4- 7  Header CRC           05 D1 BA 8B             Populate the other fields, set this on to 0, calculate CRC)
 8-11  Date??               4D 6E 3C A3             Unix timestamp?
12-15  Length               03 D7 58 C2             Actual size of the compressed image, without the 64 bytes header and without 0-padding at the end.
16-23  Constant             40 00 80 00 40 00 80 00
24-27  Data CRC             B5 D1 7E 00             CRC of the compressed image (drop header, drop padding, calculate CRC)
28-31  Constant?            05 02 07 00             Some version number maybe?
32-38  Marker?(constant)    41 6E 64 72 6F 69 64    "Android" string
39-63  Padding              00 ...

So far, I have some constant fields that I don't know what they are ("constant" means they were the same in all the ROMs I could get my hands on). I am assuming we should be safe using the same values for new images.
There is also the "date" field which I'm not sure of... the values are (relatively) close together and they seems to point to some dates in the range November 2010 - March 2011. If I would know the dates these files were published, I would feel more confident about it.

 

[vio]

I didn't have time to work on the implementation, but I'm pretty confident I will be able to repack a system partition into a system.img
In the meantime, how can we get a modified "system" partition? A "dd" on the mounted device? Anybody has an idea how to change the "system" partition and get the yaffs image?

 

[cfrockit]

I didn't have time to work on the implementation, but I'm pretty confident I will be able to repack a system partition into a system.img
In the meantime, how can we get a modified "system" partition? A "dd" on the mounted device? Anybody has an idea how to change the "system" partition and get the yaffs image?

I'm not sure I understand the request. A "dd" of mtd3 "system" doesn't preserve the OOB data. We need a custom nanddump utility.

Google Tech Talk &#8211; Geeks Guide to Digital Forensics &#8211; June 2011

# cat proc/mtd

dev:    size   erasesize  name
 mtd0: 00200000 00080000 "ramdisk"
 mtd1: 00600000 00080000 "kernel"
 mtd2: 08000000 00080000 "resv"
 mtd3: 0c000000 00080000 "system" [COLOR=#0000ff]< yaffs2 partition[/COLOR]
 mtd4: 3d800000 00080000 "userdata"
 mtd5: 04000000 00080000 "cache"
 mtd6: 1ff00000 00080000 "Local-disk"
 mtd7: 00100000 00080000 "panic"

 

[vio]

Well, my point was that we need a way to create the modified yaffs2 partition before we pack it. One way is to run "unyaffs" utility in order to extract all files in a local folder, perform the changes, then use a different utility to recreate the dump file.
I was interested if there is a different way to do it - preferably a way to extract the yaffs2 partition from a running Android system. That would present the advantage of being able to test the modification first, instead of creating a custom ROM, flash it and the test it.

I was thinking to try a "dd" dump and see what we get. Unfortunately, I have already updated my "system" a few times so it won't be a good reference (and besides I'm not able to transfer files from my tablet at the moment - long story involving moving out of my apartment...). So, if somebody with a fresh flashed device could try to "dd" the system and post it along with the name of the flashed ROM, I could check it against the original.

 

[Rrok007]

I have the EX7, freshly flashed to the 2.2 (tab goof and had to reflash it again) without any mods done yet. If someone can post the instructions step by step for what I need to do I'll be happy to give it a go.

 

[vio]

I have the EX7, freshly flashed to the 2.2 (tab goof and had to reflash it again) without any mods done yet. If someone can post the instructions step by step for what I need to do I'll be happy to give it a go.

Try this:

dd if=[FONT=monospace]/dev/block/mtdblock3[/FONT] of=/sdcard/system.img

You can check if the /system is mounted from /dev/block/mtdblock3 by typing "mount" first. You can also alter the "of" parameter to point to some other path where you want to save the file.

 

[DS_kid_9]

whats the progress of this custom ROM?