Custom Sylvania ROM development

[natura]

First CFrockit a billion and one Thank Yous at least! I seldom log in but consistently when I drop in -your stilll here. Giving such valuable info to all on this tablet.

I was considering flashing the other rom. Recovery (?) and system (maybe only system) images being checked. Why wouldn't that work? Scary since our buttons do not match and would the iuw burn everything -even if only a couple boxes are checked.

Ok, so I obviously babble but I am soooooooo tempted. At any rate Thanks for so many of us are out here reading and DO appreciate all that you have contributed.

 

[disgostu9]

I broke my touch screen after sitting on it (stupid ass), so I decided to flash the system.img using expert burn. The results seemed to be successful, but I can't get past calibration to truly find out.

Not that i'm encouraging others to do this, as it could result in a brick! I'm just notifying developers of my experiences.

 

[vio]

I thought I would give a shot to .IUS file structure... my intention is to write an application that will be able to extract .img files from a .ius file and (hopefully) the other way around.


The first step would be "breaking" the .ius file structure in the logical components, so individual images can be identified. I based my investigation on posts from stragulus and cfrockit, and tried to extrapolate the missing parts.


What I found so far:


1. The .ius file are structured in blocks 512 bytes long (or 0200 in hexa). The first block is some kind of allocation table, followed by individual images:

[FONT=lucida console]  
    --------------------[/FONT]
[FONT=lucida console]  0 |                  |
[/FONT][FONT=lucida console]    | Allocation table |           [/FONT]
[FONT=lucida console]511 |                  |
[/FONT][FONT=lucida console]    |------------------|[/FONT]
[FONT=lucida console]512 | 1st Image        |
[/FONT][FONT=lucida console] .  |------------------|[/FONT]
[FONT=lucida console] .  | 2nd Image        |[/FONT]
[FONT=lucida console] .  |------------------|[/FONT]
[FONT=lucida console] .  |      ...         |[/FONT]
[FONT=lucida console] .  |------------------|                     [/FONT]
[FONT=lucida console] .  | Last image       |[/FONT]
[FONT=lucida console] EOF--------------------[/FONT]

2. The allocation table block is also composed by a header section (32 bytes long), followed by a list of entries (16 bytes long), one for each stored image:

[FONT=lucida console]    -------------------
  0 |                 |
    |    Header       |  
 31 |                 |
    |-----------------|
 32 |                 |
    | 1st Image Entry |
 47 |                 |
    |-----------------|
 48 |                 |
    | 2nd Image Entry |
 63 |                 |
 .  |-----------------|
 .  |                 |
 .  |     ...         |
 .  |                 |
511 -------------------
[/FONT]

3. The header is containing the following info:
- Start marker (constant)
- Magic number
- ROM version (broken in a few pieces)
- ROM size (file size minus 512 bytes)
- Number of images stored in the file
- CRC values

[FONT=lucida console]    --------------------
  0 |                  |
    | Start marker     |   4 bytes, constant value: 57 75 49 00
  3 |                  | 
    |------------------|
  4 |                  |
    | bmagic           |   4 bytes, bmagic value found in /proc/cmdline
  7 |                  |
    |------------------|
  8 |                  |
    |Major version     |   4 bytes, each byte is a number from version: 06 00 02 00 --> "2.0.6"
 11 |                  |
    |------------------|
 12 |                  |
    | # of img entries |   4 bytes, integer:  05 00 00 00 --> 5
 15 |                  |
    |------------------|
 16 |                  |
    |     ROM size     |   4 bytes, integer: 00 18 03 04 -> 67,311,616 (add 512 to find the actual size of the IUS file)
 19 |                  |
    |------------------|
 20 |                  |
    |Minor version     |   2 bytes, last part of version: 00 02 --> "2.0"
 21 |                  |
    |------------------|
 22 |                  |
    | Vendor id        |   2 bytes, vendor id: 0B 00 --> 11 --> Sylvania (Sylvania = 11, Disgo = 12)
 23 |                  |
    |------------------|
 24 |                  |
    |  Header CRC      |   4 bytes, CRC of the header itself (these 32 bytes, with bytes 24-27 set to 0)
 27 |                  |
    |------------------|
 28 |                  |
    |  Data CRC        |   4 bytes, CRC of the bytes following this header 
 31 |                  |
    --------------------         
[/FONT]

The CRC algoritm is using EDB88320 as polynomial (ZIP CRC), with FFFFFFFF as initial value and FFFFFFFF as final XOR value.

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]

 

[cfrockit]

I thought I would give a shot to .IUS file structure... my intention is to write an application that will be able to extract .img files from a .ius file and (hopefully) the other way around.


The first step would be "breaking" the .ius file structure in the logical components, so individual images can be identified. I based my investigation on posts from stragulus and cfrockit, and tried to extrapolate the missing parts.

vio, I can't express my excitement to your approach. The *.ius files have been successfully split into the various parts manually so many times in order to investigate the differences in versions, having a programmatic method would allow easier and a more proven way for many others to use.

The visualization of the structure you have provided is much clearer than my novice approach. The information in Header of *.ius (infoTM Update Wrap) IUW Version 1.0 which is related to your section "3. The header ..." can now be refined as additional information is contained in the Version 1.2 ini "initialization" files as to the Company and board configurations.

The initialization files included with IUW.exe Version 1.2 of the update tools provide insight to the naming nomenclature of the "FileNum:" (Firmware Version) contained in the header.

config_company.ini

None,0
InfoTM,1
Sawee,2
sylvania,11
Disgo,12

config_board.ini

Dev-board,0,0,1
P7901A,2,0,1
P7901B,2,0,2
P7901C,2,0,3
P7901D,2,0,4
P7901E,2,0,5
P7901UH,2,0,6
P7901UJ,2,0,7
P7901UI,2,1,8
P0702A,3,0,1
P0702B,3,0,2
I7Y,4,0,1
I10Y,5,0,1
WWE10A,6,0,1
WWE10B,6,1,2
WWE10C,6,1,3
WWE10D,6,1,4
WWE08A,7,0,1
WWE08B,7,1,2
WWE08C,7,1,3

Note: Some additional "hwver" have been identified but are not listed in this file.

Additionally, if you disassemble IUW.exe some of programmatic approach to how the "wrap" is utilized by the tool is evident.

Please keep up posted on your progress and any assistance you require in order to complete this project as it will not only aide us in being able to "wrap" our own custom updates but all InfoTMIC powered devices.

 

[st0ne]

Very nice..It's funny that I had just asked cfrockit to go over his research with me so I could help continue. You have given me a good shove in the right direction!
Once we can pull IMG files out of the IUS files easly we can compare hwvr differences in the software and start to patchwork a ROM together.
All in all a great effort on your part VIO!!!

 

[vio]

Great info... thanks for the updated IUW burner (1.2). The new INI files confirm our guesses about device and vendor info. This time, the "Company" and "Board" fields are no longer displaying "error", but rather valid info.
While there are still unknown parts in the file header, the information we have so far should be enough to build an application able to "peek" inside the IUS files.
So, it is the time to put the theory to test:



That's my first iteration for (ideally) a fully functional IUS editor. It's just displaying the info about the contained images (on botton - first two columns are relevant, the rest are for testing purposes) and the header content (on top - again, left side is relevant, right side is for debugging/testing purposes).
The first results look promising - I was able to load all the images that were available to me and the displayed values looked identical with what the "IUW.exe" is displaying.

Next step would be to add some "extract" functionality to the application - so we'll be able to extract a specific image from the ROM and to save it to disk. If we are correct in our assumptions - that images are just dumped in the IUS file, without any additional processing - then it should be pretty simple to implement.
I would welcome anyone who can help me in this next step - we will need to test if the extracted files are valid: first by comparing them to some images extracted "manually". After that, if somebody is brave enough to try to burn them via "Expert burn" feature, we could really test the validity of this approach.

PS. I don't see the option to "thank" to the previous posters - maybe something with my browser - so I will just say it: Thanks to cfrockit and to everybody else who contributed to this.

 

[john allison]

To Cfrockit and all those who contributed and helped me with my sylvania synet7lp I appreciate the benefit of your experience and all your help...
I think I went as far as I could go with the sylvania tablet...I just bought the samsung galaxy tab 10.1 and many of the problems I had are solved... however I am using a netgear wireless modem I bought for a laptop 5 years ago and it is giving me some connection issues.. I wonder if you could suggest a better brand of wireless modem I could get that would work better ? thanks again
John Allison
[email protected]

 

[Rrok007]

Great info... thanks for the updated IUW burner (1.2). The new INI files confirm our guesses about device and vendor info. This time, the "Company" and "Board" fields are no longer displaying "error", but rather valid info.
While there are still unknown parts in the file header, the information we have so far should be enough to build an application able to "peek" inside the IUS files.
So, it is the time to put the theory to test:

View attachment 2868

That's my first iteration for (ideally) a fully functional IUS editor. It's just displaying the info about the contained images (on botton - first two columns are relevant, the rest are for testing purposes) and the header content (on top - again, left side is relevant, right side is for debugging/testing purposes).
The first results look promising - I was able to load all the images that were available to me and the displayed values looked identical with what the "IUW.exe" is displaying.

Next step would be to add some "extract" functionality to the application - so we'll be able to extract a specific image from the ROM and to save it to disk. If we are correct in our assumptions - that images are just dumped in the IUS file, without any additional processing - then it should be pretty simple to implement.
I would welcome anyone who can help me in this next step - we will need to test if the extracted files are valid: first by comparing them to some images extracted "manually". After that, if somebody is brave enough to try to burn them via "Expert burn" feature, we could really test the validity of this approach.

PS. I don't see the option to "thank" to the previous posters - maybe something with my browser - so I will just say it: Thanks to cfrockit and to everybody else who contributed to this.

What's the probability of Hardbricking versus softbricking?

 

[natura]

So, it is the time to put the theory to test:

View attachment 2868


PS. I don't see the option to "thank" to the previous posters - maybe something with my browser - so I will just say it: Thanks to cfrockit and to everybody else who contributed to this.

I didn't see a place to thank you on this post today! Thank YOU. You have been amazing...can't wait to see what you will post next,

 

[cfrockit]

Next step would be to add some "extract" functionality to the application - so we'll be able to extract a specific image from the ROM and to save it to disk. If we are correct in our assumptions - that images are just dumped in the IUS file, without any additional processing - then it should be pretty simple to implement.
I would welcome anyone who can help me in this next step - we will need to test if the extracted files are valid: first by comparing them to some images extracted "manually". After that, if somebody is brave enough to try to burn them via "Expert burn" feature, we could really test the validity of this approach.

PS. I don't see the option to "thank" to the previous posters - maybe something with my browser - so I will just say it: Thanks to cfrockit and to everybody else who contributed to this.

Again, another significant step forward! Congrats, vio!

Binary file comparison of some or all of the manually extracted images is not an issue once your tool is available for testing. "Expert burn" has worked flawlessly when using the appropriate manually extracted images. It was only when you mix and match randomly that you encounter the dreaded "white out" screen meaning hard brick with no hope of recovery.

Not sure which browsers are showing the "Thanks" (thumbs up) in the lower left corner of the post but all of the thanks is appreciated.


OK, Now to pile on with more information regarding the update process and utilities.

In /system/bin "infoup" is an executable ELF file utilized in the automatic update process.

$ file infoup
infoup: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

It seems to have three ways to use -

#infoup inject <path to and file name of *.ius>

#infoup clear

#infoup reboot

Invoking the command without these parameters produces the following output leading us to the belief that mtd2 "resv" was recovery containing the RAW data of the *.ius file.

#infoup
 Partition: /dev/mtd/mtd2
Size: 134217728

The following is executed during the automatic update process followed by "clear' and then finally "reboot".

infoup inject /local/system.ius

The ELF dump of infoup shows the following Functions:

Symbol table '.dynsym' contains 36 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000864c     0 FUNC    GLOBAL DEFAULT  UND putchar
     2: 00008658     0 FUNC    GLOBAL DEFAULT  UND ioctl
     3: 00008664     0 FUNC    GLOBAL DEFAULT  UND printf
     4: 00008d68     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_end
     5: 00000000     0 OBJECT  GLOBAL DEFAULT  UND __stack_chk_guard
     6: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_unwind_cpp_pr0
     7: 0000916c     0 NOTYPE  GLOBAL DEFAULT  ABS _bss_end__
     8: 00009164     4 OBJECT  GLOBAL DEFAULT   18 nand_size
     9: 00008670     0 FUNC    GLOBAL DEFAULT  UND puts
    10: 00009164     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start__
    11: 0000867c     0 FUNC    GLOBAL DEFAULT  UND fflush
    12: 00008d48     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_start
    13: 00008688     0 FUNC    GLOBAL DEFAULT  UND lseek
    14: 00008694     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail
    15: 000086a0     0 FUNC    GLOBAL DEFAULT  UND __reboot
    16: 000086ac     0 FUNC    GLOBAL DEFAULT  UND __libc_init
    17: 000086b8     0 FUNC    GLOBAL DEFAULT  UND write
    18: 0000916c     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_end__
    19: 000086c4     0 FUNC    GLOBAL DEFAULT  UND setgid
    20: 000086d0     0 FUNC    GLOBAL DEFAULT  UND read
    21: 00000000     0 OBJECT  GLOBAL DEFAULT  UND __sF
    22: 00009164     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
    23: 000086dc     0 FUNC    GLOBAL DEFAULT  UND __aeabi_uidiv
    24: 0000916c     0 NOTYPE  GLOBAL DEFAULT  ABS __end__
    25: 000086e8     0 FUNC    GLOBAL DEFAULT  UND strcmp
    26: 00009164     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
    27: 0000916c     0 NOTYPE  GLOBAL DEFAULT  ABS _end
    28: 000086f4     0 FUNC    GLOBAL DEFAULT  UND exit
    29: 00009168     4 OBJECT  GLOBAL DEFAULT   18 blk_size
    30: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_unwind_cpp_pr1
    31: 00008700     0 FUNC    GLOBAL DEFAULT  UND open
    32: 00080000     0 NOTYPE  GLOBAL DEFAULT  ABS _stack
    33: 00009164     0 NOTYPE  GLOBAL DEFAULT   18 __data_start
    34: 0000870c     0 FUNC    GLOBAL DEFAULT  UND setuid
    35: 00008718     0 FUNC    GLOBAL DEFAULT  UND close

Some assumptions can be made from these as to check of "nand" and the unpacking of the various images but a programmer/developer could provide better insight as to the value of this information.

Congrats again, just piling on anything related to the update files and process.

 

[vio]

As promised before, I continued with my pet project - the Ius Editor. Adding the "extract" functionality was relatively simple, as expected. I have attached the editor application, if anyone wants to try it.

My testing was not extensive, but I was able to extract a some .img files. I decided to check a ramdisk.img file, since it seems the simplest structured partition. I used dd to remove the 64 bytes header, gzip to uncompress it and cpio to extract the files... everything went pretty smooth.

Like I said, I would appreciate any help with testing the application, in order to identify implementation errors. If the actual implementation proves functional, I can continue with adding more functionality.

 

[cfrockit]

Like I said, I would appreciate any help with testing the application, in order to identify implementation errors. If the actual implementation proves functional, I can continue with adding more functionality.

Fantastic effort!

Worked as described - File > Open - select .ius.
-

-
Selecting the ADR_AS row then clicking on the "Shopping Cart" icon or "Export (CTRL +E)" which performs "Export an image".
-



The "Save As" dialog prompted me to save allowing me to enter a "File name:" and "Save as type:" "IMG files".
-


The saved system.img was a uImage file having a 64-byte u-boot header starting with 0x27051956.

Following the first 64-bytes is the gzip header, which always starts with the byte-range 0x1F8B08. Cutting the header and then uncompressing produces system.img.tmp.
-

-
This image can then be unpacked manually using unyaffs-4k or programtically using the "HTC Android Kitchen 0.157 - by dsixda (xda-developers.com)".

Output of "1 - Set up working folder from ROM" - HTC Android Kitchen 0.157

Creating working folder WORKING_062211_155053 ...
Copying boot.img and system.img ...

Adding an update-script ...

Chunk size is 4096 bytes in system.img
Spare size calculated to be 128 bytes
Setting chunk size = 4096 in unyaffs.c, line 20
Setting spare size = 128 in unyaffs.c, line 21
Compiling unyaffs ...
unyaffs successfully compiled

Extracting contents of system.img ...

-


Successful unpacking *.ius, cutting uImage header, umcompressing, unyaffs of system.img resulting in structure of /system for modifying.

Post any comments/questions.

 

[cfrockit]

vio's effort has now made it possible to extract the system.img from the latest update files for the 10" Sylvania SYTAB10MT. Numerous attempts to manually extract, uncompress and finally unyaffs and image had all failed until now.

IusEdit_0.02 "IusEdit.exe" works for exporting images from a InfoTM Update Wrap (*.ius) multi-part update file.

Using IusEdit_0.02 "IusEdit.exe" the ADR_AS image was exported from 11.6.1.5.2.0_beta4_0523.ius.

The uImage header was cut, the resulting image was the unzipped expanding the system.img which was then unpacked using unyaffs.

Output from "HTC Android Kitchen 0.157 - by dsixda (xda-developers.com)"

Creating working folder WORKING_062211_224005 ...
Copying boot.img and system.img ...

Adding an update-script ...

Chunk size is 4096 bytes in system.img
Spare size calculated to be 128 bytes
Compiling unyaffs ...
unyaffs successfully compiled

Extracting contents of system.img ...

Looking for symbolic links under /system/bin ...
They will now be added to the update-script and removed from system/bin

Looking for symbolic links under system/xbin of working folder ...
None detected

Found ./system/xbin/su
Moving system/xbin/su to system/bin/su

Updating update-script with su entry and symbolic link

Listing of WORKING_062211_224005:

total 8
drwxr-xr-x+ 1 Owner None    0 Jun 22 22:40 META-INF
-rwxr-xr-x  1 Owner None 6144 Jun 22 22:40 boot.img
drwxr-xr-x+ 1 Owner None    0 Jun 22 22:40 system

Finished setting up working folder!

NOTE: If you wish to add radio.img, place it under the root of the
working folder.  When you build the ROM, the update-script will be
automatically modified to account for the presence of the radio.img.

Would you like to view this ROM's info (y/n)? (default: y):

Working folder information

 Android OS version             : [B]2.2[/B]
 Device                         : [B]wwe10[/B]
 Model                          : [B]wwe10[/B]
 ROM Name                       : FRF85B
 Rooted (unsecured boot.img)    : UNKNOWN
 Rooted (Superuser.apk + su)    : NO
 BusyBox installed              : YES
 BusyBox run-parts support      : NO
 Apps2SD (Apps to EXT) enabled  : NO
 /data/app enabled              : NO
 Custom boot animation allowed  : NO
 Nano text editor installed     : NO
 Bash shell support             : NO
 /system/framework is deodexed  : YES
 /system/app is deodexed        : YES
 radio.img found                : NO
 ROM will wipe all data         : NO

Selected output of Settings.apk > DeviceInfoSettings.smali using android-apktool - A tool for reengineering Android apk files

    .line 63
    const-string v9, "[B]firmware_version[/B]"

    const-string v10, "[B]DG2.2.1-10a1[/B]"

    invoke-direct {p0, v9, v10}, Lcom/android/settings/DeviceInfoSettings;->setStringSummary(Ljava/lang/String;Ljava/lang/String;)V

    .line 65
    const-string v9, "[B]device_model[/B]"

    const-string v10, "[B]SYTAB10MT[/B]"

While vio's tool currently only extracts the image from the multi-part update wrap file (*.ius) it does is programmatically thus correctly allowing for the removal of the uImage header, extracting the archive, and then unpacking the image using unyaffs for inspection.

Congrats on the great effort.

 

[vio]

Thanks for the feedback. It seems that image extraction is working fine, so I started to look into actual editing of the IUS files. Since we're still missing a few header fields, this part will be more trial-and-error...
Anyway, the good news is that I figured out another header field: bytes 16-19 are actually an integer value representing the file size (ignoring the size of the header, which is 512). I can't believe I missed that, seems so obvious now... Also, I added the info about bmagic number found by cfrockit to my previous "file structure" post - looks like I missed that before.
However, there are still 8 bytes unknown (offset 24-31) which means that a IUS build using my app MIGHT fail to load.
I'm working on the "save" functionality of the editor right now, which will allow to add/remove images from a IUS file. I'm also considering adding some additional processing on extraction (like removing the header and uncompressing images), but these parts can already be performed by other tools.

 

[natura]

Don't consider- DO heheheOH MY you can incorporate the other tools would be fantastic for dummies like me -pretty sure there are many like me. I now have suse linux and windows and VB. I personally just get overwhelm.. right now.. I think I have to boot into windows to use unyaffs. (I am sure I don't actually. just haven't figured out how to do it in linux yet. )
Your program also seems to work well in wine.

Also with what your doing..may I suggest getting a donate button.