Database Develop

Kyocera Zio M6000 - boot.img has 4K header... odd?

I dumped the boot.img using:
Code:
cat /dev/mtd/mtd1 > /sdcard/cat-boot.img
and
Code:
dump_image boot /sdcard/dump-boot.img
Using dump_image it says:
Code:
mtd: read all-zero block at 0x00240000; skipping
mtd: read all-zero block at 0x002a0000; skipping
mtd: read all-zero block at 0x002c0000; skipping
And the sizes differ:
cat-boot.img: 4096K
dump-boot.img: 3712K
Then I ran unpackbootimg to unpack them. Neither worked, invalid gz files. So I took a look at the image files and instead of 2K header, it had a 4K header that had an extra 2K of 0's. Any idea why that might be?
I deleted the extra 2K of 0's and ran unpackbootimg again, both boot images provided identical gz's that worked.
I am able to test the gz's and extract the cpio, but how can I check if the kernel is good?
Since it seems to be malformed, it might have different spacing or something?
If I try to boot off of it using fastboot it just gives an error:
Code:
C:\android-sdk\tools>fastboot boot pulled\extracted\dump-boot.img-zImage
creating boot image...
creating boot image - 2263040 bytes
downloading 'boot.img'... OKAY [ 2.687s]
booting... FAILED (remote: invalid boot image)
finished. total time: 2.687s
Could someone with some experience take a look and help? I'm doing my best
The attached file has the extra 2K of 0's in the header I mentioned already removed.
Edit: I did the dump while the phone was booted up normally. It doesn't have any recovery mode where I could otherwise do it. If I use "adb reboot recovery" it just formats the phone and reboots.
Edit 2:
After doing a bunch of searching I tried this:
Code:
fastboot -b 400000 -n 4096 boot pulled\extracted\dump-boot.img-zImage pulled\extracted\dump-b
oot.img-ramdisk.gz
And it worked!!
Now I can try to port Clockwork Recovery
Edit 3: removed attachment, extracted version is attached to next post.

I attached the extracted kernel and ram disk here so anyone can use them without having to bother taking them apart themselves.
To fix a broken boot image, get the Andriod SDK installed, plug in the phone, reboot holding both green and red buttons to get to fastboot screen. Then use fastboot.exe to load image. Try to boot off it before flashing it. In order to flash it the "flash:raw boot" fastboot option will need to be used. I haven't tried this, but I've booted off of my extracted version and that worked.
The base address is "400000" and the page size is "4096" those need to be specified in the fastboot options.
Also just for reference, the extracted file "boot.img-cmdline" had this in it:
mem=215M console=ttyMSM2,115200n8 androidboot.hardware=qcom
Click to expand...
Click to collapse
Not sure where or when that's needed yet, not for flashing, but maybe for compiling.

Sanyo zio m6000
I have locked myself out of my phone. I was wondering if you could upload/send me the boot image you used. I have tried all the ones you have for download, but none work.

Any updates on this? I think this is suspect as to why nandroid restore borks the kyocera boot splash screen.
Sent from my Zio using XDA App

I know this is off topic so excuse me but myprepaiddroid.com has some rom's that have been converted to the zio on cricket but they have not been tested yet.

So is the kernel in the boot image?
http://db.tt/zisPRYH boot.img after 2.2.1 update.
Sent from my Zio using XDA Premium App

That extra 2k of 0s in the header is the kyocera logo (or the instruction that points to the actual image).
Would you mind unpacking the 2.2 boot.img zImage and Ramdisk and posting them phazei?

Is phazei around anymore?
Sent from my Zio using XDA Premium App

Mattix724 said:
Is phazei around anymore?
Click to expand...
Click to collapse
Haha, yeah, I'm here. Just been busy, life's been getting me down. Foreclosure, and other misc stuff.
I browse the forum a couple times a week or so.

Sweet. Do you know if there was any change to the boot.img after 2.2?
Sent from my Zio using XDA Premium App

[INFO] The Atrix sbf thread

Single Binary Format
Hi,
I thought I would start this thread so that all info about sbf utilities and formats specific to the Motorola Atrix could be in one place. (Kenneth Penn's idea) I don't know everything, not a lot, barely anything really, but I will share what I do. Feel free to chime in and correct anything I say.
First off, the software I have found:
Welcome to 2008, Portable SBF Tool / desbf
Motorola android SBF [de]Packer
SBF recalc (waiting for 1.3 edition)
Of these utilities, the one that has done anything worthwhile for me is Desbf. SBF recalc keeps saying wait for version 1.3, and while sbf depacker has been updated for the Atrix, I haven't managed to sucessfully flash anything with it, it has the most promise though and hope for the future.
First, trying these utils is like walking into a shop in chinatown looking to buy a cheeseburger. Where am I? What do I do? How do you say "do something!"?
Desbf, I don't know the history behind this or what it has been used for in the past, it was on a list of google hits for the obscure motorola sbf format. You run it, select a sbf file, and it automatically creates a folder with all the files contained in the sbf extracted. You can delete files and then save an sbf that can be flashed. It has a parse CG button, don't know what it's for. It has been used to flash the Telstra radio onto Att and Bell. I have yet to use it to flash something using RDL3, just the radio using RDL1.
SBF Recalc, shows a lot of information, to use you split the file to a folder to start, do your thing with the files in that folder, and then open the folder to recalc checksum and save an sbf. Only problem is that is doesn't work (yet).
Motorola Android [De]packer is obviously the most in depth util, it shows even more information than SBF recalc. It does do things, not sure what, or if it's my lack of understanding of the format, but I haven't sucessfully done anything with it, it creates files, displays information, but complains about RDL files not being needed for the content, even if you delete all the RDL files.
Speaking of files, here is what I understand about them:
The utilities spit out SMG files, it's a motorola format, not sure of the acronym.
RDL1:
RDL3:
Ram downloader 1 is used for the radio, it is flashed after everything else, changing mode to do so, everything else is flashed using Ram downloader 3. I don't know what happened to RDL2.
CG2 22KB
CG3 512KB, CDT.bin
CG5 is the radio, plus other things apparently. In [De]Packer it's a virtual collection of mbn files, partition.mbn, amas_sec.mbn (the radio), osb1_sec.mbn, cefs.mbn, db1_sec.mbn. I have no idea what they are about. I know they are from CG5 because an sbf with just RDL1, RDL3, and CG5 spits out RDL1, RDL3, and the above without a CG5.
CG42 3072KB mostly zeros, ends at 0xff0
CG44 3072KB Bootloader
CG47 262144 Microboot (Engine and Slot for hashing in microboot priv.c) (ref to rdl1.bin, ptable, CDT.BIN, BCT.bin, PT.bin, EBT.bin, MBR.bin, EBB.bin)
CG50 is 2KB of 0xFF, no content, probably used to clear a partition
CG52 same as above, (sent to mmcblk0p7 to clear misc? -optionally used to pass commands to recovery, it fed with command line for example to flash an update -)
CG53 1014KB begins with SOL: logo.bin (mmcblk0p8)
CG54 2KB of 0xFF (possibly sent to mmcblk0p9, Kernel Panic Data)
CG55 recovery (header, ramdisk, kernel) (mmcblk0p10)
CG56 boot (header, ramdisk (/), kernel) (mmcblk0p11)
CG57 is the system image in ext3 linux format. (mmcblk0p12)
CG58 osh (webtop) system image in ext3 (mmcblk0p13)
CG59 20MB HFS, CDROM (Motorola Helper) (mmcblk0p14)
CG60 2KB of 0xFF (possibly sent to mmcblk0p15 to clear cache image)
CG61 2KB of 0xFF (sent to mmcblk0p16 to clear userdata image, tested)
CG62 preinstall image in ext3 (mmcblk0p17)
This is a work in progress.
New for Gingerbread 2.3.4:
CG39 looks like fs, pds update?
CG42 bootloader
CG47 same as before, just full partition size
CG56 boot logo
CG58 Recovery emmc image (kernel, ramdisk.gz)
CG59 Boot emmc image
CG60 system image APP
CG61 webtop image OSH
CG62 cdrom image motohelper
CG65 preinstall image
Code:
cat /proc/partitions
major minor #blocks name
7 0 7308 loop0
7 1 4190 loop1
179 0 15668736 mmcblk0
179 1 3584 mmcblk0p1
179 2 512 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 1 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 1024 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 327680 mmcblk0p12
179 13 786432 mmcblk0p13
179 14 20480 mmcblk0p14
179 15 655360 mmcblk0p15
179 16 2097152 mmcblk0p16
179 17 353280 mmcblk0p17
179 18 11233792 mmcblk0p18
179 32 1931264 mmcblk1 (external sd card, 2 GB)
179 33 1930680 mmcblk1p1 (external sd card, 2 GB)
254 0 7308 dm-0
254 1 4189 dm-1
LINKS: (to be integrated)
http://forum.xda-developers.com/show...&postcount=502
http://and-developers.com/partitions:cdt
https://www.droid-developers.org/wiki/BootRecoverySignature
Cheers!

Heres a detailed list of the partitions:
http://forum.xda-developers.com/showpost.php?p=12687720&postcount=502

This is awesome. Thanks for the details.

Thanks,
I am thinking it might be possible to create an sbf from a dump of the partitions on a active phone. It would certainly be nice to have one for Bell. My idea is to replace all the active bits in an sbf file with versions from a dd dump of each partition. [De]Packer could possibly be used to compile a CG5 from all the bits, take that file and use Desbf to create the rest of it.
So if someone with a stock Bell Atrix could run this and post a link back with the resulting 7zip file it would help. Mediafire or some other file hosting service.
backup creator script
What it does is dump all the "other" partitions, not system or data, or webtop, but all the little ones up to 11 and 14
Cheers!

NFHimself said:
Thanks,
I am thinking it might be possible to create an sbf from a dump of the partitions on a active phone. It would certainly be nice to have one for Bell. My idea is to replace all the active bits in an sbf file with versions from a dd dump of each partition. [De]Packer could possibly be used to compile a CG5 from all the bits, take that file and use Desbf to create the rest of it.
So if someone with a stock Bell Atrix could run this and post a link back with the resulting 7zip file it would help. Mediafire or some other file hosting service.
backup creator script
What it does is dump all the "other" partitions, not system or data, or webtop, but all the little ones up to 11 and 14 15 16.
Cheers!
Click to expand...
Click to collapse
That would be a massive development for Bell users.

I have confirmed that removing CG61 causes a flash to not erase your userdata partition.
Cheers!

Great news! Keep us updated.

NFHimself said:
I have confirmed that removing CG61 causes a flash to not erase your userdata partition.
Cheers!
Click to expand...
Click to collapse
hey, how hard do you think it would be to modify the 1.2.6 SBF to also not wipe the user partition? Would it act like the 1.8.3 SBF which preserves all user settings and apps? Conversely, could we modify the 1.8.3 SBF to act like the 1.2.6 SBF by clearing all the settings out and returning completely back to stock? Sorry for all of the questions, but I just found the 1.8.3 SBF very cool, that it let me keep all my settings and apps, and thus cut down on the time I needed to spend on restoring things after the flash.

UncleCemka said:
hey, how hard do you think it would be to modify the 1.2.6 SBF to also not wipe the user partition?
Click to expand...
Click to collapse
Probably as easy as pulling CG61 out, if I recall correctly (pretty easy...)
EDIT: haha I see NFHimself confirmed this... that's the one .8.3 is missing (besides CG51 --ideas?)

That's all I did, selected CG61, hit delete, save in desbf, and run rsdlite.
Only thing about it is that Gingerbreak will still wipe your internal memory so you still have to backup that.

The error in [de]packer, where it says source not found, seems to be limited to cg3.smb, remove that and it compiles the folder.
Cheers!

Update on creating a Bell sbf:
Of the partitions 1-11, and 14, the ones with unique content are 3, 5, 9, 10, 11. Of these, 10 and 11 are straight dumps in the sbf file, the recovery and boot partitions, the partitions 3, 5, and 9 have no direct correlation to a CG that I can see so far.
However, I have managed to go from a Telstra firmware to a stock Bell firmware, just not using a sbf. I simply did a dd of all Bell partitions from sdcard to the phone, leaving mmcblk0p12 for last since it's the system partition. Well most of the partitions, I didn't dd internal memory or data, I just did a data wipe. So, you can go back to stock, you just can't recover from a bricked situation, using this method.
Cheers!

NFHimself said:
Update on creating a Bell sbf:
Of the partitions 1-11, and 14, the ones with unique content are 3, 5, 9, 10, 11. Of these, 10 and 11 are straight dumps in the sbf file, the recovery and boot partitions, the partitions 3, 5, and 9 have no direct correlation to a CG that I can see so far.
However, I have managed to go from a Telstra firmware to a stock Bell firmware, just not using a sbf. I simply did a dd of all Bell partitions from sdcard to the phone, leaving mmcblk0p12 for last since it's the system partition. Well most of the partitions, I didn't dd internal memory or data, I just did a data wipe. So, you can go back to stock, you just can't recover from a bricked situation, using this method.
Cheers!
Click to expand...
Click to collapse
that's great news and I hope that if an update comes out and Bell users aren't necessarily able to update that you might refine this method into an automated process or at least detail it for the rest of the community's benefit.

Wow. Great work NFHimself! That's the only reason I haven't taken Telstra for a spin. There's no going back......yet.
Sent from my rooted and frozen Motorola Olympus.

Well it was literally "dd if=sdcard/mmcblk0p1 of=/dev/block/mmcblk0p1" skipping 12 and continuing on, then doing 12. I did run setprop tcmd.suspend 2 first, and I was rooted, have to pull the battery to reboot since I overwrote the system partition and had no commands in my path, but that's it.
Just would need some online hosting space and do up a simple script, really.
Cheers!

NFHimself said:
Well it was literally "dd if=sdcard/mmcblk0p1 of=/dev/block/mmcblk0p1" skipping 12 and continuing on, then doing 12. I did run setprop tcmd.suspend 2 first, and I was rooted, have to pull the battery to reboot since I overwrote the system partition and had no commands in my path, but that's it.
Just would need some online hosting space and do up a simple script, really.
Cheers!
Click to expand...
Click to collapse
That is really ballsy. I will not write to my mmcblk0p1 because if there is the slightest error I believe I'd have a have a hard brick. All the options seen when holding power + volume-down (or up) can be found in that block device.
But this is not the case for Bell/Telstra?! Fascinating that your devices are different! Where *DOES* your bootloader live?
Actually, I now see that most the Telstra CG img files are signed by two keys, but almost all of the AT&T ones are signed by 3, and the keys differ between the two .sbfs (but are consistent within each.) How very strange. Our CG44s are very similar, but also different (for example do a diff on their strings):
Only in Telstra (1.4.2):
Code:
< UpdateBootBct
< BL size:%d
< MB size:%d
< NvMotBlReSign
< NvMotBctReSign End

I went through each one with hexedit, and nothing really struck me as being the bootloader, in fact, on my archos tablet, the bootloader was not stored in the mtd list at all, it was somewhere else, probably in the SOC somewhere.
Our partition 1 is all 0xFF, no danger there, either it's protected and can't be read or written to, or it really is 0xFF.
Cheers!

Oh, a dump of all the important Bell mtd partitions is available.
Bell_Full_Partition_Backup.tar.gz
Cheers!

Thanks! Yes, I suspect now that the OTA writes the mmcblk0p1 and that this is the location the new bootloader is updated from (on next boot?) and that RSD can simply skip this step and update directly. Just got an mmcblk0p1 from someone who never had an OTA (on ATT) and it is like yours "FF 00 00 00 FF: and then 3.5mb of FFs =) So, you were probably safe to overwrite it!
Will be interesting to confirm once you have your first OTA =) As for "SE" (Secured Engineering?) I don't know the difference to NS yet. Perhaps its related to the bootloader and certificate differences too.

Does anyone have much experience tinkering around with the PDS.bin file? There's reason to suspect that corruption in the mmcblk0p3 block occurs when the Internal SD is formatted and partitioned erroneously via custom recovery. this could be what causes the bottom of the touchscreen to become unresponsive for the bottom half inch of the screen (causes "ghosting" or misaligned touch response above the impacted area)
Tenfar advised me to properly format and partition mmcblk0p18 with the following command (#newfs_msdos -F 32 -S 512 -L MB860 -c 64 -u 16 /dev/block/mmcblk0p18) which did everything okay, but didn't make an impact unfortunately. Still tinkering around with this buggered AT&T Atrix for the last few weeks. Determined to fix this bish instead of sending it in lol

[TOOL][DEV] AP.bin extractor (win32/linux)

Hello everyone,
This is a AP.bin extractor
rewritten in plain C based on xonar_'s work and support both linux and win32
navossoc@xda introduced the "LGExtract.exe". the encrypyted/compressed kdz can be extracted/decrypted to AP.bin/CP.fls by LGExtract.exe
xonar_ made BIN/FLS extractor
http://forum.xda-developers.com/showthread.php?t=1879915
and release source(win32)
•http://forum.xda-developers.com/showpost.php?p=31432471&postcount=11 (original Java version by xonar_)
•http://forum.xda-developers.com/showpost.php?p=33426102&postcount=37 (win32 C port by navossoc)
•http://forum.xda-developers.com/showpost.php?p=34022349&postcount=141
Basically, the AP.bin file is plain raw file, the bootable images can be extracted by searching specific pattern "ANDROID!".
based on this work, I can figure out the AP.bin header information without searching specific pattern to extract boot.img/ext4 partitions/bootloader etc.
Usage
Download attached file. It include both win32 and linux binary and it's source(GPL).
• show AP.bin information
Code:
extract P990_AP.bin
• extract specific section
Code:
extract P990_AP.bin 3
• or extract all images
Code:
extract P990_AP.bin -1
TODO
• show filenames or partitions
References
mman-win32 is used to port win32 binary
• mman-win32 (GPLv2) by kutuzov - http://code.google.com/p/mman-win32/
• http://forum.xda-developers.com/showpost.php?p=34078601&postcount=148
ChangeLog
•*oops! no source change. just replace with working extract.exe (reported by spyrosk and Kostja_V)
Credits
• navossoc - the Author of LGExtract.exe and win32 C port of extractor.
• xonar_ - BIN/FLS extractor and it's java source.

This is a cool tool, wkpark, but I don't understand the difference to the already available tool here:
(it already does extract AP.bin files of the latest ICS leaks, dumping all the available partitions.
But I guess your tool does dump more things like header and bootloader? Could you please write the differences of those two tools?
Also it would be cool to get a tool which is capable of re-merging changed partitions (system.img, boot.img, recovery.img, cracked bootloader) again to a AP.bin --- would that possible? We could create Smartflah-Custom-ROMs then!)

Stefan Gündhör said:
This is a cool tool, wkpark, but I don't understand the difference to the already available tool here:
(it already does extract AP.bin files of the latest ICS leaks, dumping all the available partitions.
But I guess your tool does dump more things like header and bootloader? Could you please write the differences of those two tools?
Also it would be cool to get a tool which is capable of re-merging changed partitions (system.img, boot.img, recovery.img, cracked bootloader) again to a AP.bin --- would that possible? We could create Smartflah-Custom-ROMs then!)
Click to expand...
Click to collapse
as I already mentioned, just rewritten in plain C to make it more portable to support both linux and win32
and make it more unix friendly
and this tool print the exact address and size of images to make it possible to use "dd" to fix AP.bin without any specific tools
e.g.)
Code:
$ extract SU660_AP.bin
filesize: 939524096
[01] address=0x00100000 size=0x00300000
[02] address=0x00400000 size=0x00080000
[03] address=0x00480000 size=0x00180000
[04] address=0x00600000 size=0x20000000
[05] address=0x20600000 size=0x00800000
[06] address=0x20e00000 size=0x01400000
[07] address=0x22200000 size=0x15e00000
$ extract SU660_AP.bin 6 # 6 is recovery.img
...
$ dd if=cwm.img of=SU660_AP.bin bs=1024 seek=$(printf "%d" $((0x20e00000 / 1024))) conv=notrunc
now we got CWM injected AP.bin!
But currently you cant use this method for ICS firmwares

wkpark said:
as I already mentioned, just rewritten in plain C to make it more portable to support both linux and win32
and it is more unix friendly
Click to expand...
Click to collapse
Aaaah okay cool
What about the re-merging thing, do you think you could maybe look into that?
Edit: Ah I see you updated your post, thanks!

Simply awesome. Thanks wkpark!

Very good utility, bravo!
I have been able to decipher everything except partitions 1 and 2, in total there are 7 partitions
1. 01.img
2. 02.img
3. bootloader.img
4. boot.img
5. recovery.img
6. data.img
7. ext3_system.img
I have created a shell for Linux
Use
Copy the file P990_AP.bin into the AP_Toolkit folder /
Run menuen.sh or menues.sh

Look very useful! Tnx dude!

Homero2 said:
Very good utility, bravo!
I have been able to decipher everything except partitions 1 and 2, in total there are 7 partitions
1. 01.img
2. 02.img
3. bootloader.img
4. boot.img
5. recovery.img
6. data.img
7. ext3_system.img
I have created a shell for Linux
Use
Copy the file P990_AP.bin into the AP_Toolkit folder /
Run menuen.sh
Click to expand...
Click to collapse
I guess the order of images are not always the same,
the V30C of SU660 is somewhat different, so this script is not compatible with SU660
some images like as bootable images can be detected by the following method
the bootable images easily checked by dd
Code:
[ $(dd if=boot.img bs=1 count=8 2>/dev/null) = 'ANDROID!' ] && echo "this a is bootable image"

OK, actually the structure varies between models, I have checked that there are differences between P990 and SU660.
And within the same model varies structure?, I've tried several versions of P990 and it seems that the structure is maintained.

Homero2 said:
Very good utility, bravo!
I have been able to decipher everything except partitions 1 and 2, in total there are 7 partitions
1. 01.img
2. 02.img
3. bootloader.img
4. boot.img
5. recovery.img
6. data.img
7. ext3_system.img
I have created a shell for Linux
Use
Copy the file P990_AP.bin into the AP_Toolkit folder /
Run menuen.sh or menues.sh
Click to expand...
Click to collapse
If I remember well partition 1 is the bct file. I suppose that partition 2 has something to do with partition layout .
Sent from my LG-P990 using xda app-developers app

This is a new version, it is more complex than the previous version, also includes the BAT version for Window.
Forgive if there is any error in the Windows version, long time that I do not write anything serious for Windows.
In the menu you can choose the model (P990 or SU660)

Researching a bit I have seen that the 01.img portion is the star.bct, but...
The original file weighs in at 4.0kb, which is obtained with AP_Tool weighs 3.0 MB
With a hex editor I saw that the heading is:
Code:
32 DB 10 C0 A8 A2 5 C 3F 1B 17 34 84 15 57 C6
Looking for I found 7 headers, I extracted them and got 7 files which then I expose in the order found within the 01.img file
star_0.bct - 4.0Kb - this is good (exactly of 000 to FFF)
star_1.bct - 508.0Kb
star_2.bct to star_6.bct - 512.0Kb

Guys,
the extract exe in first post does not work properly. I think it doesn't extract the partitions at the right headers.
I extracted the V28g bin file and the system and data partitions when mounted are unreadable.
Using the extract2 (attached) the partitions are readable perfectly.
The sizes also, differ between the two set of partitions.
I felt I had to let you know.

spyrosk said:
Guys,
the extract exe in first post does not work properly. I think it doesn't extract the partitions at the right headers.
I extracted the V28g bin file and the system and data partitions when mounted are unreadable.
Using the extract2 (attached) the partitions are readable perfectly.
The sizes also, differ between the two set of partitions.
I felt I had to let you know.
Click to expand...
Click to collapse
Did you use the LG extract.exe or other tool to get the ap.bin?
It works perfectly with the lgextract.exe that's why I wrote this post
And why don't you attach your source code?
Isn't it modified extract.c?
Or just binary hacked executable
found at the navossoc's post?
The license of this source code is GPL but you didn't include modified source code in it.
Sent from my LG-P990 using xda app-developers app

wkpark said:
Did you use the LG extract.exe or other tool to get the ap.bin?
It works perfectly with the lgextract.exe that's why I wrote this post
And why don't you attach your source code?
Isn't it modified extract.c?
Or just binary hacked executable
found at the navossoc's post?
The license of this source code is GPL but you didn't include modified source code in it.
Sent from my LG-P990 using xda app-developers app
Click to expand...
Click to collapse
I did use LGExtract.exe to get the bin.
I just downloaded the binary in the first post of this thread. I didn't touch the source code.

The tool from OP doesn't work for me too. The extracted system.img size is 515mb, but should be 512, so it is not flashable via nvflash.
On the screenshot you can see, that files extracted using extract-v0.1 from the OP and extract2 from the http://forum.xda-developers.com/showpost.php?p=34100186&postcount=2 have different sizes.

spyrosk said:
Guys,
the extract exe in first post does not work properly. I think it doesn't extract the partitions at the right headers.
I extracted the V28g bin file and the system and data partitions when mounted are unreadable.
Using the extract2 (attached) the partitions are readable perfectly.
The sizes also, differ between the two set of partitions.
I felt I had to let you know.
Click to expand...
Click to collapse
Kostja_V said:
The tool from OP doesn't work for me too. The extracted system.img size is 515mb, but should be 512, so it is not flashable via nvflash.
On the screenshot you can see, that files extracted using extract-v0.1 from the OP and extract2 from the http://forum.xda-developers.com/showpost.php?p=34100186&postcount=2 have different sizes.
Click to expand...
Click to collapse
thankyou for your testing!!
confirmed !
my bad.. I uploaded not correctly patched win32 executable by mistake.
I just replace the old one with a working win32 binary.

Homero2 said:
Researching a bit I have seen that the 01.img portion is the star.bct, but...
The original file weighs in at 4.0kb, which is obtained with AP_Tool weighs 3.0 MB
With a hex editor I saw that the heading is:
Code:
32 DB 10 C0 A8 A2 5 C 3F 1B 17 34 84 15 57 C6
Looking for I found 7 headers, I extracted them and got 7 files which then I expose in the order found within the 01.img file
star_0.bct - 4.0Kb - this is good (exactly of 000 to FFF)
star_1.bct - 508.0Kb
star_2.bct to star_6.bct - 512.0Kb
Click to expand...
Click to collapse
the image 01(BCT) and 02(PT. Partition Table) are updated by the Smartflash or NVFlash automagically.
you can't even simply download(flash) the BCT/PT image at all
like as MBR and PT, the BCT also duplicated itself

@wkpark hi,
I bumped into the following issue, when I first had an idea making an option in AIO-Toolkit to switch between locked and yours unlocked new bootloader.
I extracted stock bootloader image with your bin extractor.
I also checked its md5 with a backed-up (by nvflash) one's (which was smartflashed) and are the same.
So far so good and your bin extractor works perfectly.
When I try to flash it, nvflash always stops here | 1507328/1572864 bytes sent
Do you have any idea why this happens?
Since the unlocked one is much smaller than the total size of the partition, I suppose stock one has about the same actual size.
Could you please make an image of the stock one for me (with its data only)? get the original from here
cause I don't know how to do it myself and actually I am on a leave and I don't have any linux pc available.
I'd like to give a try because now I am curious, why the cracked one can be flashed and the stock not.
Thank you in advance for your help
Cheers

spyrosk said:
@wkpark hi,
I bumped into the following issue, when I first had an idea making an option in AIO-Toolkit to switch between locked and yours unlocked new bootloader.
I extracted stock bootloader image with your bin extractor.
I also checked its md5 with a backed-up (by nvflash) one's (which was smartflashed) and are the same.
So far so good and your bin extractor works perfectly.
When I try to flash it, nvflash always stops here | 1507328/1572864 bytes sent
Do you have any idea why this happens?
Since the unlocked one is much smaller than the total size of the partition, I suppose stock one has about the same actual size.
Could you please make an image of the stock one for me (with its data only)? get the original from here
cause I don't know how to do it myself and actually I am on a leave and I don't have any linux pc available.
I'd like to give a try because now I am curious, why the cracked one can be flashed and the stock not.
Thank you in advance for your help
Cheers
Click to expand...
Click to collapse
Hi! I was facing the same problem like you. Open the bootloader.bin in a hex editor (WinHEX or any other hexeditor) and delet all the FF hex values from the end of the file. I hope it will work for you
Edit: I deleted the FF a valuses frrom the the backed up bootloader

[Q] Want me to try Ubuntu on RAZR i ? Answer my questions :D

ok so here we go:
i have cwm and a backp.
- does flashing a broken boot.img breaks my phone for ever?
- if not how would i recover it?
- modifying the boot.img is simply changing the text in a hex editor? i need to add some values for ubuntu...
- replacing fastboot userdate will format the complete root system correct?
- when fastbot flash userdata an ubuntu img it will fill the root system with ubuntu correct?
- when only replacing the userdata with ubuntu, would the phone still boot up?
- how would i get smthng like stack traces about what is not working?
i guess i will add questions
if those are answered till tomorow after school (18 hours to go) i will start trying
//Robert

Robbilie said:
ok so here we go:
i have cwm and a backp.
- does flashing a broken boot.img breaks my phone for ever? Nope. We got fastboot files now.
- if not how would i recover it? RSD Lite or manually flashing. 'fastboot flash boot boot.img'
- modifying the boot.img is simply changing the text in a hex editor? i need to add some values for ubuntu... We can pack and unpack it now, no hex editor needed thanks to turl1. Check his thread on the subject
- replacing fastboot userdate will format the complete root system correct? Userdata is /data/, not /system/
- when fastbot flash userdata an ubuntu img it will fill the root system with ubuntu correct? Nope, the /data/, not /system/. You would want 'fastboot flash system system.img'
- when only replacing the userdata with ubuntu, would the phone still boot up? We don't know yet. For sure will have fastboot access no matter what to fix anything in system and boot and userdata.
- how would i get smthng like stack traces about what is not working? Can't help ya there sorry.
i guess i will add questions
if those are answered till tomorow after school (18 hours to go) i will start trying
//Robert
Click to expand...
Click to collapse
I answered what I could

strange the nexus 7 tutorial only includes using the userdata partition, i guess becsuse irs the largest hum?
i need a "cat/proc/partitions" of a nexus 7 to verify this theory...
well lets see...
Sent from my XT890 using xda premium

Shield Portable 2 X1 Recovery Images

Hello! I've recently just snagged a fully functioning Tegra X1-Powered Nvidia Shield Portable 2 that's rooted. I'm trying to extract the partitions so that I can make backups of the bootloader (to flash with nvflash), system, boot, recovery, etc images for other X1-Powered Shield 2 owners for unbricking purposes, as there aren't any recovery images posted online.
Does anyone know which fastboot/adb commands could achieve this? Here is what the partition scheme looks like but I have no clue which partition is which. Any help with this would be greatly appreciated. Thank you so much!

so i just made an interesting find as to which partition is which
i ran
ls -l /dev/block/platform/sdhci-tegra.3/by-name/
and then ran
cat fstab.loki_e_lte
and now i think i know which partition needs to be extracted for each image. refer to screenshot for context
so it seems
mmcblk0p19 > system.img
mmcblk0p20 > cache.img
mmcblk0p18 > boot.img
mmcblk0p22 > misc.img
mmcblk0p23 > staging.img
mmcblk0p16 > recovery.img

i have extracted the images for recovery but i have not tested these. also currently working on figuring out how to extract the bootloader so i can have a *complete* system recovery for those even without a bootloader; if anyone knows how, i'm all ears.
i do not recommend flashing these on a non-bricked shield but someone with a bricked X1 powered shield feel free to test and let me know how it goes <3 flashing instructions are included in the folder too.
loki_e_lte - Google Drive
drive.google.com