Database Users

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

[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

Copy binary by odin (Samsung SM-G531M android 5.1)

Greetings to all.
I have a Samsung SM-G531M Galaxy Grand Prime. Android 5.1
By mistake delete a system binary (linker) and now the phone does not start. And every time I try to start it in recovery (loop) mode but I have the FRP lock. Only the downlad mode works for me.
Can you copy the binary linker by odin? Ie edit the stock rom and put only the linker (delete all, just leave / system / bin / linker).
If so, I have tried modifying the stock rom, but I can not extract a file from boot.img (file_contexts from the boot.img \ ramdisk) that it is essential to package the new modified system(using program Auto Tool v3.0 x64).
-My system is windows 7.
-CarlivImageKitchen_x64
Your image: boot.img
Create the boot folder.
*Printing information for "boot.img"
*Unpack image utility by carliv @ xda
*Header:
**Magic: ANDROID!
**Magic offset: 0
**Page size: 50331648 (0x03000000)
**Base address: 0x10000000
**Kernel address: 0x10008000
**Kernel size: 6294484 (0x00600bd4)
**Kernel offset: 0x00008000
*>> kernel written to 'boot / boot.img-kernel' (6294484 bytes)
**Ramdisk address: 0x11000000
**Ramdisk size: 1532010 (0x0017606a)
**Ramdisk offset: 0x01000000
*>> ramdisk written to 'boot / boot.img-ramdisk.unknown' (1532010 bytes)
**Second address: 0x10f00000
**Tags address: 0x0001f800
**Tags offset: 0xf001f800
**Dt size: 268435712 (0x10000100)
*>> device_tree written to 'boot / boot.img-dt' (268435712 bytes)
Compression used: unknown
Unpacking the ramdisk ....
The system can not find the specified batch label: unknown
And the ramdisk folder appears empty.
Thanks in advance.

[HOW TO][DISCUSSION] UnBrick Samsung Galaxy Tab 2

There are more possibilities how to repair Hardbrick Samsung Galaxy Tab 2:
* For those who damaged boot loader can try Running stock U-Boot from SD Card
* For those who have HW fault like eMMC bug can participate on development Running entire system from SD Card
The second one may be solve later with help of some experienced people.
Run stock U-Boot from SD Card
Requirements
* Hardbrick Samsung Galaxy Tab 2 (GT-P5100). This can be recognized that it don't do nothing, charging not working, power button do nothing, recovery not working. More info How To Unbrick Your Galaxy Tab!
* SD Card Support UHS-I UHS104 (SDR104), with is not easy to determine with Card support this format and with not. I tried many cards and label UHS-I is not enough so i asked SanDisk support they recommended SanDisk Extreme. I bought SanDisk Extreme 32GB, and this card is working. I would say that every card 90MB/s+ should work.
step 0 not for Linux
Windows
* Install drivers for OMAP 4430 Guide / Drivers inside OMAPFlash download
* VirtualBox with Linux
* Set VirtualBox to capture OMAP 4430
* Download win iso burner
step 1
Windows & Linux
* Download [omapboot](https://github.com/LukasTomek/omapboot) to Linux
* Download [ Debrick dump imgs](https://forum.xda-developers.com/showpost.php?p=65114419&postcount=2)
step 2
Prepare SD card
Windows
Usewin iso burner to write Debrick dump imgs to Sd Card.
Linux
Write Debrick dump imgs to Sd Card.
Be careful to use right device sdX
Code:
dd if=debrick.img of=/dev/sdX
step 3
In Linux Run
Code:
[email protected]:/home/lukas/SamsungP5100/omapboot# python3 omapboot.py -b
you will see:
Code:
[email protected]:/home/lukas/SamsungP5100/omapboot# python3 omapboot.py -b
Boot from MMC1 interface selected.
Waiting for omap44 device.
* Connect Tablet to PC
* Press Power button for long time approximately 10s
* You should see this in command line:
Code:
Boot from MMC1 interface selected.
Waiting for omap44 device.
Model: 4430
ROM revision: 0x04
CH: enabled
Underdocumented ASIC subblock #18: 00
IDEN: 0xE5FD23CE0F5FDF902D7EDA9B4D848D687F62372A
MPKH: 0xB585ACF1DD15B06A74813BFDDD6ECD64227CE4C90658C65B4C53AC229B4C6DC0
CRC0: 0x9C669AD9
CRC0: 0x682ADCCF
recevied ASIC ID banner:
Model: 4430
ROM revision: 0x04
CH: enabled
Underdocumented ASIC subblock #18: 00
IDEN: 0xE5FD23CE0F5FDF902D7EDA9B4D848D687F62372A
MPKH: 0xB585ACF1DD15B06A74813BFDDD6ECD64227CE4C90658C65B4C53AC229B4C6DC0
CRC0: 0x9C669AD9
CRC0: 0x682ADCCF
Giving x-loader a chance to come up...Probably loaded!
* Tablet should start to some firmware recovery mode see picture
{
"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"
}
* You should be able to use ODIN to repair internal memory, in my case ODIN stop in the half of loading, I probably have eMMC bug.
Running entire system from SD Card
I'm trying to modify U-Boot and Kernel to load entire system from SD Card. Some have done it Say hi to "CyanoBoot" -- a 2nd bootloader/w menu aka "ub2" different device same CPU.
First step of boot is loading x-loader. The x-loader is signed so we have to use original one from Samsung. After some peripheral initialization x-loader copy u-boot to ram checking for magic constant as copied code and execute it. This is the place where we can change u-boot to boot from SD Card, because x-loader load u-boot from the same device as was loaded him.
u-boot source
Do anyone have u-boot source from Samsung?
I used this Guide and copy something from Nook device u-boot source because they made boot from SD Card on same CPU OMAP4430. And lge_p920 from LG Open-source repository. Do anyone have better idea?
How to compile
[u-boot source](https://gogs.lukastomek.info/lukas/u-boot)
[Building U-BOOT #(for Blaze)](http://omappedia.org/wiki/4AJ.2.5_OMAP4_Jelly_Bean_Release_Notes)
Kernel
I'm using Stock boot.img from O2C-P5100XXDMJ2-20131203002840.zip package. Do anyone have kernel booting from SD Card?
Prepare Debrick.img
Rewrite part of Image Files
Write recovery.img to specific address in debrick_changed.img address 0x2C00000 write in hex or dec depend on system (seek=$((0x1800000)) for linux) (seek=46137344 for Windows).
You need to rewrite:
x-loader (MLO) 0x20000
u-boot (Sbl.bin) 0x1800000
boot.img 0x2400000
recovery.img 0x2C00000
Code:
dd if=C:\temp\Tablet\sdCardDebrick\recovery.img of=C:\temp\Tablet\sdCardDebrick\debrick_changed.img seek=$((0x1800000)) oflag=seek_bytes conv=notrunc
UART Debugging
Pin 21 of [Samsung Galaxy Tab 30 Pin Dock Connector Pinout](https://forum.xda-developers.com/showthread.php?t=1118986) is output of debug messages for x-loader and u-boot (port UART4). I would like send Kernel debug output to this port. Anyone know how to do it?[/HTML]I’m using UB232R for conecting to PC.
Output from debugging:
Code:
ŕ<0>
Texas Instruments X-Loader 1.41 (Apr 10 2013 - 20:55:49)
Starting OS Bootloader from MMC/SD1 ...
U-Boot 1.1.4-g01076139-dirty (Jan 8 2019 - 14:49:13)
U-Boot code: 80E80000 -> 80EAA870 BSS: -> 80F2F964
Load address: 0x80e80000
DRAM: 2048 MB
Flash: 0 kB
Using default environment
In: serial
Out: serial
Err: serial
Initializing SD(0) Slot.
ptbl slot: SD:(0).
8192 20M EFS
49152 2M SBL1
53248 2M SBL2
57344 8M PARAM
73728 8M KERNEL
90112 8M RECOVERY
106496 700M CACHE
1540096 20M MODEM
1581056 1400M FACTORYFS
4448256 12343M DATAFS
29728734 512M HIDDEN
efi partition table:
bootcmd booti mmc0ptbl slot: SD:(0).
8192 20M EFS
49152 2M SBL1
53248 2M SBL2
57344 8M PARAM
73728 8M KERNEL
90112 8M RECOVERY
106496 700M CACHE
1540096 20M MODEM
1581056 1400M FACTORYFS
4448256 12343M DATAFS
29728734 512M HIDDEN
Net: KS8851SNL
arch_number = 0x00000870
board rev = 0x00000000
env_t = 0x00000000
boot_params = 0x80000100
DRAM bank = 0x00000000
-> start = 0x80000000
-> size = 0x80000000
ethaddr = 00:00:00:00:00:00
ip_addr = 128.247.77.90
baudrate = 115200 bps
81200000: 52444e41 2144494f 0046add8 80008000 ANDROID!..F.....
81200010: 000b63a5 81000000 00000000 80f00000 .c..............
81200020: 80000100 00000800 00000000 00000000 ................
81200030: 00000000 00000000 00000000 00000000 ................
81200040: 736e6f63 3d656c6f 4f797474 31312c32 console=ttyO2,11
81200050: 30303235 6d20386e 313d6d65 4d343230 5200n8 mem=1024M
81200060: 646e6120 64696f72 746f6f62 6e6f632e androidboot.con
81200070: 656c6f73 7974743d 7620324f 3d6d6172 sole=ttyO2 vram=
kernel @ 80008000 (4632024)
ramdisk @ 81000000 (746405)
timed out in wait_for_bb: I2C_STAT=1000
I2C read: I/O error
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
ŕ<0>
This look like kernel is executed but no more info. I tried set ttyO0 - ttyO4 ttyS0 - 4 but no difference to get output from kernel. Do anyone have some idea how to get kernel output or what is wrong?

I realize I'm four years later with this, but I hope you see my message, because I'm also trying to get u-boot working on the Samsung Galaxy Tab 2 and I saw the repository with your work so far, but for some reason it isn't up anymore, so could you re-upload it maybe if it isn't too much effort?

If anyone is still interested; I managed to patch the stock bootloader from Samsung (Sbl.bin), so that more verbose logging from UART4 is working and booting entirely from the SD card is also working: https://github.com/mspitteler/espresso-sbl

[GUIDE] Universal guide for making your partitions inside super read-writable again.

Disclaimer: I'm not responsible for any result of these operations. Please be careful and well prepared. Always have your important data backed up safely on other place.
Hello everyone!
As far as 2022 and Xiaomi gets their new phones updated to MIUI13 and Android 12, they implement the new read-only filesystem "EROFS" on the logical partitions inside super partition. EROFS is a filesystem initial developed by Huawei and then Google select it as a new standard to use in read only logical partition inside super partition from Android 12. The "EROFS", is the short for "Extendable (or Enhanced?) Read-Only Filesystem", conveying that this filesystem is a one-time cooked filesystem and cannot be changed without extracting and re-cooking. With erofs we cannot modify the logical partition anymore so I found a new way to unlock these partitions.
I just faced and managed to solve the "lock" and I would like to share the solution, which may help more people.
My device: Xiaomi 12 (cupid).
System: Stock MIUI13 (Android 12).
Logical partitions with read-only lock inside super partition: system, vendor, product, system_ext, odm, vendor_dlkm. All of them are erofs filesystem.
Be aware that this device is virtual a/b and the _b partitions inside super are 0k blank files. No need to do anything with them.
In theory, all devices shipping with erofs partitions inside super are compatible with this method. Feedbacks are always welcome!
Before we start: This guide is for Android power users that wish to make their Android 12+ read-only system/vendor.... partitions with EROFS filesystem inside super read-writeable again to remove the bloatware and do more customizations to their device.
Credits:
@Yuki1001 - EROFS Guide, research, new rw discoveries.
@lebigmac - a couple of rw slogans, some binaries, inspiration.
Requirements:
1. Your phone must be unlocked as you must flash your new super.img through fastboot command. Root is required to run any command in a terminal (win cmd or linux terminal).
2. 20GB+ free space on your phone and PC.
3. The toolkit needed.
4. A clever brain and courage.
So in short, the tutorial contains these part:
(1) Dump and extract your super image.
(2) Pull the folder with partition images extracted from super image to the PC.
(3) Convert these erofs images to ext4 images (Extract and Rebuild). These new images are in the same folder.
(4) Push the folder to the phone and fix any errors of new generated ext4 images.
(5) Merge them into a new single sparse super image and pull it to the PC.
(6) Flash the new image through fastboot command.
(7) Check the rw capability of the logical partitions and do anything you want!
Let's start now!
1. Get your super image by dumping your current super partition. We can find our super partition in this way:
Code:
su
cd /dev/block/bootdevice/by-name
ls -al | grep "super"
You will get the output like this:
{
"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"
}
Then we knows the super partition block number and path immediately. Let's dump its data to a file.
Code:
dd if=%PATH_TO_SUPER_BLOCK% of=/data/local/tmp/super_orig.img bs=4096
Wait for the data transfer done and we can get the super image. DO NOT forget to replace "%PATH_TO_SUPER_BLOCK%" with your own super block path!
2. Now we can do things with the super_orig.img: Extract logical partitions inside super partition to a folder. I will use Google's official tool: lpunpack. For example, I extract these partitions inside super to "sup_unpack" folder. Give all binaries in tools folder with executive permission in advance.
Code:
./tools/lpunpack ./super_orig.img sup_unpack
Now check with the folder to confirm whether these partitions insider super are extracted. If so, we can transmit the folder to the PC with adb pull. Extract my unlock-super folder in advance and we need to place the pulled out folder in it.
Code:
adb pull /data/local/tmp/sup_unpack
Now the "sup_unpack" folder exists in the platform-tools folder. Move it to the "unlock-super" folder.
3. Extract these erofs images one by one with erofsUnpackRust.exe and repack them into ext4 image. Check the folders' size to determine how big space does the new ext4 filesystem need. I'd like to recommend you to preset some free space for every new ext4 images for further modifications.
You are required to remove all _a suffix for the images in order to make the following program works properly. For example: system_a.img --> system.img. You have been warned!
For example:
Code:
erofsUnpackRust sup_unpack/system.img system
erofsUnpackRust sup_unpack/vendor.img vendor
erofsUnpackRust sup_unpack/product.img product
.... (and so on)
You will get the output like these screenshots:
For building a new image, we need to set a timestamp for all files included. I use 1230764400 as it equals the original file timestamp in erofs image. DO NOT forget to replace %FS_SIZE% with your real fs size you want. So go with the following command:
Code:
***DO NOT COPY!***
Example:
System:
make_ext4fs -J -T 1230764400 -S system/config/system_file_contexts -l %FS_SIZE% -C system/config/system_fs_config -L system -a system system_a.img system/system
Vendor:
make_ext4fs -J -T 1230764400 -S vendor/config/vendor_file_contexts -l %FS_SIZE% -C vendor/config/vendor_fs_config -L vendor -a vendor vendor_a.img vendor/vendor
For odm, product, system_ext, vendor_dlkm...... and other partitions, use the same step.
You should get the output like these screenshots:
When you completed the steps above you should have the images in ext4 format. Then make a folder named "new_ext4" and move the new image files (_a suffix) to the new_ext4 folder. Make sure all partitions' images are correctly rebuilt.
Copy the _b blank files toghether with new built _a images:
4. Push the folder that contains your image to /data/local/tmp again. In my case use this command:
Code:
adb push new_ext4 /data/local/tmp/new_ext4
Then check whether the new folder exists in the correct place. DO NOT forget to use e2fsck -yf to fix any errors of the new images before joining them into a super image.
5. Now we have all partitions unlocked and corrected but we need to join them into a single "super_new.img" for flashing. Use the lpmake tool to create the new "super_new.img". Again, DO NOT forget to replace %SUPER_SIZE% with your super partition's physical size (the size of super_orig.img) , and replace mulitiple %SIZE% with the real size of your new built ext4 images (with _a suffix) .
Code:
***DO NOT COPY!***
cd /data/local/tmp/new_ext4
../tools/lpmake --output super_new.img --sparse --metadata-size 65536 --super-name super --metadata-slots 2 --device super:%SUPER_SIZE% --group slot_a:%SUPER_SIZE% --group slot_b:0 --partition system_a:none:%SIZE%:slot_a --image system_a=./system_a.img --partition vendor_a:none:%SIZE%:slot_a --image vendor_a=./vendor_a.img --partition product_a:none:%SIZE%:slot_a --image product_a=./product_a.img --partition system_ext_a:none:%SIZE%:slot_a --image system_ext_a=./system_ext_a.img --partition odm_a:none:%SIZE%:slot_a --image odm_a=./odm_a.img --partition vendor_dlkm_a:none:%SIZE%:slot_a --image vendor_dlkm_a=./vendor_dlkm_a.img --partition odm_b:none:0:slot_b --image odm_b=./odm_b.img --partition system_b:none:0:slot_b --image system_b=./system_b.img --partition vendor_b:none:0:slot_b --image vendor_b=./vendor_b.img --partition product_b:none:0:slot_b --image product_b=./product_b.img --partition system_ext_b:none:0:slot_b --image system_ext_b=./system_ext_b.img --partition vendor_dlkm_b:none:0:slot_b --image vendor_dlkm_b=./vendor_dlkm_b.img
In the command we use --sparse parameter to let the new joined super image sparse, for the following fastboot flash.
6. Pull the new super_new.img to the computer. Do the fastboot flash. Erase the super partition and flash the new image.
Code:
adb pull /data/local/tmp/new_ext4/super_new.img
fastboot erase super
fastboot flash super super_new.img
Now the partitions inside super should already have full r/w capability. Reboot the phone to check whether they can be mounted as r/w.
Voila!
All tools are provided as attachments.
Password: super-rw
If you think it's useful, please click the "Like" button. Thanks!

Reserved floor #2.

Reserved floor #3.

\unlock-super>erofsUnpackRust Download/product.img product
erofsUnpack 1.3.211216
<E> erofs: cannot find valid erofs superblock
thread '<unnamed>' panicked at 'read erofs super block failed', src\lib.rs:168:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

getting this error in vendor extracting
C:\unlock-super>erofsUnpackRust Download/product.img product
erofsUnpack 1.3.211216
<E> erofs: cannot find valid erofs superblock
thread '<unnamed>' panicked at 'read erofs super block failed', src\lib.rs:168:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

now this is
unlock-super>make_ext4fs -J -T 1230764400 -S system/config/system_file_contexts -l 626733056 -C system/config/system_fs_config -L system -a system system_a.img system/system
loaded 3141 fs_config entries
Creating filesystem with parameters:
Size: 626733056
Block size: 4096
Blocks per group: 32768
Inodes per group: 7664
Inode size: 256
Journal blocks: 0
Label: system
Blocks: 153011
Block groups: 5
Reserved block group size: 39
error: ext4_allocate_best_fit_partial: failed to allocate 4720 blocks, out of space?
Failed to create image system_a.img, removing it

Mr Hassan said:
now this is
unlock-super>make_ext4fs -J -T 1230764400 -S system/config/system_file_contexts -l 626733056 -C system/config/system_fs_config -L system -a system system_a.img system/system
loaded 3141 fs_config entries
Creating filesystem with parameters:
Size: 626733056
Block size: 4096
Blocks per group: 32768
Inodes per group: 7664
Inode size: 256
Journal blocks: 0
Label: system
Blocks: 153011
Block groups: 5
Reserved block group size: 39
error: ext4_allocate_best_fit_partial: failed to allocate 4720 blocks, out of space?
Failed to create image system_a.img, removing it
Click to expand...
Click to collapse
The size setting of your new ext4 img is too small. Consider a larger value.
EDIT: Normally, your files maybe 2GB+ larger than the erofs img. Check your files' real size and give a good value to -l parameter.

Yuki1001 said:
The size setting of your new ext4 img is too small. Consider a larger value.
EDIT: Normally, your files maybe 2GB+ larger than the erofs img. Check your files' real size and give a good value to -l parameter.
Click to expand...
Click to collapse
My ext have around 900mb
And vendor something like 1400mb
And both are getting same error
I thought maybe big size i just try remove some file but still same
If its small size issue then how can increase or large it?
Or should i merge both partitions on same but i don't think it'll be possible

Mr Hassan said:
My ext have around 900mb
And vendor something like 1400mb
And both are getting same error
I thought maybe big size i just try remove some file but still same
If its small size issue then how can increase or large it?
Or should i merge both partitions on same but i don't think it'll be possible
Click to expand...
Click to collapse
Would you like to take some screenshots of your extracted folder's size and the original image's size?
PS: After calculating all your files' total size, I recommend you to reserve at least 500MB+ free space inside your new ext4 image.

Mr Hassan said:
My ext have around 900mb
And vendor something like 1400mb
And both are getting same error
I thought maybe big size i just try remove some file but still same
If its small size issue then how can increase or large it?
Or should i merge both partitions on same but i don't think it'll be possible
Click to expand...
Click to collapse
You on oos 11 ?oos 11 have no erofs
Oos 12 have erofs

ChrisFeiveel84 said:
You on oos 11 ?oos 11 have no erofs
Oos 12 have erofs
Click to expand...
Click to collapse
Ofcourse I'm in os12

Yuki1001 said:
Would you like to take some screenshots of your extracted folder's size and the original image's size?
PS: After calculating all your files' total size, I recommend you to reserve at least 500MB+ free space inside your new ext4 image.
Click to expand...
Click to collapse
Sure tomorrow I'll send you the screen shot of unpack and img both images

Yuki1001 said:
Before we start: This guide is for Android power users that wish to make their Android 12+ read-only system/vendor.... partitions with EROFS filesystem inside super read-writeable again to remove the bloatware and do more customizations to their device.
Click to expand...
Click to collapse
Yuki1001 said:
Now the partitions inside super should already have full r/w capability. Reboot the phone to check whether they can be mounted as r/w.
Click to expand...
Click to collapse
Hi @Yuki1001
Please keep up the great work! The more people have RW access to their own devices the better for the open source community!
If you want to integrate your erofs fix into my script please contact me! Of course you will be properly credited!

Well its not looks like yours kind of
But you know better
But its good thing if he helping people's with a different way
I personally like this thread becoz i just want to make one vendor rw
And then I'm able to boot after flash
edited remove quote on @
Yuki1001 request​

and today its not even unpack dont know where doing mistake
unlock-super>erofsUnpackRust Download/vendor.img vendor
erofsUnpack 1.3.211216
<E> erofs: cannot find valid erofs superblock
thread '<unnamed>' panicked at 'read erofs super block failed', src\lib.rs:168:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Reserved floor#16.

Mr Hassan said:
and today its not even unpack dont know where doing mistake
unlock-super>erofsUnpackRust Download/vendor.img vendor
erofsUnpack 1.3.211216
<E> erofs: cannot find valid erofs superblock
thread '<unnamed>' panicked at 'read erofs super block failed', src\lib.rs:168:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Click to expand...
Click to collapse
I had problems extracting my vendor.img using others' erofs unpack tools. Only the erofsunpackrust.exe works. Maybe your vendor.img is special? (which means you need to try other erofs unpack tools for luck)

Yuki1001 said:
I had problems extracting my vendor.img using others' erofs unpack tools. Only the erofsunpackrust.exe works. Maybe your vendor.img is special? (which means you need to try other erofs unpack tools for luck)
Click to expand...
Click to collapse
but same thing i used before and works for me and you see upper results
anyway now is there any other erofs avaliable to test?

Yuki1001 said:
Would you like to take some screenshots of your extracted folder's size and the original image's size?
PS: After calculating all your files' total size, I recommend you to reserve at least 500MB+ free space inside your new ext4 image.
Click to expand...
Click to collapse
here,s the size of vendor unpack and repack

Mr Hassan said:
View attachment 5716687View attachment 5716689
here,s the size of vendor unpack and repack
Click to expand...
Click to collapse
So you could to set the ext4 vendor image to 2G. 2G = 2147483678 bytes. Try to set the -l parameter to 2147483648.