Related
LG BIN/TOT Extractor
This is a tool for extracting LG Bin/Tot Firmware files.
I update the git a lot more than what I update the thread so check there for latest news.
Features
Split Bin file into relevant partitions
Split Tot file into relevant blocks and merge blocks into partitions
Display AP Header
Display GPT Header
Extract Header from Bin/Tot File
Features I like to implement (and probably won't get around to)
Extracting boot img (The tools currently available don't work in all cases and it's very easy to read the header since it's open source.)
Extracting ext4 partitions. So that it's easy to access the file. Theres already other tools that can do this so this isn't essential.
Mergeing tot partitions based on data from partitions itself and not GPT
Inject Alternate Data into partitions. I'll block access to X-loader,U-boot and GPT so that You can't kill your phone.
Source
https://github.com/Xonar/LGBinExtractor
Confirmed to work with
Quite a few phones.
I lost track of which ones work.
To check just run with -daph. You'll get file information if it works and either garbled data or an error message if it doesn't.
If your phones not supported follow the steps on git readme.
Thanks
SnowLeopardJB - for lots and lots of testing
navossoc - his tool that extracts kdz and wdb files
vim1 - D821 support
scotty755 - LGL22 support
tkawajir - L-04E and LG G Flex F340K support
If you feel I forgot to thank you, msg me and I'll add you.
If it can extract BIN files then yes. We believe the nandroid V30* of KU5900 that was supplied was incomplete. So If KDZ is converted to BIN and FLS (which we can), then extract contents of BIN, then you can have complete files without looking for Koreans and Chinese to relay that the nandroid was incomplete and can have untampered files.
xonar_ said:
Question to other Devs
Will you use a tool like this or am I wasting my time?
Is a tool like this allowed or would it be considered reverse engineering? (If its not allowed I'm going to stop IMMEDIATELY)
Click to expand...
Click to collapse
Yes I will. If I myself can build a program to extract this EFI partition..
It is reverse engineering, but I don't know if it's legal or not (in this case), but for me it's legal as I'm considered this to educational purpose
Many others tool was created to have purpose like this, for example http://psas.revskills.de/?q=node/5
-CMIIW-
I've attached an image of the system partition of the V20E_00 for you guys to see.
I am going to download the v30H_00.kdz today. So I'll keep you posted about how the extracting goes. I probably won't have time to check it out until the weekend so please don't hold your breath.
I've only recently managed to find the necessary information about the ext4 file system to integrate the functionality into my tool. For now Ext2Read can extract the ext4 file system just fine. I'll add that somewhere over the weekend (Provided something doesn't come up).
Could you as soon, as you are able to unpack it fully maybe upload a complete backup of the system partition and also system2, cause we think, that in the nandroid there are some files missing and we need those, to probably be able to boot that system. Great job btw
Thanks for the positive feedback.
I am getting the v30h_00.kdz in a few hours (I got a friend to download it for me, I don't have that much cap ).
There is no way I will be able to upload the file since it will be big but if it works I'll post the tool and how to do it.
GitHub is giving me an error : "Page did not respond in a timely fashion". I am going to try again tonight to post the source.
I already tried to extract the bin files, but I didn't see any pattern to know where start or ends a partition.
Some partitions you can identify by it's header and try to extract the file size from there (i did that with recovery.exe).
If you know for sure the partition name and the address, I can improve the recovery.exe to patch always the right partition.
So, what is the trick?
[]'s
navossoc said:
I already tried to extract the bin files, but I didn't see any pattern to know where start or ends a partition.
Some partitions you can identify by it's header and try to extract the file size from there (i did that with recovery.exe).
If you know for sure the partition name and the address, I can improve the recovery.exe to patch always the right partition.
So, what is the trick?
[]'s
Click to expand...
Click to collapse
The first meg of the file contains the names of the data blocks size on file,size on disk and where they start on file. I'll post exactly how it is set out later.
The data blocks aren't only partitions though for example the first one is the GPT header with it's corresponding entries and also some blocks are empty.
I recognized the start the two partitions from your tool.
Sent from my LG Optimus Black
xonar_ said:
The first meg of the file contains the names of the data blocks size on file,size on disk and where they start on file. I'll post exactly how it is set out later.
The data blocks aren't only partitions though for example the first one is the GPT header with it's corresponding entries and also some blocks are empty.
I recognized the start the two partitions from your tool.
Sent from my LG Optimus Black
Click to expand...
Click to collapse
You are talking about the first 1MB from BIN? right?
They are using little endian or big endian to represent the numbers?
The name of the sections I already knew, but never found the initial offset.
I will try to take a look later.
[]'s
navossoc said:
You are talking about the first 1MB from BIN? right?
They are using little endian or big endian to represent the numbers?
The name of the sections I already knew, but never found the initial offset.
I will try to take a look later.
[]'s
Click to expand...
Click to collapse
Yes the BIN. They are using little endian. All the offsets and sizes are in LBA's (512 bytes in this case) with LBA 0 starting at 0x100000.
Sent from my LG Optimus Black
Source of Bin Fls Extractor (So far)
GitHub isn't working out as planned. The client stopped downloading in the middle and I don't want to waste more cap so here is the source as an attachment.
This is still a work in progress and is only confirmed to work with v20E_00 South Africa.
Linux users can just mount the *.img file of system to access it. Windows users have to use a tool like Ext2Read. Mac users I'm not sure : Google it.
EDIT : I wont be able to get the v30 kdz for another day unfortunately. Feel free to try and change my tool to work with it.
EDIT2: These sources are old. I'll upload my fixed ones later. Reads in chunks and works on P970 and KU5900 ( I don't have any other files to test it with but it should work with almost all BIN files extracted from kdz files )
xonar_ said:
GitHub isn't working out as planned. The client stopped downloading in the middle and I don't want to waste more cap so here is the source as an attachment.
This is still a work in progress and is only confirmed to work with v20E_00 South Africa.
Linux users can just mount the *.img file of system to access it. Windows users have to use a tool like Ext2Read. Mac users I'm not sure : Google it.
EDIT : I wont be able to get the v30 kdz for another day unfortunately. Feel free to try and change my tool to work with it.
Click to expand...
Click to collapse
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
navossoc said:
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
Click to expand...
Click to collapse
Nice! Great job you guys. :good:
navossoc said:
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
Click to expand...
Click to collapse
can you upload system files asap?
George Jetson said:
can you upload system files asap?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=31443301&postcount=270
Thanks to navossoc there
navossoc said:
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
Click to expand...
Click to collapse
That's good news.
I won't be able to work on the program during the rest of this week. With the system files extracted there's nothing that needs to be urgently done.
Next Step is to to try and build the BIN from other files. I think I can improve on your recovery.exe to add su binary and apk aswel (Might take a bit longer since I need to extract the ext4 partition, add su then put it back together )
Well, it's just a beta, because it use too much ram to write the files.
I need to read the file in chunks, but, for now it's a good prototype, we can using it.
extract.7z
Code:
CRC32: 2199d10f
MD5: 5b8d8031ff5d66ec2832d182e98505be
SHA-1: b6d729a20d4370e25ebc4eddfc27e25673b1d2f2
To use the tool is just run...
Code:
extract.exe filename_AP.bin
It should work on any bin file, tested on P920, P970 and KU5900.
Please report any error.
[]'s
Thanks navossoc its working well on ginger p970 bin file.
Great stuff thanks alot! You to make a great team.
Sent from my LG-P920 using xda app-developers app
Now how can we make a new bin file with that img files?
Hello there, I'm trying to make something (some prerooted rom for myself) but I'm not sure how to handle lib partition.
I already unpacked it and it's now fully located in system folder. However, lib partition on my phone is still full, so do I need to include some lines in updater-script that will erase it or it won't make conflicts if it stays like this? Will device try to mount it or having libs on system will prevent that?
Thanks in adwance.
nlooooo said:
Hello there, I'm trying to make something (some prerooted rom for myself) but I'm not sure how to handle lib partition.
I already unpacked it and it's now fully located in system folder. However, lib partition on my phone is still full, so do I need to include some lines in updater-script that will erase it or it won't make conflicts if it stays like this? Will device try to mount it or having libs on system will prevent that?
Thanks in adwance.
Click to expand...
Click to collapse
If your HBOOT supports the /lib partiton, then you will manually need to mount it in the updater-script.
Hello Everyone.
So I have seen this: http://www.xperiafirmware.com/8-firmware/65-sony-xperia-z3-compact-d5803
And then, maybe it is a silly question but I hope that someone can answer and enlighten me if it is possible or just stupid...
So if we have a locked bootloader and do this:
"2. how to backup your original firmware customization
a) if you do not want to lose warranty of your phone, first thing you have to do is to backup your original customization
b) download Sony PC Companion and connect your phone
c) select update your phone in Sony PC Companion
d) application will prompt you to disconnect your phone before starting downloading firmware, just make it (remember - dont disconnect your phone when update just start...)
e) after finish downloading firmware cancel the update
F) after that, go to C:\ProgramData\Sony Mobile\Update Engine\db\some number\blob_fs, there you find 3 (maybe 4) files, which names start FILE
g) download and install latest Flashtool from here (mirrors Google Drive, Ulozto or Mega)
h) paste the three files, which names start FILE, from blob_fs folder to folder „Firmware“ included in the XPERIA Flashtool
i) open the Flashtool, click on Advanced, choose decrypt files and put all three files from blob_fs folder to the right columm
j) click ok and after approx. one minute a pop up Window will appear via Flashtool
k) mark all files except simlock.ta and transfer them to the right column, than fill in a box in the right upper corner (fill in what you want, it is just for you)
l) now click ok and Flashtool will create backup of your original firmware customization, that you can anytime flash to your phone"
Then unlock the bootloader and if we need to revert back just flash the original backup that we have made. So that way we can recover the drm and the TA partition? Is it possible?
Or it will brick the phone if we do that?
Thanks
A proved way that someone has already archived to maintain camera functionality is in this post:
http://forum.xda-developers.com/showthread.php?p=57675821
All thanks to this guys
Sent from my D5803 using XDA Free mobile app
I open this up to the broader community for discussion: Where do you think custom bootanimations should be stored on Lollipop devices?
Android 5.0 introduces a new /oem partition, that allows for a /oem/media/bootanimation.zip file that seems to take precedence over a system/media/bootanimation.zip file (although I haven't checked AOSP source yet to confirm the exact logic). So far only AT&T+Motorola has utilized this functionality on the AT&T-branded Nexus 6, although I imagine many more OEMs will follow, given the added simplicity it provides.
Given this new option, I humbly suggest that the bootanimation community collectively decide to start placing their bootanimations in oem/media/ (via manual directions and flashable zips) for Lollipop devices, for a number of reasons:
- If a device has a pre-loaded /oem/media/bootanimation.zip, the current flashable zips and manual directions to place at /system/media/bootanimation.zip simply will not work (/oem takes precedence)
- Placing the animation on the /oem partition will persist through an OTA update, ROM update, etc.
- Placing the animation on the /oem partition preserves the ability to receive OTA updates, while placing on the /system partition causes Android 5.0+ updates to fail
Ideally, all flashable zips would contain an updater-script that is more thoughtful than all that I've seen to date; specifically testing for an /oem partition and reacting appropriately.
I haven't looked at source yet, but it's interesting to note that /oem/media/bootanimation.zip seems to supercede /system/media/bootanimation.zip (if /oem is present, then only /oem matters), however /oem/media/audio is additive (ringtones and notifications from both /oem and /system are available to the user).
there are only 2 places to boot a boot animation into.. 1st is /system/media/, but its temporary there, and will get replaced when you flash a rom. 2nd place is /data/local/, there it will not get replaced if you flash a rom.
DA6030 said:
I haven't looked at source yet, but it's interesting to note that /oem/media/bootanimation.zip seems to supercede /system/media/bootanimation.zip (if /oem is present, then only /oem matters), however /oem/media/audio is additive (ringtones and notifications from both /oem and /system are available to the user).
Click to expand...
Click to collapse
That's because audio is selected out of a picklist whereas you cannot choose a boot loader.
Its always been the case that boot animation in /data/local will take over /system/media.
rootSU said:
Its always been the case that boot animation in /data/local will take over /system/media.
Click to expand...
Click to collapse
D'oh, I had forgotten about /data/local. So, that means there are three locations now.
/oem/media is documented in the AT&T Nexus 6 thread, although I'm not sure anyone's checked source to see how it's implemented, nor tested to see where it falls in precedence to /data/local.
http://forum.xda-developers.com/showpost.php?p=56942290&postcount=11
And for reference, looking at the Shamu build.prop, it looks like the oem.prop items are imported explicitly into the build.prop, so the precedence there is clear.
DA6030 said:
D'oh, I had forgotten about /data/local. So, that means there are three locations now.
/oem/media is documented in the AT&T Nexus 6 thread, although I'm not sure anyone's checked source to see how it's implemented, nor tested to see where it falls in precedence to /data/local.
http://forum.xda-developers.com/showpost.php?p=56942290&postcount=11
And for reference, looking at the Shamu build.prop, it looks like the oem.prop items are imported explicitly into the build.prop, so the precedence there is clear.
Click to expand...
Click to collapse
you cant just add it there after manually. and theres another place to put the boot animation, but only when building a rom. i dont remember the location, but you can see it yourself, if you delete the boot animations from /system/media/ and /data/local it will appear. this one just says android
simms22 said:
you cant just add it there after manually. and theres another place to put the boot animation, but only when building a rom. i dont remember the location, but you can see it yourself, if you delete the boot animations from /system/media/ and /data/local it will appear. this one just says android
Click to expand...
Click to collapse
It used to be compiled into the frameworks I think.. Not sure if thats still the case.
Heads UP
Don't know if this is actually what caused my bootloop... but I figured I'd mention it here.
I was trying to get rid of the AT&T boot animation on my N6 and while i was renaming to .bak thought to myself, "why don't I just do my own?" Grabbed another one online, put it in /oem/media/ and bam. No boot.
The worst part is I can't fix it without full restore to stock, because I can't seem to access or even view the /oem/ folder at all through recovery. Is it only mounted after boot?
Don't kow if this means anything to y'all, but I figured someone would find this information interesting.
I have tried several times to make use of the /OEM partition with no success. Every time I reboot the contents disappear.
i tried /data/local to see if it still worked and it didnt work for me....
cmh714 said:
i tried /data/local to see if it still worked and it didnt work for me....
Click to expand...
Click to collapse
i just tried myself, you are right. not working here as well.
simms22 said:
you cant just add it there after manually. and theres another place to put the boot animation, but only when building a rom. i dont remember the location, but you can see it yourself, if you delete the boot animations from /system/media/ and /data/local it will appear. this one just says android
Click to expand...
Click to collapse
It is within framework-res.apk/assets/images/ . . there are two images.
android-logo-mask.png
android-logo-shine.PNG
The mask is a static image with partial transparency. The shine scrolls from left to right behind the mask in a loop, shinning through the mask transparency. It is actually a pretty cool way to do it and I know @rascarlo uses it in rastapop instead of the traditional bootanimation.zip
hlxanthus said:
I have tried several times to make use of the /OEM partition with no success. Every time I reboot the contents disappear.
Click to expand...
Click to collapse
I have also tried (only on stock Google builds), and had the same experience.
OEM partition unformatted on non-ATT devices
hlxanthus said:
I have tried several times to make use of the /OEM partition with no success. Every time I reboot the contents disappear.
Click to expand...
Click to collapse
I just realized that on my device (not AT&T-branded), the /oem partition has always been RAW. So, I flashed the oem.img partition from AT&T firmware (although "fastboot format ext4 oem" would probably be good enough) the partition is now formatted correctly, and now I can use it for storing personalized ringtones, bootanimations, etc. that persist through a factory reset.
DA6030 said:
I just realized that on my device (not AT&T-branded), the /oem partition has always been RAW. So, I flashed the oem.img partition from AT&T firmware (although "fastboot format ext4 oem" would probably be good enough) the partition is now formatted correctly, and now I can use it for storing personalized ringtones, bootanimations, etc. that persist through a factory reset.
Click to expand...
Click to collapse
Okay, I gotta ask. I haven't been able to find the OEM.IMG in any of my searches, just the contents found there. I wasn't aware of any att specific factory images . . got a link you can share? If you don't remember, could you upload the IMG?
hlxanthus said:
Okay, I gotta ask. I haven't been able to find the OEM.IMG in any of my searches, just the contents found there. I wasn't aware of any att specific factory images . . got a link you can share? If you don't remember, could you upload the IMG?
Click to expand...
Click to collapse
There are definitely firmware repositories other than the official Google Developers site. The one I'm thinking of hosts the full .zip file they apply using mfastboot at the factory, which includes the signed oem.img, as well as radio parameters (e.g., SIM lock/unlock for subsidized phones). I can't remember XDA's policy on linking to other sites, so I'll leave it to say that if I search for "Motorola Firmware" (incognito, to avoid personalized search results) it's the 3rd and 4th link right now. The specific file you're looking for is SHAMU_LMY47D_release-keys_subsidy-ATT_CFC.xml.zip. I want you to find it, so if that's not helpful, let me know.
DA6030 said:
There are definitely firmware repositories other than the official Google Developers site. The one I'm thinking of hosts the full .zip file they apply using mfastboot at the factory, which includes the signed oem.img, as well as radio parameters (e.g., SIM lock/unlock for subsidized phones). I can't remember XDA's policy on linking to other sites, so I'll leave it to say that if I search for "Motorola Firmware" (incognito, to avoid personalized search results) it's the 3rd and 4th link right now. The specific file you're looking for is SHAMU_LMY47D_release-keys_subsidy-ATT_CFC.xml.zip. I want you to find it, so if that's not helpful, let me know.
Click to expand...
Click to collapse
Found it, thanks!
Edit: for the record fastboot format didn't work on OEM as it won't work on raw partitions. Extracted and flashed it just as you suggested and now have the crazy att boot animation . . which I will be deleting right now. Thanks a bunch. I will likely post something soon for people who wish to do this themselves.
For those interested in this, here is the OEM.IMG. Once I play with it some more I will open a dedicated thread on how to make use of this partition.
As a little teaser, as expected you can place and set default ringtone, alarm and notification tones. Or add a bootanimation.zip. What I expected to work though did, adding user apps to it. Simply create a directory of /app within the oem partion and place your apps in there. It should be noted there is only about 50mb of space in there. I simply used a file manager to go to the /data/app and copy the desired app folder to the oem partition.(not sure you have to but I simply mirrored the file structure used there). In my case I added a copy of Root Explorer and Titanium Backup in there so they are present for all new rom installs.
Download - SHAMU_subsidy-ATT_OEM.zip
hlxanthus said:
Edit: for the record fastboot format didn't work on OEM as it won't work on raw partitions. Extracted and flashed it just as you suggested and now have the crazy att boot animation . . which I will be deleting right now. Thanks a bunch. I will likely post something soon for people who wish to do this themselves.
As a little teaser, as expected you can place and set default ringtone, alarm and notification tones. Or add a bootanimation.zip. What I expected to work though did, adding user apps to it. Simply create a directory of /app within the oem partion and place your apps in there. It should be noted there is only about 50mb of space in there. I simply used a file manager to go to the /data/app and copy the desired app folder to the oem partition.(not sure you have to but I simply mirrored the file structure used there). In my case I added a copy of Root Explorer and Titanium Backup in there so they are present for all new rom installs.
Click to expand...
Click to collapse
That's a great discovery! Would you consider submitting this as a feature request to Titanium Backup ("move app to oem partition")?
Such a pity the partition can't be formatted from fastboot. Did you try including all the option parameters (ext4 and size)? Do you think it could work from the terminal in recovery (and therefore flashable zip)?
DA6030 said:
That's a great discovery! Would you consider submitting this as a feature request to Titanium Backup ("move app to oem partition")?
Such a pity the partition can't be formatted from fastboot. Did you try including all the option parameters (ext4 and size)? Do you think it could work from the terminal in recovery (and therefore flashable zip)?
Click to expand...
Click to collapse
Alas, I tried just a few variables with fastboot format and gave up and just flashed the OEM.IMG. But fastboot did throw an error stating it could not use the format function on a RAW partition, so I don't know if there is some variable that may have worked.
Only real problem is now that I have it formated I can no longer really test what may or may not work. I can play with it some and see if OEM is accessible via recovery (it is not shown in twrp file manager, that I do know). I have a few shamu guys I can call upon to test, so if I think something might work I will give it a shot.
As for any official TiBu support I doubt it would be accepted, the partition is only 50mb so not a lot of room for stuff.
hlxanthus said:
I can play with it some and see if OEM is accessible via recovery (it is not shown in twrp file manager, that I do know). I have a few shamu guys I can call upon to test, so if I think something might work I will give it a shot.
Click to expand...
Click to collapse
Oh, really good point - TWRP support (at minimum ability to for AT&T customers to wipe the partition, but also file manager) is a way better idea. If your shamu guys are able to format /dev/block/platform/dw_mmc.0/by-name/oem from RAW to ext4 using the appropriate updater-script or recovery terminal command, that would be great to point that out to the TWRP team, to add support for format and file manager. Worst case, I would think TWRP could implement wipe (for AT&T customers) using a delete_recursive. And if format is entirely off the table, one could accomplish the same thing with a flashable zip that flashes the AT&T oem.img and then does a delete_recursive.
By the way, have you tried the format commands in any of fastboot, updater-script or recovery terminal to format your ext4 partition back to RAW?
I recently got the Z1s and decided I wanted to lighten it up a bit (coming from an N4, the SYSTEM footprint of the Z1s seems huge). Since the bootloader is locked (thanks, T-Mobile) I was just going to modify the stock ROM. So, I grabbed the newest FTF C6916_14.5.B.0.236_T-mobile_US.ftf, extracted the system.sin with 7-zip, and then extracted that to EXT4 using Flashtool 0.9.18.6. However, the resulting EXT4 can't be read by EXT4 Unpacker.
I also tried downloading and unpacking the FTF with XperiFirm (now built in to Flashtool), but the system.ext4 was still unreadable.
Does anyone have some tips on what I may be doing wrong?
elmerohueso said:
I recently got the Z1s and decided I wanted to lighten it up a bit (coming from an N4, the SYSTEM footprint of the Z1s seems huge). Since the bootloader is locked (thanks, T-Mobile) I was just going to modify the stock ROM. So, I grabbed the newest FTF C6916_14.5.B.0.236_T-mobile_US.ftf, extracted the system.sin with 7-zip, and then extracted that to EXT4 using Flashtool 0.9.18.6. However, the resulting EXT4 can't be read by EXT4 Unpacker.
I also tried downloading and unpacking the FTF with XperiFirm (now built in to Flashtool), but the system.ext4 was still unreadable.
Does anyone have some tips on what I may be doing wrong?
Click to expand...
Click to collapse
You're not doing anything wrong, I've had the same problem back in the days when my Z1 was alive. Anyways, I've found 1 app to extract system back in the days, I don't remember the name but I belive it's still somewhere on my PC/HDD I'll tell you if I find it.
And I don't think it'll be useful for modding the ftf as you can't re-pack it (or at least that was my case back in the days)
Regards,
~J2C
Just2Cause said:
You're not doing anything wrong, I've had the same problem back in the days when my Z1 was alive. Anyways, I've found 1 app to extract system back in the days, I don't remember the name but I belive it's still somewhere on my PC/HDD I'll tell you if I find it.
And I don't think it'll be useful for modding the ftf as you can't re-pack it (or at least that was my case back in the days)
Regards,
~J2C
Click to expand...
Click to collapse
Thanks, that would be helpful.
I'm actually going to try making a flashable ZIP/ROM rather than repack it as an FTF. I'm just wanting to use the FTF as a source as I don't remember getting a NANDROID of my SYSTEM prior to any modifications.
Use PRFCreator http://forum.xda-developers.com/crossdevice-dev/sony/tool-prfcreator-easily-create-pre-t2859904 then you can unpack the system.ext4 file.
Thanks for the tips. I found that AccessData's Imager Lite, a tool for reading various disk images, was able to properly read the System.ext4 and export its whole file tree. Now it's on to the next step: seeing if I can make the system dump flashable.