Database Users

Any way to access register device from bootloader?

Hi. This is a message to experts.
Loiking at bootloader in my broken ELFIN, well lets better say death, because even with GOLD CARD couldnt get alive, i found a commnad called wdata. This this the screen result:
==========================================================
Cmd>wdata
Usage:
wdata [StartAddr Len]
Write data to memory(if write to ROM, need erase first).
StartAddr : Start address of memory.
Len : How many bytes will be written.
Length must not more than 0x10000 bytes(buffer limitation).
Write to RAM: 4 bytes(CRC checksum limitation).
1 byte(in user mode).
Write to ROM: 4 bytes(CRC checksum limitation).
2(16-bit)/4(32-bit) bytes(in user mode).
Write to ROM(16-bit data bus): 32 bytes(writebuffer mode).
Write to ROM(32-bit data bus): 64 bytes(writebuffer mode).
Length must be 4 bytes boundary(CRC checksum) if not in user mode.
After command execute, then send out the data to terminal.
Data format: HTCS(4 bytes)+DATA+checksum(4 bytes, if not in user mode)+HTCE(4 bytes).
==========================================================
So the question is. Is there any way of using that command to access the F****** g_cKeyCardSecurityLevel = FF register and modify it?.
Anyone knows whats the memory position of that register?, if so, How can i change it?
Hopping anwsers.
Thanks

[TUT] SRPX compressed XIP section workout (like Asus, HP or Etens)

As I've heard some people have problems with working with XIP sections of some ROMs... as for example Asus P525 or other devices, here's a little tiny tutorial about this issue. What's the problem with them? It's their XIP sections are compressed with SRPX algorithm.
In some Asus kitchens in the ROM directory you have a ROM.TPL file. How to use it?
1. Get the OSNBTool from the attachement (it's a fantastic tool from Weisun of PDAclan.com).
2. Do:
Code:
>osnbtool -d rom.tpl 1 xip.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Deompress processing...
Successfully decompressed to xip.bin
3. Run XIPPort and click "dump xip.bin".
4. Do your work with a XIP section.
5. After you're finished, issue "realloc P" and "build xip_out.bin" in XIPPort.
6. Do:
Code:
>osnbtool -c rom.tpl 1 xip_out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
NEW Uncompressed size: 2D5000
NEW Compressed size: 1A6BF6
New Part Size: 1A71E6
Successfully compressed xip_out.bin into rom.tpl.NEW
7. You're done!

It turns out that a dumprom.exe and buildxip.exe tools handle those XIPs really well, too - and even better, as they do better reallocation of modules.
So, it can go as this:
Code:
>dumprom rom.tpl
IMGFS guidBootSignature: F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 0000001E
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
Address: 00000200, dwBlockSignature: 2F5314CE
dwNextHeaderBlock: 00000000 (size: FFFFFE00)
Header type: FFFFFFFF, Addr: 00000208
Empty header
Header type: FFFFFFFF, Addr: 0000023C
Empty header
Header type: FFFFFFFF, Addr: 00000270
Empty header
Header type: FFFFFFFF, Addr: 000002A4
Empty header
Header type: FFFFFFFF, Addr: 000002D8
Empty header
Header type: FFFFFFFF, Addr: 0000030C
Empty header
Header type: FFFFFFFF, Addr: 00000340
Empty header
Header type: FFFFFFFF, Addr: 00000374
Empty header
Header type: FFFFFFFF, Addr: 000003A8
Empty header
Now you have new files: boot.bin, msflsh.bin and romhdr.bin, and a new folder XIP. Edit your XIP folder as you want.
Now, in ..\temp\dump folder put your .VM and .ROM folders and issue:
Code:
>buildxip
BUILDXIP 0.54 Copyright (c) 2007-2008 bepe 30 Jan 2008
Slot 0 Boundary: 0x01fa0000
Slot 1 Boundary: 0x03e18000
RAMStart: 0x88868000
RAMFree: 0x888c6000 - 0x8c000000 L0373a000
KernelFlags: 0x00000000
FSRamPercent: 0x00000004
Done!
In the end put your new created out.bin file into your tpl file:
Code:
>osnbtool -c rom.tpl 1 out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
Extra data bytes : 0x00000000
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
New part size larger than old part in source OS image!
Rebuilding partition structure...
NEW Uncompressed size: 2E7000
NEW Compressed size: 1B1664
New Part Size: 1B1C78
Successfully compressed out.bin into rom.tpl.NEW
and you're done!

Hello utak3r.
This info is really important for me as I have an Eten device. Although, I've tried several times to build a XIP using "buildxip" (with or without -b flag - I don't know exactly what it does) but my rom doesn't boot.
I didn't even tried to change anything in XIP folder. Only dumped the XIP using "dumprom" and then build again to test it. Was I supposed to do something in the middle? Any idea?

bgcngm said:
with or without -b flag - I don't know exactly what it does
Click to expand...
Click to collapse
This flag tells if it should take another, external boot.rgu file, or the included one. So, you should do it without this flag.
bgcngm said:
but my rom doesn't boot.
Click to expand...
Click to collapse
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Check, what was the original xip.bin size and try to fill your new one with 0xFFs to this size - maybe it will help...
Another thing: give here full outputs from all the steps.

utak3r said:
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Click to expand...
Click to collapse
I already thought that the problem was XIP insertion, but then I found XIPKitchen.
With a XIP created by XIPKitchen, I can successfully create a bootable rom, even with a different XIP partition size. I'm happy because those XIP's are working, however XIPKitchen doesn't integrates nicely in a rom kitchen. The user has to manually input the files and select some options in the program and I wanted to build the new XIP silently which is what buildxip does.
Do you know what could be the problem? I might be missing something... like rellocating the modules... But as I said before, I tried to build the XIP without touching it, simply by dumping and then rebuilding it. In that case there was no need to rellocate the modules, right?

utak3r, don't you know what could be the problem?

Hi bro
In some Asus kitchens in the ROM directory you have a ROM.TPL file
Click to expand...
Click to collapse
use tool NB0 KITCHEN mrtoto which extracting&inserting partition xip in file out.bin in to NewROM.tpl
extracting out.bin use XipKitchen or buildrom bepe,ren xip_out_new.bin to out.bin ,move to directory Rom.tpl end push button "Build Template" in NB0 KITCHEN mrtoto

THANKS A LOT !!
Awesome tool, had troubles extracting one of the xip files since a LONG time, this just did the trick and it's nifty features like putting romhdr, o32, e32 headers nicely were also helpful.

Odroid u2 Won't boot to recovery

My Odroid won't boot to CWM recovery with CM10.1 installed on the emmc.
I extracted the three files from here: http://cyanogenmod.org/rc/odroidu2-recovery.zip and placed them on the root of the emmc but every time I boot up I get this
Code:
U-Boot 2010.12-svn (Jan 28 2013 - 14:10:19) for Exynox4412
CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
APLL = 1000MHz, MPLL = 880MHz
DRAM: 2047 MiB
PMIC VERSION : 0x00, CHIP REV : 2
TrustZone Enabled BSP
BL1 version: 20121128
Checking Boot Mode ... EMMC4.41
REVISION: 2.0
Manufacturer TOSHIBA [ 15028MB ]
NAME: S5P_MSHC4
MMC Device 0: 15028 MB
MMC Device 1: 0 MB
MMC Device 2 not found
*** Warning - using default environment
ModeKey Check... run normal_boot
Net: No ethernet found.
Hit any key to stop autoboot: 0
NAME: S5P_MSHC4
NAME: S5P_MSHC4
>>> Load Boot Script from mmc 0:1 <<<
NAME: S5P_MSHC4
Partition1: Start Address(0x520000), Size(0x181a000)
reading boot.scr
Warning : Reads a file that is smaller than the cluster size.
623 bytes read
## Executing script at 40008000
Wrong image format for "source" command
Exynos4412 #
how can i get past this?

deleted

[LIBRARY]libpit-X Online PIT analysis Tool and Library

I would like to first start by sharing a bit of history behind this library. @Benjamin Dobell started the Heimdall project where he packet-sniffed the Odin(desktop client)/Loke(on-device server) protocol in order to create Heimdall, an open source flashing tool which I've personally used in my own projects Heimdall one-click and One-Click UnBrick as well as my current project, CASUAL. Heimdall was released with a very rough, but working, analysis of the PIT files and has been slowly increasing over time.
@Ralekdev , @Rebellos and myself began looking at the PIT files much later than Benjamin. Ralekdev and Rebellos were to reverse-engineer the bootloaders of several Samsung devices and was able to come up exploits while I somewhat brought the work together and assisted where I could. Ralekdev even identified proper sizes of data blocks and has created a few tools to assist.
Introduction
I'm happy to announce that we have 100% identification of all parts of the PIT files as they stand today. We are no longer working on identifying variables thanks to Ralekdev, Rebellos and Benjamin's work. We can read, and write and integrate PIT files into our Java Applications. As a demonstration of this library, i encourage you to
Analyze Your Pit File Online
If you don't have a PIT file, you can use this one. This will provide you with human-readable analysis of a PIT file.
This can also be accomplished locally on your computer with this file: http://goo.im/devs/AdamOutler/libpitX/libpit-X-R917.jar
Code:
[email protected]:~$libpit-X.jar GalaxyCamera.pit
PIT Name: Mx
Entry Count: 17
File Type: COM_TAR2
--- Entry #0 ---
ID: 80 Partition Name: BOOTLOADER
Filename: sboot.bin param: md5
Block Size: 1734 (887.8 kB)
Block range: 0 - 1733 (hex 0x0 - 0x6c5)
PartType: 2 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Bootloader partition resides on the AP EMMC.
--- Entry #1 ---
ID: 81 Partition Name: TZSW
Filename: tz.img param: md5
Block Size: 312 (159.7 kB)
Block range: 1734 - 2045 (hex 0x6c6 - 0x7fd)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #2 ---
ID: 70 Partition Name: PIT
Filename: camera.pit
Block Size: 16 (8.2 kB)
Block range: 34 - 49 (hex 0x22 - 0x31)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #3 ---
ID: 71 Partition Name: MD5HDR
Filename: md5.img param: in.md5
Block Size: 2048 (1.0 MB)
Block range: 50 - 2097 (hex 0x32 - 0x831)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #4 ---
ID: 1 Partition Name: BOTA0
Filename: -
Block Size: 8192 (4.2 MB)
Block range: 8192 - 16383 (hex 0x2000 - 0x3fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #5 ---
ID: 2 Partition Name: BOTA1
Filename: -
Block Size: 8192 (4.2 MB)
Block range: 16384 - 24575 (hex 0x4000 - 0x5fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #6 ---
ID: 3 Partition Name: EFS
Filename: efs.img param: md5
Block Size: 40960 (21.0 MB)
Block range: 24576 - 65535 (hex 0x6000 - 0xffff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #7 ---
ID: 4 Partition Name: PARAM
Filename: param.bin param: md5
Block Size: 16384 (8.4 MB)
Block range: 65536 - 81919 (hex 0x10000 - 0x13fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #8 ---
ID: 5 Partition Name: BOOT
Filename: boot.img param: md5
Block Size: 16384 (8.4 MB)
Block range: 81920 - 98303 (hex 0x14000 - 0x17fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #9 ---
ID: 6 Partition Name: RECOVERY
Filename: recovery.img param: md5
Block Size: 16384 (8.4 MB)
Block range: 98304 - 114687 (hex 0x18000 - 0x1bfff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #10 ---
ID: 7 Partition Name: RADIO
Filename: modem.bin param: md5
Block Size: 65536 (33.6 MB)
Block range: 114688 - 180223 (hex 0x1c000 - 0x2bfff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #11 ---
ID: 8 Partition Name: CACHE
Filename: cache.img param: md5
Block Size: 2097152 (1.1 GB)
Block range: 180224 - 2277375 (hex 0x2c000 - 0x22bfff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #12 ---
ID: 9 Partition Name: SYSTEM
Filename: system.img param: md5
Block Size: 3145728 (1.6 GB)
Block range: 2277376 - 5423103 (hex 0x22c000 - 0x52bfff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #13 ---
ID: 10 Partition Name: HIDDEN
Filename: hidden.img param: md5
Block Size: 737280 (377.5 MB)
Block range: 5423104 - 6160383 (hex 0x52c000 - 0x5dffff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #14 ---
ID: 11 Partition Name: OTA
Filename: -
Block Size: 16384 (8.4 MB)
Block range: 6160384 - 6176767 (hex 0x5e0000 - 0x5e3fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #15 ---
ID: 12 Partition Name: TDATA param: TA
Filename: - param: erdata.img param: md5
Block Size: 409600 (209.7 MB)
Block range: 6176768 - 6586367 (hex 0x5e4000 - 0x647fff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA: param: Dmained
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #16 ---
ID: 13 Partition Name: USERDATA
Filename: userdata.img
Block Size: 0 (0 B)
Block range: 6586368 - 6586367 (hex 0x648000 - 0x647fff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA: remained
This EXT4 format Data partition resides on the AP EMMC. The partition will expand to fill the remainder of the EMMC.
Development Library/Downloads/Documentation
The libpit-X library is an extremely heavy overhaul of the libpit--Java- library by Benjamin Dobell. It features 100% accurate read/write/modification ability. It is also very well documented. I've submitted an issue for Benjamin to pull my changes. Until then you can find the library here.
Online documentation can be found here: http://javadoc.casual-dev.com/namespacecom_1_1casual__dev_1_1libpit_x.html
When you load a Library into your development environment, you need three parts. The Package, the Javadoc and the Source. The latest version of these three parts can be found here:
Package: http://jenkins.casual-dev.com/view/All/job/Build libpitX/ws/trunk/X/libpitX/dist/libpit-X.jar
Javadoc: http://jenkins.casual-dev.com/view/...runk/X/libpitX/dist/javadoc/*zip*/javadoc.zip
Source: http://jenkins.casual-dev.com/view/All/job/Build libpitX/ws/trunk/X/libpitX/src/*zip*/src.zip
Library Archives can be found here: http://goo.im/devs/AdamOutler/libpitX
Here's a picture of the library in action: http://dl.xda-developers.com/attach...3/7/8/Screenshot_from_2013-11-23_21_16_36.png
Automated Testing
Testing is conducted on EVERY SINGLE REVISION and compiled code is not published to the archvies if testing fails.
Latest test results: http://jenkins.casual-dev.com/job/CASUALbuild Test/lastBuild/console
Test code for this $X project: https://code.google.com/p/android-c...trunk/CASUALcore/test/CASUAL/archiving/libpit
And of course you can always test version yourself with our Analyze Your Pit File Online utility.
About
This is a $X project. The $ represents CASUAL for two reasons; CASUAL commands start with $, and the way CASUAL is commonly pronounced is cash-ual. In $X projects, the $ is silent. $X projects are not CASUAL core projects but rather offshoots. Rather than create an entire new repository for $X projects, we will host them in the http://android-casual.googlecode.com repository. For example, the working source code for this project is located in the CASUAL-Core and during build, the $X project is automatically created in the X.casual_dev.libpitX pacakge.
If you wish to contribute to this project, or any other CASUAL project, check out the "Developers" section of this page: http://casual-dev.com/about/. There's a lot to do and we are wiling to help you learn.

Please tell how to redistribute space from cache and hidden partions to increase user space with your utility?

Adam, most PIT files I analyze have one or two strange partitions at the end..is this the fault of the analysis software or is just something else completely? Also, have you ever been able to extract the pit from a device that you was the same as ( md5 match) one you would get in a odin tar? The pit files I extract never end up being the exact same as the pit files that come in the odin tar for a particular device regardless of the method used; Heimdall and/or using dd if/of= w/ correct skip/count don't yield the right results. The PIT analysis tool you helped make lists everything correctly for the VZW GS4 but doesnt list the strange partition at the end thats found with other analysis tools like the one below, so I assume the last thing isn't a partition then?
TL;DR - What is the partition at the end with strange characters?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Surge1223 said:
TL;DR - What is the partition at the end with strange characters?
Click to expand...
Click to collapse
That would appear to be a signature.

Please tell me this is going to lead 16gig Samsung Sg4 users to get more than 9 gigs free space when using a non touch wiz ROM . Great project and congrats

igoa said:
Please tell how to redistribute space from cache and hidden partions to increase user space with your utility?
Click to expand...
Click to collapse
This isn't a utility, it's a library. You would include it in your Android Application or Java Desktop App.
Here's how you would use it for your project
Code:
Class BlockResizer{
public void remove100BlocksFromCACHE(){
//Open the PIT file
PitData pd=new PitData("mypit.pit");
//get the CACHE partition
PitEntry CACHE=pd.findEntry(String partitionName);
//Remove 100 blocks from CACHE
int blocksToRemove=100;
CACHE.block_count=CACHE.block_count-blocksToRemove;
//Loop through the rest of the partitions and bump them up 100 blocks.
for (int i=CACHE.part_id+1; i<pd.entryCount; i++){
pd.getEntry(i).BLOCK_START=pd.getEntry(i).BLOCK_START-blocksToRemove;
}
//write out the new PIT to "newPit.pit"
pd.pack(new DataOutputStream(new FileOutputStream("newPit.pit");
}
This would work just fine assuming that the rest of the partitions after the CACHE are in proper order.

igoa said:
Please tell how to redistribute space from cache and hidden partions to increase user space with your utility?
Click to expand...
Click to collapse
Hey, i just added the ability to do this easily after reviewing the code for a bit. The commit is still processing and the new library and documentation should be up shortly... Here goes a partition resize
Code:
public void resize(){
PitData instance = new PitData("MyPitFile.pit");
String partName="CACHE"; //partition name to change
int changeToSize=-2000; //size to change partition (-2000 blocks= 1 megabyte smaller)
try {
instance.resizePartition(partName, changeToSize); //actually resizes the partiton and all others are moved.
} catch (ClassNotFoundException ex) {
Logger.getLogger(PitDataTest.class.getName()).log(Level.SEVERE, null, ex); //this occurs if the partition specified is not found
}
instance.pack(new DataOutputStream(new FileOutputStream("newPit.pit"); //write out the new PIT to "newPit.pit"
}
This code has accompanying test code. So, if you'd like to resize a PIT, all you need to do is add the libpitX library into an existing project then run the code above.

AdamOutler said:
That would appear to be a signature.
Click to expand...
Click to collapse
This is very interesting. Is there anything we can do with it? Or is this read only/unknown flash protocol?

ryanbg said:
This is very interesting. Is there anything we can do with it? Or is this read only/unknown flash protocol?
Click to expand...
Click to collapse
You can append it to the end of the file.

AdamOutler said:
You can append it to the end of the file.
Click to expand...
Click to collapse
So it's not possible to write my own certificate to this 'partition' yet?

ryanbg said:
So it's not possible to write my own certificate to this 'partition' yet?
Click to expand...
Click to collapse
Yeah but it's worthless without Samsung's private key.

AdamOutler said:
Yeah but it's worthless without Samsung's private key.
Click to expand...
Click to collapse
Have you seen this post? here
and more specifically this:
ERROR: Image Invalid, X509_Certificate is NULL!
ERROR: Boot Invalid, RSA_KEY is NULL!
ERROR: Image Invalid! Decryption failed!
ERROR: Image Invalid! Please use another image!
Does this make a difference?

That's just strings and it says what error you'll get if you put in a null signature.

@AdamOutler for the VZW Galaxy S4 I analyzed the PIT file produced by Heimdall and it reports the last four partitions as "remained" so I decided to manually extract my PIT file using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
which is specific to MSM8690 S4's and the PIT analysis now shows the "remained" partitions actual values and you can see the PIT I extracted is factory signed, because I compare the md5 to the PIT from a factory Odin tar here so is this problem unique to just the S4 or is it a Heimdall problem? I assumed Heimdall just extracted the padded PIT file but even so it should still show the information for the last 4 partitions.
Before
Code:
--- Entry #29 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #30 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #31 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #32 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
After
Code:
--- Entry #29 ---
ID: 70 Partition Name: PGPT
Filename: pgpt.img
Block Size: 34 (17.4kB)
Block range: 0 - 33 (hex 0x0 - 0x21)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PGPT partition, identified as partition number 70, is 17.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as pgpt.img.
--- Entry #30 ---
ID: 71 Partition Name: PIT
Filename: MSM8960.pit
Block Size: 16 (8.2kB)
Block range: 34 - 49 (hex 0x22 - 0x31)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PIT partition, identified as partition number 71, is 8.2kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as MSM8960.pit.
--- Entry #31 ---
ID: 72 Partition Name: MD5
Filename: md5.img
Block Size: 32 (16.4kB)
Block range: 50 - 81 (hex 0x32 - 0x51)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The MD5 partition, identified as partition number 72, is 16.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as md5.img.
--- Entry #32 ---
ID: 73 Partition Name: SGPT
Filename: sgpt.img
Block Size: 33 (16.9kB)
Block range: 30777311 - 30777343 (hex 0x1d59fdf - 0x1d59fff)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The SGPT partition, identified as partition number 73, is 16.9kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as sgpt.img.

bump

Surge1223 said:
@AdamOutler for the VZW Galaxy S4 I analyzed the PIT file produced by Heimdall and it reports the last four partitions as "remained" so I decided to manually extract my PIT file using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
which is specific to MSM8690 S4's and the PIT analysis now shows the "remained" partitions actual values and you can see the PIT I extracted is factory signed, because I compare the md5 to the PIT from a factory Odin tar here so is this problem unique to just the S4 or is it a Heimdall problem? I assumed Heimdall just extracted the padded PIT file but even so it should still show the information for the last 4 partitions.
Before
Code:
--- Entry #29 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #30 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #31 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #32 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
After
Code:
--- Entry #29 ---
ID: 70 Partition Name: PGPT
Filename: pgpt.img
Block Size: 34 (17.4kB)
Block range: 0 - 33 (hex 0x0 - 0x21)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PGPT partition, identified as partition number 70, is 17.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as pgpt.img.
--- Entry #30 ---
ID: 71 Partition Name: PIT
Filename: MSM8960.pit
Block Size: 16 (8.2kB)
Block range: 34 - 49 (hex 0x22 - 0x31)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PIT partition, identified as partition number 71, is 8.2kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as MSM8960.pit.
--- Entry #31 ---
ID: 72 Partition Name: MD5
Filename: md5.img
Block Size: 32 (16.4kB)
Block range: 50 - 81 (hex 0x32 - 0x51)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The MD5 partition, identified as partition number 72, is 16.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as md5.img.
--- Entry #32 ---
ID: 73 Partition Name: SGPT
Filename: sgpt.img
Block Size: 33 (16.9kB)
Block range: 30777311 - 30777343 (hex 0x1d59fdf - 0x1d59fff)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The SGPT partition, identified as partition number 73, is 16.9kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as sgpt.img.
Click to expand...
Click to collapse
@Benjamin Dobell may know something about this.

Can anyone share the file http://goo.im/devs/AdamOutler/libpitX/libpit-X-R917.jar? The link fails.

t2060079 said:
Can anyone share the file http://goo.im/devs/AdamOutler/libpitX/libpit-X-R917.jar? The link fails.
Click to expand...
Click to collapse
I'm looking for the same stuff. I think that the dev has relocated to here:
http://3of5.com/builds.casual-dev.com/files/libpit-X/
HTH, J

Full RAW flash dump

I have replaced new empty eMMC flash memory in change of previous dead one.
Reason: bootloop, google logo, no boot, no fastboot (no LED blinking), device detected only in Intel DNX fastboot (MOOREFIELD):
Code:
New USB device found, idVendor=8086, idProduct=0a2c, bcdDevice= 0.a0
New USB device strings: Mfr=2, Product=1, SerialNumber=3
Product: MOOREFIELD
Manufacturer: INTEL
Instead of android fastboot mode:
Code:
New USB device found, idVendor=18d1, idProduct=4ee0, bcdDevice=ff.ff
New USB device strings: Mfr=2, Product=3, SerialNumber=4
Product: fugu
Manufacturer: Android
xFSTK Downloader (used files from ZenFone) doesn't work. Player disconnecting during flashing.
Actually I need partitions dumps or full RAW dump.
Code:
Setting interface to EasyJtag2/E-Socket
Setting bus width to 8 Bit
Setting frequence to 42 MHz
EMMC Device Information :
EMMC CID: 110100303038474530006625C95B71F1
EMMC CSD: D05E00320F5903FFFFFFFFEF924000D3
EMMC Manufacture : TOSHIBA , EMMC NAME: 008GE0 , HEX: 303038474530 , S/N: 6625C95B , rev. 0x00
EMMC Manufacture ID: 0x11 , OEM ID: 0x00 , Device Type: BGA (Discrete embedded) , Date: 7/2014
EMMC ROM 1 (Main User Data) Capacity: 7456 MB (0001D2000000)
EMMC ROM 2/3 (Boot Partition 1/2) Capacity: 4096 KB (000000400000)
EMMC RPMB (Replay Protected Memory Block) Capacity: 4096 KB (000000400000) Counter: 716 , Response: Not Clean
EMMC Permanent Write Protection: No
EMMC Temporary Write Protection: No
Extended CSD Information :
Extended CSD rev: 1.7 (MMC 5.0, MMC 5.01)
Boot configuration [PARTITION_CONFIG]: 0x00 , Boot from: no boot
Boot Bus Config: 0x00 , width 1bit
H/W Reset Function [RST_N_FUNCTION]: 0x00, RST_n signal is temporarily disabled
Supported partition features [PARTITIONING_SUPPORT]: 0x07
Device supports partitioning features
Device can have enhanced technological features in partitions and user data area
Device can have extended partitions attribute
Partition Settings [PARTITION_SETTING_COMPLETED]: 0x00
Backup saved: 008GE0_6625C95B_20191117_171608.extcsd
EMMC Init completed.
Warning: Health report is very BAD
Device Life Time Estimation (MLC) [269]: 0x00 Not defined
Device Life Time Estimation (SLC) [268]: 0x0B Exceeded its maximum estimated device life time
Pre EOL information [267]: 0x01 Normal
Scanning soft partitions
GPT header is found and is valid
Partition: boot, [000000005000 - 000001005000], size: 000001000000 (16,0 MB)
Partition: recovery, [000001005000 - 000002005000], size: 000001000000 (16,0 MB)
Partition: fastboot, [000002005000 - 000003005000], size: 000001000000 (16,0 MB)
Partition: factory, [000003005000 - 000003605000], size: 000000600000 (6,00 MB)
Partition: splashscreen, [000003605000 - 000003A05000], size: 000000400000 (4,00 MB)
Partition: panic, [000003A05000 - 000003E05000], size: 000000400000 (4,00 MB)
Partition: misc, [000003E05000 - 000003F05000], size: 000000100000 (1,00 MB)
Partition: temp, [000003F05000 - 000004F05000], size: 000001000000 (16,0 MB)
Partition: cache, [000004F05000 - 000014F05000], size: 000010000000 (256 MB)
Partition: system, [000014F05000 - 000054F05000], size: 000040000000 (1,00 GB)
Partition: userdata, [000054F05000 - 0001D1FFBE00], size: 00017D0F6E00 (5,95 GB)
GPT header successfully parsed
Dump status:
ROM1 - failed !
ROM2/3 (bootloader = ifwi - 164 bytes ?) - ok
RPMB - ok
Partially I can get boot, recovery, fastboot (droidboot), splashscreen, system from official google firmwares.
But more important is factory partition.
Anyway it would be nice to have full RAW dump.
Thanks.