Custom Sylvania ROM development

[Rrok007]

I gotta second that donate button idea.... if your research leads to us being able to homebrew ROMs with the apks and functions that we want instead of what we're handed....

 

[natura]

system- ram- UO - LK on Stranges rom and ours (VIO we have same firmware based on your posted image earlier). I am not confident now that wine does work or if it was the hex it messed up. (If you want to know which -just let me know and I can test individually) Because after hours of no success in unpacking- I booted into windows and did it all first run to complete unpack.

Also, I love a solid stream of info in threads, Good info -should I be quiet again? LOL Might only be a few of you talking but the reading would be fabulous : )

Tidbit: http://forum.xda-developers.com/showthread.php?t=682828
[APP] Superuser 2.3.6.1 - I just straight installed the apk. Seems to be working great as it also logs what is happening. I have rebooted and encountered no troubles. (thinking it might be even more useful to those who know a lot LOL)

Tidbit:init.goldfish.rc file showing how they bypassed some other proprietary bootloader
http://forum.xda-developers.com/showthread.php?t=726813&page=23

 

[cfrockit]

However, there are still 8 bytes unknown (offset 24-31) which means that a IUS build using my app MIGHT fail to load.

vio, as you observed I did not identify these bytes. I was looking at the error/responses embedded in the *.ius file itself as possible leads to their meaning along with disassembling IUW.exe and /system/bin/infoup.

Here's the snippet of data in the all of the *.ius files that looked promising:

iuw (InfoTM Update Wrap tools)
[LIST]
[*]reginfo
[*]print register information
[*]Bad magic number
[*]Bad header crc
[*]Bad data crc
[*]Bad image type
[*]Empty Script
[*]Wrong image format for "source" command
[/LIST]

Four examples of offset 24-31 - First two images are other infoTM devices, 3rd & 4th are Sylvania.

 

[cfrockit]

4. Image entries have a simple structure:
- Start marker (constant)
- Image type
- First block in the image (multiply this value by 512 to find the image start position from the start of the file)
- Image size in blocks (multiply this value by 512 to find the size of the image in bytes)

[FONT=lucida console]    --------------------
  0 |                  |
    | Start marker     |   4 bytes, constant value: 57 75 49 00
  3 |                  | 
    |------------------|
  4 |                  |
    | Image type       |   4 bytes, integer: 00 00 00 00 --> 0 --> U0 (0=U0, 1=UBOOT , 2=RD, 4=LK, 7=ADR_USER, 9=ADR_AS)
  7 |                  |
    |------------------|
  8 |                  |
    |Image start       |   4 bytes, integer: 01 00 00 00 --> 1 --> 512 (multiply by 512)
 11 |                  |
    |------------------|
 12 |                  |
    | Image size       |   4 bytes, integer:  EC 01 00 00 --> 492 --> 251904 (multiply by 512) --> 246 kb
 15 |                  |
    --------------------
[/FONT]

A further inspection of the IUW.exe Version 1.2 revealed a reference to an embedded database - "f:\\IUW\\beifen\\iuw1.2\\release\\IUW.pdb"

Some of the entries relate back to the "Image type" above while the others reference the major "boards".

00 U0
01 UBOOT
02 RD
03 RD_
04 LK
05 NK
06 ADR_SYS
07 ADR_USER
08 ADR_NDISK
09 ADR_AS

10 wwe10d
11 wwe8c
12 p7901a
13 p0702
14 generic

0x0a ICK
0x0b ENV
0x0c LK_XIP
0x0d RD_XIP
0x0e IMG_XIP
0x0f UNDEF

 

[st0ne]

I think InfoTMIC should be doing the donating..... I could be wrong, but I think we have made more progress than they have.... I would really hate to think that they are giving up on the 7" Tabs to focus on the dev of the 10". But I think it's safe to say "Who needs them?" LOL
Great work guys! I just told my wife that I love being part of the "Nerd Culture!" She rolled her eyes... until she wants me to fix her Tab... BWAHAHAH!

 

[epeereboom]

Wow! You go away for a week and you miss so much. I'm going to have to start sitting down when my boy goes in for a nap and start contributing more.

Keep rocking and rolling! You guys are awesome.

Sent from my p7901a using Tapatalk

 

[vio]

Thanks for the new info on file header... it looks like my original guess is correct and the unknown bytes are some kind of checksum used to validate the consistency of the IUS file. I still have to find the correct way to calculate them, but at least it looks like there are 2 parts, one for header and one for data part.
For now, I'm attaching an updated version of the editor application. It allows adding and removing for images as well as saving the modified IUS file. You can also edit version info, magic number and checksum value. I had little time to test it, but it is at least consistent with itself - I have exported the "system" image, removed the image from IUS file, saved it, then added the image from the previously created "system.img" and the final file was binary identical with the original one.

PLEASE USE WITH CARE! I don't have a solution for computing the checksum bytes, as noted above, so the resulting IUS file might be deemed incorrect by the flashing application. Also, please note that I don't have too much validation code added, so you could technically create a IUS file containing 2 "U0" images, or some other invalid configuration. Try to avoid any "exotic" configurations if you decide to try to use it.

 

[tfurrows]

Here is a link I used recently for another project, calculates CRC using some common equations. The link also has some good into info on CRC calculation:

On-line CRC calculation and free library

If you can identify the data that belongs to the check bits/bytes and run it through a few of the common calculations, that would be a great place to start.

 

[cfrockit]

Here is a link I used recently for another project, calculates CRC using some common equations. The link also has some good into info on CRC calculation:

On-line CRC calculation and free library

If you can identify the data that belongs to the check bits/bytes and run it through a few of the common calculations, that would be a great place to start.

Good insight! This led me to review a U0 "u-boot-nand.bin" image extracted from a .ius update file which contains references to CRC32.

Header CRC32 do not match!!
Data CRC32 do not match!!

Attached is the readable ASCII from the U0 "u-boot-nand.bin" image for further examination.

zSYS.img

In the attached readable ASCII from the U0 "u-boot-nand.bin" image is a reference to a recovery image zSYS.img. When Applying a factory reset (three finger method) this image is burned to the device. It is still unknown where this zSYS.img is saved so that it could be pulled from a working tablet.

Getting recovery image ... 0:1 zSYS.img Recovery failed due to no available image is found.
 Try to recover from SD card.

Any insight to where the zSYS.img could be located and extracted?

 

[tfurrows]

Forgive me if some of what follows isn't up to speed with your efforts, I haven't been following too closely. I'm not sure what insights I could offer in zSYS.img that you guys haven't already discovered. However, I will ask:

Have you downloaded this file: Deposit Files
Mentioned here: http://bit.ly/mJE8gb

Inside, you'll find a version of zSYS.img for another device, which is some sort of a start I guess. In that file, you'll see the text "system.img.tmp" at the top. The zSYS.img file is about 76MB for that device.

Now, you seem to have already concluded that mtd2 is the recovery partition (resv). Have you dumped it with 'cat /dev/block/mtdblock2 > ./resv.img' or some such command yet, and examined it at all? Would you like a copy of mine (I have no idea what I'm looking at anyway)?

 

[cfrockit]

Forgive me if some of what follows isn't up to speed with your efforts, I haven't been following too closely. I'm not sure what insights I could offer in zSYS.img that you guys haven't already discovered. However, I will ask:

Have you downloaded this file: Deposit Files
Mentioned here: http://bit.ly/mJE8gb

Inside, you'll find a version of zSYS.img for another device, which is some sort of a start I guess. In that file, you'll see the text "system.img.tmp" at the top. The zSYS.img file is about 76MB for that device.

Now, you seem to have already concluded that mtd2 is the recovery partition (resv). Have you dumped it with 'cat /dev/block/mtdblock2 > ./resv.img' or some such command yet, and examined it at all? Would you like a copy of mine (I have no idea what I'm looking at anyway)?

tfurrows, sorry for the confusion and mixing of topics. It's sort of been a running commentary to discoveries specific to how infoTMIC has programmed these tablets.

I had not downloaded that version file for investigation but if it includes a "system.img.tmp" that's consistent with what is compressed in the *.ius InfoTM Update Wrap files. What was of interest to me was the reference to a zSys.img for Recovery, therefore a single backup system.img. When we've previously dumped mtd2 it was a complete *.ius InfoTM Update Wrap file which includes all the images U0, Ramdisk, Kernel, Userdata and system.img. Since manually updating to 2.2 every attempt at dumping mtd2 has resulted in just getting padding 0xffff thus I suspect that DG is burning a zSys.img as Recovery image differently than our manual update process. Other infoTM tablets have various approaches to recovery and are burning their updates as separate images (Expert burn) since that is what their supplier is providing. All we've had to work with are the complete *.ius files up till now given with vio utility we can now programmatically split into separate images. What is still unknown is where is this zSys.img stored on the tablet.

If you've dumped your mtd2 and it's a valid file the 128M file will open properly in the IUW.exe application. If it's all padding you will get a "bad magic" error.

What we would like to do is assist those users who receive the "Try to recover from SD card." when attempting to apply a factory reset. If we can identify where zSys.img is saved on a working tablet and we can dump it and then find the method to burn it to tablets that are missing a Recovery image, that would be of assistance.

The only method to recover from that situation now is the manually update. Thanks.

Update - thanks tfurrows for pointing in correct direction and vio for IusEdit_0.03.

User's encountering the "Try booting from SD ..." message when trying to a Factory reset (three finger method) can now with vio's application IusEdit_0.03 extract the ADR_AS image and save as zSYS.img. Then using IUW.exe in "USB mode:" "Expert burn" and checking SYSBACK can burn zSYS.img as the "Recovery image" needed to Apply a factory reset (three finger method).

 

[Rrok007]

So we're getting close huh?

 

[tfurrows]

My resv partition (mtdblock2) is exactly 128MB (134217728 bytes), and is definitely NOT padding (my "panic" partition, mtdblock7, is all FF padding though). I am uploading it now and will post the link here later tonight or tomorrow morning.

 

[tfurrows]

You can download my resv.img (mtdblock2 partition), from the following link.

SYTAB10MT
Hardware ID: 11.6.3.1
Kernel: 2.6.32.9
Android: DG2.2.1-10a2

mtdblock2 ("resv") image file: http://jozhaus.com/files/resv.img

It was retrieved simply by using 'cat /dev/block/mtdblock2 > ./resv.img' on my SD card. I have inspected it with Pspad HEX, nothing further.

 

[vio]

I've updated the editor with the new image types found by cfrockit (thanks). Plus, added the option to change the order of the images inside the file (it might be important) and a quick sort button that arrange images by type.
I also added a protection when adding images, so it is no longer possible to add more images of the same type.

In regards with checksum bytes, still no progress. I've run multiple algorithms (including a few CRC32 implementations) over both the header and the image part of the file, but the results are not close to the expected values.
The visual inspection of the "U0" image suggests that there is indeed a "header crc" and a "data crc", but so far I couldn't break the code.