Related
Summary: in many cases this allows to revive (not really repair!) your N7000 (and some other samsung devices) after an emmc brick and should be relatively easy to follow. The method uses PIT files.
Note: This thread is rather old now (2012).
Please note that the emmc brick bug should be triggered only by a combination of a few conditions:
an old samsung ics kernel (from Ice Cream Sandwich versions 4.0–4.0.4, see wikipedia)
wiping or formatting by custom software, usually an old cwm of that time (especially an often used file called CWM.ZIP)
most important: an older emmc chip (or firmware).
All affected devices should be covered by the thread, some got patched PIT files, some could not be supported (see below).
Some insights here (as part of this thread)
after the problem had been analyzed by the community and Samsung, all those parts got fixed to prevent the problem for the future.
In case only one of the conditions is not true, the brick should not happen.
So if you have more current hardware (somewhat newer than note1) or current software (newer than ics), the bug will not happen.
So, as an example, S3 or Note 3 should be safe because both hardware and software are fixed.
Especially, all current roms or recoveries should be safe.
If you have a brick nowadays, it's very very unlikely it's an emmc brick. Instead you probably have some other problem.
So in most cases, don't look here, unless you are using rather old devices and rather old software.
Note: this is a living post, it will change while progressing. If you want to refer to it, please make a reference to the whole thread (this link).
Don't directly link to the attached files, as they will go away, when I update the files or their names from time to time.
Note: You should generally post in the correct thread (please look in my signature)
Note: I will answer PMs which are of general interest relating to one of my topics (please look in my signature) publicly in the thread (quoting your interesting paragraphs).
It's sad the following has to be said in such big letters, but there are still people not reading anything and therefore failing seriously:
Please, please, please:
Read this multiple times and try to understand all aspects before using anything of this thread.
If you have questions, read it again!
If you have questions, read it again!
...
If you have questions, read it again!
If you have questions, read it again!
If you don't know exactly what you are doing, you may HARM your device seriously or even DAMAGE it for all times (e.g. meaning motherboard has to be changed with >150EUR).
If you are a noob, then please ask someone with more knowledge to assist you, but ignore those blowhards/bigmouths which will probably do more harm to your phone than you would.
If you have questions, read first post again and again and also read the whole thread!
Most questions are asked several in this thread and are already answered in this first post. Others are answered later in the thread. You should also use the search function before asking something a second time.
Please don't waste my time with superfluous questions already answered in the thread only because you are too lazy to search for it!
It took much much time to write this down and describe most aspects. So, please take a similar amount of YOUR time to read it carefully.
Certainly, my descriptions will not be perfect, so if you are SURE your question is NOT answered HERE, then you are welcome to ask in the thread. But don't expect a quick answer. I am usually very busy with other things and I am doing this only to help other people. I definitely don't generate any profit from this...
Please don't quote this post (in it's entirety), because it's very long and will disturbe all other readers. Instead post without a quote or extract some of the text you are referring to. I think this should be common sense...
You can find the former first post of this thread at post #9...I switched it with this continuously updated post, which I hope is more understandable for the users of this method.
-------------------- manual method and tools for using adb
I think forest1971's thread is better for the description of and questions about the manual method which I used first to revive my own phone. Looks like we developed the same thing at the same time. I started this thread before I read his (I also wasn't an active user of xda before).
Along the way our threads started to be companions to each other.
forest1971's thread has some useful tools for using in adb. Some of these will be useful for procedures described here.
But please read on, because I think the PIT file method is easier for most users with kind of standard emmc bricks.
It's less error prone, because you don't have to calculate the numbers yourself (my pit generator script did it already).
However, the manual method can do more, especially if you have special cases.
-------------------- find begin and end of bricked area
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You should write down two numbers:
* where emmc_find_brick_start.zip freezes -> BRICK_START
* where emmc_find_brick_end.zip freezes -> BRICK_END
I have reports, that the stock recovery doesn't show the output of the scanners, so you should probably install a custom recovery first (see forrest1971 's thread).
-------------------- patched pit files
I finally hacked a perl script, which generates a set of PIT files for me.
But because I cannot test the PITs on my phone (because I need it):
==> NO GUARANTY <==
Say you have a situation like this:
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
^ ^
| |
BRICK_START BRICK_END
(? = bad blocks)
The repartitioning should leave a hole in the partition table around the bricked area.
Therefore the bricked area will lie fallow (i.e. not accessed) after the repartitioning.
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
(? = bad blocks)
The calculation is done like the following (Example: N7000_16GB) with X being the size of the HOLE:
Code:
16GB original (Q1_20110914_16GB.pit)
FACTORYFS 548864 ->Fo 1744896 ->Fs
DATAFS 2293760 ->Do 4194304 ->Ds
UMS 6488064 ->Uo 23232512 ->Us
HIDDEN 29720576 ->Ho 1048576 ->Hs
16GB MMC_CAP_ERASE patched
FACTORYFS FoX = Fo+X unchanged
DATAFS DoX = Do+X unchanged
UMS UoX = Uo+X UsX = Us-X
HIDDEN unchanged unchanged
The PITs are named like that:
N7000_16GB_Q1_20110914--patched--brick-between-281-and-2428-MB--FACTORYFS-moved-by-2048-MiB
This PIT is for the N7000 with 16GB and derived from the file Q1_20110914.pit.
Here, the HOLE is from 281 MB up to 2428 MB (MB = 1000000 bytes) which is 2147 MB or 2048 MiB (MiB = 1024*1024 bytes) in size.
So the following relations have to match: BRICK_START >= 281 MB and BRICK_END <= 2428 MB
Note that these numbers are rounded, so if your brick lies exactly on this border, it is possible that your aprtitions are not brick free after the repartitioning.
So to be sure this would be safer: BRICK_START > 281 MB and BRICK_END < 2428 MB
In the example all partitions from FACTORYFS up to the "big" partition (here UMS) have their beginning moved by 2048 MiB.
The "big" partition is shrinked by the same amount, so it ends at the same block as before the repartitioning.
Therefore the following partitions (only HIDDEN in this case) remain unchanged.
All partitions before the first moved partition (FACTORYFS) remain also unchanged.
I recently added more starting partitions for the brick (XXX-moved-by-...).
As a rule, all partitions from this starting partition up to the "big" partition are moved by the size of the HOLE.
All partitions in front of the starting partition and all partitions after the "big" partitions remain unchanged.
Code:
case FACTORYFS-moved-by-...
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
case DATAFS-moved-by-...
before: ...-|-FACTORYFS-|D??T?FS-|-UMS------------------------------------|...
after: ...-|-FACTORYFS-| ?? ?|-DATAFS-|-UMS------------------------------|...
\ /
-+-
|
HOLE
(? = bad blocks)
The PIT file will repartition the phone automatically when flashed using Odin, but the moved partitions will not be formatted after that.
If you flash a partition in Odin, you will also put a valid file system on this partition(because the partition image also contains the file system).
For all other partitions, you have to format those partitions, before you can use them.
At least the data partition should be formatted
The revived phone does in nearly no user noticeable way differ from a stock phone afterwards.
You just have a smaller internal sd (called "big" partition above) and you cannot flash a stock pit file again (this would revert the phone to the bricked state).
ATTENTION: different recoveries and ROMs mount external and internal sdcard on varying directories.
I also had the following problem:
I couldn't format my internal sdcard with the cm9 recovery. I think it's too big for the mkfs.vfat tool of current cm9. So I installed another recovery, formatted the internal sd (I thought).
This erased all my current backups and downloads, because in reality it was my external sd. Fortunately I had a backup of the external sdcard from before rescuing my phone.
So, you may want to create a backup of your external sdcard first.
Then double check which is your internal sdcard (the UMS partition) and which is your external sdcard.
Or you could remove the external sd completely. But think about when to remove it, because you might need it for some files (e.g. to use the emmc partition scanner).
-------------------- backup
before messing with the partition table, everyone should make backups of all partitions that can be accessed.
-------------------- efs backup
The most important backup is the efs partition, which very crucial, it includes your IMEI number, bluetooth MAC etc., and without this individual information, your phone cannot be used as a phone again.
For most supported phones, you can do this via adb:
Code:
dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard/efs.img
please look at forrest1971's thread for details about using adb.
If your phone uses another partition number for efs, then use this instead of the "1" in mmcblk0p1.
Perhaps you have to mount your sdcard first, to be able to save it there.
Then you should copy the backup to your PC (the recovery should have the option to mount usb).
-------------------- backup files from internal sd before repartitioning
the repartitioning will clear all data in the affected partitions, so all data in your big partition (internal sd etc.) will be lost.
You can try to backup your data, if the partition is accessible. The different methods below may have different success, depending which parts of your phone are usable.
* you can use aroma file manager, which is a full fledged gui file manager which starts standalone by being flashed in CWM. So it should be completely independent (sorry, I could not test it for this kind of backup myself).
For the following possibilities you should first ensure, you have a working recovery with working adb support.
Mount your external sd in recovery (which might be /emmc or /sdcard, please check), to be able to copy files.
* you can use QtAdb to copy files to your PC:
* you can use adb pull to copy any files or directory tree to your PC, e.g.:
adb pull /emmc/. emmc
* you can use tar from adb to archive files to a file on sdcard:
adb shell tar cvjf /sdcard/emmc.tar.bz2 /emmc/.
* you can use a copy command in adb shell to copy files to a folder in sdcard:
adb shell cp -ra /emmc/. /sdcard/emmc.backup
Note: you will loose file attributes and owner information if emmc is formatted with ext2/ext3/ext4, because vfat cannot handle these.
This may matter for system and some app related files.
-------------------- recommended procedures for "standard" cases
"standard" in this sense are pits that only affect FACTORYFS, DATA, CACHE or internal SD (UMS/USERDATA etc.).
All other partitions need special considerations and are not handled in this section!
Note these are from theory only. My phone is running now and I don't want to brick it again, only for testing the procedure.
Therefore the procedure is *NOT* tested (by me) and may contain problems which I didn't expect!
So be "careful with that axe, Eugene!"
Note, there are always multiple ways to reinstall the phone.
phase "find brick"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* flash emmc_find_brick_start.zip, note where it freezes -> BRICK_START
* flash emmc_find_brick_end.zip, note where it freezes -> BRICK_END
phase "flash pit and ROM"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a known good ROM via Odin (especially not a faulty stock ICS ROMs)
phase "check partitions"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* check the partitions (see section "checking all partitions" below)
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format cache
* format data
* format internal SD (if it fails read below)
phase "start ROM"
...
After formatting or wiping data you can probably also boot into the ROM and format the internal sd from there (again: keep the external sd removed, to not format the external sd instead of the internal sd unintentionally).
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
I would recommend a cyanogen ROM though, if you can live with some features missing from stock ROM.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
It may be easier to take a custom ROM with a better custom recovery, but it has to be flashable via Odin (tar file).
A second method is via recovery using a custom kernel:
phase "find brick" like above
phase "flash pit and kernel"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a custom kernel with a good recovery (e.g. cm9 safe kernel) via Odin (which will increment the flash counter! -> yellow triangle -> warranty lost until you reset the counter)
phase "check partitions" like above
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format system
* format cache
* format data
* format internal SD
phase "install ROM"
* install the zip of the ROM
phase "start ROM"
...
So you generally install the ROM like usual, the only difference is to restore all the partitions moved by the repartitioning with the patched PIT.
This is neccessary because all changed/moved partitions don't have a valid file system or content after the repartitioning.
For some partitions this can be done by a simple format (cache, data, internal sd).
Others need true contents (e.g. system, kernel, recovery can be restored by installing a rom/kernel/recovery).
In other cases (non-standard situations) you need to restore a backup (efs, if you have one) or some generic contents (param, sbl1/2).
EFS is the most critical one, because it contains information unique to your own phone. Also see the efs section in this post.
I assume SBL1/2 are needed by the boot process (secondary boot loader), but I never tested this. I don't even know where to get these boot loaders (which probably have to be installed with the PIT via odin, because they are involved in the boot process).
You may find other important information in the thread, please read it completely before asking the same things over and over again.
There may also be useful information and experiences from users.
I try to incorporate useful information in the thread starter, but my time is often very limited.
Also, some information may not look valuable enough for me to integrate it, but it may be valuable for you.
...suggestions or corrections welcome!...
-------------------- checking all partitions for bricked blocks
After repartitioning some partitions may still have bricked blocks inside (because of moving brick or choosing a wrong pit etc.).
Bricked blocks in any partition will lead to random freezes when these blocks are accessed in any way.
So you should check all your partitions after repartitioning to be sure.
With both methods below, you can check the partitions even before formatting any of them.
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You can also do it manual via dd commands in adb, but this is much slower.
Use commands like this, using the partition block device in the if=... argument:
adb shell dd if=/dev/block/mmcblk0p1 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p2 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p3 of=/dev/null
...
adb shell dd if=/dev/block/mmcblk0p9 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p10 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p11 of=/dev/null
etc.
If any of these freeze the phone (or reboots the phone or doesn't come to an end even after an hour), you probably (still) have bricked blocks inside the according partition.
-------------------- pit.str for DataWorkshop
For those who want to edit their own patched pit file, I made a structure definition file (pit.str) for an open source multi-platform tool (java) called DataWorkshop, which allows looking at binary data in structured form.
The tool is not very comfortable when it comes to copy/paste etc. but you can edit the values (just put the cursor at the correct digit before typing the number).
Please ask (PM), if you are interested in this.
-------------------- PITs for other devices
Because Samsung doesn't fix their kernels (thinking their software doesn't have the problem) there is a growing number of affected devices.
Look at the attached files, which devices are currently available.
If pits for your device aren't available yet, please send me a stock PIT and tell me which partitions are bricked (or BRICK_START and BRICK_END, and if you know, which partitions are usually bricked for your device).
I'll look what I can do...
I will add comments for special cases below.
-------------------- device i9250 - experimental PITs
I added i9250 PITs which are very experimental, because I don't know how some details of it's stock PIT affect the result. May be it breaks everything, so beware.
I added this especially for Shanava, who said to be able to recover even from a hard brick.
His brick is in userdata.
So this will probably revive the internal sd (is it userdata?) and reinstalling a ROM shouldn't be necessary, only formatting userdata.
But I also added system and cache as possible starting partition for the brick, then you have to install a ROM and format cache accordingly.
-------------------- devices not supported/supportable
i9000, i9300 (and similar):
These devices have a different PIT structure.
The structure for each partition entry doesn't include an offset, so I don't know a way to define a gap for skipping the bricked blocks.
Inserting an unused partition changes the partition numbers after it, which shouldn't work.
-------------------- FOR-EXPERTS-ONLY packages
DO NOT USE one of the packages with "FOR-EXPERTS-ONLY" in it's name unless you are REALLY REALLY sure how to handle/restore/initialize all the affected partitions, often meaning you were involved in the discussion leading to these files or you read this VERY carefully.
These packages contain files to be used by those who have special problems and want to take the risk to try them.
They are only documented by the corresponding discussion (somewhere in this thread).
note: this is a living post, it changes while progressing. If you want to refer to it, please make a reference to the whole thread, beginning at the first post.
Don't directly link to the attached files, as they will go away, when I update the files and their names from time to time.
Let's hear it....
ok I wait. ..
Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S
RavenY2K3 said:
Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S
Click to expand...
Click to collapse
That's why I said "Let's hear it....". Like, I am very curious because I noticed the same thing you did. I hate doubting people, but sometimes you have to.
hg42 said:
go straight ahead to the final solution (see next post)...
Click to expand...
Click to collapse
andreww88 said:
Let's hear it....
Click to expand...
Click to collapse
errr
I very much doubt it. But lets hear your version of "The curious case of Benjamin eMMC bug"
panyan said:
errr
Click to expand...
Click to collapse
Why did you quote me?
Repartitioning around the bad blocks
This is the former first post of this thread...I switched it with a continuously updated version, which is more understandable for ths users of my pit method.
-----------------------snip -------------------------------------
Hi everyone, especially those with an ICS brick,
last week I jumped straight into a MMC_CAP_ERASE brick.
Sadly, I knew very well what not to do with a LPY kernel on my phone (wiping etc.).
But one weak moment (touching "wipe data/factory reset" in CWM), and then a moment later a flash (pun!) going through my brain, telling me "wow, now the phone will be bricked, right?".
Well I rebooted the phone and thought to be a lucky man, because the system booted correctly.
But after about a minute the SGN started to get FCs in android.*.acore and Google Play etc. I looked with a root file manager and found that the /data partition wasn't mounted.
So I got the BRICK!
After some days of analysing and thinking about the situation, I found a way out of the dilemma. I think, I will not bother you with all the details of these days, but go straight ahead to the final solution...
(this was planned as the second post in the thread, but the dynamic community inserted many post in between, so I added it here sorry, my fault)
---- cut ----
This is a rewrite in english of my report at a german forum:
ICS Brick, Samsung Galaxy Note N7000, Erfahrungsbericht
www.handy-faq.de/.../249283-ics_brick_samsung_galaxy_note_n7000_erfahrungsbericht.html
My brick created bad blocks in the phone's flash memory.
I got I/O-Errors when attempting to read or write those blocks.
My SGN was still able to boot into recovery and all kinds of kernels/recovery.
Odin was able to flash boot loaders, kernels, modems and CSCs.
But flashing a factory_fs stopped at the very beginning.
I found, that any access to some blocks inside /system and also ANY access to /data left an inaccessible phone and I had to restart it.
For all of the following I needed access to some tools (mainly e2fsck and parted).
As I had completely deleted my system partition before (formatting it), I had no single useful tool around, so the recovery had to provide any of those.
The stock recovery e.g. of KL8 engineering kernel doesn't provide such tools, so I had to find a better one first.
I found all this packed in the Thor kernel, but would not recommend it, because it's closed source.
You may use the tools from forrest1971, see below under "manual method".
One of my attempts to get around those bad blocks, was to create a bad blocks list which can be used by the ext4 file system, I tried this command:
e2fsck -c /dev/block/mmcblk0p9 (which is the /system partition)
Click to expand...
Click to collapse
This failed, because to find out which blocks are bad, e2fsck tries to read them and gets stuck by doing so.
I could have created a list manually, but because the data partition was corrupted starting at it's first block, this bad blocks list wouldn't work here anyway.
At the end, my solution was to recreate the partition scheme, leaving a big hole at the space where /system (893MB) and /data (2147MB) resided before:
Code:
before: - ...-|-FAC?ORYFS-|??ATAFS-|-UMS------------------------------------|...
after: + ...-| ? ?? |-FACTORYFS-|-DATAFS-|-UMS---------------|...
(? = bad blocks, + working, - = not working still bad blocks inside)
In order to not access those bad blocks, I could not move these partitions, but instead I had to delete them first and recreate them at another place afterwards.
So I needed a backup of them first (fortunately I always have 7 Titanium backup levels around).
Here is a log of my steps (but see below in the blue sections for other probably easier procedures):
Code:
I managed to access the device via [I]adb shell[/I]...which is another story for itself...
Then I started [I]parted[/I] with the flash device:
~ # parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
As a greeting I got some error messages about the GPT layout, which parted wanted to fix:
[QUOTE]Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? f
f
f
Warning: Not all of the space available to /dev/block/mmcblk0 appears to be
used, you can fix the GPT to use all of the space (an extra 2048 blocks) or
continue with the current setting?
Fix/Ignore? f
f
f
this was the partition scheme before implementing the workaround:
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
then I deleted the partitions 9=FACTORYFS=/system, 10=DATAFS=/data and 11=UMS=/sdcard(internal) and recreated them starting at the former start of the internal sdcard partition (11) leaving the former space of the /system and /data partitions unused:
(parted) rm 11
(parted) rm 10
(parted) rm 9
(parted) mkpartfs primary ext2 3500 4400
(parted) mkpartfs primary ext2 4400 7000
(parted) mkpartfs primary fat32 7000 15.2G
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
now I upgraded both new ext2 partitions to ext4:
~ # tune2fs -j /dev/block/mmcblk0p9
tune2fs -j /dev/block/mmcblk0p9
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # tune2fs -j /dev/block/mmcblk0p10
tune2fs -j /dev/block/mmcblk0p10
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # e2fsck -fDp /dev/block/mmcblk0p9
e2fsck -fDp /dev/block/mmcblk0p9
/dev/block/mmcblk0p9: 11/439776 files (0.0% non-contiguous), 71701/878907 blocks
~ # e2fsck -fDp /dev/block/mmcblk0p10
e2fsck -fDp /dev/block/mmcblk0p10
/dev/block/mmcblk0p10: 11/317440 files (9.1% non-contiguous), 26386/634765 blocks
and this is the final partition layout:
~ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 3500MB 4400MB 900MB ext3 FACTORYFS
10 4400MB 7000MB 2600MB ext3 DATAFS
11 7000MB 15.2GB 8217MB fat32 UMS msftres
12 15.2GB 15.8GB 537MB ext4 HIDDEN
This configuration works so far (one complete day now).
I can install firmwares and restore backups via recoveries.
Also flashing via Odin should work (not tried yet).
I currently can only imagine one standard procedure which will not work, that is creating a new partition scheme, e.g. via Odin (PIT file) or may be a CWM script.
I think/hope this will not occur too often...
-- naturally, it's much faster to insert those short messages than rewriting a long german post in english.
Next time I should write the main text prior to posting anything, I think...
sorry...
WoooooooOOOOOOoooooooowwwww!!!!
YeeeeeeEEEEEEaaaaaAAAAAaaaahhhhhh!!!!!!
You are the man, bro.
man has a few posts but are worth a lot. .. thanks for share with us
And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Is the damage so serious? Is it physical??
Interesting Read, this should be of a great help to those bricked without warranty.
straycat said:
And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Click to expand...
Click to collapse
you *can* indeed try to recreate the standard partition scheme (I did it very early with a PIT file in Odin and also tried formatting those partions etc.), but this doesn't work because *accessing* those blocks in any way is the *real* problem.
Is the damage so serious? Is it physical??
Click to expand...
Click to collapse
yes, you can't even fix the bad blocks with the usual JTAG equipment.
I was told by a technician from a good repair center that a fix could eventually be possible by directly reprogramming the flash chip in some way (JTAG again), but no one tried yet, because this would cause several hours of work...
usually they swap the whole motherboard instead (which is >250EUR)
Thanks, hg42.
I really apreciate your efforts and to share with us.
I'm not a superbriked note owner but I follow with great interest those posts.
Again, thank you, man.
Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Thanks anyway for your efforts!
Sent from my GT-N7000 using Tapatalk 2
Zamboney said:
Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Click to expand...
Click to collapse
LOL, you're right, at the end I also thought, that's really simple
but, at least...I had several problems to solve before getting adb up and running properly with root permissions and having the necessary tools at hand (inside adb).
I think this was mainly because I wiped my /system before.
But, it's easy to be wise after the event.
hmm, I tried to export this partition scheme to a PIT file (using heimdall-frontend), but I got a file that is exactly equal to the one I flashed last via Odin, which was Q1_20110914_16GB.pit.
So I assume the PIT file is one way only?
A PIT file would probably allow even unexperienced users to unbrick their phones.
This is the same method here:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
Although your post I found easier to read.
Hi Folks!
It is a simple guide to backup and restore efs and others partitions in your device, i use to backup IMEI and avoid " emergency calls only ".
Requirements:
Terminal Emulator
EFS Professional Backup - thanks a lot @lyriquidperfection for the great program!
BusyBox
Drivers update
USB Debugging ON
Root
Guide (BACKUP):
Open EFS Professional Backup and wait to check some requirements, then go to Backup tab;
In "Devices Filters" select 'All partitions';
In "Devices Partitions" choose: modem, efs, modemst1, modemst2, fsg, fsc, backup, dbi, ddr and pad [modemst1 and modemst2 for dual sim devices];
Then press backup button and save this file .
Guide (RESTORE):
To restore just find file in "Backup Archives" and press restore button.
Method 2 thanks for @jackeagle:
Open terminal emulator and write: su
Allow root permission if asked
Write this: dd if=/dev/block/mmcblk0p11 of=/sdcard/efs.img bs=4096
Look at your internal storage for efs.img (14 mb)
If saved your device don't forgot press thanks button
Hy, has maybe anyone a EFS file for a S5 mini duos? I would be very happy... tnx
zippyzippy said:
Hy, has maybe anyone a EFS file for a S5 mini duos? I would be very happy... tnx
Click to expand...
Click to collapse
Do not use other Device EFS Partition .. IMEI is unique for every device and every device which is manufactured will be given different IMEI no hence you cannot use any other device IMEI its against the law... if you have not done backup of efs partition then you may have to take your device to your Samsung Service Center and they will repair it for you ..
Each device has unique efs, then make backup by yourself
heloo , my problem
In "Devices Partitions" choose: modem, efs, modemst1, modemst2, fsg, fsc, backup, dbi, ddr and pad [modemst1 and modemst2 for dual sim devices];
My phone has only this item :
bota0
bota1
efs
m9kefs1
m9kefs2
m9kefs3
carrier
param
boot
recovery
ota
cdma-radio
tombstones
tdata
persdata
reserved2
system
cach
hidden
userdata
Where I have a problem ?
I do not see why modem, efs, modemst1, modemst2, fsg, fsc, backup, dbi, ddr and pad ?
thx you for your help
TL;DR ... please skip to the bottom for a step-by-step how-to.
It is still a bit of a mystery on how easy it is for someone to lose their EFS data (including baseband/IMEI). It has happened a few times (judging by the forum activity). Even for more reason, especially since this data cannot be replaced without warranty work, it is always best to protect yourself.
So I took the task of backing up all my partitions (some through TWRP, others through shell/dd), and then pulling the dd'd partitions to my PC. Best practice is to back up everything...there may be something else lost that you may need in the future.
My old theory (based on grep'ping the images) targeted p16 and p18. According to /dev/block/by-name, mmcblk0p16 translates to the APD partition (which is related to the demo program), and mmcblk0p18 the system partition ...
Code:
lrwxrwxrwx root root 2015-07-07 16:40 ADF -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2015-07-07 16:40 APD -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2015-07-07 16:40 boot -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2015-07-07 16:40 boot-one-shot -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2015-07-07 16:40 cache -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2015-07-07 16:40 config -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2015-07-07 16:40 data -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2015-07-07 16:40 factory -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2015-07-07 16:40 fastboot -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2015-07-07 16:40 misc -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2015-07-07 16:40 panic -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2015-07-07 16:40 persistent -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2015-07-07 16:40 ramdump -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2015-07-07 16:40 recovery -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2015-07-07 16:40 reserved -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2015-07-07 16:40 silentlake -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2015-07-07 16:40 splashscreen -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2015-07-07 16:40 system -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2015-07-07 16:40 userkeystore -> /dev/block/mmcblk0p8
...however, the location within system is elusive (no common files between the search terms, except "/system/usr/srec/en-US/hmm_symbols", which doesn't seem to count)...
...please note, I have redacted my IMEI segments for protection.
Code:
[email protected]:~/Build/ArchiKitchen-master/PROJECT_070815_181336$ grep -c -r -a abcd * | grep -v :0
system/lib/arm/libcrypto.so:1
system/lib/libstagefright.so:1
system/lib/libcrypto.so:1
system/tts/lang_pico/en-GB_kh0_sg.bin:1
system/tts/lang_pico/es-ES_zl0_sg.bin:1
system/app/ASUSBrowser/ASUSBrowser.apk:2
system/app/LiveWallpapers/LiveWallpapers.apk:1
system/priv-app/GmsCore/lib/x86/libsslwrapper_jni.so:1
system/priv-app/FileManager2/x86/FileManager2.odex:1
system/priv-app/AsusZenUIServices/x86/AsusZenUIServices.odex:1
system/usr/icu/icudt53l.dat:1
system/usr/srec/en-US/hmm_symbols:1
system/usr/xt9/databases/ldb/ZHsbUNps_GB18030_xt9_big.ldb:1
system/bin/wpa_supplicant:1
system/bin/hostapd:1
[email protected]:~/Build/ArchiKitchen-master/PROJECT_070815_181336$ grep -c -r -a efgh * | grep -v :0
system/etc/security/cacerts/ccc52f49.0:1
system/etc/catalog/V1_7260/audiocomms_config/parameter-framework/Settings/Audio/AudioConfigurableDomains.xml:35
system/etc/catalog/V1_DSDA/audiocomms_config/parameter-framework/Settings/Audio/AudioConfigurableDomains.xml:29
system/framework/x86/boot.oat:1
system/usr/srec/en-US/hmm_symbols:1
system/usr/xt9/databases/ldb/ENubUN_xt9.ldb:1
system/usr/xt9/databases/ldb/ESusUN_xt9.ldb:1
system/vendor/lib/libWVStreamControlAPI_L1.so:1
[email protected]:~/Build/ArchiKitchen-master/PROJECT_070815_181336$ grep -c -r -a ijkl * | grep -v :0
system/etc/security/cacerts/d16a5865.0:2
system/tts/lang_pico/en-GB_kh0_sg.bin:1
system/app/MYuppyHK_Medium/MYuppyHK_Medium.apk:6
system/app/YouTube/YouTube.apk:1
system/app/Newsstand/x86/Newsstand.odex:1
system/usr/srec/en-US/hmm_symbols:1
system/usr/xt9/databases/ldb/ITusUN_xt9.ldb:1
[email protected]:~/Build/ArchiKitchen-master/PROJECT_070815_181336$
Just recently, user noviardi did a real world test with two devices...one with a working baseband, the other with a borked EFS. Noviardi managed to get device number two working by cloning p14 (also known as the config partition). Please note there are consequences, that with this solution, only one device can be "online" at a time, or the functioning IMEI will get blacklisted (then neither devices will have cell access). Which is the least of the problems. Hence, why I do not share my EFS data (neither should anyone else), or even snippets.
So, if you want to back up your EFS for personal resuce, your best shot is to back up the mmcblk0p14 / Config partition. But if you are paranoid (like me ), might as well back up everything.
Here's how to do it:
Connect the device to your PC
Turn on USB debugging (if not already)
From your PC, fire up a terminal/command prompt
Type "adb shell" (without the quotes - may need to add "sudo" to the front depending on your situation)
Run these commands:
Code:
su
dd if=/dev/block/mmcblk0p14 of=/storage/MicroSD/mmcblk0p14.img
Repeat the last line for any other partitions to back up (changing both numbers)
Type "exit", press enter (and repeat to close adb shell)
Run the following command:
Code:
adb pull /storage/MicroSD/mmcblk0p14.img .
Repeat for any other partitions to copy to your PC
Close out terminal, unplug USB cable.
Also, there is at least one version of TWRP (TheSSJ's release) that will back up your Config partition for you, as Config is also responsible for connectivity issues (not related to IMEI) switching between ROM's.
Hope this helps on how to protect your IMEI, with a big thanks to noviardi.
Mines showing that too..emei of abcdefgh........and not number sometimes...its weird.
pato2015 said:
Mines showing that too..emei of abcdefgh........and not number sometimes...its weird.
Click to expand...
Click to collapse
I clarified my text above.
I masked my IMEI (with abcd...) in the code boxes as I did not want even part of my IMEI known (for personal security reasons). My actual terminal I used the numbers in groups of four obtained from dialing *#06#.
If you are getting letters after dialing *#06#, I must ask - can you dial out? Did you do any modifications to the phone since you got it (e.g. root, unlock bootloader, etc)?
joel.maxuel said:
I clarified my text above.
I masked my IMEI (with abcd...) in the code boxes as I did not want even part of my IMEI known (for personal security reasons). My actual terminal I used the numbers in groups of four obtained from dialing *#06#.
If you are getting letters after dialing *#06#, I must ask - can you dial out? Did you do any modifications to the phone since you got it (e.g. root, unlock bootloader, etc)?
Click to expand...
Click to collapse
Im still on stock due , i join the asus beta program on going ....change imei only appears abcd change imei only appears during when im on recovery mode...when pound number sign asterisk it imei appears the original imei on my side.
pato2015 said:
Im still on stock due , i join the asus beta program on going ....change imei only appears abcd change imei only appears during when im on recovery mode...when pound number sign asterisk it imei appears the original imei on my side.
Click to expand...
Click to collapse
Doesn't sound corrupted then, just boatloader is being protective.
Or at worst, bug in boatloader.
Sent from my ASUS ZenFone 2
I haven't heard of any easier way or any potential issues, but as always, better safe than sorry with this stuff .
Hi,
I tried to copy the blocks from a terminal emulator on the device itself, and it took a long time and I cancelled it. How big are the blocks, and how long should the copy take?
BobboVilla said:
Hi,
I tried to copy the blocks from a terminal emulator on the device itself, and it took a long time and I cancelled it. How big are the blocks, and how long should the copy take?
Click to expand...
Click to collapse
mmcblk0p16 is about 300MB, so will take a couple minutes (one to dd it, the other to adb pull it). mmcblk0p18 (which I don't think carries EFS as I was able to grep the individual files in the system partition and no common files came up) is ~2.3GB and will (probably) take over 10 minutes.
Also, my procedure above assumes you have a MicroSD card inserted. Don't know the outcome if one ran the commands without one (probably an out of space error).
joel.maxuel said:
mmcblk0p16 is about 300MB, so will take a couple minutes (one to dd it, the other to adb pull it). mmcblk0p18 (which I don't think carries EFS as I was able to grep the individual files in the system partition and no common files came up) is ~2.3GB and will (probably) take over 10 minutes.
Also, my procedure above assumes you have a MicroSD card inserted. Don't know the outcome if one ran the commands without one (probably an out of space error).
Click to expand...
Click to collapse
Thanks. Although I'm not an android developer, I am a programmer, so I can understand code/scripting, and I realized that the command assumed I had an SD card .
I'll do it again and this time let it finish .
mmmm i tried this procedure (also used for oneplus one) and works well.
Type "adb shell" (without the quotes - may need to add "sudo" to the front depending on your situation)
Run these commands for backup efs:
su
dd if=/dev/block/mmcblk0p10 of=/sdcard/modemst1.bin bs=512
dd if=/dev/block/mmcblk0p11 of=/sdcard/modemst2.bin bs=512
Modemst1.bin and Modemst2.bin are saved in internal storage
for restore use fastboot
fastboot flash modemst1 modemst1.bin
fastboot flash modemst2 modemst2.bin
Bye.
fosseperme said:
mmmm i tried this procedure (also used for oneplus one) and works well.
Type "adb shell" (without the quotes - may need to add "sudo" to the front depending on your situation)
Run these commands for backup efs:
su
dd if=/dev/block/mmcblk0p10 of=/sdcard/modemst1.bin bs=512
dd if=/dev/block/mmcblk0p11 of=/sdcard/modemst2.bin bs=512
Modemst1.bin and Modemst2.bin are saved in internal storage
for restore use fastboot
fastboot flash modemst1 modemst1.bin
fastboot flash modemst2 modemst2.bin
Bye.
Click to expand...
Click to collapse
Keep in mind that procedure backs up "reserved" and "panic" for this device, as this one does not have modemst1/2 partitions.
It is still a hunting match.
Sent from my ASUS_Z00AD
if I could get a copy of mmcblk0p16 ? whether it is contained individual device's IMEI number ?
omgwtf19924 said:
if I could get a copy of mmcblk0p16 ? whether it is contained individual device's IMEI number ?
Click to expand...
Click to collapse
I wouldn't recommend that. Because it is the phone's unique identity like someone's fingerprints, services like cell providers will have difficulty distinguishing one from the other, and I think the policy in that case is to shut both devices down (blacklist the IMEI). So now, you would have two unusable devices.
I got your PM also, reconstructing that partition (that is your EFS) is a taboo topic, mostly because it is illegal in many countries. I wouldn't recommend that either.
Best course of action is servicing. Even if you voided your warranty, ASUS won't say no, it's just be prepared to pay (more). Of course, in this case you could pretend the warranty is still good, go back to unrooted stock, and play unaware...
Just curious, how did you hurt your IMEI? Just to see if there is a pattern of events that can cause that (and ultimately be prevented for someone else).
This happened so that, for some time I could not enter into a standard recovery, update your phone through the built-in program ended in failure, and at the entrance to recovery tried to update the phone and soon jumped mistake. Restore factory settings did not help, full unroot nothing distance, upload the new system did not help ... at the end I installed a temporary CWM used for root and reformatted /factory , /config, /cache, /ADP, /ADF and probably in one of them sat a match for IMEI ... oh well, I contacted ASUS service center and wait for a response. Currently, it is not detected SIM1 and SIM2 work and logs on to the network, both have the same IMEI and should have separate.
EDIT: Phone service reported to ASUS, after returning once the makings copies of files on the future ...
efs problem....help
i lost my asus zenfone 2 ze550ml's efs file so its showing only one dummy imei number,
But i have system backup which i took using temporary recovery
tell me if there is a way to recover efs from system backup?
thanks.
i havnt unlocked bootloader yet!
psurve01 said:
i lost my asus zenfone 2 ze550ml's efs file so its showing only one dummy imei number,
But i have system backup which i took using temporary recovery
tell me if there is a way to recover efs from system backup?
thanks.
i havnt unlocked bootloader yet!
Click to expand...
Click to collapse
I'm pretty sure it's the APD (mmcblk0p16) partition at this point.
You can try to restore system, I just don't think it would be fruitful.
Always curious with this sort of thing, what (do you think) happened that you lost your EFS?
The actual partition that keep imei is on mmcblk0p14 named Config
i got 2 phone with one dead baseband chip to tried out.
the mmcblk0p16 that you mention doesn't contain imei at all..
best luck
noviardi said:
The actual partition that keep imei is on mmcblk0p14 named Config
i got 2 phone with one dead baseband chip to tried out.
the mmcblk0p16 that you mention doesn't contain imei at all..
best luck
Click to expand...
Click to collapse
I was considering this one a while back. There was just no search matches to back that theory up.
If you have successfully revived one EFS with the partition (#14) from the other device, that not only makes sense with the problems I have had with config in the past, also means we have something more solid to go by than just block searches.
Will update in a little bit, with attribution. Thanks!
OfficerJimLahey said:
I was considering this one a while back. There was just no search matches to back that theory up.
If you have successfully revived one EFS with the partition (#14) from the other device, that not only makes sense with the problems I have had with config in the past, also means we have something more solid to go by than just block searches.
Will update in a little bit, with attribution. Thanks!
Click to expand...
Click to collapse
yes sir.
as we now confirmed that the imei is containing in the #14..
let hope some expert will extract the importance imei from that 64mb partition..
the backup command should be
adb shell
su
dd if=/dev/block/mmcblk0p14 of=/storage/MicroSD/mmcblk0p14.img
and restore whole 14 partition from the adb shell
with this command
adb shell
su
dd if=/storage/MicroSD/mmcblk0p14.img of=/dev/block/mmcblk0p14
Recently I tried to root the phone and successfully did it via CWM Temporary Recovery.
I used Exposed Framework, Intelli3G module, greenify etc. My phone was running well except I needed to turn flight mode on and off each time after booting or restarting my phone to get network on sim 1. But it was going well until one day when there was a new OTA update available. I just had forgotten the issue of OTA update on a rooted device.
After updating my rooted device it went into bootlops. I am not so geeky so I was looking for a solution. Then I restored a previous NANDROID backup via CWM but the it was showing error after restoration when the device rebooted.
So then again I went to CWM recovery mode and FORMATTED ALL THE PARTITIONS INCLUDING EFSthen I flashed some downgraded recovery.img, droidboot.img etc and updated my phone with the lattest official stock firmware via CWM
I was lucky to unbrick my phone as it started well
But then the real problem started
THERE'S NO NETWORK ON SIM 1
I reflashed my phone but it was same then I took it to a servicing store they said I have IMEI problem in my phone, the phone is now in the servicing shop,
Isn't there any way to restore my imei???
How about Zenfone Rescue tool kit(by Aztech)??
Can someone post how one can backup efs? I did it thru adb on my one. Just want to make sure how to do it on the two. Thank you
From TWRP recovery choosing into backup only EFS
damsolu said:
From TWRP recovery choosing into backup only EFS
Click to expand...
Click to collapse
Thanks, had already done that and the files that it created didnt say modem.bin etc like it did when I backed up one my One a few months ago. Just want to make sure that what twrp created will be all i need to do? Thanks again
i lost my efs with no backup anyhelp?
godzulu said:
Thanks, had already done that and the files that it created didnt say modem.bin etc like it did when I backed up one my One a few months ago. Just want to make sure that what twrp created will be all i need to do? Thanks again
Click to expand...
Click to collapse
The last time I looked, the EFS backup option in TWRP didn't actually backup the two EFS partitions, so don't rely on it.
There's a flashable zip here that will backup your EFS partitions (modemst1 & modemst2). It also includes a Restore_EFS.bat file that can restore your EFS via fastboot.
Spannaa said:
The last time I looked, the EFS backup option in TWRP didn't actually backup the two EFS partitions, so don't rely on it.
There's a flashable zip here that will backup your EFS partitions (modemst1 & modemst1). It also includes a Restore_EFS.bat file that can restore your EFS via fastboot.
Click to expand...
Click to collapse
yeah..i have backup EFS from twrp but only realize that the EFS backup from TWRP is not EFS, now my IMEI2 lost & i dont know how to solve it. really head ache
I've done a complete device backup and could you tell me which files indicate efs has been backed up ? Is it modem.emmc.win or sbl1.emmc.win or some other file ?
akashpopat21 said:
I've done a complete device backup and could you tell me which files indicate efs has been backed up ? Is it modem.emmc.win or sbl1.emmc.win or some other file ?
Click to expand...
Click to collapse
Did you read the last few posts?
there is one more option, you can backup via flashfire
On creating a back up using TWRP it makes a file named "oem_stanvbk.emmc.win".... Maybe it is having two modems.....any idea how to explore this file? @Spannaa
Droidlover123 said:
On creating a back up using TWRP it makes a file named "oem_stanvbk.emmc.win".... Maybe it is having two modems.....any idea how to explore this file? @Spannaa
Click to expand...
Click to collapse
The oem_stanvbk partition contains the modem (static_nvbk.bin) which is included in OOS roms.
Not sure why you'd want to explore it...
I guess they lost the imei2 (h2o/erase modemst) and they are trying to find out, if this twrp backup file contains the imei2.
pryggi said:
I guess they lost the imei2 (h2o/erase modemst) and they are trying to find out, if this twrp backup file contains the imei2.
Click to expand...
Click to collapse
It doesn't, it's just the modem/radio.
AFAIK, the IMEIs are in modemst1 & modemst2 (The two modem firmware data partitions).
Yep, this is my understanding too. On op2 the modem firmware is in
oneplus2:/ # ls -l /dev/block/platform/soc.0/f9824900.sdhci/by-name
..
lrwxrwxrwx 1 root root 20 1970-08-26 21:51 modem -> /dev/block/mmcblk0p1
And the modem settings/imeis are in:
lrwxrwxrwx 1 root root 21 1970-08-26 21:51 modemst1 -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 1970-08-26 21:51 modemst2 -> /dev/block/mmcblk0p18
The question is, if it is possible to figure out the format of the data on p17/p18 and edit it by adding the imei2 back.
It doesn't seem to be a file system:
Oneplus2:/ # fdisk -l /dev/block/mmcblk0p17
Disk /dev/block/mmcblk0p17: 1 MB, 1572864 bytes
4 heads, 16 sectors/track, 48 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device /dev/block/mmcblk0p17: doesn't contain a valid partition table
file -L /dev/block/mmcblk0p17
/dev/block/mmcblk0p17: block special
and
blkid -o value -s TYPE /dev/block/mmcblk0p17
does not return anything.
And if you open the modemst1/2.bin files it seems to be binary data, which does not make sense even in hex editor.
I wonder if oneplus staff could help the poor souls who have lost the imei2 and disclose this info how to get imei2 back...
DISCLAIMER: This thread is unofficial and may contain errors. This information comes from personal knowledge and research from other threads. I am not responsible for what you do with your device.
Context
This thread is intended to provide an explanation of the function and importance of each partition on the Motorola Moto G. Some partitions are very ambiguous, but I will attempt to describe what these partitions store, and whether they are unique/permanent/temporary etc. Again, I am not a developer, but I hope that this will explain the structure of the partitions to new users. Also, feel free to leave more information about these partitions in the comments, and I will try to update the OP with that information.
The following partition layout can be found with root access using various commands such as
Code:
ls /dev/block/platform/msm_sdcc.1/by-name
List of partitions
Code:
DDR -> /dev/block/mmcblk0p3
aboot -> /dev/block/mmcblk0p4
abootBackup -> /dev/block/mmcblk0p11
boot -> /dev/block/mmcblk0p31
cache -> /dev/block/mmcblk0p33
cid -> /dev/block/mmcblk0p25
clogo -> /dev/block/mmcblk0p28
dhob -> /dev/block/mmcblk0p20
fsc -> /dev/block/mmcblk0p22
fsg -> /dev/block/mmcblk0p21
hob -> /dev/block/mmcblk0p19
kpan -> /dev/block/mmcblk0p35
logo -> /dev/block/mmcblk0p27
logs -> /dev/block/mmcblk0p9
misc -> /dev/block/mmcblk0p30
modem -> /dev/block/mmcblk0p1
modemst1 -> /dev/block/mmcblk0p17
modemst2 -> /dev/block/mmcblk0p18
padA -> /dev/block/mmcblk0p10
padB -> /dev/block/mmcblk0p16
pds -> /dev/block/mmcblk0p26
persist -> /dev/block/mmcblk0p29
recovery -> /dev/block/mmcblk0p32
rpm -> /dev/block/mmcblk0p5
rpmBackup -> /dev/block/mmcblk0p12
sbl1 -> /dev/block/mmcblk0p2
sdi -> /dev/block/mmcblk0p7
sdiBackup -> /dev/block/mmcblk0p14
sp -> /dev/block/mmcblk0p24
ssd -> /dev/block/mmcblk0p23
system -> /dev/block/mmcblk0p34
tz -> /dev/block/mmcblk0p6
tzBackup -> /dev/block/mmcblk0p13
userdata -> /dev/block/mmcblk0p36
utags -> /dev/block/mmcblk0p8
utagsBackup -> /dev/block/mmcblk0p15
Partition explanations
Terminology
- Partition: A hard drive, eMMC, or any storage device can be divided into separate section called partitions. Most Windows, OS X or Linux machines have 1 to 3 partitions but android devices tend to have many.
- Unique: This means this partition contains data is specific to only that device, e.g. serial numbers, IMEIs, MAC addresses etc. This data cannot be found on the internet and so one should be careful not to modify or lose it.
- Flashing: Writing data to a disk or partition, replacing what was already there.
- Root ("/"): Not to be confused with "root access", this is the Unix term for the top directory. Similar to C:\, but everything is stored in it, including partition mount points.
Common Partitions
boot: This partition contains the boot image, which includes the kernel, a device tree blob (this describes the hardware to the kernel), and the ramdisk for the root filesystem (not root access - see above). This partition is usually flashed when installing custom or stock ROMs, and can be found within stock firmware. This partition does not contain the bootloader.
system: This partition contains the Android system files (i.e. the ROM). This is what is flashed (alongside 'boot') when installing a ROM, and what is modified to give root access. Before rooting or installing a ROM, one should backup this partition (and boot) to ensure they can restore to stock.
recovery: This partitions hold the files that allow one to enter ‘recovery mode’, which is essentially a second boot partition that allows one to apply OTAs, make/restore backups, and install ROMs or root binaries. This partition will either hold the stock recovery, or a custom recovery. Custom recoveries can be flashed and allow the user to backup, restore, install to and wipe other partitions, among other features. This partition can be safely modified but ensure to always have a stock recovery flashed when applying stock OTAs.
userdata: Also known as the Data partition, this is where every user file, preference and is stored, e.g. photos, settings, app settings, messages, and everything created directly or indirectly by the user. This partition is empty on a new device, and is mounted at /Data. This partition should always be backed up before modifying the phone as it contains essentially everything personal on the phone.
cache: Another common partition; this historically contained temporary data that allows the system and apps to run more efficiently. Now it is mostly used by the recovery. Nothing important is stored here, and so it can, and often should, be wiped when necessary.
Other Partitions
Bootloader Related Partitions
aboot: This partition seems to be the main part of the bootloader. It loads the kernel and is responsible for the bootloader menu and fastboot functionality. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
abootBackup: This likely stores a backup of the aboot partition.
tz: This partition also seems to be related to the bootloader, specifically something called 'Trust Zone' . This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
tzBackup: Again, this likely stores a backup of the 'tz' partition.
rpm: Another bootloader related partition. This partition could possibly be the 'Resource and Power Manager' manager partition. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
rpmBackup: hopefully you get the general idea by now...
sdi: I have no idea, but it is flashed as part of motoboot.img, therefore it must be bootloader related. Is included with stock firmware.
sdiBackup: A backup of the above.
sdb1: Bootloader related. Interestingly, after looking around, I found that this appears to contains files relating to a 'Secondary BootLoader'. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
Network Related Partitions
modemst1 and modemst2: These partitions appear to contain non-essentials/temporary network related data. Interestingly, they are erased when flashing a stock rom, meaning they are probably not crucial, possibly some kind of ‘baseband cache’?
modem: The modem partition contains modem/baseband related files. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it also is likely not unique (again ensure to get firmware for the right region).
fsg: This partition also contains files related to the modem firmware/baseband. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it likely contains non-unique data (but ensure to get firmware for the right region).
Maybe ‘fsg’ and ‘modem’ are related to the modemst1 and modemst2 partitions?
Important/Unique Partitions
pds: This partition likely contains important device specific data like the IMEI, Serial Number, etc. It is important to backup this partition when you get the chance, as people in other threads attribute the loss of the IMEI to this partition. This is not included in stock firmware, reinforcing the importance of backing up this partition.
persist: Apparently this partition contains files related to WiFi, Bluetooth, MAC addresses etc. Nevertheless, it is quite important and should be backed up if possible.
hob and dhob: The exact function is not known, but they appear to contain very important information relating to the modem and/or IMEI.
fsc: Appears to be empty. Although, this partition could sometimes store important IMEI related info. Not included in factory firmware and so best left alone.
Extra
ssd: This partition appears to contains files related to something called the ‘Secure Software Download’ feature. These files are not included in factory firmware so should be left alone.
logo: This partition contains the startup splash screen and bootloader unlock warning. This partition is included with stock firmware.
clogo: After doing some research, it appears this partition might store the boot logo in an image format. Interestingly, this is not included in stock firmware, unlike the 'logo' partition.
cid: This partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
sp: Like CID, this partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
misc: This partition contains ‘miscellaneous system settings’, more specifically, this partition also helps the bootloader boot to recovery and pass information between boot stages. This partition is best left alone as it is apparently very important, and not included in stock firmware.
padA and padB: Apparently these are empty.
kpan: This partition seems to store kernel panic data.
logs: Possibly stores some form of log files.
utags: These partition seem to contain information used by the barcodes option in the bootloader menu.
utagsBackup: A backup of the above.
Unknown Partitions
DDR <-- Device Description Repository?.. Dance Dance Revolution?..
I could not find any information about the function of the above partitions. Although, none of these partitions are included in factory firmware, so they are likely important and best left alone. Anyone is welcome to share they own knowledge or opinion on what these partitions are for in the comments.
Sources/Interesting information:
Moto G Partition Layout.
http://forum.xda-developers.com/showthread.php?t=2540799
Bootloader Related Partitions (motoboot.img - tz, rpm, sdi, aboot, and sbl1).
http://forum.xda-developers.com/showthread.php?t=2644703&page=2
http://forum.xda-developers.com/mot...rom-xt1033-t3357718/post66336145#post66336145
Great reading about partitions on Samsung phones, although it appears a lot of this information is relevant to the Moto G. Specifically, this thread gives some hints about the function of motoboot.img, baseband partitions and the 'ssd' partition.
http://forum.xda-developers.com/showthread.php?t=1959445
Possible explanation of modemst1, modemst2 and fsg partitions. (About Samsung partitions but still relevant).
http://forum.xda-developers.com/showthread.php?p=49587431#post49587431
Instructions on flashing factory firmware.
http://forum.xda-developers.com/showthread.php?t=2542219
CID, Trust Zone, and SP partition Information.
http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
Possible /misc explanation, also some simple explanation of common partitions for new users.
http://www.addictivetips.com/mobile...plained-boot-system-recovery-data-cache-misc/
Some more /misc info
http://linux-sunxi.org/Android/partitions
Thread with some information relating to 'hob' and 'dhob'
http://forum.xda-developers.com/moto-g/help/imp-imei-backup-scripts-moto-g-eall-t3174569
Moto X Boot Logo Change - Appears to show purpose of 'clogo' partition on Moto G
http://www.talkandroid.com/guides/m...on-the-moto-x-splash-screen-no-root-required/
Info on Persist partition
http://forum.xda-developers.com/google-nexus-5/general/guide-to-fix-persist-partition-t2821576
https://forums.lenovo.com/t5/MOTO-G...gs-like-hell-after-update/td-p/3231064/page/2
Likely explanation of 'kpan' partition - although 'Kernel PANic' does fit well
https://plus.google.com/+hashcode0f/posts/W84mLxfMomf
Information vaguely referencing 'logs' partition
http://www.ptsmobile.com/tc55/tc55-integrator-guide.pdf
http://techtablets.com/forum/topic/help-windows-fell-by-flash-android/
Info on 'utags'
http://forum.xda-developers.com/moto-g/help/info-moto-g-imei0-t2925970/page26
Finally, thanks to @_that for extra information and corrections.
Most awesome first post I've ever seen. :good:
A few additions:
"boot" and "recovery" both contain a boot image. It begins with the magic string "ANDROID!" and they contain a Linux kernel image, a device tree blob (tables describing the hardware for the kernel), and a ramdisk image for the root ("/") filesystem.
"system" is actually mounted at /system at runtime. "userdata" is mounted on "/data".
"cache" is mostly used for communicating with the recovery.
"aboot" is the Android bootloader. It is the last step in the bootloader chain which loads the kernel. It also implements the bootloader menu and the fastboot protocol.
"logo" contains the startup splash screen and the ugly "your bootloader is unlocked" image. The boot animation is part of /system.
"misc" is used, among other things, by Android to tell the bootloader to boot to recovery.
"padA" and "padB" are really empty.
"hob" and "dhob" are somehow very important for the modem to work.
_that said:
Most awesome first post I've ever seen. :good:
A few additions:
"boot" and "recovery" both contain a boot image. It begins with the magic string "ANDROID!" and they contain a Linux kernel image, a device tree blob (tables describing the hardware for the kernel), and a ramdisk image for the root ("/") filesystem.
"system" is actually mounted at /system at runtime. "userdata" is mounted on "/data".
"cache" is mostly used for communicating with the recovery.
"aboot" is the Android bootloader. It is the last step in the bootloader chain which loads the kernel. It also implements the bootloader menu and the fastboot protocol.
"logo" contains the startup splash screen and the ugly "your bootloader is unlocked" image. The boot animation is part of /system.
"misc" is used, among other things, by Android to tell the bootloader to boot to recovery.
"padA" and "padB" are really empty.
"hob" and "dhob" are somehow very important for the modem to work.
Click to expand...
Click to collapse
Thanks _that. I've updated the OP with this info.
Which of these partitions stores the PRL file
Professor Gibbins said:
DISCLAIMER: This thread is unofficial and may contain errors. This information comes from personal knowledge and research from other threads. I am not responsible for what you do with your device.
Context
This thread is intended to provide an explanation of the function and importance of each partition on the Motorola Moto G. Some partitions are very ambiguous, but I will attempt to describe what these partitions store, and whether they are unique/permanent/temporary etc. Again, I am not a developer, but I hope that this will explain the structure of the partitions to new users. Also, feel free to leave more information about these partitions in the comments, and I will try to update the OP with that information.
The following partition layout can be found with root access using various commands such as
Code:
ls /dev/block/platform/msm_sdcc.1/by-name
List of partitions
Code:
DDR -> /dev/block/mmcblk0p3
aboot -> /dev/block/mmcblk0p4
abootBackup -> /dev/block/mmcblk0p11
boot -> /dev/block/mmcblk0p31
cache -> /dev/block/mmcblk0p33
cid -> /dev/block/mmcblk0p25
clogo -> /dev/block/mmcblk0p28
dhob -> /dev/block/mmcblk0p20
fsc -> /dev/block/mmcblk0p22
fsg -> /dev/block/mmcblk0p21
hob -> /dev/block/mmcblk0p19
kpan -> /dev/block/mmcblk0p35
logo -> /dev/block/mmcblk0p27
logs -> /dev/block/mmcblk0p9
misc -> /dev/block/mmcblk0p30
modem -> /dev/block/mmcblk0p1
modemst1 -> /dev/block/mmcblk0p17
modemst2 -> /dev/block/mmcblk0p18
padA -> /dev/block/mmcblk0p10
padB -> /dev/block/mmcblk0p16
pds -> /dev/block/mmcblk0p26
persist -> /dev/block/mmcblk0p29
recovery -> /dev/block/mmcblk0p32
rpm -> /dev/block/mmcblk0p5
rpmBackup -> /dev/block/mmcblk0p12
sbl1 -> /dev/block/mmcblk0p2
sdi -> /dev/block/mmcblk0p7
sdiBackup -> /dev/block/mmcblk0p14
sp -> /dev/block/mmcblk0p24
ssd -> /dev/block/mmcblk0p23
system -> /dev/block/mmcblk0p34
tz -> /dev/block/mmcblk0p6
tzBackup -> /dev/block/mmcblk0p13
userdata -> /dev/block/mmcblk0p36
utags -> /dev/block/mmcblk0p8
utagsBackup -> /dev/block/mmcblk0p15
Partition explanations
Terminology
- Partition: A hard drive, eMMC, or any storage device can be divided into separate section called partitions. Most Windows, OS X or Linux machines have 1 to 3 partitions but android devices tend to have many.
- Unique: This means this partition contains data is specific to only that device, e.g. serial numbers, IMEIs, MAC addresses etc. This data cannot be found on the internet and so one should be careful not to modify or lose it.
- Flashing: Writing data to a disk or partition, replacing what was already there.
- Root ("/"): Not to be confused with "root access", this is the Unix term for the top directory. Similar to C:\, but everything is stored in it, including partition mount points.
Common Partitions
boot: This partition contains the boot image, which includes the kernel, a device tree blob (this describes the hardware to the kernel), and the ramdisk for the root filesystem (not root access - see above). This partition is usually flashed when installing custom or stock ROMs, and can be found within stock firmware. This partition does not contain the bootloader.
system: This partition contains the Android system files (i.e. the ROM). This is what is flashed (alongside 'boot') when installing a ROM, and what is modified to give root access. Before rooting or installing a ROM, one should backup this partition (and boot) to ensure they can restore to stock.
recovery: This partitions hold the files that allow one to enter ‘recovery mode’, which is essentially a second boot partition that allows one to apply OTAs, make/restore backups, and install ROMs or root binaries. This partition will either hold the stock recovery, or a custom recovery. Custom recoveries can be flashed and allow the user to backup, restore, install to and wipe other partitions, among other features. This partition can be safely modified but ensure to always have a stock recovery flashed when applying stock OTAs.
userdata: Also known as the Data partition, this is where every user file, preference and is stored, e.g. photos, settings, app settings, messages, and everything created directly or indirectly by the user. This partition is empty on a new device, and is mounted at /Data. This partition should always be backed up before modifying the phone as it contains essentially everything personal on the phone.
cache: Another common partition; this historically contained temporary data that allows the system and apps to run more efficiently. Now it is mostly used by the recovery. Nothing important is stored here, and so it can, and often should, be wiped when necessary.
Other Partitions
Bootloader Related Partitions
aboot: This partition seems to be the main part of the bootloader. It loads the kernel and is responsible for the bootloader menu and fastboot functionality. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
abootBackup: This likely stores a backup of the aboot partition.
tz: This partition also seems to be related to the bootloader, specifically something called 'Trust Zone' . This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
tzBackup: Again, this likely stores a backup of the 'tz' partition.
rpm: Another bootloader related partition. This partition could possibly be the 'Resource and Power Manager' manager partition. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
rpmBackup: hopefully you get the general idea by now...
sdi: I have no idea, but it is flashed as part of motoboot.img, therefore it must be bootloader related. Is included with stock firmware.
sdiBackup: A backup of the above.
sdb1: Bootloader related. Interestingly, after looking around, I found that this appears to contains files relating to a 'Secondary BootLoader'. This partition is flashed as part of motoboot.img (source below) and so can be restored with stock firmware.
Network Related Partitions
modemst1 and modemst2: These partitions appear to contain non-essentials/temporary network related data. Interestingly, they are erased when flashing a stock rom, meaning they are probably not crucial, possibly some kind of ‘baseband cache’?
modem: The modem partition contains modem/baseband related files. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it also is likely not unique (again ensure to get firmware for the right region).
fsg: This partition also contains files related to the modem firmware/baseband. These files store store settings that allow the device to communicate with cell towers, such as the frequencies. This partitions is region, not device, specific. This partition is flashed as part of the stock firmware flash procedure, so it likely contains non-unique data (but ensure to get firmware for the right region).
Maybe ‘fsg’ and ‘modem’ are related to the modemst1 and modemst2 partitions?
Important/Unique Partitions
pds: This partition likely contains important device specific data like the IMEI, Serial Number, etc. It is important to backup this partition when you get the chance, as people in other threads attribute the loss of the IMEI to this partition. This is not included in stock firmware, reinforcing the importance of backing up this partition.
persist: Apparently this partition contains files related to WiFi, Bluetooth, MAC addresses etc. Nevertheless, it is quite important and should be backed up if possible.
hob and dhob: The exact function is not known, but they appear to contain very important information relating to the modem and/or IMEI.
fsc: Appears to be empty. Although, this partition could sometimes store important IMEI related info. Not included in factory firmware and so best left alone.
Extra
ssd: This partition appears to contains files related to something called the ‘Secure Software Download’ feature. These files are not included in factory firmware so should be left alone.
logo: This partition contains the startup splash screen and bootloader unlock warning. This partition is included with stock firmware.
clogo: After doing some research, it appears this partition might store the boot logo in an image format. Interestingly, this is not included in stock firmware, unlike the 'logo' partition.
cid: This partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
sp: Like CID, this partition appears to contain authentication/digital signature files for the bootloader. This partition is usually never interfered with, and there is no stock firmware for it, so it is best left alone.
misc: This partition contains ‘miscellaneous system settings’, more specifically, this partition also helps the bootloader boot to recovery and pass information between boot stages. This partition is best left alone as it is apparently very important, and not included in stock firmware.
padA and padB: Apparently these are empty.
kpan: This partition seems to store kernel panic data.
logs: Possibly stores some form of log files.
utags: These partition seem to contain information used by the barcodes option in the bootloader menu.
utagsBackup: A backup of the above.
Unknown Partitions
DDR <-- Device Description Repository?.. Dance Dance Revolution?..
I could not find any information about the function of the above partitions. Although, none of these partitions are included in factory firmware, so they are likely important and best left alone. Anyone is welcome to share they own knowledge or opinion on what these partitions are for in the comments.
Sources/Interesting information:
Moto G Partition Layout.
http://forum.xda-developers.com/showthread.php?t=2540799
Bootloader Related Partitions (motoboot.img - tz, rpm, sdi, aboot, and sbl1).
http://forum.xda-developers.com/showthread.php?t=2644703&page=2
http://forum.xda-developers.com/mot...rom-xt1033-t3357718/post66336145#post66336145
Great reading about partitions on Samsung phones, although it appears a lot of this information is relevant to the Moto G. Specifically, this thread gives some hints about the function of motoboot.img, baseband partitions and the 'ssd' partition.
http://forum.xda-developers.com/showthread.php?t=1959445
Possible explanation of modemst1, modemst2 and fsg partitions. (About Samsung partitions but still relevant).
http://forum.xda-developers.com/showthread.php?p=49587431#post49587431
Instructions on flashing factory firmware.
http://forum.xda-developers.com/showthread.php?t=2542219
CID, Trust Zone, and SP partition Information.
http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
Possible /misc explanation, also some simple explanation of common partitions for new users.
http://www.addictivetips.com/mobile...plained-boot-system-recovery-data-cache-misc/
Some more /misc info
http://linux-sunxi.org/Android/partitions
Thread with some information relating to 'hob' and 'dhob'
http://forum.xda-developers.com/moto-g/help/imp-imei-backup-scripts-moto-g-eall-t3174569
Moto X Boot Logo Change - Appears to show purpose of 'clogo' partition on Moto G
http://www.talkandroid.com/guides/m...on-the-moto-x-splash-screen-no-root-required/
Info on Persist partition
http://forum.xda-developers.com/google-nexus-5/general/guide-to-fix-persist-partition-t2821576
https://forums.lenovo.com/t5/MOTO-G...gs-like-hell-after-update/td-p/3231064/page/2
Likely explanation of 'kpan' partition - although 'Kernel PANic' does fit well
https://plus.google.com/+hashcode0f/posts/W84mLxfMomf
Information vaguely referencing 'logs' partition
http://www.ptsmobile.com/tc55/tc55-integrator-guide.pdf
http://techtablets.com/forum/topic/help-windows-fell-by-flash-android/
Info on 'utags'
http://forum.xda-developers.com/moto-g/help/info-moto-g-imei0-t2925970/page26
Finally, thanks to @_that for extra information and corrections.
Click to expand...
Click to collapse
Thanks for posting such an in depth explanation on what all those partitions mean. I am using the Moto G3 2015 and I would like to know which one of those partitions stores the PRL file, I would like to manually update my PRL as I am using Cyanogenmod and do not want to deal with the hassle of going to Stock just to perform this one simple task, so I figure that I can perform a back up with Partitions Backup and Restore app, then mount the image on ubuntu, copy the new .prl file there, unmount image and then restore the image to the corresponding partition. I am assuming that's all what it would take to change my prl provided that the prl is actually stored on one of those partition.
Nice post but lacks informations about hob and dhob partitions. This post says
1. Dhob and Hob are nothing but plain text partitions, Dhob is dynamic hob and Hob is static Hob.
2. Dhob stores cryptotext by default, this crypto text contains information like Imei, ESN, Meid etc.
3. The Hob partition is a XML formatted plain-text file that contains Data which i am not sure about.
4. Uses a PBKDF2 key for encryption and decryption of Dhob.
5. The size field in Hob is Hex. So, 16 is 22 and 32 is 50.
6. The modem updates NV items on the fly which is why you can get 0 and null IMEI by fiddling.
7. In case the IMEI doesn't match with equipment then NV item is made 0.
8. EFS is created on the go not sure.
Click to expand...
Click to collapse