Database Info

[TOOL] rkflashtool for Linux and rk2808, rk2818 and rk2918 based tablets

Hi,
Because I don't run Windows nor NetBSD, I rewrote rkflash from scratch with the use of libusb-1.0, so you can now read and write your rk2818-based tablet's flash memory under Linux (also w/o the need to root your tablet). Credit for reverse-engineering the protocol goes to the original author of rkflash (see source).
Small guide
- unzip the file
- compile
Linux (Debian, Ubuntu, ...)
Code:
sudo apt-get install libusb-1.0-0-dev
gcc -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall -s
Mac OS X (thanks to surfer63, binary here)
Code:
sudo port install libusb
gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall
Preparation
- powerdown your tablet
- disconnect all cables
To get into flash mode differs for many tablets. Google around or use trial and error
- insert the USB cable in computer
- hold vol+ (or put on/off/locked-switch in the locked position)
- insert the other end of your cable in the tablet
- wait a few seconds
- release vol+
Now if you run lsusb, the following line should appear:
Bus 001 Device 044: ID 2207:281a (290a for rk2918 based tablets)
Bus and device number may be different. The screen of your tablet stays black.
The USB device must be readable and writable for the user running rkflashtool. If that's not the case, you'll see an error like this:
Code:
$ ./rkflashtool b
libusb couldn't open USB device /dev/bus/usb/001/048: Permission denied.
libusb requires write access to USB device nodes.
rkflashtool: fatal: cannot open device
This can be fixed in several ways (chmod, run as root, udev rules) but that's beyond the scope of this posting. For now, chmod 666 the device mentioned in the error message.
Usage of rkflashtool
Code:
$ ./rkflashtool
rkflashtool: fatal: usage:
rkflashtool b reboot device
rkflashtool r offset size >file read flash
rkflashtool w offset size <file write flash
offset and size are in units of 512 bytes
On my tablet, the boot partition starts at offset 0x8000 (in blocks of 512 bytes)
Its size is 0x2000 blocks
To backup the partition, issue:
Code:
$ ./rkflashtool r 0x8000 0x2000 >boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: reading flash memory at offset 0x00008000
rkflashtool: info: reading flash memory at offset 0x00008020
.......
rkflashtool: info: reading flash memory at offset 0x00009fe0
To write a new boot.img or an old backup back to the device:
Code:
$ ./rkflashtool w 0x8000 0x2000 <boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: writing flash memory at offset 0x00008000
rkflashtool: info: writing flash memory at offset 0x00008020
.......
rkflashtool: info: writing flash memory at offset 0x00009fe0
You can find a list of all partitions of your tablet in the HWDEF file, which is inside the update.img for your tablet. If no such file is available, you can also look at /proc/cmdline on a running device (either through adb or a terminal app running on the device itself). Depending on the tablet, you might need root access to view /proc/cmdline. Another option is dumping the first 0x2000 blocks of nand flash by issuing rkflashtool r 0x0000 0x2000 >parm. View the file with hexedit, xxd, or a similar program. The kernel parameters contain a description of several mtd partitions (sizes and offsets).
After reading and writing at will, you can reboot your tablet by issuing
./rkflashtool b
Note that if your tablet has an on/off/locked-switch and it is still in the locked position, rebooting won't work.
If the file you are writing is smaller than the specified size, the rest is padded with zeroes. If it's bigger, it will be truncated. This is different from rkflash, which will overwrite blocks beyond the partition size.
rkflashtool does not support flashing a new bootloader directly.
If you have a different tablet, please try rkflashtool b and r first before flashing (w) something new.
Standard DISCLAIMER with regard to bricking your tablet applies.
Enjoy!
EDIT: better build instructions, clean up text
EDIT2: works on rk2918 tablets too (tested on Arnova 7 G2) if you change the USB product id from 0x281a to 0x290a before compilation
EDIT3: released version 2 of rkflashtool. now supports rk2918 tablets out of the box. if it doesn't find one, it falls back to rk2808/rk2818. also, updated the wording a bit.
EDIT4: new mac osx binary
EDIT5: more ways to find offsets and sizes of partitions on your tablet
EDIT6: small emphasis changes above and...
version 1 is here ONLY for archival purposes or if version 2 does not work on your rk28xx tablet. In all other cases, you need to download rkflashtool-v2.zip

Thanks a lot for this flash tool. I'm on MacOSX and Ubuntu and don't have Windows either. I tried the original rkflash as well but couldn't get it to work. On my Ubuntu boxes your rkflashtool compiles and works fine.
My Archos 7 HT V2 presents itself also as:
Code:
Bus 002 Device 004: ID 2207:281a
Reading partitions works fine and so does writing.
I did a quick modification of a system.img (left some files out) of my custom froyo rom and wrote it to my tablet.
That works fine. As /data is a separate partition I even have all my downloaded apps, data, settings, etc. This makes modifying a new rom much faster then building a complete update.img, flashing it, restore some data and then start testing.
Nice work.

great! finally I can remove one line from my todo list
thank you!
EDIT:
random notes (I don't see your code yet so it may be fixed, then sorry)
* I always specify b(reboot) for rk2818 tablets with my rkflash because it hanged easily if I try to write multiple times without b
* parameter file need to be converted with rkcrc -p. official RKAndroid tools flashed it 5 times with offsets. (read & check 1st 0x0-0x2000 block)
* I logged how to update bootloader, but it's complicated and I could not understand probably bootloader can be updated via misc partition. see update-script in update.img. (but not recommended/no reason to do it)
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.
on Windows, there is RKAndroidTool.exe (not batchupgrade). but "read" function in rkflash/rkflashtool may be useful on some case on Windows

Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.
Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.
About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools
Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.

ivop said:
About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools
Click to expand...
Click to collapse
probably you also need a needle to short pins of NAND chip
so I don't recommend to flash bootloader
ivop said:
Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.
Click to expand...
Click to collapse
I made that log several months ago with another windows machine which is not used lately. I'm not sure log is still exist... if I find it, I'll send it to you (but please don't expect)
probably you may also get log on Windows on VM on Linux. it seems VMware has log function (refer http://vusb-analyzer.sourceforge.net/tutorial.html) or there is "usbmon" function in Linux.
actually I didn't try this way myself so it may be wrong, sorry.

I've tryed a couple of firmwares, cooking my own.
Every time after flashing, tablet shows boot animation and after few seconds display becomes dark.
My investigation led me to following:
Log shows:
Code:
ERROR/Lights(865): write_int failed to open /sys/class/backlight/rk28_button_light/brightness
in /sys/class/backlight I found symlink (rk28_bl):
rk28_bl -> ../../devices/platform/rk28_backlight/backlight/rk28_bl
Shouldn't be there another symlink named r28_button_light ?
I'm using MANTA MID001 from Poland.

fun_ said:
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.
Click to expand...
Click to collapse
ivop said:
Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.
Click to expand...
Click to collapse
I did a couple of successive writes as well from ubuntu.
ivop said:
Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.
Click to expand...
Click to collapse
My main platform is OSX and I immediately added libusb. So far I have not been able to compile rkflashtool despite declaring all kind of CFLAGS, CXXFLAGS and/or LDFLAGS.
Trying a little bit more.

Could you post the compiler warnings/errors here? I might be able to help out.

ivop said:
Could you post the compiler warnings/errors here? I might be able to help out.
Click to expand...
Click to collapse
I managed to compile it. It took a lot of hurdles. I used the build environment I also use for Hugin for which I'm the OSX maintainer.
I now built a single combined 32/64bit (i386/x86_64) rkflashtool that will run on 10.4.x/10.5.x/10.6.x/10.7.x (building multi-architecture, multi-version binaries/libraries in one binary/library is possible on OSX. I'm not going to explain that here but it's a feature of OSX).
The compiled version is attached. You can also attach it to your first post if you like.
It works fine. I did some reading/writing of images without issues.

If you are on OSX and have macports installed, you can do the following to build rkflashtool.
Install libusb from Macports:
Code:
sudo port install libusb
cd into the folder where your rkflashtool.c is is and run the following command:
Code:
gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -W -Wall
This will build rkflashtool for your native environment (OSX version, hardware and config).
--- removed the rest of the post as well as the attachments. He/She who is interested in building a complete universal distributable rkflashtool can ask via this thread ---

UPDATE: Works on rk2918 tablet too
Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:
... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...
to
... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...
it'll work, except for rebooting the device if the tablet is still locked. To boot the tablet in bootloader mode, turn off the tablet completely, put the on/off-switch in the locked position and connect it to your computer. It should be visible now with lsusb. For further instructions, see first post. I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.

ivop said:
UPDATE: Works on rk2918 tablet too
Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:
... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...
to
... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...
Click to expand...
Click to collapse
Feature request :
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.

surfer63 said:
Feature request :
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.
Click to expand...
Click to collapse
I released a new version and updated the first post. It now tries to connect to an rk2918 tablet and if it doesn't find one, it falls back to rk2818.

The V2 version works fine too on MacOSX. The compilation is still the same for a "my machine only" version.
I compiled a universal Intel 32bit/64bit 10.4/10.5/10.6/10.7 V2 version as well.
See attached.
Note: I don't have a RK2918 so I can only test for a RK2818 tablet.

Hi,
Thanks for your thread it's very intersting.
I succeed flashing my boot partition with your tool but I don't success in remount,rw my system partition. It's cramFS and in init.rk28board.rc you can see those line :
Code:
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount cramfs [email protected] /system
mount cramfs [email protected] /system ro remount
I tried everything like replacing ro by rw, deleting the second line but my system stills in ReadOnly, don't understand why. I also tried deleting those lines to test if my flash process works properly and it's worked... So I'm lost. Any idea ?
----
Other thing, if I want to do same as flashing boot partition but with system partition is it possible with the same process ? Unfortunately I don't know the beginning offset of the partition. I don't know where to find HWDEF file. The size of partition is 00038000 (hex) bytes => 229376 (dec) bytes
Here is my /proc/mtd :
Code:
dev: size erasesize name
mtd0: 00002000 00000010 "misc"
mtd1: 00004000 00000010 "kernel"
mtd2: 00002000 00000010 "boot"
mtd3: 00004000 00000010 "recovery"
mtd4: 00038000 00000010 "system"
mtd5: 0003a000 00000010 "backup"
mtd6: 0003a000 00000010 "cache"
mtd7: 00080000 00000010 "userdata"
mtd8: 00534000 00000010 "user"
mtd9: 00020000 00000010 "pagecache"
mtd10: 00020000 00000010 "swap"
Thank you for your great job

My problem is solved. I was searching for a while but ivop gave the answer in a previous post
I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.
Click to expand...
Click to collapse
So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :
Code:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](user)
So system partition starts at E000 and has a length of 38000 (hex) bytes.
Thanks for your help this thread is now in my bookmarks
And really nice job with this flashtool

I pushed latest my rkutils to https://github.com/naobsd/rkutils
rkunpack can unpack RKFW image used in RK2918 ROM, RKAF image (update.img), KRNL/PARM image used in some single partition image. unpack will be done recursively.
rkcrc can make KRNL/PARM images with -k/-p.
rkafpack can make RKAF image. (I need to write docs/howtos...)
little off-topic,
latest RK2918 ROMs which is based on "SDK2.0", new format for boot.img/recovery.img is introduced. it's almost same as common boot.img format for android. unpackbootimg/mkbootimg can be used to unpack/repack it with one exception...
there is SHA1 hash value in header of boot.img (offset 0x240 bytes). Rockchip changes it by some unknown way. normal mkbootimg can't generate same hash value as Rockchip, so we can't make custom boot.img with new format
fortunately, we can split new boot.img, and we can make separate kernel.img and boot.img(ramdisk) like as pre-SDK2.0 RK2918 ROMs, which is loadable with new bootloader in SDK2.0 ROMs.
--
btw I just found interesting one: https://github.com/jhonxie/rk2918_tools

relsyou said:
My problem is solved. I was searching for a while but ivop gave the answer in a previous post
So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :
Code:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](user)
So system partition starts at E000 and has a length of 38000 (hex) bytes.
Thanks for your help this thread is now in my bookmarks
And really nice job with this flashtool
Click to expand...
Click to collapse
I'll add that to my first post. Also, you can view /proc/cmdline to see a list of partitions. It's part of the kernel command line.
Note that the lengths are not in bytes but in blocks of 512 bytes. This happens to be the same as the requirements of the rkflashtool btw (length in blocks).
As for having a writable system partition, currently the system partition is cramfs which cannot be written to. Ever. If you want a writable system partition, you need to change it to ext3 for example. That means unpacking fun_'s system.img and recreating it as an ext3 partition.
In short:
Unpack cramfs img with cramfsck -x (as root, so you preserve permissions and uid/gid)
Create an empty file the size of your system partition (dd if=/dev/null of=fubar.img bs=512 count=...... et cetera, do the math)
mkfs.ext3 fubar.img
mount -o loop fubar.img /someplacemountable
copy contents of old image to /someplacemountable (use cp -a to preserve ownership etc)
umount
flash fubar.img to system partition
change init.rk28board.rc to reflect the changes
reflash boot.img
reboot device
This is untested, but should work in theory.
Another option is to keep the system partition read-only and use unionfs to overlay a writable partition. I'm not sure if this can be a file on your userdata partition mounted with -o loop, but I suppose it can. This depends on your kernel having unionfs and loopback support though.

fun_ said:
I pushed latest my rkutils to https://github.com/naobsd/rkutils
Click to expand...
Click to collapse
Nice! I was thinking about creating an rkpack(tool ) myself, but I see it's not necessary anymore.

here is an example for rkafpack
Code:
$ rkunpack N3NET-2.3-20110722.img
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR]
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR]
MACHINE_ID:
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR]
unpacking 12 files
-------------------------------------------------------------------------------
00000800-00000fff [COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] 797 bytes
00001000-000017ff [COLOR="Red"][B]package-file:package-file[/B][/COLOR] 532 bytes
00001800-00021fff [COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR] 131700 bytes
00022000-000227ff [COLOR="Red"][B]parameter:parameter:[email protected][/B][/COLOR] 506 bytes
00022800-0002e7ff [COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] 49152 bytes
0002e800-0066bfff [COLOR="Red"][B]kernel:Image/kernel.img:[email protected][/B][/COLOR] 6541946 bytes
0066c000-006947ff [COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] 163844 bytes
00694800-008e8fff [COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] 2441220 bytes
008e9000-085fc7ff [COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] 131149828 bytes
----------------- [COLOR="Red"][B]backup:SELF:[email protected][/B][/COLOR] (N3NET-2.3-20110722.img) 140498948 bytes
085fc800-085fcfff [COLOR="Red"][COLOR="Red"][B]update-script:update-script[/B][/COLOR][/COLOR] 1294 bytes
085fd000-085fd7ff [COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] 266 bytes
-------------------------------------------------------------------------------
unpacked
$ rkafpack \
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR] \
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR] \
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR] \
[COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] \
[COLOR="Red"][B]package-file:package-file[/B][/COLOR] \
'[COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR]' \
[COLOR="Red"][B]parameter:parameter:[email protected][/B][/COLOR] \
[COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B][B]kernel:Image/kernel.img:[email protected][/B][/B][/COLOR] \
[COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]backup:SELF:[email protected][/B][/COLOR] \
[COLOR="Red"][B]update-script:update-script[/B][/COLOR] \
[COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] \
> new.img
$ sha1sum N3NET-2.3-20110722.img new.img
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826 N3NET-2.3-20110722.img
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826 new.img
some values are empty in RK2818 ROM.
--
here is how to make RKFW image
Code:
$ rkunpack N50-2.3-20111103-ZZ-SDK2.0.img
VERSION:2.0.3
unpacking
00000000-00000065 N50-2.3-20111103-ZZ-SDK2.0.img-HEAD 102 bytes
00000066-00022623 N50-2.3-20111103-ZZ-SDK2.0.img-BOOT 140734 bytes
00022624-0c342627 update.img 204603396 bytes
unpacking update.img
================================================================================
FIRMWARE_VER:0.2.3
MACHINE_MODEL:rk29sdk
MACHINE_ID:007
MANUFACTURER:RK29SDK
unpacking 10 files
-------------------------------------------------------------------------------
00000800-00000fff package-file:package-file 540 bytes
00001000-000237ff bootloader:RK29xxLoader(L)_V2.08.bin 140734 bytes
00023800-00023fff parameter:parameter:[email protected] 610 bytes
00024000-0002ffff misc:Image/misc.img:[email protected] 49152 bytes
00030000-006a3fff boot:Image/boot.img:[email protected] 6766592 bytes
006a4000-01167fff recovery:Image/recovery.img:[email protected] 11288576 bytes
01168000-0c31efff system:Image/system.img:[email protected] 186346496 bytes
----------------- backup:SELF:[email protected] (update.img) 204603396 bytes
0c31f000-0c31f7ff update-script:update-script 933 bytes
0c31f800-0c31ffff recover-script:recover-script 266 bytes
-------------------------------------------------------------------------------
================================================================================
00022624-0c342627 N50-2.3-20111103-ZZ-SDK2.0.img-MD5 32 bytes
unpacked
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-HEAD N50-2.3-20111103-ZZ-SDK2.0.img-BOOT update.img > new.img
$ md5sum new.img
[COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR] new.img
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-MD5
5191abc65649eacf8d2476e37d84a046
$ echo -n [COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR] >> new.img
$ sha1sum N50-2.3-20111103-ZZ-SDK2.0.img new.img
3120b13df8886e0ddfae0e35379443c27c925572 N50-2.3-20111103-ZZ-SDK2.0.img
3120b13df8886e0ddfae0e35379443c27c925572 new.img

Broken Webtop

During the weekend, I was testing few things in the webtop using Debian packages and I needed to use my backup image (I did it using dd) to restore the Webtop partition (/dev/block/webtop). The first time I used my backup, everything went fine and the Webtop was restored. But then I understand my mistake in the first trial and tryed install gcc again causing another brake in webtop. After that I restored one more time, but it stopped working.
From the point of view of the Linux system, it seens the problem is that it can't mount correctly the partitions. A df give me:
Filesystem Size Used Available Use% Mounted on
rootfs 1.3G 724.6M 587.0M 55% /
tmpfs 1.3G 724.6M 587.0M 55% /dev
devpts 1.3G 724.6M 587.0M 55% /dev/pts
sysfs 1.3G 724.6M 587.0M 55% /sys
df: /acct: No such file or directory
df: /mnt/asec: No such file or directory
df: /mnt/obb: No such file or directory
df: /dev/cpuctl: No such file or directory
df: /system: No such file or directory
df: /data: No such file or directory
df: /cache: No such file or directory
/dev/block/webtop 1.3G 724.6M 587.0M 55% /
df: /pds: No such file or directory
df: /preinstall: No such file or directory
df: /sys/kernel/security: No such file or directory
df: /mnt/sdcard: No such file or directory
df: /mnt/secure/asec: No such file or directory
df: /mnt/sdcard/.android_secure: No such file or directory
df: /mnt/sdcard: No such file or directory
df: /mnt/asec/com.quoord.tapatalkxda.activity-1: No such file or directory
And when I mkdir /mnt/secure/ or /mnt/sdcard/ it automaticly mounts /dev/block/webtop on it.
I can't even see any block device inside the webtop. A ls /dev/ gives me:
agpgart kmem midi1 ram1 ram9 stdout
audio loop0 midi2 ram10 random tty
audio1 loop1 midi3 ram11 rmidi0 tty0
audio2 loop2 mixer ram12 rmidi1 tty1
audio3 loop3 mixer1 ram13 rmidi2 tty2
audioctl loop4 mixer2 ram14 rmidi3 tty3
console loop5 mixer3 ram15 sequencer tty4
core loop6 mpu401data ram16 shm tty5
dsp loop7 mpu401stat ram2 smpte0 tty6
dsp1 mem null ram3 smpte1 tty7
dsp2 midi0 port ram4 smpte2 tty8
dsp3 midi00 ptmx ram5 smpte3 tty9
fd midi01 pts ram6 sndstat urandom
full midi02 ram ram7 stderr xconsole
fuse midi03 ram0 ram8 stdin zero
And I can't mount any loop device.
In the Android part, everything looks fine.
Anyone have any idea?
Thank you very much!
Cheers,
Luis.

Well, we will need more information before we can be of much help.
1) How were you able install gcc? Did you use my webtop hack, so that you can install using synaptic?
2) Were are you installing these deb packages from?
3) Are you sure you edited ONLY parts in the webtop partition and not the android filesystem? Both of them run a form of linux, and can be confused very easily if you are in the wrong directory, such as /etc and not /osh/etc.
4) Have you tried to flash just the webtop image from the fxz?
This is a good place to start the questions, so that we can be of more help here. Once you answer the above, I will know which way to go from here, hopefully.

jimbridgman said:
Well, we will need more information before we can be of much help.
1) How were you able install gcc? Did you use my webtop hack, so that you can install using synaptic?
2) Were are you installing these deb packages from?
3) Are you sure you edited ONLY parts in the webtop partition and not the android filesystem? Both of them run a form of linux, and can be confused very easily if you are in the wrong directory, such as /etc and not /osh/etc.
4) Have you tried to flash just the webtop image from the fxz?
This is a good place to start the questions, so that we can be of more help here. Once you answer the above, I will know which way to go from here, hopefully.
Click to expand...
Click to collapse
Thank you very much for your repply!
So,
1) I was not abble to install gcc from the repositories (from Ubuntu Maverick one). I always get an error installing the libc6. After I tracked the error to readlink it almost worked, I was only getting a error to move a file. But then I gave up and decided to wait for my sdcard arrive.
2) From the repositories. I tried the first time using Debian Squeeze repository and, after that, using Ubuntu Maverick one. I didn't use your hack because I was trying to learn what exactly brake compability with moto's packages.
3) That's a excelent question! In first place I really thought I was changing only the /osh partition, but I saw today that the /etc/ is actualy /osh/etc even for Android. So I changed things for Android too.
But in principle, this partition was restored when I dd it back to my backup.
4) No. Actualy I was looking for a FXZ image to do this. The only one I found Online was this: InlineFlashing_edison_5.5.175.16_cfc_p3_APBP_CID285.zip in Filefactory site, but I could not Download it yet due site limitations.
Thank you very much!
Cheers,
Luis.

lfgomez said:
Thank you very much for your repply!
So,
1) I was not abble to install gcc from the repositories (from Ubuntu Maverick one). I always get an error installing the libc6. After I tracked the error to readlink it almost worked, I was only getting a error to move a file. But then I gave up and decided to wait for my sdcard arrive.
2) From the repositories. I tried the first time using Debian Squeeze repository and, after that, using Ubuntu Maverick one. I didn't use your hack because I was trying to learn what exactly brake compability with moto's packages.
3) That's a excelent question! In first place I really thought I was changing only the /osh partition, but I saw today that the /etc/ is actualy /osh/etc even for Android. So I changed things for Android too.
But in principle, this partition was restored when I dd it back to my backup.
4) No. Actualy I was looking for a FXZ image to do this. The only one I found Online was this: InlineFlashing_edison_5.5.175.16_cfc_p3_APBP_CID285.zip in Filefactory site, but I could not Download it yet due site limitations.
Thank you very much!
Cheers,
Luis.
Click to expand...
Click to collapse
Ok, there are a few issues here.
1) try to restore the webtop image from the fxz. Go and grab the correct version of the fxz from here:
http://sbf.droid-developers.org/edison/list.php
Then unzip and cd into the directory and, make sure you have the moto-fastboot command, and that adb works:
Motofastboot:
32bit for windows:
https://dl.dropbox.com/u/45576654/moto-fastboot-win32.zip
put it somwhere in your path and open a command line and cd into the directory where you unzipped the fxz and run the following, this will take a bit of time to complete, once started (about 10 min):
Code:
adb reboot bootloader
moto-fastboot flash webtop grfs.img
moto-fastboot reboot
2) Now go run my hack, once you have your SDcard, the issue you ran into is that the webtop instance had MACLs and FACLs inplace, and any changes you make to ANY files can have a BAD effect. That is why my hack exists.
My webtop hack:
http://forum.xda-developers.com/showthread.php?t=1375042

jimbridgman said:
Ok, there are a few issues here.
1) try to restore the webtop image from the fxz. Go and grab the correct version of the fxz from here:
http://sbf.droid-developers.org/edison/list.php
Then unzip and cd into the directory and, make sure you have the moto-fastboot command, and that adb works:
Motofastboot:
32bit for windows:
https://dl.dropbox.com/u/45576654/moto-fastboot-win32.zip
put it somwhere in your path and open a command line and cd into the directory where you unzipped the fxz and run the following, this will take a bit of time to complete, once started (about 10 min):
Code:
adb reboot bootloader
moto-fastboot flash webtop grfs.img
moto-fastboot reboot
2) Now go run my hack, once you have your SDcard, the issue you ran into is that the webtop instance had MACLs and FACLs inplace, and any changes you make to ANY files can have a BAD effect. That is why my hack exists.
My webtop hack:
http://forum.xda-developers.com/showthread.php?t=1375042
Click to expand...
Click to collapse
Thank you very much!
I'm downloading now the image! I will restore it using your guide.
I will wait my SDCard to play more freely with the Webtop!
Again, thank you very much!
Cheers,
Luis.

Still broken webtop
Hi,
I tried to unlock the webtop, but I broken it.
Now I try to flash back the webtop, but I get following messages:
C:\Program Files\sdk\platform-tools>moto-fastboot flash webtop grfs.img
load_file: could not allocate 1400635392 bytes
error: cannot load 'grfs.img'
Seems to me that the webtop partition is to small for grfs.img (only 1GB space)
At the moment even HDMI out from my ATRIX2 do not show any response. :crying:

florescu said:
Hi,
I tried to unlock the webtop, but I broken it.
Now I try to flash back the webtop, but I get following messages:
C:\Program Files\sdk\platform-tools>moto-fastboot flash webtop grfs.img
load_file: could not allocate 1400635392 bytes
error: cannot load 'grfs.img'
Seems to me that the webtop partition is to small for grfs.img (only 1GB space)
At the moment even HDMI out from my ATRIX2 do not show any response. :crying:
Click to expand...
Click to collapse
Are you flashing a correct image? Double check.
Sent from my MB865 using Tapatalk 2

duchski said:
Are you flashing a correct image? Double check.
Sent from my MB865 using Tapatalk 2
Click to expand...
Click to collapse
I am using 2.3.6, systemversion 55.28.37.MB865.MERetail.en.06, Build 5.5.1-EDEM-28-37, and webtob WT-1.3.0-176. It is an ATT device.
I tryed the webtop image from
InlineFlashing_edison_5.5.175.25_cfc_p3_APBP.xml.zip
and
Returntostock2.3.5script.zip (edison-user 2.3.5 5.5.1-175_EDFFW1-16 5.51.175.16)
Both with the same error:
C:\Program Files\sdk\platform-tools>moto-fastboot flash webtop "\ATRIX2\Return to stock\grfs.img"
load_file: could not allocate 1400635392 bytes
error: cannot load '\ATRIX2\Return to stock\grfs.img'
C:\Program Files\sdk\platform-tools>fastboot flash webtop "\ATRIX2\Return to stock\grfs.img"
target reported max download size of 1056964608 bytes
Invalid sparse file format at header magi
Perhaps both version should be wrong? Where can I find the right one?

I was able to flash webtop via RDS light 6.0 using following script in InlineFlashing_edison_5.5.175.25_cfc_p3_APBP.xml and ndp.xml
<?xml version="1.0" encoding="UTF-8"?>
<flashing>
<header>
<phone_model model="EDISON" />
<software_version version="edison-user 2.3.6 5.5.1-175_EDMR1.25 5.51.175.25 release-keys2011-11-16 23:52 Off.Bld LUD_EDISON_R1D7_PATCH_36_111116_2336 crh1090280_M570_PC_CARD_RAIN" />
<interfaces>
<interface name="AP" />
</interfaces>
</header>
<steps interface="AP">
<step operation="flash" partition="webtop" filename="grfs.img" MD5="0f5c9e3fae804041d9f21a32b5c4179f" />
</steps>
</flashing>
It seems flashing without any error message.
But it sill not working ... no HDMI signal ...

After all I have to use the "Returntostock2.3.5script.zip" and reinstall my "MERetail-MEARET-55.28.37.zip" ROM and all apps.
Now webtop works and I will do a backup BEFORE I will try webtop2sd again ...

TF700T complete flash layout

I spent some time in analyzing of flash layout. The comprehensive description below attempts to map each byte of the flash and describes way to extract it.
I would be glad if somebody could provide more detailed info about bootloader, signatures, DRM etc.
Patches are welcome.
Code:
mmcblk0 layout
All dumps were done on Asus Eee Pad Transformer Infinity TF700T, 64GB version, firmware 9.4.5.26, locked
mmcblk0 off-partition section
Offset: 0 (0x0)
Size: 38273024 (0x2480000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0pre1.img bs=524288 count=73
Offset: 0 (0x0)
Size: 3670016 (0x380000)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s1.img bs=3670016 count=1
Process command: tr -d '\0' <mmcblk0pre1s1.img >mmcblk0pre1s1nz.img # mmcblk0pre1s1nz.img must be empty file
Offset: 3670016 (0x380000)
Contains: Recovery kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s2.img bs=524288 skip=7 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s2.img
mkdir mmcblk0pre1s2.img-ramdisk
cd mmcblk0pre1s2.img-ramdisk
zcat ../mmcblk0pre1s2.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 12058624 (0xb80000)
Contains: Regular boot kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s3.img bs=524288 skip=23 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s3.img
mkdir mmcblk0pre1s3.img-ramdisk
cd mmcblk0pre1s3.img-ramdisk
zcat ../mmcblk0pre1s3.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 20447232 (0x1380000)
Contains: Block of 16 bytes followed by 0x2de0 hexadecimal numbers followed by FF
Size: 12288 (0x3000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s4.img bs=524288 skip=39
Vital data:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss2.img bs=4096 skip=3
Binary part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch1.img bs=16 count=1
Hexadecimal part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch2.img bs=16 count=734 skip=1
Process command: unhex <mmcblk0pre1s4ss1ch2.img >mmcblk0pre1s4ss1ch2bin.img
FF part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch3.img bs=16 skip=735
Process command: tr -d '\377' <mmcblk0pre1s4ss1ch3.img >mmcblk0pre1s4ss1ch3nff.img # mmcblk0pre1s4ss1ch3nff.img must be empty file
Zeroes:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss1.img bs=4096 count=3
Process command: tr -d '\0' <mmcblk0pre1s4ss2.img >mmcblk0pre1s4ss2nz.img # mmcblk0pre1s4ss2nz.img must be empty file
Purpose: Probably encrypted bootloader
mmcblk0p1
Offset: 38273024 (0x2480000)
Size: 805306368 (0x30000000)
File system size: 196608 * 4096 = 805306368 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /system
Mount options: read only, extended attributes, ACL
Permissions: only root can manipulate
Contains: Base system and embedded applications
Purpose: Base system
mmcblk0p2
Offset: 843579392 (0x32480000)
Size: 448790528 (0x1ac00000)
File system size: 109568 * 4096 = 448790528 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /cache
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, UID system and GID cache can read and write
Contains: Cache
Purpose: Application cache
Note: The volume has the same UUID as mmcblk0p1
mmcblk0p3
Offset: 1292369920 (0x4d080000)
Size: 2097152 (0x200000)
File system size: 512 * 4096 = 2097152 (fully occupies partition)
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /misc
Referenced by: /system/lib/libandroid_runtime.so recovery ramdisk: /etc/recovery.fstab
Note: File system is referenced in recovery as emmc, not ext3!
mmcblk0p4
Offset: 1294467072 (0x4d280000)
Size: 855638016 (0x33000000)
File system size: 208896 * 4096 = 855638016
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /staging
Referenced by: recovery ramdisk: init.rc /etc/recovery.fstab
mmcblk0p5
Offset: 2150105088 (0x80280000)
Size: 5242880 (0x500000)
File system size: 5092 * 1024 = 5147488
Format: FAT32 file system, no partition table, MS-DOS "Non-system disk" boot block
Not mounted
Permissions: only root can manipulate
Contains: File system with files:
Serial numbers (ISN, PPID, SSN, UUID)
Calibration data (AL3010 light sensor, AMI304 magnetic sensor, KXTF9 motion sensor)
Purpose: Device specific unique system data, mounted as /btmac during Android boot
Referenced by: /system/bin/wifimacwriter /system/bin/brcm_patchram_plus /system/bin/sensors-config /system/bin/sixpair ramdisk: /init recovery ramdisk: /etc/recovery.fstab /init
mmcblk0p5 off file-system area
Offset in section: 5147488 (0x4e8b60)
Size: 28672 (0x7000)
Read command: busybox dd if=/dev/block/mmcblk0p5 of=/mnt/sdcard/mmcblk0p5s2.img bs=1024 skip=5092
Process command: tr -d '\0' <mmcblk0p5s2.img >mmcblk0p5s2nz.img # mmcblk0p5s2nz.img must be empty file
mmcblk0p6
Offset: 2155347968 (0x80780000)
Size: 524288 (0x80000)
Format: binary data
Permissions: UID drm can manipulate
Contains: 208 bytes of binary data, the rest are zeroes
Purpose: DRM, probably contains encrypted DRM key
Referenced by: /system/bin/wvdrmserver /system/vendor/lib/drm/libdrmwvmplugin.so
mmcblk0p7
Offset: 2155872256 (0x80800000)
Size: 5242880 (0x500000)
Format: empty
Contains: Zeroes
Purpose: Unknown
mmcblk0p8
Offset: 2161115136 (0x80d00000)
Size: 61415620608 (0xe4ca80000)
File system size: 14994040 * 4096 = 61415587840
Format: Linux ext4 filesystem
Mounted at: /data
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, read and write are directory specific
Contains: User applications, user data, and virtual internal SD card
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
mmcblk0p8 off file-system area
Offset in section: 61415587840 (0xe4ca78000)
Size: 32768 (0x8000)
Read command: busybox dd if=/dev/block/mmcblk0p8 of=/mnt/sdcard/mmcblk0p8s2.img bs=4096 skip=14994040
mmcblk0 off-partition section
Offset: 63576735744 (0xecd780000)
Size: 524288 (0x80000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0post8.img bs=524288 skip=121263
Process command: tr -d '\0' <mmcblk0p8s2.img >mmcblk0p8s2nz.img # mmcblk0p8s2nz.img must be empty file
Offset: 63576735744 (0xecd780000)
Offset in section: 0 (0x0)
Size: 507392 (0x7be00)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s1.img bs=507392 count=1
Process command: tr -d '\0' <mmcblk0post8s1.img >mmcblk0post8s1nz.img # mmcblk0post8s1nz.img must be empty file
Offset: 63577243136 (0xecd7fbe00)
Offset in section: 507392 (0x7be00)
Size: 16896 (0x4200)
Contains: EFI Partition table (partition names: APP, CAC, MSC, USP, PER, YTU, CRA, UDA)
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s2.img bs=512 skip=991
Purpose: Partition table
Total size of mmcblk0: 63577260032 (0xecd800000)
Notes:
can manipulate = can read, write partition vital data, only root can mount
can read, write = can read, write partition file system contents
Read commands are ran on the Transformer
Extract and process commands are run anywhere, with pre-read image file in the current directory.
You need dd with large files support. Vanilla dd on TF700T does not support large files. Busybox dd does.
Dropbox link to Asus_Transformer_Infinity_TF700T/flash_layout.txt

Wow, thanks for this detailed analysis - much more detailed than mine.
So what can I add to your research?
Tegra-based systems have another partition table, which has a proprietary layout and an unknown purpose (maybe just important for NVFlash and for flashing blobs?). Looking at the flash.cfg in the NVFlash package from AndroidRoot.mobi, we can get the Tegra partition layout and partition names:
Partition number 1 is missing in the list, maybe it contains the extremely well-hidden APX mode recovery code or even the answer to life, the universe and everything.
The following 3 partitions are located at the beginning of mmcblk0 and their contents are apparently encrypted with a device-specific key. For some reason, with ICS-based ROMs it reads as all zeros; in JB-based ROMs additional mmcblk0boot0 and mmcblk0boot1 partitions appear which together cover this area. The "bricksafe.img" in the nvflash guide covers these 3 partitions.
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
You already know the following 2:
5 SOS: Recovery kernel - 8388608 bytes
6 LNX: Linux kernel - 8388608 bytes
Then some more funny ones:
7 CER: I think this stands for "Certificate" and contains the bootloader unlock token. - 8388608 bytes. If I calculated correctly, this is at 0x1380000 into mmcblk0. Saved as "unlock-token.img" in the nvflash guide.
8 IMG: no idea what this is for - 8388608 bytes
9 GP1: space for a GPT partition table, maybe unused - 1048576 bytes
Now the regular partitions follow (p1 to p8):
10 APP: p1 = /system (Android OS)
11 CAC: p2 = /cache (for communication between Android and recovery)
12 MSC: p3 ="misc", whatever that is. On the TF101 it was used for bootloader commands.
13 USP: p4 = The update staging partition. Update blobs are copied here and flashed to the correct partition by the bootloader.
14 PER: p5 = device-specific config in a FAT filesystem
15 YTU: p6 = Apparently the DRM key. Confirmed to be overwritten with 0 by the unlocking process.
16 CRA: p7 = unknown (reserved for crash dumps?)
17 UDA: p8 = /data (Android user data)
And finally:
18 GPT: the EFI partition table that is actually used by the kernel

Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.

utx said:
Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
Click to expand...
Click to collapse
Yes, before unlocking I had something very similar to you there - a 16 byte header followed by some hexdump. I don't know what it was. It was overwritten by the unlock process with a 4 byte data block prefixed with a "-SIGNED-BY-SIGNBLOB-" header and followed by 256 bytes of what looks like a digital signature, very similar to the signed update blobs.
utx said:
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
Click to expand...
Click to collapse
Definitely back up the YTU partition before unlocking (p6) and then make the nvflash backups - but maybe the key must match something that is broken by the unlocking process, or it is renewed periodically, etc., so it might not help. Maybe try using DRM before unlocking and watch if the content of the partition changes over time.
utx said:
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.
Click to expand...
Click to collapse
Never tried to write directly to the block device - too scared to break something.
---------- Post added at 09:32 PM ---------- Previous post was at 09:28 PM ----------
Another small addition:
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
Click to expand...
Click to collapse
This FUSE trick also makes /mnt/sdcard case-insensitive.

I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?

ostar2 said:
I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?
Click to expand...
Click to collapse
How do you define "data recovery process"? You cannot recover data that has been overwritten.

_that said:
How do you define "data recovery process"? You cannot recover data that has been overwritten.
Click to expand...
Click to collapse
Well, if the DRM partition is write enabled, it may be possible to restore its contents, if you backed it up before unlock (it is probably per-device unique). But it could be insufficient. Locked bootloader can be different than unlocked bootloader, and may drop cipher needed for DRM decihering. It is just a theory. Somebody could proof it or falsify, if:
1) Backed all accessible data before unlock.
2) Unlocked (and to be safe, also made brickproof image).
3) Recovered the data creates in step 1.
Will DRM work then? Or did we need the contents of (currently inaccessible) locked stock data of the first megabytes?
But I see no way, how to back-up first megabytes of locked device (on ICS; JB is not as interesting for us, once you upgrade to JB, you cannot create brickproof image for nvflash).
I even don't know, which part of the subsystem causes these megabytes being reported as zeroes. Is it stock Asus ICS kernel? Is it bootloader? Is it a hardware lock on the flash device?

Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.

ostar2 said:
Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.
Click to expand...
Click to collapse
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works

_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.

firetech said:
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.
Click to expand...
Click to collapse
Oops, thanks for noticing. I edited my post.

what if we were to read from the NAND externally (RAW)....xbox 360 style...wouldn't that be the same as nvflash....
except that the three partitions in question are encrypted with a key that is probably unique per Tegra...
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
but I would suppose it wouldn't be a problem since a raw flash would restore everything back to normal...even if we can't read it..the CPU can..and that's all that matters.
---------- Post added at 11:21 AM ---------- Previous post was at 11:13 AM ----------
never mind...its a BGA

_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
Correct order maybe.
- get new TF700
- update to 9.4.5.26.
- root it using debugfs
- make a backup of /dev/block/*.*
- unlock (this erases mmcblk06 and voids warranty)
- install AndroidRoot hacked bootloader to make blobs for nvflash
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?

W3ber said:
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?
Click to expand...
Click to collapse
No way - the BCT, bootloader, etc. is not visible to the kernel at all (so it's not included in your images), and I don't know which kind of magic the blob creation tool uses, but I assume it's more than reading stuff from the nand.

Bricked pixel 3, need partition information

Well I was dumb and modified a single byte in "xbl_a -> /dev/block/sdb1" and "xbl_b -> /dev/block/sdc1" and then did these commands:
Code:
dd if=/sdcard/xbl_a.img of=/dev/block/bootdevice/by-name/xbl_a
dd if=/sdcard/xbl_b.img of=/dev/block/bootdevice/by-name/xbl_b
And now i am getting nothing but a black screen no matter what combinations of buttons I press...
No adb access and no fastboot access...
And it is only showing up as "Qualcomm HS-USB QDLoader 9008" in device manager in windows...
I was going to try and maybe flash the original xbl_a/b images with some qualcomm eMMC flash tool that I found but it seems that I need information about the partition layout of the device? Sort of like this but for the pixel 3.
Pixel 2 example:
Code:
+ fdisk -l /dev/block/sdb
Note: sector size is 4096 (not 512)
Found valid GPT with protective MBR; using GPT
Disk /dev/block/sdb: 8192 sectors, 32.0M
Logical sector size: 4096
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 4 entries
First usable sector is 6, last usable sector is 1018
Number Start (sector) End (sector) Size Code Name
1 6 1018 4052K 0700 xbl_a
And I was going to try and make my own rawprogram.xml file with as line like this:
Code:
<program SECTOR_SIZE_IN_BYTES="4096" file_sector_offset="0" filename="xbl_a.bin" label="modem" num_partition_sectors="900" partofsingleimage="false" physical_partition_number="0" readbackverify="false" size_in_KB="3598.0" sparse="false" start_byte_hex="??????" start_sector="????"/>
Could anyone please post the output of
Code:
fdisk -l /dev/block/sdb
and
Code:
fdisk -l /dev/block/sdc
For a stock pixel 3?
I believe that I need the sector start and end and sizes of the xbl_a and xbl_b partitions?
Like in the other post for the pixel 2
Thank you to anyone who can help.

download tool all in one. download factory image. flash factory image.

[TOOL] imjtool - Unpack and extract a variety of OTA images from various vendors

Hello All,
My Imjtool is now at version 1.6 , supporting MediaTek images, improving QCom FBPK (SD845 and onwards ".img"), DTBO (Device tree blob overlay) slicing, super.img (liblp logical partitions) and block based update images (system.transfer.list and ..new.dat) even when compressed with Brotli (.br) compression.
By now, there's support for quite a few formats, including proprietary QCOM FBPK, Huawei UPDATE.APP, and even UEFI containers:
Code:
/**
*
* Rudimentary Android image and partition unpacking tool
*
* v0.1 - Support unpacking of BootLoader and Boot images, as well as imgdata
* v0.2 - Supports offset= (for HTC and other boot.imgs where ANDROID! is wrapped)
* Supports cmdline= (to override kernel command line)
*
* v0.3 - Integrated mkbootimg functionality, added dt_size and id
*
* v0.4 - cmdline, addrs..
*
* v0.4.1 - Fix for Edvard Holst on Essential PH1 images.. (who uses Essential nowadays, I wonder?)
*
* v0.5 - Update with LZ4 binaries, fix for extract devicetree even if can't uncompress kernel
*
* v0.6 - Samsung images (with DT > 0) - Device Tree now found whereever it may hide
*
* v0.7 - system.transfer.list support
*
* v0.8 - FBPK (SD845 CrossHatch (Pixel 3 XL) bootloader images) AND Huawei Mate
* Also compiles cleanly
*
* v0.85 - system.transfer.list support for v4 (MTK 64 bit)
*
* v1.0 - EFI. Worthy enough a feature that (after three years) I hit version 1 on it, and - JCOLOR
*
* v1.1 - Samsung baseband images ("TOC") - 03/04/2020
*
* v1.2 - DTBO, super.img (03/20/2020) and integrated Brötli
*
* v1.2.1 - Lots of QCOM EFI GUIDs added. Thanks to anonymous contributor!
*
* v1.3 - Can now also pack super.img and boot.img based on existing!
*
* v1.4 - uBoot uimage format
*
* v1.5 - MTK images!
*
* v1.5.1 - Fixes: QCOM FPBK fixed (accidentally removed during refactoring around 1.3.. oops)
* UEFI now unpacks files by UI, if presenr, rather than GUID
*
* 1.6 - Peek into images to detect payload format
*
*
* platform-innovation-framework-for-uefi-complete-specifications-v0.90-v0.97 from Intel
* was invaluable for figuring out EFI
*
*
* This tool is part of the free downloads for the book
* "Android Internals: A Confectioner's Cookbook"
* But (as of v1.0) is also quite useful or MacOS T2 firmwares
*
* Author: Jonathan Levin, http://NewAndroidBook.com
*
* (New edition of Book and the loooong overdue Vol II coming soon! Check /TOC.html on site!)
*
* License: Use freely, BUT give credit where due. This way people learn of the website and books.
*
* If you have suggestions for improvement/new image types/etc - let me know and I'll gladly
* add them in.
**/
Totally free to use, feedback or requests appreciated.
Link: NewAndroidBook.com/tools/imjtool.html

Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images are stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?

err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Typhus_ said:
Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images ares stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?
Click to expand...
Click to collapse

morpheus______ said:
err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Click to expand...
Click to collapse
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.

Just making sure there - better safe than sorry, as, even with "critical partitions" unlocked, I can't vouch for your boot sequence not rejecting this - whether the ELF is valid or corrupt won't be the main risk - what will be is that the bootROM (or UEFI runtime) might reject this xbl as it won't be validly signed.
Still, it's an interesting challenge. I can get on it. I'll update, and you can always get me over DM.
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Typhus_ said:
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.
Click to expand...
Click to collapse

morpheus______ said:
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Click to expand...
Click to collapse
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.

There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Typhus_ said:
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" it will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.
Click to expand...
Click to collapse

morpheus______ said:
There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Click to expand...
Click to collapse
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.

yep.
NewAndroidBook.com/tools/imjtool.tgz is direct link.
Patching ELF might take me a while
J
Typhus_ said:
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.
Click to expand...
Click to collapse

How to repack super.img
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...

bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse
Update: I've found my answer: https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70

That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse

This is very helpful. Many thanks!
Chaser

Yeah great stuff... just used imjtool to extract abl.img and hunt for hidden fastboot commands.
This is an awesome tool!!!
Thanks a lot and best regards,
scholbert

morpheus______ said:
That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
Click to expand...
Click to collapse
Thank you for this tool!! I could also definitely use the ability to do this ^^^ with imjtool.

Unpacking/Repacking for Samsung S9
Hey, nice work, thank you!
I pulled the working boot.img from a Samsung Galaxy S9. I am just trying to unpack it, repack it and flash it back, and see it working (as a test, if that works I'll move to replace the kernel).
Your tool also extracts the DTB, which is great, abootimg didn't do that. However, when I repack like
Code:
imjtool.x86_64 make boot-repacked.img extracted/kernel extracted/ramdisk extracted/kernelimage extracted/devicetree.dtb
the result is only 38M large, the original is 55M, which seems already fishy. When I flash it anyway (using heimdall if it matters), it results in a bootloop.
So my questions are:
Am I using your tool wrong? Is the Samsung S9 not supported? Or is it a bug?
Another thing that puzzles me:
imjtool unpacks
Code:
devicetree.dtb kernel kernelimage ramdisk
abootimg unpacks
Code:
bootimg.cfg initrd.img zImage
So I know abootimg apparently misses the DTB (and "kernelimage" which is the .config used when the kernel was built) - But is your tool missing the info in bootimg.cfg (e.g. kernel command line?)
Thanks for your work/help!
This is what imjtool printed when extracting, in case it matters:
Code:
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 13352456
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
57.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x2534800
Found DT Magic @800

Hi Arcepth,
Odd; I have an S9 myself, and re-creating the image worked for me way back when I tried it. Could you do me a favor and send your boot.img? DM is fine.
The kernel command line should be taken from the boot.img, (the .cfg file abootimg generates is artificial). You can specify cmdline= to imjtool and it will embed that cmdline.
Samsung's odd with their device tree. They put it as the secondary, whereas others just fuse it to the kernel.
Any deviation from what Samsung expects will boot loop. I know this the very hard way
Anyway, DM me.

Using imjtool on S20 boot.img
I am having the same issue with Galaxy S20's "boot.img".
The original is ~60MB but after repack is ~38MB
-----------------------------Log---------------------------
root:/home/tools/imjtool# ./imjtool.x86_64 boot.img extract
Boot image detected
Part Size Pages Addr
Kernel: 37801996 18459 0x10008000
Ramdisk: 889691 435 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 2 bytes
ID: ##################################
Name: S##########
CmdLine: androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 16951272
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
62.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x24e7800
Unable to locate device tree
-----------------------------------End Log---------------------------------
My command for repack:
roothome:/home/tools/imjtool# ./imjtool.x86_64 make boot2.img extracted/kernel extracted/ramdisk extracted/kernelimage [cmdline='androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive'] [addr=0x10008000]
I didn't try to flash this though.

Thank you for the feedback! The tool is built around my use cases, but I don't get to experience all the crazy variants in image formats out there..
Anyway - I got this one: It took a bit to figure out but Samsung shoves a LOT of stuff after the DT which isn't part of the boot.img specification, as well as stuff which now is (AVB0) but I wasn't aware of when I started imjtool. So - I'm updating imjtool to handle this. I can already reliably detect and extract all their extras:
Code:
[email protected]öst (~/Documents/Android/src/Imjtool) %./imjtool ~/Downloads/boot.original.img
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
Found Samsung DTBH @0x2534800 with 6 trees
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x10-0x10
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x11-0x11
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x12-0x13
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x14-0x16
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x17-0x19
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x1a-0xff
DTBH block ends @0x26e9000
Warning: DT ends 0x26e9000, but filesize is 0x3700000 - looking further
Found [email protected]
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
And I'm working on finalizing a "repack" command which will use the base boot.img you provide and just enable the select overriding of portions or values.
Please try this build: http:// NewAndroidBook.com /tools /imjtoolbeta.tgz
You can use repack (base.img) and then change a variety of parameters. New image will be repacked.img in same dir.

Repacked size looks better now
Tried the beta and it looks much better! The "repacked.img" is much closer to the original size (I tried with a kernel built from official source code).
Only issue left is that ODIN fails to flash my created "boot.img.tar" file to the S20.
Just see a generic "RQT_CLOSE" message on ODIN.
Any clue what I'm missing? (already LZ4 compressed, tarballed with various methods, even disabled AVB)