Database Develop

aWizard "ERROR: ITWriteDisk - An internal error occurre

Code:
3 partitions, 2 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 38 1b 01 01 35 3a 02 3f 11 0b 05 24
CopyFileToTFFS(SplashBMP\splash-temp.bin:0, 2d0000, 0002581e)
ERROR: ITWriteDisk - An internal error occurred.
I get this when trying to use the "c" option to install a splash screen, also when I try the "s" option to restore a backup splash screen, and when I use the "splash_bmp_to_wizard.exe" (i think it just uses awizard anyway, so no surprise there). Does anyone know the solution or have the same problem?
It worked just fine on my stock 8125, this is only since the ROM 2.17 upgrade.
Please check it out, Later; Lew

Lew,
currently there is no way to change the splash screen on 2.x.
I hope they get this working soon though... i don't care for the HTC logo, Qtek's isn't bad, but I would rather have 1 logo rather than 2 anyway.

Moving this thread here
http://forum.xda-developers.com/viewtopic.php?t=44411
Please post all replys there.
Thanx; Lew

Extracting the CID and Coutry code out of a nbh and matching to the device

When looking at RUU_signed.nbh extracted out of RUU_BlackStone_HTC_WWE_EastEurope_1.14.479.3_Radio_52.49a.25.26_1.09.25.14_Ship
I find at
00 00 00 00 40h BLAC10000
00 00 00 1e 0hh HTC__032
00 00 00 20 00h 1.14.479.3
00 00 00 21 10h USA
It looks like the ModelID, CID, Rom Version and the Country code.
How can I find out what those values are of my device so that I can match a shipped rom with it ??

Model ID should be under the battery.
Have you tried using ATCommander to query the CID with the:
[email protected]? command?
Ta
Dave

MDAIIIUser said:
When looking at RUU_signed.nbh extracted out of RUU_BlackStone_HTC_WWE_EastEurope_1.14.479.3_Radio_52.49a.25.26_1.09.25.14_Ship
I find at
00 00 00 00 40h BLAC10000
00 00 00 1e 0hh HTC__032
00 00 00 20 00h 1.14.479.3
00 00 00 21 10h USA
It looks like the ModelID, CID, Rom Version and the Country code.
How can I find out what those values are of my device so that I can match a shipped rom with it ??
Click to expand...
Click to collapse
could perhaps help cmonex, when she has gained enough...

DaveShaw said:
Model ID should be under the battery.
Have you tried using ATCommander to query the CID with the:
[email protected]? command?
Ta
Dave
Click to expand...
Click to collapse
No I did the old approach based on the blueangel.
Here flashing software gave you a getdevicedata.exe so I had a look at an extracted HD_ship.exe and found RUUGetInfo.exe.
So I put it on my device, ran it and sorted my windows dir by date.
I found:
RUUImei.txt ---- > contains the IMEI of my device
RUUInfo.txt-----> Gives me the same info the rom version under Divice info

here is how
gd day
here is how
put your phone into boot loader model by pressing power and volume down till 3 color s screen comes.
in active sync right click the mouse and go into connection settings and move the v from allow us connection
connect your phone and run mtty software
http://rapidshare.com/files/173474965/mtty_0513.zip.html
after your install it just go in and chose usb instead of com port
when its open press one time enter and you can see answer back cmd>
then key in cmd2
u can see the details
gd luck

he means "info 2" for CID.
but DaveShaw is right too.
anyway. it won't flash that way without hardspl.

MDAIIIUser said:
00 00 00 00 40h BLAC10000
00 00 00 1e 0hh HTC__032
00 00 00 20 00h 1.14.479.3
00 00 00 21 10h USA
Click to expand...
Click to collapse
What if I change cid in that nbh file? To match cid of my device. Will I be able to flash that rom?

lipa47 said:
What if I change cid in that nbh file? To match cid of my device. Will I be able to flash that rom?
Click to expand...
Click to collapse
Unless you can sign the NBH file with the Private Key of the Carrier (or whoevers signs them), you won't have much luck.
The HardSPL is patched so it doesn't check the signature on the file.
Ta
Dave

Now that is cool
Here is a working link
http://wiki.xda-developers.com/uploads/mtty.exe
So do we know the other codes for the rest of the stuff I found in the nbh ??

May I know that the CID will be changed or not if the hardspl is install? As I know, HTC will check the CID if it is taken for repair, and they will not repair if the CID is not valid.

CID will not be changed. Hard-spl only bypasses checking CID, signature, overwriting spl etc.

It means that there is a CID stored in the phone and also in the ROM file so that the SPL will check between them during ROM upgrade. If it is that case, is there any means to change the CID & country code stored in the phone?

Yes it is but is not available for HD at the moment.
Anyway hard-spl is bit better method because you can flash custom roms, radios only etc.
If you only change cid you can only flash HTC signed roms.

Determine CID from mtty 'info 2' output
Hi guys,
If you consider this useful keep it if not delete it ...
When issued the 'info 2' command, I got:
Cmd>info 2
Card inserted
SD clk rate 19MHz
Cmd5 CMD_TIMEOUT
SD clk rate 144KHZ
SD 2.0 HC card
SD Clk rate 24 MHz
SD Init OK
-- The
Card inserted
...
SD Init OK
-- was repeated 2 more time.
HTCSHTC__032ðúÔ•HTCE
Cmd>
Then it was not clear for me which was the CID. But http://wiki.xda-developers.com/index.php?pagename=Hermes_BootLoader was quite useful. It is stated "Returns "HTCS" + CID + (4-byte checksum) + "HTCE"" so I presume the CID is 'HTC__032'. HTCS/HTCE (Start/End) seems to be only control strings.
As written on the mentioned page 'info 4' would have shorter output and still providing the CID.
Thanks for the good doc.

[Samsung GT-S5570] my experiments - call for experts contributions

Hi all,
Here I'll describe every Hack/Mod/Discovery i'll do on my phone,
the Samsung Galaxy Next/Mini/Pop GT-S5570.
ASSUMPTION : I will not install CWM.
I've already made some experiments, and bricked the phone...
... but i'm still going on.
I'll log every step i made - while expecting a repaired device from service.
Every suggestion from other experience are welcome!

Summary & Status
--------------------------------------------------------------------------------------------------
This is the summary/status of the work i made - direct on the phone (Configuration, APKs, Mods, ...)
1) Root the phone AND ADB demon. [post 3]
2) Add Essential APKs. [post 3]
3) Remove/Replace Stock applications. [post 6]
4) Got a personalized Restore. [post 6]
5) my device is back, with new GB ROM ... and personalized /system. [post 58]
--------------------------------------------------------------------------------------------------
This is the summary/status of every experiment i do with the ROM ...
1) use of ADB and related tools. [post 7]
2) backup copy of /system folder [post 7]/URL]
3) dump of partitions. [URL="http://forum.xda-developers.com/showpost.php?p=17900113&postcount=7"][post 7]
4) extract the list of partitions. [post 8]
Analizing the dumped files...
5) the dumped images can be flashed with odin !!! [post TODO]
6) extract the /system filesystem. [post 9]
7) extract the boot & recovey images. [post 12]
8) after extracting boot images...rebuild them (thanks to Doc_cheilvenerdi.org ) [post 32] and [post 40]
9) add ext4 FileSystem and busybox! (thanks to Doc_cheilvenerdi.org ) [post 44]
10) moved /data to SD !! (thanks to Doc_cheilvenerdi.org ) [post 50] and [post 52]
after explaining here how to modify the boot.img, Doc_cheilvenerdi.org wrote some exellent guides to describe his methods to to add ext4 support and move /data to SD and then move /system to SD. He also guides you in hacking the initial logos and animations and gaining root privileges on every ROM(here the IT source). Since he's not only a master in hacking and developing, but he explain it all, this 3ds are a must read !!​Only... they're in italian languages... (need help in translation, please)​
ToDo
...) share my PC connection to device (Reverse-Tethering) - investigation starts in [post 59]
...) understand and investigate init*** files in ramdisk ( apart from init.rc, when are they started? what they'll do ?).
...) understand and investigate the APK install process
...) understand and investigate the android framework.
...) move /data/apps/ /data/data and /data/dal***-cache to SD (should be simple, after Doc effort !!)
...) load and adapt my dumped images to androind_x86 (porting to PC/VM of android) [post ...]
--------------------------------------------------------------------------------------------------
>>> OPENED QUESTIONS <<<
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
please see also my considerations in [post27]
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
please see also my considerations in [post27]
5) what are MIBIB, QCSBL, OEMSBL, AMSS, EFS2, NVBACKUP, APPSBL, PARAM, FOTA partitions ?
6) why the kernel has a gziped part in it ?

=======================================================================================
stepph said:
1) Root the phone AND ADB demon.
Click to expand...
Click to collapse
I used SuperOneClick tool. Its easy.
Only remeber to root also the adb shell, in order to be able to acess as super user.
As you use the tool, the SuperUser.apk is added to your ROM.
This tool make a window appear every time an apps need root access, and you have a log.
Even if you reset the device, the rooting and SU will survive.
=======================================================================================
stepph said:
2) Add Essential APKs.
Click to expand...
Click to collapse
I install RootExplorer, ES_FileManager in order to be able to navigate in the filesystem.
With rooting, i can also mount /system as R/W... and RootExplorer also indicate the mountpoint of some folders...
Eploring the FS, I notice :
/system/apps - where the preloade apks are. Some are systems apps (unknow), some are apps that i have in the apps folder.
/cache - where tempoarary data are stored.
/data - where apps save info
=======================================================================================
... continue in [post 6]...

3x. Would you like to tell how you modify the recovery.img and boot.img?

dongbincpp said:
3x. Would you like to tell how you modify the recovery.img and boot.img?
Click to expand...
Click to collapse
at now i'm studing on that...
... reading "HOWTO: Unpack, Edit, and Re-Pack Boot Images".

stepph said:
3) Remove/Replace Stock applications.
Click to expand...
Click to collapse
So I manage to remove (and backup on SD and then o my PC) the unused apk
from /systems/apps/
Some APKs have odex file (that are a way to speed up loading...) - the unused one to be removed too.
After a wipe - I noticed that the apks are DEFINITELY removed - WOW i delete something from the ROM of my phone...
If i put the backup copy of the removed files back, they still work.
Instead, if i try to install them, some of them does not work anymore (why?)
I notice the SuperUser apks too... so I try to add different apk here, or change the old one with an updated version...
So when i'll wipe the phone i'll get it with what i want.
Sometimes it works, sometimes i got errors on startup, sometimes the device ignore the new apps (??)
=======================================================================================
stepph said:
4) Got a personalized Restore.
Click to expand...
Click to collapse
When I wipe the phone, widget and links are the defult ones... how can i modify this ??
I notice dat inside /data/ folder are stored the Launcher dta & options - inside a *.db file.
So i can save & restore what i set.
But i still not understand where the setting are recorder on wipe...
=======================================================================================
... continue in [post 7]...

stepph said:
1) use of ADB and related tools.
Click to expand...
Click to collapse
great ... it is like a shell working on my terminal...
i'm not so experienced with linux command, buti'll try
I also use adb mask control, thas has a GUI to rapidly make some operation.
so i push sqlite and a new version of busybox on my device
stepph said:
2) backup copy of /system folder
Click to expand...
Click to collapse
playing with mount and my adb shell, i found:
Code:
d rwx r-x r-x root root 2011-09-09 10:10 acct
d r-x --- --- root root 2011-09-09 10:10 config
d rwx r-x r-x root root 1970-01-01 01:00 lib
d rwx --- --- root root 2011-05-02 04:40 root
d rwx r-x --- root root 1970-01-01 01:00 sbin
d rwx rwx --x system system 2011-09-09 10:10 persist
d rwx r-x r-x root root 2011-09-09 10:12 dev mount from tmpfs
d r-x r-x r-x root root 1970-01-01 01:00 proc mount from proc
d rwx r-x r-x root root 1970-01-01 01:00 sys mount from sysfs
d rwx rwx --- system cache 2011-09-09 10:10 cache mount from /dev/stl14 (rfs)
d rwx rwx --x system system 2011-09-09 10:10 data mount from /dev/stl13 (rfs)
d rwx r-x r-x root root 2011-09-09 10:10 system mount from /dev/stl12 (rfs)
d rwx rwx r-x root system 2011-09-09 10:10 mnt
/mnt/asec ??
/mnt/sdcard ??
/mnt/secure ??
l rwx rwx rwx root root 2011-09-09 10:10 d link from /sys/kernel/debug
l rwx rwx rwx root root 2011-09-09 10:10 etc link from /system/etc
l rwx rwx rwx root root 2011-09-09 10:10 sdcard link from /mnt/sdcard
i simply make a backup of files in / and of /system/ on my PC...
since other folders have 'strange' mountpoints... i let them apart for now.
stepph said:
3) dump of partitions.
Click to expand...
Click to collapse
i found this list: cat proc/partition/
Code:
major minor #blocks name
137 0 513024 bml0/c
137 1 1536 bml1
137 2 512 bml2
137 3 768 bml3
137 4 25600 bml4
137 5 9216 bml5
137 6 5120 bml6
137 7 2048 bml7
137 8 8192 bml8
137 9 8192 bml9
137 10 768 bml10
137 11 6144 bml11
137 12 222464 bml12
137 13 192768 bml13
137 14 29696 bml14
138 12 214784 stl12
138 13 185600 stl13
138 14 25856 stl14
179 0 1927168 mmcblk0
179 1 1926144 mmcblk0p1
so i start with cat /dev/bml0 >/sdcard/bml0.img
and so on for each BML to 14.
Then i try with STL... and I brick my PHONE !!!
Reading around...
>>>> DO NOT TRY TO ACCESS TO STL5<<<<​
Now my phone is at service for repairing - i hope they accept warranty -
I'll continue my investigations on the BMLxx.img files...
=======================================================================================
... continue in [post 8] - without phone - ...

Now, i have the segunt dumped images:
Code:
0 513024 bml0/c
1 1536 bml1
2 512 bml2
3 768 bml3
4 25600 bml4
5 9216 bml5
6 5120 bml6
7 2048 bml7
8 8192 bml8
9 8192 bml9
10 768 bml10
11 6144 bml11
12 222464 bml12
13 192768 bml13
14 29696 bml14
an easy check prove me that the first and bigger one is simply the join on the others... so first of all i look for some indication about the partitioning of BML0, from which the others are derived.
With a hex editor, I found :
Code:
00081000h: AA 73 EE 55 DB BD 5E E3 03 00 00 00 0E 00 00 00 ªsîUÛ½^ã........
00081010h: 30 3A 4D 49 42 49 42 00 00 00 00 00 00 00 00 00 0:MIBIB.........
00081020h: 00 00 00 00 06 00 00 00 12 10 FF 00 30 3A 51 43 ..........ÿ.0:QC
00081030h: 53 42 4C 00 00 00 00 00 00 00 00 00 06 00 00 00 SBL.............
00081040h: 02 00 00 00 12 10 FF 00 30 3A 4F 45 4D 53 42 4C ......ÿ.0:OEMSBL
00081050h: 31 00 00 00 00 00 00 00 08 00 00 00 03 00 00 00 1...............
00081060h: 12 10 FF 00 30 3A 41 4D 53 53 00 00 00 00 00 00 ..ÿ.0:AMSS......
00081070h: 00 00 00 00 0B 00 00 00 64 00 00 00 12 10 FF 00 ........d.....ÿ.
00081080h: 30 3A 45 46 53 32 00 00 00 00 00 00 00 00 00 00 0:EFS2..........
00081090h: 6F 00 00 00 24 00 00 00 01 11 FF 00 30 3A 4E 56 o...$.....ÿ.0:NV
000810a0h: 42 41 43 4B 55 50 00 00 00 00 00 00 93 00 00 00 BACKUP......“...
000810b0h: 14 00 00 00 01 11 FF 00 30 3A 41 50 50 53 42 4C ......ÿ.0:APPSBL
000810c0h: 00 00 00 00 00 00 00 00 A7 00 00 00 08 00 00 00 ........§.......
000810d0h: 12 10 FF 00 30 3A 41 50 50 53 00 00 00 00 00 00 ..ÿ.0:APPS......
000810e0h: 00 00 00 00 AF 00 00 00 20 00 00 00 12 10 FF 00 ....¯... .....ÿ.
000810f0h: 30 3A 52 45 43 4F 56 45 52 59 00 00 00 00 00 00 0:RECOVERY......
00081100h: CF 00 00 00 20 00 00 00 12 10 FF 00 30 3A 50 41 Ï... .....ÿ.0:PA
00081110h: 52 41 4D 00 00 00 00 00 00 00 00 00 EF 00 00 00 RAM.........ï...
00081120h: 03 00 00 00 12 10 FF 00 30 3A 46 4F 54 41 00 00 ......ÿ.0:FOTA..
00081130h: 00 00 00 00 00 00 00 00 F2 00 00 00 18 00 00 00 ........ò.......
00081140h: 01 10 FF 00 30 3A 53 59 53 41 50 50 53 00 00 00 ..ÿ.0:SYSAPPS...
00081150h: 00 00 00 00 0A 01 00 00 65 03 00 00 01 11 FF 00 ........e.....ÿ.
00081160h: 30 3A 44 41 54 41 00 00 00 00 00 00 00 00 00 00 0:DATA..........
00081170h: 6F 04 00 00 F1 02 00 00 01 11 FF 00 30 3A 43 41 o...ñ.....ÿ.0:CA
00081180h: 43 48 45 00 00 00 00 00 00 00 00 00 60 07 00 00 CHE.........`...
00081190h: 74 00 00 00 01 11 FF 00 FF FF FF FF FF FF FF FF t.....ÿ.ÿÿÿÿÿÿÿÿ
i.e.
Code:
[I]name[/I] [I]start[/I] [I]len[/I] [I]??[/I]
MIBIB 00000000 00000600 12 10
QCSBL 00000600 00000200 12 10
OEMSBL 00000800 00000300 12 10
AMSS 00000B00 00006400 12 10
EFS2 00006F00 00002400 01 11
NVBACKUP 00009300 00001400 01 11
APPSBL 0000A700 00000800 12 10
APPS 0000AF00 00002000 12 10
RECOVERY 0000CF00 00002000 12 10
PARAM 0000EF00 00000300 12 10
FOTA 0000F200 00001800 01 10
SYSAPPS 00010A00 00036500 01 11
DATA 00046F00 0002F100 01 11
CACHE 00076000 00007400 01 11
that is not only the list of the partition of BML0 in BML1..14, with the correspondant sizes, but also the name of each - they match with what i read in some posts !!
Here it is also some binary tags for ech BML; and adding a quick examiation of the head of each file, i get the following table of preliminary infos:
Code:
Disk MB KB bytes Name flags FSR_STL note Start Lenght
/dev/bml0: 525 513.024 525.336.576
/dev/bml1: 1 1.536 1.572.864 MIBIB 12 10 00000000 00000600
/dev/bml2: 0 512 524.288 QCSBL 12 10 00000600 00000200
/dev/bml3: 0 768 786.432 OEMSBL 12 10 00000800 00000300
/dev/bml4: 26 25.600 26.214.400 AMSS 12 10 ELF 00000B00 00006400
/dev/bml5: 9 9.216 9.437.184 EFS2 01 11 X dev/stl5 ! Attento! 00006F00 00002400
/dev/bml6: 5 5.120 5.242.880 NVBACKUP 01 11 X dev/stl6 (empty) 00009300 00001400
/dev/bml7: 2 2.048 2.097.152 APPSBL 12 10 arm11boot ? 0000A700 00000800
/dev/bml8: 8 8.192 8.388.608 APPS 12 10 ANDROID! - boot image 0000AF00 00002000
/dev/bml9: 8 8.192 8.388.608 RECOVERY 12 10 ANDROID! - recovery image 0000CF00 00002000
/dev/bml10: 1 768 786.432 PARAM 12 10 0000EF00 00000300
/dev/bml11: 6 6.144 6.291.456 FOTA 01 10 empty 0000F200 00001800
/dev/bml12: 217 222.464 227.803.136 SYSAPPS 01 11 X /dev/stl12 - /system (rfs) 00010A00 00036500
/dev/bml13: 197 192.768 197.394.432 DATA 01 11 X /dev/stl13 - /data (rfs) 00046F00 0002F100
/dev/bml14: 30 29.696 30.408.704 CACHE 01 11 X /dev/stl14 - /cache (rfs) 00076000 00007400
================================================== =====================================
... continue in post 9 - without phone - ...

First, i work on the BML12, that is the file related to /system folder.
I read a lot of stuff about Samsung BML, STL, RFS, and so on...
My understanding is that BML is the layer of block level devices,
and STL is the 'file system like' layer on it. I read also that STL are FAT compatible, and that images can be opened with MagicISO.
So i found in BML12.img file the signature MSWIN4.1, cut the previus part (two byte more) and i get a fat-12 image.
MagicISO was able to extract this files.
I compare the extracted /system folder wit the backup i done directly from the phone ... SURPRISE... the files i removed from ROM are there again !! why this ??
On the other side i wander where the others files in original filesystem are...
Same tecnich on BML13 & BML14 for /data and /cach partition does'n work at all -- why ?
=======================================================================================
... continue in post 12 - without phone - ...

stepph
wat ur doing here is great.
but didn u notice a few other mini threads here already..a few roms n cm7?
http://forum.xda-developers.com/showthread.php?t=1167750
http://forum.xda-developers.com/showthread.php?t=1176927
there are other threads too
---------- Post added at 02:01 PM ---------- Previous post was at 01:52 PM ----------
stepph said:
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
Click to expand...
Click to collapse
I dont think u can install any app as a system, think u can only replace an already existing system app with another of ur wish by renaming the app correctly and replacing it in /system/app
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
Click to expand...
Click to collapse
u cannot install app as a system app. as said abv u can only replace them.
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
Click to expand...
Click to collapse
maybe u need to remove them frm the dalvik-cache too
----edit------
clearly I have not played with my phone enough to be answering such questions.

roofrider said:
stepph wat ur doing here is great.
but didn u notice a few other mini threads here already..a few roms n cm7?
http://forum.xda-developers.com/showthread.php?t=1167750
http://forum.xda-developers.com/showthread.php?t=1176927
there are other threads too
Click to expand...
Click to collapse
Thank you for the links,
I notice that already...but none of them talk about HOW it was made...
... i don't want a " download and install " work, but explain to everybody what i do.
roofrider said:
I dont think u can install any app as a system, think u can only replace an already existing system app with another of ur wish by renaming the app correctly and replacing it in /system/app
u cannot install app as a system app. as said abv u can only replace them.
maybe u need to remove them frm the dalvik-cache too
Click to expand...
Click to collapse
Ok, it was what i think about 1st & 2nd point...I'll look for technical infos about those 'system' apps.
About the 3rd, you may be right if it was about a running device; but i worked on dumped images, so VM cache should not be involved... i'll investigate.

About Boot.img and Recovery.img
I tested this method on my duped BML files, and on some downloaded ROM.
in bootimg.h - from Android SDK (so i suppose, but i found in this forum)
Code:
#define BOOT_MAGIC "ANDROID!"
#define BOOT_MAGIC_SIZE 8
#define BOOT_NAME_SIZE 16
#define BOOT_ARGS_SIZE 512
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE];
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
/*
** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size != 0)
** 2. second is optional (second_size == 0 -> no second)
** 3. load each element (kernel, ramdisk, second) at
** the specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr. kernel_args[] is
** appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size != 0: jump to second_addr
** else: jump to kernel_addr
So i opened my file, and found
Code:
414E4452 4F494421 C8F42E00 00806013 0E143000 00006014 00000000 00005014 00016013 00100000 00000000 ...
that is
Code:
00000000 struct BOOT_IMG_HDR
00000000 magic[8] ANDROID!
00000008 DWORD kernel_size 3077320
0000000C DWORD kernel_addr 325091328
00000010 DWORD ramdisk_size 3150862
00000014 DWORD ramdisk_addr 341835776
00000018 DWORD second_size 0
0000001C DWORD second_addr 340787200
00000020 DWORD tags_addr 325058816
00000024 DWQRD page_size 4096
00000028 unused[2] 0
00000030 name[16] 0
00000040 cmdline[512] 0
00000240 id[8] xxxxxxx
so i calculate
Code:
n = (3077320 + 4096 - 1) / 4096 = 752
m = (3150862 + 4096 - 1) / 4096 = 770
o = (0 + 4096 - 1) / 4096 = 0
** +-----------------+
** | boot header | 1 page = 0 to 4095 (h00000FFF)
** +-----------------+
** | kernel | 752 pages = 4096 to 4096+752*4096 = 3084287 (h002F0FFF)
** +-----------------+
** | ramdisk | 770 pages = 3084288 to 3084288+770*4096 = 2378055679 (h8DBE3FFF)
** +-----------------+
so i spli the file in 3 parts : header, kernel, and ramdisk.
NOTE: at offset 18825 (h4989) i find 1F 8F that is the head of a gzipped file..
so i split kernel in kernel.head and kernel.gz => decompressed in kernel.tail.
This worked, sinc in decompressed part i found readable strings...
Ramdisk is ramdisk.cpio.gz, so i was able to decompress it and get the filesystems loaded on start.
There are many interesting files...
TASS.rle and TASS-HUI.rle (the original logo, and the logo for italy - HUI is my region)
init and init.rc - and some other script file, that i saw on root folder of my devices
some folders with bins, and so on...
When i use this method with dumped Recovery.img and downloaded ClockWorkMod_recovery.img, i get i working...
So i'll investigate about differences in ramdisk files of those...
=======================================================================================
... continued in [post 14] - without phone - ...

I'm neither an Android, nor a Linux expert but I'll try to answer your questions to the best of my knowledge:
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
Click to expand...
Click to collapse
Some system apks don't have a registered activity (meaning they don't have a UI), so they won't appear in your launcher, also (and take this with a grain of salt), I've personally found that some of the apks placed in /system/app/ need to be installed too.
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
Click to expand...
Click to collapse
Dunno about this one, but I'd dare say that it has something to do with the extra files that are placed in other folders, What apps have you had this problem with?, maybe we can find out why they have that behavior
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
Click to expand...
Click to collapse
If they're not wiped they have to be either in the system partition or in the SD
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
Click to expand...
Click to collapse
Taken from the link you put on the BML mapping thread:
What you generally see is that BML partitions contain 'static' data (bootloaders, boot / recovery images) and STL partitions contain 'live' filesystem (on android: /system, /data, /cache, /efs, /dbdata). The idea is that things directly on an BML partition don't change very often and wear leveling isn't required. Read/write filesystems however, do benefit from wear leveling and are thus placed on an STL partition.
Click to expand...
Click to collapse
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
Click to expand...
Click to collapse
You'd have to find out the partition's filesystem, I believe it's a Samsung propietary FS so you're out of luck with that one
5) what are MIBIB, QCSBL, OEMSBL, AMSS, EFS2, NVBACKUP, APPSBL, PARAM, FOTA partitions ?
Click to expand...
Click to collapse
Way above my paygrade!!
6) why the kernel has a gziped part in it ?
Click to expand...
Click to collapse
See 5

Great !!
thank you Akath19 for your contribution....
I want to continue this discussion with details on some topics...if you or someone else is able to contribute.
-------------------------------------------------------------------------
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
A : Some system apks don't have a registered activity (meaning they don't have a UI), so they won't appear in your launcher, also (and take this with a grain of salt), I've personally found that some of the apks placed in /system/app/ need to be installed too.
Click to expand...
Click to collapse
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
A: Dunno about this one, but I'd dare say that it has something to do with the extra files that are placed in other folders, What apps have you had this problem with?, maybe we can find out why they have that behavior
Click to expand...
Click to collapse
In /system/apps i find some different kind of apps...
- those without icon, not appearing in the 'GUI' - (the app folder in launche) - i call them of 'system type' and i do not touch them.
- apps with icon, implementing important functions - gallery, phone, launcher, etc...
- Google Apps
- some other samsung/provider apps
- some 'generic' app - Analog clock, Dual clock, some widget... (i think they are inserted as demo of capabilities)
Many of those apps have related .odex file.
REMOVING Apps - and restore them
I removed the apps that i do not need - and backup the on my sdcard.
If i want to restore them, i can adb push them a their previus place, and this is the only method for odexed ones.
As alternative to reinstall i tried to do 'normal' install for the apps without .odex ... this also mean that they will be installed in /data/apps,
and they are moved from system STL12 to data STL13 - different partitions, with impact on free space)
This doesn't work for many of the apps - ??
ADDING Apps
I want to add some apps - in order to find them installed after a wipe.
This works with some apps, doesnot with others... some apps (TitaniumBackup) generate a force close on power on...
I suppose that apps in system/apps have to be differrent from those in /data/apps...
-------------------------------------------------------------------------
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
A: If they're not wiped they have to be either in the system partition or in the SD
Click to expand...
Click to collapse
They do are wiped... so the infos are written in /data/data/(somefolder)...
But the preloade info - those appearing after a wipe - where are they ?
I suppose that a wipe completely erase /data and not preload its contents...or a part of /data is restored after a wipe ? how ??
-------------------------------------------------------------------------
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
a: Taken from the link you put on the BML mapping thread:
What you generally see is that BML partitions contain 'static' data (bootloaders, boot / recovery images) and STL partitions contain 'live' filesystem (on android: /system, /data, /cache, /efs, /dbdata). The idea is that things directly on an BML partition don't change very often and wear leveling isn't required. Read/write filesystems however, do benefit from wear leveling and are thus placed on an STL partition.
Click to expand...
Click to collapse
This is the description of 'driver level' to access to the phisical chip...
STL are a layer up the BML, adding a wear leveling services, enabling secure r/w of bits...
I understand that in a BML dump is contained the STL dump.
This does'n explain why the apps i removed are still present in dump
(unless i make a mistake, and dumepd before removing ??)
-------------------------------------------------------------------------
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
A: You'd have to find out the partition's filesystem, I believe it's a Samsung propietary FS so you're out of luck with that one
Click to expand...
Click to collapse
You are right... unless we find the source of RFS, in order to be compiled for linux, the only way i have to correctly mount, is on my device - that support RFS.
RFS is reported to be FAT compatible, in fact i was able to extract files form BML12 - aftre some editing - with MagicISO. I suppose that this SW read it as a FAT12 partition - or at least, I found a valid FAT12 heder.
This method does'not work with BML13 and BML14, thas seem to have many FAT12 section in it - but each unreadable.
-------------------------------------------------------------------------
... continue in [post 24] - with Doc_cheilvenerdi.org great contribution

No worries man, I'm also really interested in learning and this is a much better way than just downloading and flashing files.
Anyways, on to the discussion:
stepph said:
REMOVING Apps - and restore them
I removed the apps that i do not need - and backup the on my sdcard.
If i want to restore them, i can adb push them a their previus place, and this is the only method for odexed ones.
As alternative to reinstall i tried to do 'normal' install for the apps without .odex ... this also mean that they will be installed in /data/apps,
and they are moved from system STL12 to data STL13 - different partitions, with impact on free space)
This doesn't work for many of the apps - ??
Click to expand...
Click to collapse
Well if the apps are odexed, they won't work (not even if you install them), 'cause you'd need to deodex them first before trying to install them (learned this the hard way while theming my stock Phone.apk)
For the other apps I guess trying on a case by case basis would be the answer, give me a list of the apps that don't work I'll try to figure out why.
stepph said:
ADDING Apps
I want to add some apps - in order to find them installed after a wipe.
This works with some apps, doesnot with others... some apps (TitaniumBackup) generate a force close on power on...
I suppose that apps in system/apps have to be differrent from those in /data/apps...
Click to expand...
Click to collapse
Personally I don't use TB, I think manually saving apks and configs works better, also I've heard numerous horror stories regarding TB.
What I do in order to keep stuff after a wipe is, I make a small CWM flashable zip that has all the info that I want to keep, and I just flash it after wiping.
stepph said:
They do are wiped... so the infos are written in /data/data/(somefolder)...
But the preloade info - those appearing after a wipe - where are they ?
I suppose that a wipe completely erase /data and not preload its contents...or a part of /data is restored after a wipe ? how ??
stepph said:
I don't exactly know if this is true but I'd dare say some settings are saved inside the apk itself, so that the user has some "default" settings ready available
Also, no part of /data/ is restored after a wipe.
stepph said:
This is the description of 'driver level' to access to the phisical chip...
STL are a layer up the BML, adding a wear leveling services, enabling secure r/w of bits...
I understand that in a BML dump is contained the STL dump.
This does'n explain why the apps i removed are still present in dump
(unless i make a mistake, and dumepd before removing ??)
Click to expand...
Click to collapse
I guess this question would need someone extremely knowledgeable about the underlying subsystem (someone like Darky), but IMHO the phone must copy the STL contents into BML every certain amount of time or something like that.
stepph said:
You are right... unless we find the source of RFS, in order to be compiled for linux, the only way i have to correctly mount, is on my device - that support RFS.
RFS is reported to be FAT compatible, in fact i was able to extract files form BML12 - aftre some editing - with MagicISO. I suppose that this SW read it as a FAT12 partition - or at least, I found a valid FAT12 heder.
This method does'not work with BML13 and BML14, thas seem to have many FAT12 section in it - but each unreadable.
Click to expand...
Click to collapse
If the partitions have a true RFS FS you could just mount them as a loopback device, that's what I did in order to check the contents of BML5, if there are mutliple partitions I guess you would need to find that start and end of each and split them in order to read them
Click to expand...
Click to collapse
Click to expand...
Click to collapse

This is really what I expected from this 3d !!
Akath19 said:
For the other apps I guess trying on a case by case basis would be the answer, give me a list of the apps that don't work I'll try to figure out why.
Click to expand...
Click to collapse
I'll post the list of the removed apps... but need to wait for it since i'm without phone and - don't ask too much to my memory - i have to re-check the ones loading.
Akath19 said:
What I do in order to keep stuff after a wipe is, I make a small CWM flashable zip that has all the info that I want to keep, and I just flash it after wiping.
Click to expand...
Click to collapse
Good ... else - i do not want to use CWM - i was unable to prepare update.zip for original recovery. This could be another discussion...
Akath19 said:
I don't exactly know if this is true but I'd dare say some settings are saved inside the apk itself, so that the user has some "default" settings ready available
Also, no part of /data/ is restored after a wipe.
Click to expand...
Click to collapse
this is also my guess.
-->> and now the important part... <<---
Akath19 said:
I guess this question would need someone extremely knowledgeable about the underlying subsystem (someone like Darky), but IMHO the phone must copy the STL contents into BML every certain amount of time or something like that.
If the partitions have a true RFS FS you could just mount them as a loopback device, that's what I did in order to check the contents of BML5, if there are mutliple partitions I guess you would need to find that start and end of each and split them in order to read them
Click to expand...
Click to collapse
I tried mounting with loopback - my experiments are slowly migrating to linux - but it works only for STL12 /system. It doesn't work for others, nor splitted parts - they result in unreadbles files with unreadable filenames.
Does'n work even with bml5 ... but i probably have a corrupted dump, since after that - by reading STL5 - the phone is gone...
.

Have you gotten your phone back yet stepph, 'cause I'm eager to start tinkering with our phones but I can't do it alone!!

I got it yesterday... with a russian gingerbread FW (who knows where it was downloaded ), but without radio FW, and shutting down every minute...
... The guy of the service was not so able... and he doesn't work with 'official' FW... I have to take the phone back to him - for warranty at least.
I'm tempted to do it by myself - but if EFS is gone ?
Meanwhile, i'm working with androidx86 - a porting for PC - on a virtual machine... it seems great for testing some mods on /system - but kernel, executables, and libraries are recompiled...
And i'm tryng revskill - in order to understand AMSS - the free version seem good... but is limited...
If i get some new results, i'll post it...
(interested in matlab scripts for codig/decoding RLE logos ?)

Download the official Euro FW via checkfusdownloader and flash it through ODIN, those FWs come directly from Samsung servers so you shouldn't have a problem.
I checked out that port but I didn't quite like it (too slow for my taste).
What's revskill (forgive my ignorance)
Meanwhile I'm looking into porting voodoo kernel (from SGS) into our minis, mainly to get better audio support through voodoo sound.
(Ewww, I hate matlab!!)

Akath19 said:
Download the official Euro FW via checkfusdownloader and flash it through ODIN, those FWs come directly from Samsung servers so you shouldn't have a problem.
Click to expand...
Click to collapse
just tried...ODIN reported success, but now the phone does'nt boot anymore...

Understand 5.1.1 bootloader bricking & perhaps fix it :

On Fire HD 2014 I started looking at md5sum for partitions for different OS versions, and it seems that on Fire 2015 one can figure out which partition gets screwed up by 5.1.1 bootloaders, and perhaps restore it to pre-5.1.1 state. If this fails, the warranty should kick in (all of the Fire 2015s are still under warranty !!!)
Please see this link for some details :
http://forum.xda-developers.com/fire-hd/help/trying-to-undo-bricking-5-2-2u2-t3301374
Basically, the idea is simple. First one captures all the partitions while running 5.0.1 bootloaders. Then the bootloaders are updated to 5.1.1 version. At this point the partitions are captured again. This is the code to capture partitions to be run on PC via adb:
Code:
adb shell
su
mkdir /sdcard/tmp/
dd if=/dev/block/mmcblk0p1 of=/sdcard/tmp/01_kb.img
dd if=/dev/block/mmcblk0p2 of=/sdcard/tmp/02_dkb.img
dd if=/dev/block/mmcblk0p3 of=/sdcard/tmp/03_expdb.img
dd if=/dev/block/mmcblk0p7 of=/sdcard/tmp/07_misc.img
dd if=/dev/block/mmcblk0p8 of=/sdcard/tmp/08_logo.img
cd /sdcard/tmp
md5 *.img
Then one can simply exit, and do "adb pull /sdcard/tmp/" to get all these *.img files off the device.
Then those partitions that changed (KB,DKB,EXPDB,MISC) are dd'ed back under 5.1.1, and bootloaders are dd'ed back to 5.0.1 versions. If it reboots OK, this means that the device is effectively restored to pre-5.1.1 state. If failure, warranty return.
The next step to try would be to transplant this offending partition from a different Fire to a device with 5.1.1, along with 5.0.1 bootloaders.
Here is the list of partitions for reference:
http://forum.xda-developers.com/amazon-fire/development/partitions-list-t3236213

When one tires to downgrade to 5.0.1, it's the preloader stage which the Fire keeps cycling at. We have already tried flashing the 5.0.1 bootloader & preloader onto a 5.1.1 Fire.

blueberry.sky said:
When one tires to downgrade to 5.0.1, it's the preloader stage which the Fire keeps cycling at. We have already tried flashing the 5.0.1 bootloader & preloader onto a 5.1.1 Fire.
Click to expand...
Click to collapse
But this would not make sense. Are you saying that the preloader does not even try to call the 5.0.1 bootloaders ? But then why ?
Since the preloader stays the same, the only difference is that 5.0.1 bootloaders are trying to run after 5.1.1 bootloaders already ran on the device. At this stage 5.0.1 cannot proceed normally, which must be due to some changes sitting on some of the partitions that the bootloaders are reading early on.
We have no indication that 5.0.1 bootloaders do not run at all, they may run a bit, and then crash, and the device is back at the preloader stage.
So restoring additional partitions together with 5.0.1 bootloaders may enable 5.0.1 to function again after 5.1.1, as per my original post.

bibikalka said:
Since the preloader stays the same, the only difference is that 5.0.1 bootloaders are trying to run after 5.1.1 bootloaders already ran on the device.
Click to expand...
Click to collapse
Have you verified that the 5.0.1 and 5.1.1 preloaders are the same?
bibikalka said:
Are you saying that the preloader does not even try to call the 5.0.1 bootloaders ?
Click to expand...
Click to collapse
Just know that when plugged into a pc you will see the preloader cycle endlessly. Connect, disconnect, repeat. And someone did try to flash the both the bootloader & preloader extracted from 5.0.1.
It could be that 5.1.1 is blowing a fuse which tell older versions to refuse to boot.

bibikalka said:
On Fire HD 2014 I started looking at md5sum for partitions for different OS versions, and it seems that on Fire 2015 one can figure out which partition gets screwed up by 5.1.1 bootloaders, and perhaps restore it to pre-5.1.1 state. If this fails, the warranty should kick in (all of the Fire 2015s are still under warranty !!!)
Please see this link for some details :
http://forum.xda-developers.com/fire-hd/help/trying-to-undo-bricking-5-2-2u2-t3301374
Basically, the idea is simple. First one captures all the partitions while running 5.0.1 bootloaders. Then the bootloaders are updated to 5.1.1 version. At this point the partitions are captured again. This is the code to capture partitions to be run on PC via adb:
Code:
adb shell
su
mkdir /sdcard/tmp/
dd if=/dev/block/mmcblk0p1 of=/sdcard/tmp/01_kb.img
dd if=/dev/block/mmcblk0p2 of=/sdcard/tmp/02_dkb.img
dd if=/dev/block/mmcblk0p3 of=/sdcard/tmp/03_expdb.img
dd if=/dev/block/mmcblk0p7 of=/sdcard/tmp/07_misc.img
dd if=/dev/block/mmcblk0p8 of=/sdcard/tmp/08_logo.img
cd /sdcard/tmp
md5 *.img
Then one can simply exit, and do "adb pull /sdcard/tmp/" to get all these *.img files off the device.
Then those partitions that changed (KB,DKB,EXPDB,MISC) are dd'ed back under 5.1.1, and bootloaders are dd'ed back to 5.0.1 versions. If it reboots OK, this means that the device is effectively restored to pre-5.1.1 state. If failure, warranty return.
The next step to try would be to transplant this offending partition from a different Fire to a device with 5.1.1, along with 5.0.1 bootloaders.
Here is the list of partitions for reference:
http://forum.xda-developers.com/amazon-fire/development/partitions-list-t3236213
Click to expand...
Click to collapse
Thanks Bibikalpa. The problem is, to try your solution we have to be able to use adb. We are stuck at fastboot. :crying:

rongweiss said:
Thanks Bibikalpa. The problem is, to try your solution we have to be able to use adb. We are stuck at fastboot. :crying:
Click to expand...
Click to collapse
What he is proposing is not a solution for people who are bricked. Rather it would help prevent people on 5.1.1 from getting bricked in the first place. It would allow downgrading to 5.0.1, restoring the ability to load twrp recovery from fastboot.
---------- Post added at 09:53 PM ---------- Previous post was at 09:11 PM ----------
Here are the md5 checksums from my 5.0.1 Fire
Code:
e1c2e27a6dae694cbf14594b6d963f11 ./01_kb.img
175ec1eea0b65b15ea6ee455531f154d ./02_dkb.img
1d837a219b515afae6c19d9126168f5c ./03_expdb.img
00ff461906b45fc4af74f81839a30069 ./07_misc.img
c414b0be43b26efb5009639be06a74e2 ./08_logo.img
926c891ba8bc265d5dfeabe1ba3838c8 ./09_tee1.img
926c891ba8bc265d5dfeabe1ba3838c8 ./10_tee2.img
Perhaps some of them are the same even between different Fires.
I've already had to get a warranty replacement for my Fire due to a cluster of stuck pixels. Don't want to try upgrading to 5.1.1, risk having to try for a 2nd replacement.

Here are my md5 checksums from 5.1.1 (with 5.1,0 bootloaders, so may not help much, but you didn't ask for bootloaders)
Code:
d47ae72b30dd03c08d0c41883ac219f4 01_kb.img
8b50c460e75aef889840a9077b12c20a 02_dkb.img
4af5655b4a4f2b36ffb81b20605bb75d 03_expdb.img
00ff461906b45fc4af74f81839a30069 07_misc.img
c414b0be43b26efb5009639be06a74e2 08_logo.img
926c891ba8bc265d5dfeabe1ba3838c8 09_tee1.img
926c891ba8bc265d5dfeabe1ba3838c8 10_tee2.img
83b74c9782b889e246bc7b7cfa184d64 04_uboot.img
I'm OK with testing, starting from scratch and rooting my unadultered 5.1.0.

DoLooper said:
Here are my md5 checksums from 5.1.1 (with 5.1,0 bootloaders, so may not help much, but you didn't ask for bootloaders)
Code:
I'm OK with testing, starting from scratch and rooting my unadultered 5.1.0.
Click to expand...
Click to collapse
These look like 5.0.1 checksums for TEE1/TEE2, the same as @blueberry.sky post.
Only the 1st 3 partitions seem to differ. If you run "adb shell; idme print" with root, it actually prints the first few lines of KB & DKB, at least on Fire HD 2014. Does this work on Fire 2015 ?

bibikalka said:
These look like 5.0.1 checksums for TEE1/TEE2, the same as @blueberry.sky post. Only the 1st 3 partitions seem to differ.
Click to expand...
Click to collapse
As said, I'm running 5.0.1 bootloaders.
If you run "adb shell; idme print" with root, it actually prints the first few lines of KB & DKB, at least on Fire HD 2014. Does this work on Fire 2015 ?
Click to expand...
Click to collapse
I get no output with either "idme print /dev/block/kb.img" or "idme print /dev/block/dkb.img" while in su. I assume this is correct syntax.

DoLooper said:
As said, I'm running 5.0.1 bootloaders.
I get no output with either "idme print /dev/block/kb.img" or "idme print /dev/block/dkb.img" while in su. I assume this is correct syntax.
Click to expand...
Click to collapse
It's just straight "idme print", nothing else after that.

bibikalka said:
It's just straight "idme print", nothing else after that.
Click to expand...
Click to collapse
Cool!
Code:
[email protected]:/ # idme print
. . .
KB:
4b 42 50 46 18 0e 00 00 28 0e
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
DKB:
30 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
. . .

Have you tried to connect your device to a computer running SP Flash Tool? If that works, and you manage to get data from the Fire (using the readback window), you may be able to unbrick your tablet.

Identify your bootloader version:

While playing with AFTV2 tools quite a bit, I thought it'd be convenient to have some way to identify what bootloader version one has (given bricking implications & all). Doing checksums on the full TEE1 & UBOOT partitions is not very useful, because the empty area in the partitions may have junk, and that would impact the checksum. So something slightly different is needed.
Here is what I propose, one can read the first few bytes of TEE1 & UBOOT partitions, and then look at them with a hex editor. Fairly low tech, but there you go ... Unfortunately, "hexdump" is not present by default on Fire, so a few more manipulations are required. First, run this with adb (can also be read with AFTV2 tools):
Code:
adb shell
su
mkdir /sdcard/tmp/
dd if=/dev/block/mmcblk0p4 of=/sdcard/tmp/04_uboot.img
dd if=/dev/block/mmcblk0p9 of=/sdcard/tmp/09_tee1.img
cd /sdcard/tmp
md5 *.img
exit
exit
adb pull /sdcard/tmp
Then, with a hex editor (such as Frhed), look at the first few bytes of these images on your PC. On linux it's even easier, just do "cat -c 8 *.img | hexdump". You should see something like the following:
Code:
04_uboot.img: UBOOT: 88 16 88 58 [COLOR="Red"]b4 33 06 00[/COLOR] 4c 4b 00 00 "LK"
09_tee1.img: TEE1: 88 16 88 58 [COLOR="Red"]00 3c 10 00[/COLOR] 54 45 45 00 "TEE"
The 4 bytes in red are key to identify the version. Please see the table below for the data I've compiled so far. Let's add to it as more versions become available/known (if your combination is not listed, please post here):
Code:
UBOOT
d8 27 06 00 Unreleased, 5.0.0, (Build date Saturday, August 1, 2015, 10:39 PM GMT)
b4 33 06 00 5.2.2_053820 5.0.1
54 3f 06 00 5.2.2_055120 5.0.1
e4 3b 06 00 5.4.1_112720 5.1.1
38 34 06 00 5.4.2_168620 5.1.2
78 34 06 00 5.4.4_271020 5.1.4
b8 3c 06 00 5.5.2_153420 5.3.1.0
TEE1
00 3c 10 00 Unreleased, 5.0.0, (Build date Saturday, August 1, 2015, 10:39 PM GMT)
00 3c 10 00 5.2.2_053820 5.0.1
00 3c 10 00 5.2.2_055120 5.0.1
00 3c 10 00 5.4.1_112720 5.1.1
00 3c 10 00 5.4.2_168620 5.1.2
00 3c 10 00 5.4.4_271020 5.1.4
90 84 11 00 5.5.2_153420 5.3.1.0
@DoLooper, @kirito9, @sd_shadow, @Kramar111, @zeroepoch, @hwmod, @Tomsgt

unknown 5.0.1
Code:
UBOOT
54 3f 06 00 5.2.2_055120 5.0.1
TEE1
00 3c 10 00 5.2.2_055120 5.0.1

Fire originally with 5.1.3 - downgraded to 5.1.2 . uboot and tee1 are consistent with 5.1.2 .

fmc000 said:
Fire originally with 5.1.3 - downgraded to 5.1.2 . uboot and tee1 are consistent with 5.1.2 .
Click to expand...
Click to collapse
Indeed, when you downgraded, the bootloaders got overwritten and so you see 5.1.2 ! But luckily, this combination does not brick.

fmc000 said:
Fire originally with 5.1.3 - downgraded to 5.1.2 . uboot and tee1 are consistent with 5.1.2 .
Click to expand...
Click to collapse
bibikalka said:
Indeed, when you downgraded, the bootloaders got overwritten and so you see 5.1.2 ! But luckily, this combination does not brick.
Click to expand...
Click to collapse
Hence the 'special' procedure for upgrading FireOS while leaving the current bootloader intact. A standard sideload/OTA update refreshes bootloader, kernel, rom, etc.

Davey126 said:
Hence the 'special' procedure for upgrading FireOS while leaving the current bootloader intact.
Click to expand...
Click to collapse
In a strict sense, the procedure doesn't leave the bootloader intact - it first writes the newer version (which is part of the stock ROM) to later replace it back with the original one. And this "later" may be crucial - if in-between something bad happens (bad battery level, bad cable, power outage on the PC side), game over.
What's the ratio of successful vs. bricking here?
Unfortunately, nobody seems to have followed the path @Vlasp had suggested a year ago: to trim down stock ROMs to explicitly exclude bootloader files and install instructions (and possibly add su, and disable ota and ads). I understand that with FF we're no longer limited to signed ROMs, so this should be feasible, and scriptable for future ROM versions, no? (If I could extend days to 36 hours...)

steve8x8 said:
In a strict sense, the procedure doesn't leave the bootloader intact - it first writes the newer version (which is part of the stock ROM) to later replace it back with the original one. And this "later" may be crucial - if in-between something bad happens (bad battery level, bad cable, power outage on the PC side), game over.
Click to expand...
Click to collapse
True. Didn't expect a literal interpretation but appreciate the clarification and associated cautions for others.
steve8x8 said:
Unfortunately, nobody seems to have followed the path @Vlasp had suggested a year ago: to trim down stock ROMs to explicitly exclude bootloader files and install instructions (and possibly add su, and disable ota and ads).
Click to expand...
Click to collapse
This has been done for other Amazon devices (eg: 3rd gen HDX) but garnished little user interest as an alternative to custom ROMs. The misunderstanding/misuse of custom stock builds actually created bigger headaches and a few unfortunate bricks. Eventually the images stopped being maintained.
steve8x8 said:
If I could extend days to 36 hours...
Click to expand...
Click to collapse
Still searching for those elusive hours! . Same can be said for developers who struggle to maintain what is already out there. Witness the cracks in several custom ROMs that have not seen recent updates.

Great and easy way to identify bootloader version. Disappointed to find that I was on 5.3.1 bootloader, but at least I know now

Quick update (although useless since reading off the timestamps would require root which isn't available yet for 5.3.2.1 and higher - that's why I won't merge this into the checker tool yet):
Code:
fireOS-5.0.0/images/preloader.img: 20150728-232738
fireOS-5.0.1/images/preloader_prod.img: 20150730-164940
fireOS-5.1.1/images/preloader_prod.img: 20150923-180133
fireOS-5.0.1/images/preloader.img: 20150930-051243
fireOS-5.1.1/images/preloader.img: 20151202-052945
fireOS-5.1.2/images/preloader_prod.img: 20160120-094719
fireOS-5.1.4/images/preloader_prod.img: 20160217-183554
fireOS-5.1.2/images/preloader.img: 20160227-021828
fireOS-5.1.4/images/preloader.img: 20160506-045524
fireOS-5.3.1.0/images/preloader_prod.img: 20160603-023745
fireOS-5.3.2.0/images/preloader_prod.img: 20160603-023745
fireOS-5.3.1.0/images/preloader.img: 20160624-191357
fireOS-5.3.2.1/images/preloader_prod.img: 20161102-031807
fireOS-5.3.2.0/images/preloader.img: 20161104-214024
fireOS-5.3.2.1/images/preloader.img: 20161201-113631
fireOS-5.3.3.0/images/preloader_prod.img: 20170116-085533
fireOS-5.3.3.0/images/preloader.img: 20170328-012523
---------- Post added at 01:58 PM ---------- Previous post was at 01:11 PM ----------
Um, by the way, there had been reports that 5.1.3 had been rooted without downgrading to 5.1.2, if I remember correctly.
If that's your last FireOS version, may I ask you to run the bootloader tool and report back the result? Same for 5.1.2.1... Thanks

After an adventure in updating to 5.3.3.0 I have :
uboot : b0 99 0e 00
tee : not recognisable
The tablet boots, I can reload TWRP if needed but if I flash the previous bootloader I had 541 it bricks and I have to recover using the linux ISO. It looks like my tee1 partition is corrupted. Any advice on how to proceed would be good ! Thanks.

jpearn said:
After an adventure in updating to 5.3.3.0 I have :
uboot : b0 99 0e 00
tee : not recognisable
The tablet boots, I can reload TWRP if needed but if I flash the previous bootloader I had 541 it bricks and I have to recover using the linux ISO. It looks like my tee1 partition is corrupted. Any advice on how to proceed would be good ! Thanks.
Click to expand...
Click to collapse
Reflash the partition with DD?
Download the firmware update, rename it to *.zip from *.bin, and there should be something called TEE.img or something similar. Then push it to the device with "adb push /path/to/TEE.img /sdcard" Then, on the tablet or in adb shell, run 'dd if=/sdcard/TEE.img of=/dev/block/mmcblk0p9'

PorygonZRocks said:
Reflash the partition with DD?
Download the firmware update, rename it to *.zip from *.bin, and there should be something called TEE.img or something similar. Then push it to the device with "adb push /path/to/TEE.img /sdcard" Then, on the tablet or in adb shell, run 'dd if=/sdcard/TEE.img of=/dev/block/mmcblk0p9'
Click to expand...
Click to collapse
I thought this however I noted in the other gapps / root thread that it should be dd if=453_tee1.img of=/dev/block/mmcblk0p3
I'm on Ariel Fire 7 4th, so I guess the partitions are different ?

jpearn said:
I thought this however I noted in the other gapps / root thread that it should be dd if=453_tee1.img of=/dev/block/mmcblk0p3
I'm on Ariel Fire 7 4th, so I guess the partitions are different ?
Click to expand...
Click to collapse
Yes, they would be different. Make sure to use a TEE from the correct device, not one from this model.

jpearn said:
After an adventure in updating to 5.3.3.0 I have :
uboot : b0 99 0e 00
tee : not recognisable
The tablet boots, I can reload TWRP if needed but if I flash the previous bootloader I had 541 it bricks and I have to recover using the linux ISO. It looks like my tee1 partition is corrupted. Any advice on how to proceed would be good ! Thanks.
Click to expand...
Click to collapse
This thread pertains to the 5th gen Fire 7 (Ford) not the 4th gen HD 7 (Ariel).

Identifying the bootloader version is one thing, being able to decide whether a downgrade would result in a brick is another...
Is there a way, on a Fire 7 (5th), to extract the anti-r* "stepping numbers" from bootloader files/partitions that get compared with entries in RPMB (which is only accessible by the bootloader, but not the kernel)? This might save a lot of guesswork and bricks.
In lk.bin, there's "androidboot.rpmb_state=%d" right next to "androidboot.unlocked_kernel=true" and "androidboot.unlocked_kernel=false". Access seems to happen via device numbers.
OTOH, preloader_prod.img contains strings like "[RPMB] Invalid magic, re-creating..." and "[RPMB] RPMB provisioning disabled" or even a message about a skipped, invalid anti-r* state.
Too bad it seems to be impossible to watch the device boot at such an early stage. Half a MB of ARM code is not what I'd want to trace manually... extracting the preloader from its MTK wrapper seems to be the easiest part...

steve8x8 said:
Too bad it seems to be impossible to watch the device boot at such an early stage.
Click to expand...
Click to collapse
https://forum.xda-developers.com/am...bootloader-unlock-ideas-t3289721/post65585385 and some previous/next post

Thanks for the pointer to one of the missing links! Being able to track the messages down might limit the amount of machine code to be parsed...

uboot - 88 16 88 58 B8 3C 06 00 4C 4B 00 00 00 00 00
tee1 - 88 16 88 58 90 84 11 00 54 45 45 00 00 00 00
5.3.1, lol. whats a good rom for this amazon fire 5th gen?

2WR3505 said:
uboot - 88 16 88 58 B8 3C 06 00 4C 4B 00 00 00 00 00
tee1 - 88 16 88 58 90 84 11 00 54 45 45 00 00 00 00
5.3.1, lol. whats a good rom for this amazon fire 5th gen?
Click to expand...
Click to collapse
[ROM][AOSP] Fire Nexus ROM - LMY49M [22 JULY 2017] - XDA Developers
https://forum.xda-developers.com/amazon-fire/orig-development/rom-fire-nexus-rom-lmy49f-t3300714
[ROM] Lineage-12.1 [12 SEP 2017] - XDA Developers
https://forum.xda-developers.com/amazon-fire/orig-development/rom-lineage-12-1-t3639447

Thanks, i went with the nexus rom, it runs nicely