Database Develop

[TUT] Flashing Himalaya from SD card

In nowadays HTC devices flashing from a SD card is a trivial task, just copy your ROM image to the card and boot it... Unfortunately, with elder devices, like with Himalaya for example, it's different - every image to be flashed have to have a special signature, which is individual not only for your device, but... for the given SD card aswell!
1. Getting a header.
How to get it? You have to make a backup of your actually flashed ROM. You'll need an USB cable and your device in a bootloader mode. Make a backup with below command:
Code:
password BOOTLOADER
Pass.
USB>d2s
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD:Detected one card
SD:ready for transfer OK
pc->drive.total_lba=F5800
pc->drive.num_heads=0
pc->drive.sec_p_track=0
pc->drive.num_cylinders=0
pc->drive.block_size=200
pc->drive.features=0
pc->drive.RCA=2
pc->drive.drv_type=40000000
pc->drive.securedAreaSize=0
pc->drive.securityDrv=0
pc->drive.busWidth=1
pc->drive.erasedSize=0
Total card size=1EB00000
SDCARDD2S+,cStoragePlatformType=FF
*******************************************************************************************************************************
Store image to SD/MMC card successful.
USB>
Done... but when you try to read this card, it shows it's not written in the meaning of a file - it's written sector by sector! Normally you would use ntrw for reading that into a normal file, but it has one major flaw: it dumps a whole card, so if you had 1GB card, you gonna get 1GB file... and that's why our beloved itsme wrote a small utility called psdread (and psdwrite, too), which I'm including in this tutorial.
Using this utility you have to read a header first. Assuming your card reader got a letter m: from your system (that's letter I have assigned to my card reader), just type:
Code:
c:>psdread.exe m: 0 0x19c
so you get something like this:
Code:
00000000: 48 49 4d 41 4c 41 59 41 53 20 20 20 20 20 20 20 HIMALAYAS
00000010: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
00000020: 31 2e 30 36 20 20 20 20 20 20 20 20 20 20 20 20 1.06
00000030: 78 7e a8 50 96 f5 45 3b 13 0d 89 0a 1c db ae 32 x~.P..E;.......2
00000040: 20 9a 50 ee 40 78 36 fd 12 49 32 f6 9e 7d 49 dc 1.P..x6..I2..}I.
00000050: ad 4f 14 f2 44 40 66 d0 6b c4 30 b7 32 3b a1 22 .O..D.f.k.0.2;..
00000060: f6 22 91 9d e1 8b 1f da b0 ca 99 02 b9 72 9d 49 .............r.I
00000070: 2c 80 7e c5 99 d5 e9 80 b2 ea c9 cc dd 00 4c f2 ,.~...........L.
00000080: 53 41 30 30 e1 dc d6 ae 83 90 49 f1 f1 ff e9 eb SA00......I.....
00000090: b3 a6 db 1e 87 0c 3e 77 24 42 0d 1c 06 b7 47 de .......w$B....G.
000000a0: 6d 12 4d c8 43 2e cb a6 1f 03 5a 7d 09 38 25 1f m.M.C.....Z}.8%.
000000b0: 5d 9f d4 fc 96 f5 45 3b 13 0d 89 0a 1c d3 90 2d ].....E;.......-
000000c0: 48 9a 50 ee 40 78 36 fd 12 49 32 f6 9e 81 49 dc H.P..x6..I2...I.
000000d0: ad 4f 14 f2 44 40 66 d0 6b c4 30 b7 3c 84 f2 87 .O..D.f.k.0.....
000000e0: 61 49 d1 4f 0a d8 16 e7 72 e6 bb 12 84 34 a6 77 aI.O....r....4.w
000000f0: 02 37 e4 97 2c 74 cb c9 12 68 33 74 9e ad 87 d5 .7..,t...h3t....
00000100: fa 16 bb 11 ad ae 24 88 79 fe 52 db 25 43 e5 3c ......$.y.R.%C..
00000110: b3 12 4d c8 43 bb 8b a6 1f 03 5a 7d 09 38 25 1f ..M.C.....Z}.8%.
00000120: 5d d4 cb fc 96 f5 45 3b 13 0d 89 0a 1c db ae 32 ].....E;.......2
00000130: 20 9a 50 ee 40 78 36 fd 12 49 32 f6 9e 7d 49 dc ..P..x6..I2..}I.
00000140: ad 4f 14 f2 44 40 66 d0 6b c4 30 b7 32 3b a1 22 .O...D.f.k.0.2;.
00000150: f6 22 91 9d e1 8b 1f da b0 ca 99 02 b9 72 9d 49 .............r.I
00000160: 2c 80 7e c5 99 d5 e9 80 b2 ea c9 cc 53 bf 67 d6 ,.~.........S.g.
00000170: bf 14 d6 7e 2d dc 8e 66 83 ef 57 49 61 ff 69 8f ...~-..f..WIa.i.
00000180: 48 54 43 53 41 30 30 34 30 30 30 30 30 31 46 43 HTCSA004000001FC
00000190: 30 30 30 30 46 45 46 39 46 32 43 44 0000FEF9F2CD
Well, it could be the end of the first part of this tutorial, but let's make a full backup file. Let's take a look at the end of this block:
Code:
HTCS A0040000 01FC0000 FEF9F2CD
where:
A0040000 - location of your OS image in a device
01FC0000 - size of the actual OS (decimal 33292288 bytes)
FEF9F2CD - checksum
On the very end of the ROM image there're 4 bytes more (HTCE), so the size of the whole image would be: 19C + 1FC0000 + 4 = 0x1FC01A0 bytes total.
Now you can make your backup image with following commands:
Code:
c:\> psdread.exe m: 0 0x1FC01A0 os.img
While the header itself (needed for the next steps of this tutorial) will be created with:
Code:
c:\> psdread.exe m: 0 0x19c header.img
2. Getting a bare OS.nb file
While in nowadays kitchens a bare OS.nb file os normal, you probably haven't even seen this file... so how to get it?
Normal ROM image is in nk.nbf file, which is XOR-encoded actual image. Decode it with:
Code:
c:\> xda2nbftool.exe -x nk.nbf nk.nba 0x20040304
so you have nk.nba file now. You can dismantle it now with:
Code:
c:\> dump.exe -o 0x40040 -l 0x1FC0000 nk.nba os.nb
and you have your OS.nb
3. Making a flashing ready image file.
Putting this all to a final file is trivial... it's just our header + OS.nb:
Code:
c:\> type header.img > SD_img.img
c:\> type OS.nb >> SD_img.img
And in the end you get SD_img.img file, which you can transfer to your SD card with:
Code:
c:\> psdwrite m: SD_img.img
I'd like to recommend using some good hexeditor.. I recommend you really great freeware one, called HxD (you can get it here). It can even operate on disk images and disks themselves.
4. Flashing your device.
Well, this will be the most tough part...
Well, not really
Turn off your Himalaya (really! the best would be to put out your battery), put your SD card in and turn it on. It will display a message: "press power to flash". Just press the power button and wait until it finishes. YOU CAN'T ABORT THE PROCESS, DON'T TOUCH IT! GO AND MAKE YOURSELF A COFFEE OR TEA OR GO FOR A SMOKE!!!
and... that's it
happy flashing!

......
good work very thank's

Flashing Himalaya from SD card- Many thanks "utak3r"
Atlast !!!!!!!!!
u r my saviour ........
Many Many Thanks for the steps......
I been asking and waiting a proper procedure to flash from sd card especially for xda2.
I will give a try and see if am succeeding.
well actually my usb is broken that is the reason am looking to flash from sd card.
In that case, can anyone post a lasted stable rom which is already ready to flash from SD Card ?
should the same SD card should be used ?
will it not work if I copy the SD image to a different SD card and flash it?
Many thanks utak3r

WOW!!! amazing tut
Stickied it!

gopi159 said:
should the same SD card should be used ?
will it not work if I copy the SD image to a different SD card and flash it?
Click to expand...
Click to collapse
As I said it in this tut - the header is unique for every device and every SD card, so... no, you can't download some image and flash it, sorry. Your bootloader will say: "not allowed" and that's it.
I'm working now on getting this header from a device without a cable - will I succeed? I don't know, last time I tried (about 2 years ago) I failed...

i cant understand all this
can you explain how to flash a new rom with a sd card only without cable

abdelamine said:
i cant understand all this
can you explain how to flash a new rom with a sd card only without cable
Click to expand...
Click to collapse
You can do it only if you have this header I'm talking above. If you don't have it - no flashing, unfortunately.

Flashing from SD card
How long time to be need it for flashing from SD card?
did we can charging battery while flashing from SD Card?
because we have old device with a short period of prodigal battery condition

Well, I can't remember it now, but it's faster than flashing through a cable. It shouldn't be longer than 20 minutes AFAIR.
And no, there's no charging while in this mode...

utak3r said:
I'm working now on getting this header from a device without a cable - will I succeed? I don't know, last time I tried (about 2 years ago) I failed...
Click to expand...
Click to collapse
I wish You luck in this task!
I think, that there must be the way to generate SD header information.
And thanx for such good tutorial - now I can make SDImage without using of sdtool.pl

Avis said:
I wish You luck in this task!
I think, that there must be the way to generate SD header information.
Click to expand...
Click to collapse
well, thanks
As for now I can dump ROM, but with my way, so it doesn't contain this header... it has to be generated by bootloader. So probably I'll end with decompiling a bootloader code

HOW CAN I write password BOOTLOADER and where

hi utak3r,
on the first part of the tutorial, how can we get this header?
where can we actually put this code? is it on command prompt or on device?
thanks...
got it.. use hyperterminal...

abdelamine said:
HOW CAN I write password BOOTLOADER and where
Click to expand...
Click to collapse
while you're in bootloader mode connect with your hima with mtty... and that's where you can issue various commands.

easy
any have easy tool..????

my usb connector is really broken, is there any solution to do it without using a pc and usb connection?
thanks

You have Vista, XP???

same question
& i have xp & vista

utak3r said:
As I said it in this tut - the header is unique for every device and every SD card, so... no, you can't download some image and flash it, sorry. Your bootloader will say: "not allowed" and that's it.
I'm working now on getting this header from a device without a cable - will I succeed? I don't know, last time I tried (about 2 years ago) I failed...
Click to expand...
Click to collapse
Is every header really unique? let us say, there are 1000 hima, so there are 1000 different headers?
If the answer is not, maybe we can flash the device using only our SD card without the help of usb connection. someone may post their ready-made file then try to flash it, if fails, try another.
I just want to make a possibilty coz my usb connection was broken too.

you can go and try to collect few headers... but I really doubt

[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...

why is 52bytes?

I had search lot of thread which write "busybox dd if=/system/framework/xxxx.odex of=/data/local/tmp/odex/xxx.odex bs=1 count=20 skip=52 seek=52 conv=notrunc".according to http://source.android.com document(odex/dex format), signature don't start at 0x34!
why?how to calculate is 52bytes(0x34)?THX
according to dex/odex format( http://source.android.com ),signature should start at 0x0c,not 0x34.so skip=52 seek=52 should skip = 12 seek= 12.But in lots of thread write 52 bytes,so i dont understand.

quywz said:
I had search lot of thread which write "busybox dd if=/system/framework/xxxx.odex of=/data/local/tmp/odex/xxx.odex bs=1 count=20 skip=52 seek=52 conv=notrunc".according to http://source.android.com document(odex/dex format), signature don't start at 0x34!
why?how to calculate is 52bytes(0x34)?THX
Click to expand...
Click to collapse
Did I understand you right that you want to know how 0x34 can be 52? Well, it's a hexadecimal number. Strike the '0x'(not part of the number) out and you have '34'. Hexadecimal is base 16, so it's:
4*16^0=4 and 3*16^1=48, together it makes 52.

dark_knight35 said:
Did I understand you right that you want to know how 0x34 can be 52? Well, it's a hexadecimal number. Strike the '0x'(not part of the number) out and you have '34'. Hexadecimal is base 16, so it's:
4*16^0=4 and 3*16^1=48, together it makes 52.
Click to expand...
Click to collapse
NO,according to dex/odex format( http://source.android.com ),signature should start at 0x0c,not 0x34.so skip=52 seek=52 should skip = 12 seek= 12.But in lots of thread write 52 bytes,so i dont understand.

quywz said:
I had search lot of thread which write "busybox dd if=/system/framework/xxxx.odex of=/data/local/tmp/odex/xxx.odex bs=1 count=20 skip=52 seek=52 conv=notrunc".according to http://source.android.com document(odex/dex format), signature don't start at 0x34!
why?how to calculate is 52bytes(0x34)?THX
according to dex/odex format( http://source.android.com ),signature should start at 0x0c,not 0x34.so skip=52 seek=52 should skip = 12 seek= 12.But in lots of thread write 52 bytes,so i dont understand.
Click to expand...
Click to collapse
Indeed, this is an interesting question. With the 8 "magic" bytes and the 4 bytes of the checksum, the signature should begin at 12 (0x0c), not 52.
Maybe this is related to the .odex format. I was only able to find documentation for the .dex format, and maybe the optimization process adds 40 bytes at the beginning of the file. I'll try to look into the source code, but if someone has the answer, I'll be glad to hear it as well.
EDIT : Found in libdex/DexFile.h
Code:
/*
* Header added by DEX optimization pass. Values are always written in
* local byte and structure padding. The first field (magic + version)
* is guaranteed to be present and directly readable for all expected
* compiler configurations; the rest is version-dependent.
*
* Try to keep this simple and fixed-size.
*/
struct DexOptHeader {
u1 magic[8]; /* includes version number */
u4 dexOffset; /* file offset of DEX header */
u4 dexLength;
u4 depsOffset; /* offset of optimized DEX dependency table */
u4 depsLength;
u4 optOffset; /* file offset of optimized data tables */
u4 optLength;
u4 flags; /* some info flags */
u4 checksum; /* adler32 checksum covering deps/opt */
/* pad for 64-bit alignment if necessary */
};
This additional header for optimized .dex files (.odex) is indeed 40 bytes-long.

Einril said:
Indeed, this is an interesting question. With the 8 "magic" bytes and the 4 bytes of the checksum, the signature should begin at 12 (0x0c), not 52.
Maybe this is related to the .odex format. I was only able to find documentation for the .dex format, and maybe the optimization process adds 40 bytes at the beginning of the file. I'll try to look into the source code, but if someone has the answer, I'll be glad to hear it as well.
EDIT : Found in libdex/DexFile.h
Code:
/*
* Header added by DEX optimization pass. Values are always written in
* local byte and structure padding. The first field (magic + version)
* is guaranteed to be present and directly readable for all expected
* compiler configurations; the rest is version-dependent.
*
* Try to keep this simple and fixed-size.
*/
struct DexOptHeader {
u1 magic[8]; /* includes version number */
u4 dexOffset; /* file offset of DEX header */
u4 dexLength;
u4 depsOffset; /* offset of optimized DEX dependency table */
u4 depsLength;
u4 optOffset; /* file offset of optimized data tables */
u4 optLength;
u4 flags; /* some info flags */
u4 checksum; /* adler32 checksum covering deps/opt */
/* pad for 64-bit alignment if necessary */
};
This additional header for optimized .dex files (.odex) is indeed 40 bytes-long.
Click to expand...
Click to collapse
struct DexOptHeader is 40 bytes-long,but already include magic + checksum.pls look at dexOffset which is file offset of DEX header and depsOffset which is offset of optimized DEX dependency table.so, maybe the pos of signature is magic + checksum +dexOffset +depsOffset.right?
maybe the dexOffset and depsOffset are according to device models have different value.
I copy aheader 40 bytes from classes.dex(836KB).
Code:
64 65 78 0a 30 33 35 00 a1 f6 7a 1b e6 a3 fb 35
5b d5 66 72 b8 33 36 3a 40 a1 4b ea 40 2f d3 fc
58 0e 0d 00 70 00 00 00
but In Dalvik Executable Format document,dex header is 112 bytes.
according to struct DexOptHeader, checksum = 0x70.dexOffset is so large!depsOffset is large too!
DexOptHeader seem unused.

I copy aheader 40 bytes from classes.dex(836KB).
Code:
64 65 78 0a 30 33 35 00 a1 f6 7a 1b e6 a3 fb 35
5b d5 66 72 b8 33 36 3a 40 a1 4b ea 40 2f d3 fc
58 0e 0d 00 70 00 00 00
but In Dalvik Executable Format document,dex header is 112 bytes.
according to struct DexOptHeader, checksum = 0x70.dexOffset is so large!depsOffset is large too!
DexOptHeader seem unused.

quywz said:
I copy aheader 40 bytes from classes.dex(836KB).
Code:
64 65 78 0a 30 33 35 00 a1 f6 7a 1b e6 a3 fb 35
5b d5 66 72 b8 33 36 3a 40 a1 4b ea 40 2f d3 fc
58 0e 0d 00 70 00 00 00
but In Dalvik Executable Format document,dex header is 112 bytes.
according to struct DexOptHeader, checksum = 0x70.dexOffset is so large!depsOffset is large too!
DexOptHeader seem unused.
Click to expand...
Click to collapse
Actually, you're looking at a .dex file header, not a .odex file header, so I'm not sure what you're looking for. Here there is no dexOffset, nor depsOffset, and the checksum is "a1 f6 7a 1b".
For the magic bytes + checksum, maybe these are redundant, and the optimization process only add a 40 bytes header without altering the old one.
To be sure, we would need to look into a .odex file header.
EDIT : Here are the 0x40 first bytes of systemUI.odex
Code:
000000 [B][COLOR="Red"]64 65 79 0A 30 33 36 00[/COLOR][/B] [B][COLOR="YellowGreen"]28[/COLOR][/B] 00 00 00 58 57 09 00
000010 80 57 09 00 C0 02 00 00 40 5A 09 00 38 16 01 00
000020 00 00 00 00 A2 E1 D9 FA [B][COLOR="Red"]64 65 78 0A 30 33 35 00[/COLOR][/B]
000030 E9 5F F1 ED B3 06 98 D7 80 5D 7D EF 63 7B D7 23
000040 5D 79 05 67 EF 1B 35 E7 58 57 09 00 70 00 00 00
We can see that there are indeed two sets of magic bytes, one beginning at 0 (the .odex magic bytes), and one beginning at 40 bytes (the .dex magic bytes).
As a side note, dexOffset is indeed 0x28 (40).

Einril said:
Actually, you're looking at a .dex file header, not a .odex file header, so I'm not sure what you're looking for. Here there is no dexOffset, nor depsOffset, and the checksum is "a1 f6 7a 1b".
For the magic bytes + checksum, maybe these are redundant, and the optimization process only add a 40 bytes header without altering the old one.
To be sure, we would need to look into a .odex file header.
EDIT : Here are the 0x40 first bytes of systemUI.odex
Code:
000000 [B][COLOR="Red"]64 65 79 0A 30 33 36 00[/COLOR][/B] [B][COLOR="YellowGreen"]28[/COLOR][/B] 00 00 00 58 57 09 00
000010 80 57 09 00 C0 02 00 00 40 5A 09 00 38 16 01 00
000020 00 00 00 00 A2 E1 D9 FA [B][COLOR="Red"]64 65 78 0A 30 33 35 00[/COLOR][/B]
000030 E9 5F F1 ED B3 06 98 D7 80 5D 7D EF 63 7B D7 23
000040 5D 79 05 67 EF 1B 35 E7 58 57 09 00 70 00 00 00
We can see that there are indeed two sets of magic bytes, one beginning at 0 (the .odex magic bytes), and one beginning at 40 bytes (the .dex magic bytes).
As a side note, dexOffset is indeed 0x28 (40).
Click to expand...
Click to collapse
right.
thank for your libdex/DexFile.h.
Pls take note of dexOffset is file offset of DEX header.Refer original android.policy.odex,I guess odex header format is DexOptHeader + dex's Header.now,the signature pos is dexOffset + magic(dex's magic) + checksum(dex's checksum).view original android.policy.odex,we will find dexOffset value is 0x28.so signature = 0x28 +0x8 + 0x4=0x34

quywz said:
right.
thank for your libdex/DexFile.h.
Pls take note of dexOffset is file offset of DEX header.Refer original android.policy.odex,I guess odex header format is DexOptHeader + dex's Header.now,the signature pos is dexOffset + magic(dex's magic) + checksum(dex's checksum).view original android.policy.odex,we will find dexOffset value is 0x28.so signature = 0x28 +0x8 + 0x4=0x34
Click to expand...
Click to collapse
Exactly. When optimizing an .dex file, the process adds the DexOptHeader at the beginning of the file. Thus, the resulting header is DexOptHeader + DexHeader (DexHeader beginning at 0x28), and the new position of the signature is 0x34 = 52 bytes

Einril said:
Exactly. When optimizing an .dex file, the process adds the DexOptHeader at the beginning of the file. Thus, the resulting header is DexOptHeader + DexHeader (DexHeader beginning at 0x28), and the new position of the signature is 0x34 = 52 bytes
Click to expand...
Click to collapse
THX.
Next topic.If you have time,pls help http://forum.xda-developers.com/showthread.php?p=41254960#post41254960:)

dark_knight35 said:
Did I understand you right that you want to know how 0x34 can be 52? Well, it's a hexadecimal number. Strike the '0x'(not part of the number) out and you have '34'. Hexadecimal is base 16, so it's:
4*16^0=4 and 3*16^1=48, together it makes 52.
Click to expand...
Click to collapse
If you have time,pls help http://forum.xda-developers.com/show...#post41254960:)
thx.

[solved] Relocking S1 v37

@RO.maniac ask how to relock his v37 bootloader on another thread:
RO.maniac said:
I have a little situation here. on a D6603.
Was running LP, unlocked, andropluskernel, root, xposed. happy.
Relocked bootloader with flashtool.
Updated to N preview using xperia companion.
Unlocked bootloader with flashtool.
That new bootloader, nexus style, was telling me safe boot off and unlocked bootloader.
Wasn't satisfied with the lack of root on N preview, so I decided to go back to stock LP via Xperia Companion. Then I found out the lastest update Xperia would flash is MM. I said fine.
Tried to relock bootloader with flashtool, I got ok message but it didn't relock the bootloader. tried a lot of times, different pc, flashtool version, regenerated code. nothing. so no Xperia Companion - no big deal, I just have an obsession with latest official builds, since my main device is a Nexus5. oh, what a nice girl that is. and easy to undress.
flashed a LP .ftf, tried to relock bootloader, no success.
[...]
What the heck happened with the relocking of the bootloader??!!
I'm thinking it has something to do with the new bootloader from N preview which I was running when I unlocked it. Now it won't relock on any version.
Click to expand...
Click to collapse
The idea of this dev-thread is understanding why S1 v37 is not re-lockable and if there is a way to relock it or downgrade it then relock, without bricking the phone obviously.
@RO.maniac can you, please, provide
- the S1boot part of your cmdline,
- backups of your TA partition before, after upgrading the bootloader,
- any flashtool log?
Thanks in advance.

N preview TA backup & flashtool log
Here you have the flashtool log and two backups of the current TA partition. One is pulled with ADB and one is from TWRP.
https://drive.google.com/file/d/0B0YzIybNxHcQa3E0Q1JJZlBkUU0/view?usp=sharing - TWRP ver.
https://drive.google.com/file/d/0B0YzIybNxHcQRXR2MjQ0Y3UzOWM/view?usp=sharing - ADB ver.
I don't have a TA backup of my old bootloader.
https://drive.google.com/file/d/0B0YzIybNxHcQcWNMMUtWeF9RNFk/view?usp=sharing - flashtool log. Tried to relock three times.
https://drive.google.com/file/d/0B0YzIybNxHcQVk1CZ1RISmhLMWM/view?usp=sharing - current bootloader mode photo.
I am now running N Preview 3, rooted, permissive.

RO.maniac said:
Here you have the flashtool log and two backups of the current TA partition. One is pulled with ADB and one is from TWRP.
Click to expand...
Click to collapse
Thanks! And no worries for the old TA. Just we can't revert to old version without it.
Can you send me your s1boot partition and the cmdline part with 's1boot'?
Also can you provide me your oem unlock code? (I should be able to find it in your ta partition)
P.S. your name is in plain text in your flashtool log.

nailyk said:
Thanks! And no worries for the old TA. Just we can't revert to old version without it.
Can you send me your s1boot partition and the cmdline part with 's1boot'?
Also can you provide me your oem unlock code? (I should be able to find it in your ta partition)
P.S. your name is in plain text in your flashtool log.
Click to expand...
Click to collapse
My name is no secret.
I'm not familiar with pulling s1boot partition and the cmdline part with 's1boot'. Do you need anything more than the photo I just popped in the post? - oh, you mean the boot partition and the code in the photo. That s1 upfront blinded me.
https://drive.google.com/open?id=0B0YzIybNxHcQMGxSTUdtdzBzTjQ - boot TWRP backup
Unlock code: C88FB2FFCCE72540

RO.maniac said:
My name is no secret.
I'm not familiar with pulling s1boot partition and the cmdline part with 's1boot'. Do you need anything more than the photo I just popped in the post?
Unlock code: C88FB2FFCCE72540
Click to expand...
Click to collapse
Awesome! I miss the picture, sorry.
Your fastbootlog also says: S1_Boot_MSM8974AC_LA3.0_L_Hero_17 which make me doubt....
Never read this version before. and never seen the screen you post before....
For me, fastboot mode was only blue light.... on this bootloader version.
I will start re with this elements, thank you.
Do you know exactly when this Hero_L17 version get installed on your phone? Is it coming from a custom rom?

nailyk said:
Awesome! I miss the picture, sorry.
Your fastbootlog also says: S1_Boot_MSM8974AC_LA3.0_L_Hero_17 which make me doubt....
Never read this version before. and never seen the screen you post before....
For me, fastboot mode was only blue light.... on this bootloader version.
I will start re with this elements, thank you.
Do you know exactly when this Hero_L17 version get installed on your phone? Is it coming from a custom rom?
Click to expand...
Click to collapse
This is the bootloader mode from N preview. Just like the Nexus line. I was really surprised to see it just as on my Nexus5.
Other than stock LP and MM , the only custom rom I've had is RXSW 3.0 which is MM.
I think this Hero_L17 is coming with N preview.
This is what I may seem not to understand. When I flash a complete .ftf doesn't EVERYTHING change, including the bootloader?
You are asking like it's there for some time, surviving .ftf flashes.
---------- Post added at 06:19 PM ---------- Previous post was at 06:17 PM ----------
nailyk said:
Awesome! I miss the picture, sorry.
Your fastbootlog also says: S1_Boot_MSM8974AC_LA3.0_L_Hero_17 which make me doubt....
Never read this version before. and never seen the screen you post before....
For me, fastboot mode was only blue light.... on this bootloader version.
I will start re with this elements, thank you.
Do you know exactly when this Hero_L17 version get installed on your phone? Is it coming from a custom rom?
Click to expand...
Click to collapse
Also, you should watch my past posts here because I tend to edit them a lot and add things instead of writing a new reply. I will let go of this habit, I promise.

RO.maniac said:
This is what I may seem not to understand. When I flash a complete .ftf doesn't EVERYTHING change, including the bootloader?
You are asking like it's there for some time, surviving .ftf flashes.
Click to expand...
Click to collapse
afaik ftf files are almost the same that flashable zip files: partition binaries and script files.
To check that, some tools give you the ability of unpack ftf files.
So some ftf custom rom only flash kernel and system, some other flash everything on the phone. Some other add ta partitions modifying.
But as the full boot process is signed, maybe other process are in cause. That's why i'm digging on.
I hope i didn't miss the point. (my English is really bad )
RO.maniac said:
Also, you should watch my past posts here because I tend to edit them a lot and add things instead of writing a new reply. I will let go of this habit, I promise.
Click to expand...
Click to collapse
No worries, but as I'm really slow to write my answers I miss some edits From now I will double check

Your English is not that bad. Yes, you got the point and I got it about the .ftf files.
From what I can remember when I flashed a .ftf of N preview 3, the flashtool log listed everything, from boot to some TA. I'll do a backup and reflash just to check. Will post log.
---------- Post added at 07:20 PM ---------- Previous post was at 06:49 PM ----------
nailyk said:
afaik ftf files are almost the same that flashable zip files: partition binaries and script files.
To check that, some tools give you the ability of unpack ftf files.
So some ftf custom rom only flash kernel and system, some other flash everything on the phone. Some other add ta partitions modifying.
But as the full boot process is signed, maybe other process are in cause. That's why i'm digging on.
I hope i didn't miss the point. (my English is really bad )
Click to expand...
Click to collapse
https://drive.google.com/open?id=0B0YzIybNxHcQNVA3OTZCM2ZqTm8 - flashtool log of N preview 3 flash

You can continue this little study but just so you know, the screen just died on me. It started flicking all of a sudden and in under an hour is gave away for good. Now is backlit but no color.
So the test object is dead.
For the second time, after the main board water damage. I'm officially done with it. When my friend gets back in the country he'll find out his phone died again. ))

As I've said, my screen died. So I decided to dump the phone and cleaned my pc of flashtool, xperia companion and all that.
Some minutes ago I decided to try another flash because my mind was running scenarios about the facts before the screen just died. What happened exactly before: TWRP backup, updated flashtool at startup, flashed N preview 3, in order to get the log so I can see if that Hero7 bootloader is coming with N preview. And it is indeed.
Booted and the screen was flicking with white flashes on the edges. In a few minutes I saw a vertical black line and then it turned black, but backlight on.
Today I thought, what the hell, flash it again, maybe it's not a hw problem. But now I know it is
So I installed an older version of flashtool, 0.9.18.6, and flashed N preview. Still dead screen
But this version of flashtool RELOCKED my bootloader. I could see the code written to TA and I can flash with Xperia Companion. Too bad I don't have a screen.
One in all, just dump this discussion and everything about my friend's damned Z3. Just close the drawer, as I've done.

RO.maniac said:
https://drive.google.com/open?id=0B0YzIybNxHcQNVA3OTZCM2ZqTm8 - flashtool log of N preview 3 flash
Click to expand...
Click to collapse
I see from the github there is a branch 0.9.16 so that is a good idea to test with this version.
First, we see the ta block between your two tries are different. First try block n° 8B2, second try 8FD. I can't understand why (same version of flashtool used).
It take me a lot of time because that was not a hexadecimal place in the ta partition but an unit in the ta partition.
Investigations:
For memory, your unlock code is C88FB2FFCCE72540 (in hex: 43 38 38 46 42 32 46 46 43 43 45 37 32 35 34 30),
my unlock code is 481FD30094B6F2FC (in hex: 34 38 31 46 44 33 30 30 39 34 42 36 46 32 46 43)
If we look in the 8B2 unit we found that:
my ta partition after unlocking
Code:
[COLOR="Magenta"]B2 08 00 00[/COLOR] [COLOR="SeaGreen"]10 00 00 00[/COLOR] [COLOR="Blue"]C1 E9 F8 3B FF FF FF FF[/COLOR] 34 38 31 46 44 33 30 30 39 34 42 36 46 32 46 43
your ta partition after unlocking:
Code:
[COLOR="magenta"]B2 08 00 00[/COLOR] [COLOR="SeaGreen"]10 00 00 00[/COLOR] [COLOR="Blue"]C1 E9 F8 3B FF FF FF FF[/COLOR] 43 38 38 46 42 32 46 46 43 43 45 37 32 35 34 30
So our unlock code is present. Why it doesn't work?
If I take a look in my ta partition, before unlocking my bootloader, there is no 8b2 unit.
For the 8FD unit, i cannot find it.
So I cannot understand why your first try did not lock the bootloader. Maybe an issue with the usb cable and/or the booted mode, or just with the download of flashtool.
RO.maniac said:
You can continue this little study but just so you know, the screen just died on me. It started flicking all of a sudden and in under an hour is gave away for good. Now is backlit but no color.
So the test object is dead.
For the second time, after the main board water damage. I'm officially done with it. When my friend gets back in the country he'll find out his phone died again. ))
Click to expand...
Click to collapse
That's sad. I read some thread about dead backlights but not about screen. Did you think software cause this?
RO.maniac said:
As I've said, my screen died. So I decided to dump the phone and cleaned my pc of flashtool, xperia companion and all that.
Some minutes ago I decided to try another flash because my mind was running scenarios about the facts before the screen just died. What happened exactly before: TWRP backup, updated flashtool at startup, flashed N preview 3, in order to get the log so I can see if that Hero7 bootloader is coming with N preview. And it is indeed.
Booted and the screen was flicking with white flashes on the edges. In a few minutes I saw a vertical black line and then it turned black, but backlight on.
Today I thought, what the hell, flash it again, maybe it's not a hw problem. But now I know it is
So I installed an older version of flashtool, 0.9.18.6, and flashed N preview. Still dead screen
But this version of flashtool RELOCKED my bootloader. I could see the code written to TA and I can flash with Xperia Companion. Too bad I don't have a screen.
One in all, just dump this discussion and everything about my friend's damned Z3. Just close the drawer, as I've done.
Click to expand...
Click to collapse
Maybe it is just a connection problem between the motherboard and the screen. I read your other post so it maybe is 'just' a bad connection (cleaning or flyed-up)?
Anyway thanks a lot for your time, I learn a lot with information you provide! I will mostly help me for this project.
P.S.: don't forget I'm looking for a dev z3, broken screen is not a big deal for me Contact me privately if your friend is ok to sell that phone to me.
P.S.2: just for fun:
if you take a look in the (critical) 7DA ta unit it look like:
Code:
hexdump -C TA.img -s 0x0002073c -n 664
0002073c [COLOR="Magenta"]da 07 00 00[/COLOR] [COLOR="SeaGreen"]87 02 00 00[/COLOR] [COLOR="Blue"] c1 e9 f8 3b ff ff ff ff[/COLOR] |...........;....|
0002074c 73 eb 3d 40 59 80 18 1a 68 1a 33 84 5b a6 ad c3 |[email protected][...|
0002075c 45 d3 66 47 02 00 05 0a 02 00 00 00 0a db 37 24 |E.fG..........7$|
0002076c 02 0c b2 c4 85 f4 c9 6c 21 f1 84 33 29 4d 27 ff |.......l!..3)M'.|
0002077c 81 20 a3 65 b6 40 3c 80 16 c9 4a e3 1b 59 d6 54 |. [email protected]<...J..Y.T|
0002078c fa 50 37 82 f9 50 53 ce 1c dc aa fb 0b 98 96 e3 |.P7..PS.........|
0002079c 22 6a 02 00 00 00 0a d2 d9 95 24 b0 77 2b 91 59 |"j........$.w+.Y|
000207ac 59 f2 ee 30 a1 dc d9 88 c7 79 51 20 a2 19 73 0e |Y..0.....yQ ..s.|
000207bc 30 4c a1 29 94 4c 43 2b 8a cd 23 e9 3a 09 0b 03 |0L.).LC+..#.:...|
000207cc 06 74 6a 86 1f ce 97 ea 6c d0 b7 ba 00 90 4f 50 |.tj.....l.....OP|
000207dc 5f 49 44 3d 22 34 33 35 22 3b 4f 50 5f 4e 41 4d |_ID="435";OP_NAM|
000207ec 45 3d 22 43 75 73 74 6f 6d 69 7a 65 64 22 3b 43 |E="Customized";C|
000207fc 44 41 5f 4e 52 3d 22 31 32 38 38 2d 35 30 32 38 |DA_NR="1288-5028|
0002080c 22 3b 52 4f 4f 54 49 4e 47 5f 41 4c 4c 4f 57 45 |";ROOTING_ALLOWE|
0002081c 44 3d 22 31 22 3b 52 43 4b 5f 48 3d 22 46 41 45 |D="1";RCK_H="FAE|
0002082c 46 35 31 39 39 31 34 31 39 34 36 38 43 41 37 38 |F51991419468CA78|
0002083c 43 39 43 33 37 30 38 35 36 31 36 43 42 33 31 39 |C9C37085616CB319|
0002084c 42 39 46 36 36 45 30 35 30 45 34 33 31 38 34 37 |B9F66E050E431847|
0002085c 41 39 41 34 36 46 43 33 39 44 42 41 34 22 00 43 |A9A46FC39DBA4".C|
0002086c 53 45 52 56 45 52 49 44 3d 22 62 6d 63 73 65 63 |SERVERID="bmcsec|
0002087c 73 30 33 22 3b 41 55 54 48 43 45 52 54 3d 22 55 |s03";AUTHCERT="U|
0002088c 4e 4b 4e 4f 57 4e 22 3b 54 49 4d 45 53 54 41 4d |NKNOWN";TIMESTAM|
0002089c 50 3d 22 31 35 30 34 30 39 20 32 30 3a 33 31 3a |P="150409 20:31:|
000208ac 35 38 22 00 09 00 07 30 30 31 30 31 2d 2a 00 00 |58"....00101-*..|
000208bc 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0a 4e |...............N|
000208cc d0 29 6b 2c bf 7b ec 14 0b bb 94 f5 9c fa 62 6a |.)k,.{........bj|
000208dc 1c 02 61 20 6d 79 f5 a7 3e ca c6 6e 30 69 30 f7 |..a my..>..n0i0.|
000208ec c3 a4 80 1e 60 bc ba e8 59 7d 5e 99 55 c4 47 e9 |....`...Y}^.U.G.|
000208fc f5 f5 58 be 02 00 00 00 0a 36 04 d9 c2 fd 86 a1 |..X......6......|
0002090c a1 3c 91 c1 d0 8d bb 35 ab a6 b1 10 f0 20 67 0e |.<.....5..... g.|
0002091c dc a5 62 dd 45 db 51 1e eb 6e f7 c6 95 58 f1 d4 |..b.E.Q..n...X..|
0002092c 39 73 5d 53 c5 22 14 b2 06 be 0c 01 ea 5f 02 00 |9s]S."......._..|
0002093c 00 00 0a 22 39 fe 4a f7 2e 93 6d a7 70 5d 3e 53 |..."9.J...m.p]>S|
0002094c a3 11 6c 96 70 84 18 20 3a 17 7b 00 05 63 1b fc |..l.p.. :.{..c..|
0002095c 6b 96 a4 e2 22 33 e2 05 7a 38 7b 72 81 60 ee ec |k..."3..z8{r.`..|
0002096c f9 da 55 c8 c1 81 e7 bd 02 00 00 00 0a cc 10 ff |..U.............|
0002097c a1 49 75 63 f3 c9 ee 40 fa d8 ac 09 65 b6 e6 dc |[email protected]|
0002098c a3 20 9c 57 33 bf 51 c3 ff 29 20 78 fa 57 2c 69 |. .W3.Q..) x.W,i|
0002099c a5 97 52 fc 33 fa 97 f6 3d 5d 38 89 e0 d7 34 1c |..R.3...=]8...4.|
000209ac 95 eb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000209bc 00 00 14 57 0a e6 ee af 30 a1 e8 57 69 59 10 22 |...W....0..WiY."|
000209cc 6f 78 32 5c 5c f4 0b ff |ox2\\...|
000209d4
There is a RCK_H key. With the script provided here i enter your unlock code and the script answer that:
Code:
RCK_H="FAEF51991419468CA78C9C37085616CB319B9F66E050E431847A9A46FC39DBA4"
When you enter 'fastboot oem unlock <key>' the key is computed by s1 and compared to this information.

EDL partitions cloning

Hi,
As Redmi 4A are already pretty cheap I wanted to experiment a bit. I have two of them, which one of them had unlocked bootloader and second did not.
I used emmcdl.exe to dump all partitions from one with unlocked bootloader:
Code:
# PartNum PartName StartSec NumSecs
# PartNum PartName StartSec NumSecs
1 modem 131072 172032
2 fsc 393216 2
3 ssd 393218 16
4 sbl1 393234 1024
5 sbl1bak 394258 1024
6 rpm 395282 1024
7 rpmbak 396306 1024
8 tz 397330 4096
9 tzbak 401426 4096
10 devcfg 405522 512
11 devcfgbak 406034 512
12 dsp 406546 32768
13 modemst1 439314 3072
14 modemst2 442386 3072
15 DDR 524288 64
16 fsg 524352 3072
17 sec 527424 32
18 splash 655360 40960
19 aboot 786432 2048
20 abootbak 788480 2048
21 boot 790528 131072
22 recovery 921600 131072
23 devinfo 1052672 2048
24 system 1054720 6291456
25 cache 7471104 524288
26 persist 7995392 65536
27 misc 8060928 2048
28 keystore 8062976 1024
29 config 8064000 64
30 oem 8064064 131072
31 limits 8257536 64
32 mota 8388608 1024
33 dip 8389632 2048
34 mdtp 8391680 65536
35 syscfg 8457216 1024
36 mcfg 8458240 8192
37 lksecapp 8519680 256
38 lksecappbak 8519936 256
39 cmnlib 8520192 512
40 cmnlibbak 8520704 512
41 cmnlib64 8521216 512
42 cmnlib64bak 8521728 512
43 keymaster 8522240 512
44 keymasterbak 8522752 512
45 apdp 8650752 512
46 msadp 8651264 512
47 dpo 8651776 16
48 cust 8781824 1048576
49 userdata 9830400 51240927
and then I have written them to the second Redmi 4A (I dumped them again, checked CRC sums which were fine). I hoped I got clone of the phone. Unfortunately I did not. I lost imei's and what is more phone stopped charging. WiFi and other functions are working working.
Are persist and modemst partitions that contain information about sensors and imei's?
Do you have idea what may went wrong as clonning partitions went OK ?

.