Database Users

[REQ] Need a little help for porting my WM6 ROM on my MIO P550 / Airis T620

hello everybody
I'm a user of a mio p550. I'ma développor, and i want to port à wm6 rom for this pda, because there are many users of this pda, and i want to flash my pda on wm6 !
The mio p550 have three clones : the mio p350, the Aris T620, ans the Yakumo Delat X, so there are many many users of these pda, but no wm6 rom.
SO i have begun, but, it stay a little problem !
The only available flashable image is the "famous" "MioP550 - Osc260A R05_P09.nb0" file.
The header of it looks like:
Code:
00000000: 50 6f 63 6b 65 74 50 43 5f 32 30 30 35 00 00 00 PocketPC_2005...
00000010: 10 01 00 00 00 00 02 00 5a fc 35 00 00 00 00 00 ........Z.5.....
00000020: 4d 53 5f 49 50 4c 00 00 00 00 00 00 00 00 00 00 MS_IPL..........
00000030: 10 01 02 00 00 88 e9 01 70 1f ae 1c 00 00 00 00 ........p.......
00000040: 4f 53 5f 49 4d 41 47 45 00 00 00 00 00 00 00 00 OS_IMAGE........
00000050: 10 89 eb 01 00 00 02 00 de 1e f8 00 00 00 00 00 ................
00000060: 55 42 4f 4f 54 00 00 00 00 00 00 00 00 00 00 00 UBOOT...........
The structure is somewhat easy to see:
Code:
00000000: "Pocket_PC_2005" // some sort of signature. In UBOOT section I could find the very same string, so I'd assume the update loader checks it.
00000010: 10 01 00 00 // 4 bytes : offset of the 1st section -> 0x110
00 00 02 00 // 4 bytes : length of the 1st section -> 0x20000
5a fc 35 00 // 4 bytes : checksum -> 0x35fc5a
00 00 00 00 ...
00000020: "MS_IPL" // name/id of the 1st section
00000030: 10 01 02 00 // 4 bytes : offset of the 2nd section -> 0x20110
00 88 e9 01 // 4 bytes : length of the 2nd section -> 0x1e98800
70 1f ae 1c // 4 bytes : checksum -> 0x1cae1f70
00 00 00 00 ...
00000040: "OS_IMAGE" // name/id of the 2nd section
00000050: 10 89 eb 01 // 4 bytes : offset of the 3rd section -> 0x1eb8910
00 00 02 00 // 4 bytes : length of the 3rd section -> 0x20000
de 1e f8 00 // 4 bytes : checksum -> 0xf81ede
00 00 00 00 ...
00000060: "UBOOT" // name/id of the 3rd section
You can split the nb0 file into the corresponding parts based on the above informacion. Use your favourite hex editor, or write a script , or ... you can use dump from itsutils like below.
Code:
dump -o 0x110 -l 0x20000 "MioP550 - Osc260A R05_P09.nbh" MS_IPL.nb
dump -o 0x20110 -l 0x1e98800 "MioP550 - Osc260A R05_P09.nbh" OS_IMAGE.nb
dump -o 0x1eb8910 -l0x20000 "MioP550 - Osc260A R05_P09.nbh" BOOT.nb
The OS_IMAGE.nb file you get, can be used in most of the kitchens. The only special thing, that is has 512+8 (data+spare) bytes structure. Tadzio's imgfs tools can handle that. Below is some example output.
Code:
NBSplit.exe -data 512 -extra 8 OS_IMAGE.nb
NBSplit 2.1rc2
Using data chunk size = 0x200 and extra chunk size = 0x8
on file OS_IMAGE.nb
Done.
Code:
NBInfo.exe OS_IMAGE.nb.payload
NBInfo 2.1rc2
'OS_IMAGE.nb.payload' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x000008fe
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x08
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x00000900
Total Sectors: 0x00000f00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x09
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x17
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x00001800
Total Sectors: 0x0000d500
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x18
Last Head: 0xff
Last Sector: 0x01
Last Track: 0xec
Partition 3
-----------
File System: 0x04 (FAT)
Start Sector: 0x0000ed00
Total Sectors: 0x003f0c00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0xed
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x1f8
Geometry: flash has 256 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000018 -> Size in sectors: 0x00001800
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Flash Region Entry 1:
---------------------
Region type: READONLY_FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x000000d5 -> Size in sectors: 0x0000d500
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Flash Region Entry 2:
---------------------
Region type: FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0xffffffff -> Size in sectors: 0xffffff00
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00340000 (sector 0x00001a00).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 000135F5
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
---
Now you can extract all parts. The SRXP compressed XIP part you need for cooking. You can use msflshtool to extract it, srpx2xip to decompress and dumprom to dump it. All these tools you can find in Scoter Kitchen. You can use Tadzio's imgfs tool to dump/modify/build the IMGFS part. You can collect the rest of the tools you need, depending on the modification you plan.
Based on the above header description, you can easily assemble a flashable image. The checksums are checked, but a wrong checksum does not prevent the flasing procedure . My today's finding : the checksum calculatin is rather easy, just create a 32 byte masked sum of all the bytes in the region in little endian format
I hope this helps for those interested in P550 ROM cooking.
-------
In addition, i possed a dump of a mio p560 rom ( which is the mio p550 with wm6),.
The 3 files here in the P560 dump correspond to Partition0/1/2 in that description. With a hexeditor you can fabricate an MBR and an MSFLSH50 header that corrensponds to P560 partition sizes and inject P560 raw files into the nb0 file and you can flash that. And there's a chance that you brick your device
I took a look at the part01.raw and what makes me sceptic, in OEM KERNEL package P560 uses a different flash driver than P550. So hw is not necessarily the same. And the above method without further cooking might not work smoothly.
Anyway as P560 is really close to P550 in hw, the above dump can be really useful in cooking a WM6 for P550. So I believe we would need help from an experience chef to proceed
So , i don't know how to do, but i want to adapt the rom !
Please, Please, Please, I need help
Is there any god who can help me !
Great thanks !!!!
Nixeus

175 view and no a little answer

Nixeus said:
175 view and no a little answer
Click to expand...
Click to collapse
Soory, but can't help you...
Maybe you should change te name of the topic, because it doesn't say anything about the real subject of the first post...
Hope someone will come by to help you...

Nixeus said:
175 view and no a little answer
Click to expand...
Click to collapse
Dear Nixeus, I agree with rvdgeer, I've been following this thread and waiting for a reply/solution all this time for my MIO P550, so please change the title of this thread to [REQ] or something very similar... Thanks.

I hope you'll find help, it would be awesome a wm6 or wm6.1 rom for my p350!

There are more and more person who wants wm6 or 6.1 for these pda, but no body help me......

I would like to help you, but the only thing I could do for you is an italian translation but i don't think it's gonna help..

I think it's not coming help here.. Are you keeping up the work?

Thanks all you had done for us! However, I am not a specialist on this. Can you please make a *.nb0 file using MioP560 with WM6 dump file? If it can be uploaded to rapidshare.com, it is easy to get it for us.
Thanks in advance.
Anson
Nixeus said:
hello everybody
I'm a user of a mio p550. I'ma développor, and i want to port à wm6 rom for this pda, because there are many users of this pda, and i want to flash my pda on wm6 !
The mio p550 have three clones : the mio p350, the Aris T620, ans the Yakumo Delat X, so there are many many users of these pda, but no wm6 rom.
SO i have begun, but, it stay a little problem !
The only available flashable image is the "famous" "MioP550 - Osc260A R05_P09.nb0" file.
The header of it looks like:
Code:
00000000: 50 6f 63 6b 65 74 50 43 5f 32 30 30 35 00 00 00 PocketPC_2005...
00000010: 10 01 00 00 00 00 02 00 5a fc 35 00 00 00 00 00 ........Z.5.....
00000020: 4d 53 5f 49 50 4c 00 00 00 00 00 00 00 00 00 00 MS_IPL..........
00000030: 10 01 02 00 00 88 e9 01 70 1f ae 1c 00 00 00 00 ........p.......
00000040: 4f 53 5f 49 4d 41 47 45 00 00 00 00 00 00 00 00 OS_IMAGE........
00000050: 10 89 eb 01 00 00 02 00 de 1e f8 00 00 00 00 00 ................
00000060: 55 42 4f 4f 54 00 00 00 00 00 00 00 00 00 00 00 UBOOT...........
The structure is somewhat easy to see:
Code:
00000000: "Pocket_PC_2005" // some sort of signature. In UBOOT section I could find the very same string, so I'd assume the update loader checks it.
00000010: 10 01 00 00 // 4 bytes : offset of the 1st section -> 0x110
00 00 02 00 // 4 bytes : length of the 1st section -> 0x20000
5a fc 35 00 // 4 bytes : checksum -> 0x35fc5a
00 00 00 00 ...
00000020: "MS_IPL" // name/id of the 1st section
00000030: 10 01 02 00 // 4 bytes : offset of the 2nd section -> 0x20110
00 88 e9 01 // 4 bytes : length of the 2nd section -> 0x1e98800
70 1f ae 1c // 4 bytes : checksum -> 0x1cae1f70
00 00 00 00 ...
00000040: "OS_IMAGE" // name/id of the 2nd section
00000050: 10 89 eb 01 // 4 bytes : offset of the 3rd section -> 0x1eb8910
00 00 02 00 // 4 bytes : length of the 3rd section -> 0x20000
de 1e f8 00 // 4 bytes : checksum -> 0xf81ede
00 00 00 00 ...
00000060: "UBOOT" // name/id of the 3rd section
You can split the nb0 file into the corresponding parts based on the above informacion. Use your favourite hex editor, or write a script , or ... you can use dump from itsutils like below.
Code:
dump -o 0x110 -l 0x20000 "MioP550 - Osc260A R05_P09.nbh" MS_IPL.nb
dump -o 0x20110 -l 0x1e98800 "MioP550 - Osc260A R05_P09.nbh" OS_IMAGE.nb
dump -o 0x1eb8910 -l0x20000 "MioP550 - Osc260A R05_P09.nbh" BOOT.nb
The OS_IMAGE.nb file you get, can be used in most of the kitchens. The only special thing, that is has 512+8 (data+spare) bytes structure. Tadzio's imgfs tools can handle that. Below is some example output.
Code:
NBSplit.exe -data 512 -extra 8 OS_IMAGE.nb
NBSplit 2.1rc2
Using data chunk size = 0x200 and extra chunk size = 0x8
on file OS_IMAGE.nb
Done.
Code:
NBInfo.exe OS_IMAGE.nb.payload
NBInfo 2.1rc2
'OS_IMAGE.nb.payload' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x000008fe
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x08
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x00000900
Total Sectors: 0x00000f00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x09
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x17
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x00001800
Total Sectors: 0x0000d500
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x18
Last Head: 0xff
Last Sector: 0x01
Last Track: 0xec
Partition 3
-----------
File System: 0x04 (FAT)
Start Sector: 0x0000ed00
Total Sectors: 0x003f0c00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0xed
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x1f8
Geometry: flash has 256 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000018 -> Size in sectors: 0x00001800
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Flash Region Entry 1:
---------------------
Region type: READONLY_FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x000000d5 -> Size in sectors: 0x0000d500
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Flash Region Entry 2:
---------------------
Region type: FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0xffffffff -> Size in sectors: 0xffffff00
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00340000 (sector 0x00001a00).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 000135F5
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
---
Now you can extract all parts. The SRXP compressed XIP part you need for cooking. You can use msflshtool to extract it, srpx2xip to decompress and dumprom to dump it. All these tools you can find in Scoter Kitchen. You can use Tadzio's imgfs tool to dump/modify/build the IMGFS part. You can collect the rest of the tools you need, depending on the modification you plan.
Based on the above header description, you can easily assemble a flashable image. The checksums are checked, but a wrong checksum does not prevent the flasing procedure . My today's finding : the checksum calculatin is rather easy, just create a 32 byte masked sum of all the bytes in the region in little endian format
I hope this helps for those interested in P550 ROM cooking.
-------
In addition, i possed a dump of a mio p560 rom ( which is the mio p550 with wm6),.
The 3 files here in the P560 dump correspond to Partition0/1/2 in that description. With a hexeditor you can fabricate an MBR and an MSFLSH50 header that corrensponds to P560 partition sizes and inject P560 raw files into the nb0 file and you can flash that. And there's a chance that you brick your device
I took a look at the part01.raw and what makes me sceptic, in OEM KERNEL package P560 uses a different flash driver than P550. So hw is not necessarily the same. And the above method without further cooking might not work smoothly.
Anyway as P560 is really close to P550 in hw, the above dump can be really useful in cooking a WM6 for P550. So I believe we would need help from an experience chef to proceed
So , i don't know how to do, but i want to adapt the rom !
Please, Please, Please, I need help
Is there any god who can help me !
Great thanks !!!!
Nixeus
Click to expand...
Click to collapse

hi
how could i use the 3 raw files of p560 rom to restore seflash my p560?
thanks

please
please please please teach me how to make MBR and an MSFLSH50 header.
I own an p560 but in an atempt to dump rom it was broken, i d/ont know why but at the restart after mio logo and at the expected windows screen the lcd remain white and that is all, nothing happen after...

Here is a solution in order to maker a wm6 rom for our mio p550 / Airis T620 !
Thanks to ASAM !!
http://www.miousers.co.uk/viewtopic.php?t=4068

[DEV][R&D] FW & Partition Tables (Here!)

I'm working on a project doing Firmware/Bootloader analysis and documentation.
This will eventually be crucially important in providing service, repair and
unbricking of these device. And if you think that these will not soft-brick,
just remember that the OS have "Windows" in it's name...
However, this project requires detailed knowledge of the following two components:
Bootloader & Firmware files
Partition Table
To make things more simple for this project, I have chosen to only focus on devices using the Qualcomm
Snapdragon S4 Plus/Pro processors, these are also known as the MSM8960, MSM8960T and MSM8930.
So if you have any of the devices shown in the list below, please try to extract and post these details,
when and if they become available. (I recommend using Sendspace to upload large files.)
Code:
[SIZE=2]HTC Windows Phone 8X LTE ADR6990 Verizon
HTC Windows Phone 8X LTE
Nokia Lumia 820 (Nokia Arrow)
Nokia Lumia 820.2 (Nokia Arrow)
Nokia Lumia 822 (Nokia Atlas) Verizon
Nokia Lumia 920 (Nokia Phi)
Nokia Lumia 920.2 (Nokia Phi)
Samsung GT-i8750 Ativ S 16GB (Samsung Odyssey)
Samsung GT-i8750 Ativ S 32GB (Samsung Odyssey)[/SIZE]
[Obtained from the PDAdb web site.]
This list is in no way exhaustive, and it may be very likely that you have another device or still using
Windows Phone 7 (?) with that same processor. That would also be interesting. Another thing that may
be very useful, is documentation related to the Windows Phone build structure.
The results of this project will be published here and will benefit the development community
in several different ways.
Please do not post any general unrelated questions here, they will be removed.
And I will not answer to any support related PM's.
Thanks in advance.

< Here Be Snap ! Dragons >

Good start .. E.V.A have u trued to contact Cotulla on htc-linux or DFT team. They might have something that might interest you . I'll post once i grab my hands on them.
Sent from my GT-I9300 using xda premium

If someone has a working Windows Phone 8, and if at all possible, please follow these instructions to dump the partition tables. As you're on a windows phone, you may need to connect it to a linux based PC, to get these...

Hi, I am in possession of an HTC 8X engineering unit (see here http://forum.xda-developers.com/showthread.php?t=1966327). How can I help? Someone on my thread suggested that I should post here.

Hi! Yes, you could be of great help, if you could provide the partition tables from that device. I know it's politically incorrect to ask you to use a linux tool for doing this, but that is (probably) the only way it will be useful, as you cannot trust native windows partition information...
The way to do it, is by connecting your WP to a linux computer or possibly by using some linux distribution under a virtual machine (VirtualBox, VMware etc.) Then follow the instructions found here.
Thanks in advance.

8X Partition table
Hello. Also have a 8X engineering unit. This is the Partition Info:
Code:
# fdisk -l /dev/sdb
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdb: 15.6 GB, 15634268160 bytes
1 heads, 32 sectors/track, 954240 cylinders
Units = cylinders of 32 * 512 = 16384 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 444417 7110656 ee GPT
Partition 1 does not end on cylinder boundary.
# parted /dev/sdb
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Qualcomm MMC Storage (scsi)
Disk /dev/sdb: 15,6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 62,9MB 61,9MB pg1fs
2 62,9MB 66,1MB 3146kB MODEM_FSG
3 66,1MB 67,1MB 1049kB board_info
4 67,1MB 75,5MB 8389kB DPP
5 75,5MB 77,6MB 2097kB SSD
6 77,6MB 78,6MB 1049kB SBL1
7 78,6MB 79,7MB 1049kB SBL2
8 79,7MB 81,8MB 2097kB SBL3
9 81,8MB 83,9MB 2097kB UEFI
10 83,9MB 84,9MB 1049kB RPM
11 84,9MB 86,0MB 1049kB TZ
12 86,0MB 87,0MB 1049kB WINSECAPP
13 87,0MB 88,1MB 1049kB BACKUP_SBL1
14 88,1MB 89,1MB 1049kB BACKUP_SBL2
15 89,1MB 91,2MB 2097kB BACKUP_SBL3
16 91,2MB 93,3MB 2097kB BACKUP_UEFI
17 93,3MB 94,4MB 1049kB BACKUP_RPM
18 94,4MB 95,4MB 1049kB BACKUP_TZ
19 95,4MB 96,5MB 1049kB BACKUP_WINSECAPP
20 96,5MB 138MB 41,9MB RADIO
21 138MB 139MB 262kB UEFI_BS_NV
22 139MB 140MB 262kB UEFI_NV
23 141MB 149MB 8389kB PLAT
24 149MB 192MB 43,0MB fat16 EFIESP
25 192MB 193MB 1049kB pg2fs
26 193MB 194MB 1049kB RFG_0
27 194MB 195MB 1049kB RFG_1
28 195MB 196MB 1049kB RFG_2
29 196MB 197MB 1049kB RFG_3
30 197MB 198MB 1049kB RFG_4
31 198MB 199MB 1049kB RFG_5
32 199MB 200MB 1049kB RFG_6
33 200MB 201MB 1049kB RFG_7
34 201MB 202MB 1049kB RFG_8
35 202MB 207MB 4194kB MODEM_FS1
36 207MB 211MB 4194kB MODEM_FS2
37 211MB 211MB 262kB UEFI_RT_NV
38 212MB 212MB 131kB UEFI_RT_NV_RPMB
39 213MB 214MB 1049kB MFG
40 214MB 215MB 1049kB MISC
41 215MB 228MB 13,4MB fat16 MMOS
42 235MB 2698MB 2463MB ntfs MainOS
43 2698MB 5114MB 2416MB fat32 CrashDump
44 5117MB 15,6GB 10,5GB ntfs Data
(parted) q
# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 30535680 sectors, 14.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): AE420040-13DD-41F2-AE7F-0DC35854C8D7
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30535646
Partitions will be aligned on 2048-sector boundaries
Total free space is 27687 sectors (13.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 122879 59.0 MiB FFFF pg1fs
2 122880 129023 3.0 MiB FFFF MODEM_FSG
3 129024 131071 1024.0 KiB FFFF board_info
4 131072 147455 8.0 MiB 0700 DPP
5 147456 151551 2.0 MiB FFFF SSD
6 151552 153599 1024.0 KiB FFFF SBL1
7 153600 155647 1024.0 KiB FFFF SBL2
8 155648 159743 2.0 MiB FFFF SBL3
9 159744 163839 2.0 MiB FFFF UEFI
10 163840 165887 1024.0 KiB FFFF RPM
11 165888 167935 1024.0 KiB FFFF TZ
12 167936 169983 1024.0 KiB FFFF WINSECAPP
13 169984 172031 1024.0 KiB FFFF BACKUP_SBL1
14 172032 174079 1024.0 KiB FFFF BACKUP_SBL2
15 174080 178175 2.0 MiB FFFF BACKUP_SBL3
16 178176 182271 2.0 MiB FFFF BACKUP_UEFI
17 182272 184319 1024.0 KiB FFFF BACKUP_RPM
18 184320 186367 1024.0 KiB FFFF BACKUP_TZ
19 186368 188415 1024.0 KiB FFFF BACKUP_WINSECAPP
20 188416 270335 40.0 MiB FFFF RADIO
21 270336 270847 256.0 KiB FFFF UEFI_BS_NV
22 272384 272895 256.0 KiB FFFF UEFI_NV
23 274432 290815 8.0 MiB FFFF PLAT
24 290816 374783 41.0 MiB 0700 EFIESP
25 374784 376831 1024.0 KiB FFFF pg2fs
26 376832 378879 1024.0 KiB FFFF RFG_0
27 378880 380927 1024.0 KiB FFFF RFG_1
28 380928 382975 1024.0 KiB FFFF RFG_2
29 382976 385023 1024.0 KiB FFFF RFG_3
30 385024 387071 1024.0 KiB FFFF RFG_4
31 387072 389119 1024.0 KiB FFFF RFG_5
32 389120 391167 1024.0 KiB FFFF RFG_6
33 391168 393215 1024.0 KiB FFFF RFG_7
34 393216 395263 1024.0 KiB FFFF RFG_8
35 395264 403455 4.0 MiB FFFF MODEM_FS1
36 403456 411647 4.0 MiB FFFF MODEM_FS2
37 411648 412159 256.0 KiB FFFF UEFI_RT_NV
38 413696 413951 128.0 KiB FFFF UEFI_RT_NV_RPMB
39 415744 417791 1024.0 KiB FFFF MFG
40 417792 419839 1024.0 KiB FFFF MISC
41 419840 446031 12.8 MiB 0700 MMOS
42 458752 5269094 2.3 GiB 0700 MainOS
43 5269504 9988095 2.2 GiB 0700 CrashDump
44 9994240 30535646 9.8 GiB 0700 Data
#

^^ Very nice!
Also for everybody's information. I was looking into one of the FFU files of the WP7 (?) Nokia Lumina 800 (RM-801), and it appears that hidden partitions (or mounts) are set in a registry key...
Code:
[SIZE=2][HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MMC\IMGFS]
"MountHidden"=dword:1
"MountAsROM"=dword:1
"XIP"=dword:0
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\SDMemory\IMGFS]
"MountHidden"=dword:1
"MountAsROM"=dword:1
"XIP"=dword:0
[HKEY_LOCAL_MACHINE\Drivers\BlockDevice\UniBlk]
"InternalStoreProfile"="MMC"
"InternalPartitionType"=dword:4[/SIZE]
and that the write protection is set by these registry items:
Code:
[SIZE=2][HKEY_LOCAL_MACHINE\System\StorageManager\WMPART\WriteProtectRegions\Region1]
"StartSector"=dword:0
"SectorCount"=dword:60000
[HKEY_LOCAL_MACHINE\System\StorageManager\WMPART]
"EnableHardwareWriteProtection"=dword:1
"PadAlignment"=dword:10000[/SIZE]
of course I could be wrong, since there are loads of similar items in there.
But it will perhaps help someone finding out where to look.

Partition problems, no ERI, Unknown IMEI, no USB

I was attempting to troubleshoot another phone I had and it was suggested somewhere on here that I back up my efs partition and gave directions to use the command "reboot nvbackup". Well the result was not good. I've searched the forums for over a week and have decided to finally post as I'm out of ideas.
I followed radionerd's thread here and was able to get the Baseband back but I still do not have anything in "Hardware Version", and show "0" in PRL version, "None" in ERI version, "Unknown" in IMEI. The kicker is that somehow my USB no longer works when connecting to the PC. The cord works fine with other phones and it charges this phone but gives a "USB device is not recognized" error when connecting, under device manager it shows up as "Device Descriptor Request Failed".
I have been able to flash back to a stock ROM using TWRP (RUEOF1 is what I've been flashing) but that hasn't helped at all. I've attempted to copy mmcblk1 from the sd but it always fails, both from TWRP file manager and from the ES File Explorer. I'm guessing if I was able to flash a new PIT file I'd be good but I have no idea how to do that without having USB support. I do have working WIFI and SD card access, along with a good operating system.
I've tried a lot of stuff over the past week so I apologize if I haven't already mentioned it but I'm looking for help to see if anyone has an idea about what can be done.
Thanks!

If you unlocked your bootloader using the "standard method" then the "debrick" image you created on the SD card has a backup of literally every partition EXCEPT the ones that you would normally flash with Odin (or a ROM, e.g. boot, system, userdata, cache etc).
The reason that that unlocking method created a debrick image is so that people could save it so they would have it for emergencies. Such as the one you created.
Even the PIT data is included in a hidden partition inside the debrick image. But having a PIT file only allows you to re-partition flash memory, which you don't need; it's partitioned already. Re-writing the PIT is not going to magically recreate data inside those partitions that you erased.
Here's the bottom line: factory images, just like ROM files have NEVER had 100% of the partitions needed to restore the phone back to working condition. So there's darn good reasons to have backups or avoid wiping all of memory.
I think that @hsbadr had posted some debrick images taken during older ROM releases (N* series, I think) on his AFH (androidfilehost.com) site. Whether or not substituting some subset of those partitions (e.g. efs, persist, etc) onto your device will work correctly or not, but it's certainly worth a try at this point.
Skills you need to learn: figuring out byte offsets from the GPT partition table at the beginning of the debrick file to get the partition offsets in the "debrick" blob, and "dd" command options for grabbing exactly the byte ranges you want out of a single large blob file containing many partitions. (e.g. "skip=", "bs=", "count=").
Note also that the Unix GPT partitioning tools "gdisk" will let you examine the Primary GPT (UEFI?) partition table in the debrick image even though the secondary GPT is not present. That way, you can figure out the exact length and initial offset of partitions that you want to copy out of the debrick image into your device. (The reason for the missing secondary GPT is that the GPT/UEFI partition table indicates the presence of very large partitions such as /system, /cache, and /userdata, and the secondary GPT is always near the very end of the disk. Because the "debrick" image is literally a byte-for-byte copy of only the first 256 MB of the mmcblk0 flash device, there is no secondary GPT some 32GB "later" then the beginning of the debrick image.
red indicates partitions in debrick not appearing in Odin factory Images
Code:
$ gdisk /tmp/mj7-debrick-unlocked.img
Command (? for help): p
Disk /tmp/mj7-debrick-unlocked.img: 524288 sectors, 256.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 61071326
Partitions will be aligned on 2-sector boundaries
Total free space is 8158 sectors (4.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 38911 15.0 MiB 8300 apnhlos
2 38912 156543 57.4 MiB 0700 modem
3 156544 157567 512.0 KiB FFFF sbl1
4 157568 157631 32.0 KiB FFFF dbi
5 157632 157695 32.0 KiB FFFF ddr
6 157696 161791 2.0 MiB FFFF aboot
7 161792 162815 512.0 KiB FFFF rpm
8 162816 163839 512.0 KiB FFFF tz
[color=red] 9 163840 184319 10.0 MiB FFFF pad
10 184320 204799 10.0 MiB 8300 param
11 204800 233471 14.0 MiB 8300 efs
12 233472 239615 3.0 MiB FFFF modemst1
13 239616 245759 3.0 MiB FFFF modemst2[/color]
14 245760 268287 11.0 MiB FFFF boot
15 268288 294911 13.0 MiB FFFF recovery
[color=red] 16 294912 321535 13.0 MiB FFFF fota
17 321536 335853 7.0 MiB 8300 backup
18 335854 341997 3.0 MiB FFFF fsg
19 341998 341999 1024 bytes FFFF fsc
20 342000 342015 8.0 KiB FFFF ssd
21 342016 358399 8.0 MiB 8300 persist
22 358400 376831 9.0 MiB 8300 persdata [/color]
--------- debrick image ends ~72 MB into the start of the system partition --------
23 376832 5931007 2.6 GiB 8300 system
24 5931008 8028159 1024.0 MiB 8300 cache
25 8028160 61071326 25.3 GiB 8300 userdata
I would start by restoring as few partitions are necessary e.g. "efs" and "persist" before I would bother with the others.
Example using data given above. (You should check your own work.)
efs partition: blocks 204800 to 233471 in debrick image, blocks are 512 bytes.
check length:
(233471-204800+1)*512 = 14680064
14680064 / (1024 * 1024) = 14 O.K.
so:
# dd if=/sdcard/debrick.img bs=512 skip=204800 count=28672 of=/dev/block/platform/msm_sdcc.1/by-name/efs
(or get clever and faster)
# dd if=/sdcard/debrick.img bs=1048576 skip=100 count=14 of=/dev/block/platform/msm_sdcc.1/by-name/efs
You should be pretty sure what you are doing with byte offset calculations with the "dd" command. Fortunately you are relying on the partitioning already present on the output side of things, so the worst that you could do is write misaligned garbage to a partition. So long as you don't do something incredibly stupid like overwrite a bootloader partition you should be OK.
cheers

Thanks for the reply, I forgot to subscribe so I just saw the post.
I have been able to copy all of the partitions from another phone but it hasn't helped. I'm now wondering if I'm missing a hidden partition.

(WIP) ZTE Blade X Max Z983 R&D Root Research

Well like the rest of you I want to unlock and root this device.
I'm sure this is going to be a long road for all of us but I really like this device so personally I will do what i can to help figure out how to unlock and root this thing.
As a single soul this could take months or even a year but with combined efforts of this community I think we can pull it off. We all have our strengths and if we combine them with your help and the help of others it might turn out to be quite easy.
Don't be fooled and believe that fastboot is removed from the bootloader. It is there im sure we just need to figure out how to access it.
On a good note I already have a method to overcome update.zip signing that I developed for the alcatel one touch fierce 2. When using the recovery to flash the phone things actually become simpler. I would expect though that the recovery image is signed as well meaning we dont simply have the ability to flash the recovery. Unless we can unlock the boot loader first.
In reality to do any of this we are going to need temp root. At this time i have no idea how were going to get that but if you can get temp root even just enough to pull a backup from the device that will be a huge step forward.
To do anything useful we need a device backup. Or a update.zip.
If you can find a way to copy the update from this device before it is installed that would be wonderful.
My device already updated so if you have a brand new device that is not updated let us know so we can get our hands on the update.
In the meantime ( Until we get some firmware to reverse engineer ) I will document all the data I can get and how to get it.
The very first thing we need is to know all of the partitions on the device. If I can get the full GPT Partition Table that would be best.
So without further adieu I will start this journey.
Some of my post will be fairly basic to some and very complex to others.
I'm going to start by seeing what all boot modes i can get into.
Then see what I can get with ADB without root permissions.
Map out the partition scheme, and see how much of the security scheme I can determine is in place. All the fun stuff like what files are signed, how the boot chain is verified. I have seen it before where overcoming the initial security mechanism opens up a whole world of possibilities.
Programmers get lazy and to save money if they think your blocked out of a vulnerable area period they may lax on harder to bypass security.

Ok after a day of research and some gleaning of info from my blade x max I have a direction to move in anyway.
The closest device and one of the only devices zte allowed unlocked is the ZTE axom7.
We can study the Axom7 and get some Ideas on what will work on the BladeXMax.
First fastboot is crippled initially.
But this is easily overcome by swapping a few bytes on the right partition.
Thats my theory anyway. I'm in the process of proving it.
After Fastboot receives its prosthetic Limb oem unlock is as simple as 1 command.
Once the bootloader is unlocked the device will allow for a unsigned TWRP to run.
Now of course we need to compile our own TWRP. And then we can root.
Obviously we need the ability to write to this fastboot partition.
And we need to be able to flash TWRP.
Without Root how???
Just like the axon 7. EDL mode.
ZTE seems EDL Mode Friendly.
And the flash programmer (Firehose) is not signed.
Miflash can write partitions on the zte devices.
The only issue right now is we need the files of of the Blade x max.
And the GPT partition table.
Seeing that axom7tool can backup partitions from the axon7 in edl mode.......
Knowing that miflash works.
One of us that knows the protocol of miflash ( saraha ??? )
Can write a tool for linux that uses the same protocol.
Once this tool exists we can backup all the partitions and the GPT without root.
Once i have the files from the blade it should be possible to edit the fastboot partition and un-cripple the Fastboot.
So if any of you know the guys that wrote the axon 7 tool he can help us with a tool.
Other than that were stuck writing the tool ourself.
On a good not the sahara protocol and other edl protocols are very well documented.
If you seriously want in this Blade this is the way to go.

Well my theory about fastboot is correct.
I guess its obvious that versions of the axon 7 fastboot would be different.
The unlocked and the locked fastboot.
I'm going to hexdump and diff all the fastboot images i can find but so far it looks like this.
It seems that ZTE has used the same fastboot partition for a while.
If you boot into recovery on the blade x max and view the recovery log. Last log
You will find a list of all the parttion names on our device.
system
cache
persist
data
sdcard
boot
recovery
misc
aboot
apdp
bluetooth
carrier
cdt
cmnlib
cmnlib64
cryptkey
DDR
devcfg
devcfgbak
devinfo
dip
dpo
dsp
echarge
fastboot
fbop
fingerid
fsc
fsg
hyp
keymaster
keystore
lksecapp
mdtp
modem
msadp
persistent
pmic
reserve
rpm
sbl1
sec
splash
ssd
sti
tz
xbl
xblbak
ztecfg
tmp
Yep you can see we have the fastboot partition.
But the fbop partition is an important important one.
If we look at the updater scripts of the firmware upgrade packages we see.
FROM Partition.xml
<data><program SECTOR_SIZE_IN_BYTES="4096" file_sector_offset="0" filename="fastboot.img" label="fbop" num_partition_sectors="32" partofsingleimage="false" physical_partition_number="0" readbackverify="false" size_in_KB="128.0" sparse="false" start_byte_hex="0x321a8000" start_sector="205224"/></data>
FROM Update Zip
getprop("ro.product.device") == "ailsa_ii" || abort("E3004: This package is for "ailsa_ii" devices; this is a "" + getprop("ro.product.device") + "".");
assert(getprop("ro.product.name") == "P996A01_N");
ui_print("Target: ZTE/P996A01_N/ailsa_ii:7.1.1/NMF26F/20170301.161705:user/release-keys");
show_progress(0.650000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat") ||
abort("E1001: Failed to update system image.");
show_progress(0.050000, 5);
package_extract_file("boot.img", "/dev/block/bootdevice/by-name/boot");
package_extract_file("ddr.img", "/dev/block/bootdevice/by-name/ddr");
package_extract_file("keymaster.mbn", "/dev/block/bootdevice/by-name/xblbak");
package_extract_file("lksecapp.mbn", "/dev/block/bootdevice/by-name/lksecapp");
package_extract_file("rpm.mbn", "/dev/block/bootdevice/by-name/rpm");
package_extract_file("tz.mbn", "/dev/block/bootdevice/by-name/tz");
package_extract_file("echarge.img", "/dev/block/bootdevice/by-name/echarge");
package_extract_file("mdtp.img", "/dev/block/bootdevice/by-name/mdtp");
package_extract_file("xbl.elf", "/dev/block/bootdevice/by-name/xbl");
package_extract_file("cmnlib64.mbn", "/dev/block/bootdevice/by-name/cmnlib64");
package_extract_file("adspso.bin", "/dev/block/bootdevice/by-name/dsp");
package_extract_file("recovery.img", "/dev/block/bootdevice/by-name/recovery");
package_extract_file("sec.dat", "/dev/block/bootdevice/by-name/sec");
package_extract_file("NON-HLOS.bin", "/dev/block/bootdevice/by-name/modem");
package_extract_file("pmic.elf", "/dev/block/bootdevice/by-name/pmic");
package_extract_file("devcfg.mbn", "/dev/block/bootdevice/by-name/devcfg");
package_extract_file("emmc_appsboot.mbn", "/dev/block/bootdevice/by-name/aboot");
package_extract_file("fastboot.img", "/dev/block/bootdevice/by-name/fbop");
package_extract_file("splash.img", "/dev/block/bootdevice/by-name/splash");
package_extract_file("hyp.mbn", "/dev/block/bootdevice/by-name/hyp");
package_extract_file("BTFM.bin", "/dev/block/bootdevice/by-name/bluetooth");
package_extract_file("cmnlib.mbn", "/dev/block/bootdevice/by-name/cmnlib");
show_progress(0.200000, 10);
show_progress(0.100000, 10);
format("ext4", "EMMC", "/dev/block/bootdevice/by-name/userdata", "0", "/data");
set_progress(1.000000);
Here we can conclude that the fastboot.img is flashed to the fob partition which is where the flags to enable the full fastboot commands. It's basically a security partition.
Is the Whole Partition different??
Is it just a few bytes difference??
Its actually not much and seeing that this identical partition has been used for several years
We can hope our fastboot image is the same or very similar. But remember it is the fob partition.
Here is the difference.
[email protected]:~$ hexdump -C -v /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/A2017U_FASTBOOT_UNLOCK_EDL/fastboot.img > /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt
[email protected]:~$ diff home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt /home/bigcountry907/Desktop/ZTE/stock/fbstock.txt
diff: home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt: No such file or directory
[email protected]:~$ hexdump -C -v /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/A2017U_FASTBOOT_UNLOCK_EDL/fastboot.img > /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt
[email protected]:~$ diff /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt /home/bigcountry907/Desktop/ZTE/stock/fbstock.txt
257c257
< 00001000 01 00 00 00 78 56 34 12 00 00 00 00 01 00 00 00 |....xV4.........|
---
> 00001000 00 00 00 00 78 56 34 12 00 00 00 00 00 00 00 00 |....xV4.........|
579,595c579,595
< 00002420 62 6f 6f 74 02 02 20 00 04 82 01 00 04 e0 4f a3 |boot.. .......O.|
< 00002430 b8 c0 79 df 98 9a ce 8b 47 ed f6 23 61 e8 3e 4d |..y.....G..#a.>M|
< 00002440 7a 43 fc 4b d4 39 60 c5 5a a6 96 ea c0 4d e2 52 |zC.K.9`.Z....M.R|
< 00002450 27 3e b6 d0 21 72 72 c8 59 03 44 90 ff 4a 86 3b |'>..!rr.Y.D..J.;|
< 00002460 29 2c 16 7a 04 2b 36 07 6f 8f 04 8e 35 7c f2 9f |),.z.+6.o...5|..|
< 00002470 cc 29 e5 0b 74 30 e9 0c ec cd 23 4b 19 84 c7 d1 |.)..t0....#K....|
< 00002480 f7 46 9b 7d dc 8b 6b bb 01 d3 f0 0a ab 96 ca 7e |.F.}..k........~|
< 00002490 a2 6e 91 6b d9 38 d6 d6 2e 4f 50 3e 2d 17 55 e3 |.n.k.8...OP>-.U.|
< 000024a0 e5 50 e4 1f dc 03 26 9e e9 22 19 dc 60 e1 0b a0 |.P....&.."..`...|
< 000024b0 b5 06 25 bd e4 08 24 4f 7b dd 42 29 82 55 06 84 |..%...$O{.B).U..|
< 000024c0 a1 5f d7 c1 99 3f 83 30 5d 10 59 5e 9d 2a 31 3f |._...?.0].Y^.*1?|
< 000024d0 f9 87 54 55 1e 82 40 68 5b c8 e4 18 98 80 d1 ec |[email protected][.......|
< 000024e0 df d7 01 d1 ec a5 a2 e4 c1 86 76 63 e0 82 13 35 |..........vc...5|
< 000024f0 61 30 63 d7 cd e8 21 33 73 e9 c4 93 ad 65 68 77 |a0c...!3s....ehw|
< 00002500 3e eb 3e 90 8a bb 8b 07 1b 26 ff d5 0d 37 a4 6c |>.>......&...7.l|
< 00002510 ec c6 69 30 dd 22 1b 9f 69 79 47 69 22 ba 9e c8 |..i0."..iyGi"...|
< 00002520 0c 23 96 f8 cf 66 74 74 11 98 d6 e4 |.#...ftt....|
---
> 00002420 62 6f 6f 74 02 02 20 00 04 82 01 00 a8 e0 dd 69 |boot.. ........i|
> 00002430 5b b2 47 12 bf 74 41 7a 00 37 a0 b8 10 15 d4 4e |[.G..tAz.7.....N|
> 00002440 a6 59 74 9b 7d a4 df 95 eb 3f 1a 29 1c 60 23 7c |.Yt.}....?.).`#||
> 00002450 91 37 2a 07 d3 e9 45 17 ac ac ab a9 ba b4 42 70 |.7*...E.......Bp|
> 00002460 46 5f 67 22 f7 37 1f de 46 f9 67 44 74 d7 26 42 |F_g".7..F.gDt.&B|
> 00002470 49 9c e8 ee 98 78 89 2b b2 1e c3 58 a8 d2 3a 7f |I....x.+...X..:.|
> 00002480 39 7d 22 09 c6 01 c5 0f 95 65 57 1e af 79 d9 d6 |9}"......eW..y..|
> 00002490 8d 99 84 4f 24 ff 55 b2 b0 20 07 00 39 e6 9a 27 |...O$.U.. ..9..'|
> 000024a0 a0 bc 97 dd 27 7d f2 a2 88 b6 b5 53 4a ba 7a 8e |....'}.....SJ.z.|
> 000024b0 65 98 f6 ef 4d 7e 2e 91 01 66 35 9e e1 da 15 c4 |e...M~...f5.....|
> 000024c0 fe a4 d2 26 a1 99 88 a3 55 2f ac 65 71 f8 5f 86 |...&....U/.eq._.|
> 000024d0 a7 79 f8 b5 61 b5 da 2c 7b 89 39 3b ff 45 a3 7f |.y..a..,{.9;.E..|
> 000024e0 dc 92 d5 4e 8b df 68 c0 e9 43 18 7b 60 5a 03 60 |...N..h..C.{`Z.`|
> 000024f0 18 da 96 84 e7 97 a7 09 a9 1a 2d b6 5b d3 d2 f6 |..........-.[...|
> 00002500 c8 33 a2 8f ef 32 5e 6a 45 39 66 b5 a6 a4 35 0f |.3...2^jE9f...5.|
> 00002510 03 0c 9d 57 79 28 43 09 9a 3e 7b 01 8c 6e 66 b2 |...Wy(C..>{..nf.|
> 00002520 1a f3 3d 92 d1 66 91 04 4a 3e 79 69 |..=..f..J>yi|
[email protected]:~$ hexdump -C -v /home/bigcountry907/Desktop/ZTE/Fastboot-UL/fastboot.img > /home/bigcountry907/Desktop/ZTE/Fastboot-UL/fbul2.txt
[email protected]:~$ diff /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt /home/bigcountry907/Desktop/ZTE/Fastboot-UL/fbul2.txt
[email protected]:~$
There's definitely more to come but this is enough to think about for now.
Here are all the partition block sizes and labels for the blade x max
30535680 mmcblk0 EMMC CHIP
4096 mmcblk0p1
4096 mmcblk0p2
4096 mmcblk0p3
4096 mmcblk0p4
4096 mmcblk0p5
4096 mmcblk0p6
4096 mmcblk0p7
16384 mmcblk0p8
16384 mmcblk0p9
16384 mmcblk0p10
4096 mmcblk0p11
4096 mmcblk0p12
4096 mmcblk0p13
4096 mmcblk0p14
4096 mmcblk0p15
4096 mmcblk0p16
4096 mmcblk0p17
4096 mmcblk0p18
32768 mmcblk0p19
4096 mmcblk0p20
94208 mmcblk0p21
65536 mmcblk0p22
65536 mmcblk0p23
4096 mmcblk0p24
4096 mmcblk0p25
4096 mmcblk0p26
4096 mmcblk0p27
4096 mmcblk0p28
4096 mmcblk0p29
4096 mmcblk0p30
4096 mmcblk0p31
4096 mmcblk0p32
4096 mmcblk0p33
32768 mmcblk0p34
4096 mmcblk0p35
4096 mmcblk0p36
4096 mmcblk0p37
4096 mmcblk0p38
65536 mmcblk0p39
4096 mmcblk0p40
4096 mmcblk0p41
4096 mmcblk0p42
4096 mmcblk0p43
65536 mmcblk0p44
1048576 mmcblk0p45 cache
5242880 mmcblk0p46 system
23629807 mmcblk0p47 data
4096 mmcblk0rpmb
31166976 mmcblk1 SD CARD
31165935 mmcblk1p1 SD CARD Storage

Old codehead (emphasis on the "old"), and I have this device... unfortunately, it's been updated, so there's not a whole lot I could offer...
With an at least rudimentary how-to provided, though... as long as I can get the device back to square-one, if things go tits-up and it's necessary... bitter experience... not a few Cricket LG G Stylo paperweights at hand... I'l like to offer myself as an alpha-tester for whatever you find out...
Just bought this lovely new home in Albuquerque, and, until a few things settle down, don't have a lot of cash... but I'll offer mine as a test-bed of sorts...
I'm fascinated with the work you are doing, and I really dig this phone for pretty much every reason except Cricket's bullheadedness, and am looking forward to watching you work...
I'm also kinda horrified that, seeing your log dumps upthread, I could actually understand it... can take the boy out of the tech, but some things seem to be stuck in the little grey cells forever.... *chuckle*
My tech chops tended more towards xBASE and Delphi, and still do... was what I learned, along with COBOL and RPig...
Have been trying, over the past few years, to get some C++ and Java under my belt, but it's more important to me to finish my BA in the up coming spring semester, and do UNM School of Law... Renaissance man wanna-be here... *grin*

Just wondering, good madam or sir, what progress you've been able to do... I don't mean to push, as we all have lives away from this forum (at least I do hope so.. *smile*), but, as I love to learn, and now in my 60's, found my Java, C and C++ texts, have downloaded and installed all my preferred tools, and would just really dig seeing some journaling of your progress on this rather fascinating device... more internal RAM than I would have ever expected on a smart phone, and, as such, space is not at such a premium that I'm required to use Apps2SD Pro (although I paid for it), Titanium (although I paid for it), but just damn...
I'm disgusted that Cricket would be so paranoid against their paying customers that they insist on absolute control... just damn...
Sorry... woolgathering on a Friday afternoon, while installing other dev tools... <smile>

Firmware update downloaded
My phone has the firmware downloaded please let me know if there is a way to pull it for R&D
---------- Post added at 03:31 AM ---------- Previous post was at 02:55 AM ----------
This phone just force installed nevermind

Update not installed
I have the update downloaded but not installed. The phone is trying to force update but it can't because my battery is too low, I'll try and leave it that way. Do we have a way to find and extract the update?

Scratch that. Force install starts at 20% battery or so. Accidently over charged haha.

We need to post the way to pull the update
We need to post a way to extract the update so that the next person who has it but it is not installed can pull it for us any help from more experienced individuals would be greatly appreciated

Update ready to dl
Any ideas how to pull it from the phone

If you have an update.zip signing bypass, I could leverage that to get a dump of the partition table.

Z983 Root Method Development
Hello world of XDA,
We want to root this device. Yes? Well, as of right now, 01-27-2018, there is no working method available on the internet. We have to do this ourselves. Ive rooted literally hundereds of phones, but this one, Crickets down played version of the Blade Zmax, re-dubbed Blade XMax Z983..
First, we need the boot loader. I am willing to team up with some people, to make this happen. Any takers?

Has anyone been able to get the last update files, about a week ago i think, off the phone before applying the update. If anyone has those we may be in business, at least further along than we were. That last update was a decent size update, and if it had anything to do with the spectre/meldown patch, that update would have had the partition layout, how the bootloader has been hidden and so on and so fourth. So if anyone was able to grab the update please post here, as the thread creator and a few others seem to know what to do from there.

Can I start by modifying tye system UI apk?

Hey so I've got this device and it's FRP locked. If anybody is willing to work on this still these days (for root, frp, various unlocks, etc) then let's make it happen. Can't say for sure if I'll have the device for very long, but I'm definitely down to try while I have it. Lmk if there's anything I can do to help the progress.

dammi.forza0910 said:
Hello world of XDA,
We want to root this device. Yes? Well, as of right now, 01-27-2018, there is no working method available on the internet. We have to do this ourselves. Ive rooted literally hundereds of phones, but this one, Crickets down played version of the Blade Zmax, re-dubbed Blade XMax Z983..
First, we need the boot loader. I am willing to team up with some people, to make this happen. Any takers?
Click to expand...
Click to collapse
You know how bad I wish I could take you up on this? I just don't have the experience or the knowledge. I'd love to learn but I don't even know where to start.

Okay, so I have successfully copied the boot animation.zip and have attatched it as proof. I believe, i can actuall copy the firmware because I found the file locatiom after an exhausting amount of trial and error with different approaches. Usong Debian (wheezy) ,and a combination of file explores, and modifying apk's through luck patcher, I was able to view the device tree and so on. Anybody willing to guide me to the next step?

Z983 Firmware .img files found and uploaded
Okay, I found the firmware files and when I moved them to my external SD card, they combined automatically and was labled update.zip. This is it guys, help me!

Device Tree
Can anyone let me know if this is helping, or if everyone gave up....?

dammi.forza0910 said:
Okay, I found the firmware files and when I moved them to my external SD card, they combined automatically and was labled update.zip. This is it guys, help me!
Click to expand...
Click to collapse
Downloading the files when I get off work and will look at them as best I can, maybe we can get the bootloader to show up in the recovery, Cricket did something to the flags that bypasses the bootloader, maybe we can reflag and get it to show up again. Good work, hopefully some progress can be made now.

LG G2 bricked, partition table corrupt

Update:
Somehow, the phone came back, sort of (battery low?!), and I was able to see all partitions again.
So I tried fixing the problem by copying boot.img and laf.img to the respective partitions ... I guess you shouldn't try these things at 1:30 am after already getting yourself in a horrible mess, but here I am. Now the phone is stuck at the LG logo screen, the LED flashes green and blue, and nothing happens. All I can do is to push the power button, and the process repeats.
Naturally, I cannot see any partitions any longer. Now the device seems to be REALLY dead.
Anything I can still try?!
Original problem description
I have tried, after somehow messing things up when following the guide to install LineageOS on the LG G2 (d802, international version with 32 GB), to resurrect my phone using this guide.
However, it failed to solve my problem, and when I tried to boot, the phone still showed only the LG logo, the secure booting error, and then the screen went black, just as before. I guess I should have used dd as well to copy the boot, dbi and laf partitions.
Instead, I figured maybe I should try the TWRP Recovery v2.6.3.2 instead of either TWRP v2.8.7.3 or the LineageOS Recovery image, and that probably has been my (final) mistake. Because, before, the output from gdisk looked liked this:
Code:
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 61071360 sectors, 29.1 GiB
Model: MMC Storage
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 98101B32-BBE2-4BF2-A06E-2BB33D000C20
Partition table holds up to 36 entries
Main partition table begins at sector 2 and ends at sector 10
First usable sector is 34, last usable sector is 61071326
Partitions will be aligned on 2-sector boundaries
Total free space is 257992 sectors (126.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 32768 163839 64.0 MiB 0700 modem
2 163840 165887 1024.0 KiB FFFF sbl1
3 165888 166911 512.0 KiB FFFF dbi
4 196608 197631 512.0 KiB FFFF DDR
5 229376 231423 1024.0 KiB FFFF aboot
6 231424 233471 1024.0 KiB FFFF rpm
7 262144 294911 16.0 MiB FFFF boot
8 294912 296959 1024.0 KiB FFFF tz
9 296960 296961 1024 bytes 0700 pad
10 327680 333823 3.0 MiB FFFF modemst1
11 333824 339967 3.0 MiB FFFF modemst2
12 339968 339969 1024 bytes FFFF pad1
13 360448 393215 16.0 MiB FFFF misc
14 393216 458751 32.0 MiB 0700 persist
15 458752 491519 16.0 MiB FFFF recovery
16 491520 497663 3.0 MiB FFFF fsg
17 524288 525311 512.0 KiB FFFF fsc
18 525312 526335 512.0 KiB FFFF ssd
19 526336 526337 1024 bytes FFFF pad2
20 526338 527361 512.0 KiB FFFF encrypt
21 557056 573439 8.0 MiB 0700 drm
22 573440 589823 8.0 MiB 0700 sns
23 589824 655359 32.0 MiB FFFF laf
24 655360 720895 32.0 MiB FFFF fota
25 720896 786431 32.0 MiB 0700 mpt
26 786432 787455 512.0 KiB FFFF dbibak
27 787456 789503 1024.0 KiB FFFF rpmbak
28 789504 791551 1024.0 KiB FFFF tzbak
29 791552 791567 8.0 KiB FFFF rct
30 819200 6488063 2.7 GiB 0700 system
31 6488064 7733247 608.0 MiB 0700 cache
32 7733248 7897087 80.0 MiB 0700 tombstones
33 7897088 7929855 16.0 MiB 0700 spare
34 7929856 8028159 48.0 MiB 0700 cust
35 8028160 60948479 25.2 GiB 0700 userdata
36 60948480 61071326 60.0 MiB 0700 grow
Now, it looks like this, so I am unable to use dd to copy any files to the (now apparently deleted or at least unavailable) partitions of the LG G2:
Code:
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Warning! Main partition table overlaps the first partition by 32 blocks!
You will need to delete this partition or resize it in another utility.
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sdb: 2014208 sectors, 983.5 MiB
Model: Mighty Drive
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): DEF7EA8F-7D62-49A1-8F27-4F59EF0FDF29
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 2014174
Partitions will be aligned on 2-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 2 2014207 983.5 MiB 0700 Microsoft basic data
I am afraid I have no backup of the partition table other than the output above, because I only learned of this feature of gdisk when looking for solutions of this (last) issue.
Is there any way I can restore the partition table of my device?
Any help in unbricking my phone is, of course, GREATLY appreciated. :fingers-crossed: