Database Users

Discussion : Hard Bricking bug could be fixed

Today Franco Kernel R3 was released and it included the removal of :
* Removed MMC_CAP_ERASE (workaround to fix the superbrick bug)
Boy124 on the other hand, flashed the kernel. Performed a wipe/factory reset twice, and phone successfully booted. As well as, flashed stock GB in PC Odin for checkup, and the rom was successfully flashed.
So is it the time where the bug is being solved? The more confirmation, the better, the safer. Cheers.

GocaS6 said:
In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Alternate erase method?
Originally Posted by Ken Sumrall (Android)
If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition.
Click to expand...
Click to collapse
Based on the other thread about this.
Is it possible to create a partition from that faulty blocks and mount it on to PC? later on I will use data wiping software to write 0..
Im thinking of trying this. but Im still quite unsure yet on how to actually mount second partition to PC, besides the UMS partitition

Looks like the bug is still there!

blue_panther9_9 said:
Based on the other thread about this.
Is it possible to create a partition from that faulty blocks and mount it on to PC? later on I will use data wiping software to write 0..
Im thinking of trying this. but Im still quite unsure yet on how to actually mount second partition to PC, besides the UMS partitition
Click to expand...
Click to collapse
You cannot format or write zeros into the bad blocks because you cannot access them.
You can low level format the whole chip, but then you need to restore the or rebuild the bad blocks list. Finally you would need a Jtag to rewrite the bootloaders into the chip.

Princeomi said:
Looks like the bug is still there!
Click to expand...
Click to collapse
When the bug damages the emmc, it will not be until after the faulty sector is written to/used that the problem will become apparent.
The bug does not have to be present in the current kernel to cause the brick. In the case of this claim, info about his/her previous ICS flashes and wipes is much more important than the proverbial straw that broke the camels back.
Sent from my GT-N7000 using XDA

[PROBLEM] Phone completly DEAD - bootloader problem

Hi all,
I tried yesterday this mod, messing with swap and stuff at the sd card and installed swapper2 from market, but after hitting "on" at the app and tried to reboot, my phone died... and by that I mean completely died...
It doesn't power up, it doesn't boot at CWM neither at bootloader (pink screen).
When I plug it to the charger nothing happens and it doesn't get recognised by the PC also.
I tried booting without the sd card, i tried reformatting it (with swap or without swap) but again... nothing.
I tried to flash the stock firmware (dload folder at sdcard and stuff) but again it doesn't start the bootloader...
Any suggestions before I through it off the window much appreciated
EDIT: I was on latest Aurora...

You may have better luck accessing it through Linux.
If you can get access then you can restore a dd backup from someone.

That program uses root, right? And you put swap partition as mmcblk0p2?
If so, then it simply replaced your main bootloader with the swap file and you have to take it to repair service.
The correct way would've been to use mmcblk1p2, as external SD uses mmcblk1.

m!xal!s said:
You may have better luck accessing it through Linux.
If you can get access then you can restore a dd backup from someone.
Click to expand...
Click to collapse
All the above where done with Linux.
Blefish said:
That program uses root, right? And you put swap partition as mmcblk0p2?
If so, then it simply replaced your main bootloader with the swap file and you have to take it to repair service.
The correct way would've been to use mmcblk1p2, as external SD uses mmcblk1.
Click to expand...
Click to collapse
That is exactly what it did... I will sent it to service then ... I hope my 1 year warranty covers this... Thanks
If anyone knows a way to change the bootloader manually I would love him forever...

spirosbond said:
If anyone knows a way to change the bootloader manually I would love him forever...
Click to expand...
Click to collapse
You have to get phone boot from USB and then use USB JIG which contains bootloader to boot phone and then use some flash tool to flash bootloader to phone. It's very hard and I have no idea how get it boot from USB. Another solution is write bootloader directly to internal sd. I can't help you more.
Sent from my U8800 using Tapatalk 2

Can someone upload the mmcblk0p2 file? I think is inside /dev/block/ folder.
Does anyone knows how to boot something from the sd card? I don't know what... another ROM, another OS...
Thanks a lot.

http://db.tt/Qb32A8Z0
I know how to boot my galaxy tab from USB but I don't know about u8800.
Sent from my U8800 using Tapatalk 2

Qqqxxxzzz said:
http://db.tt/Qb32A8Z0
I know how to boot my galaxy tab from USB but I don't know about u8800.
Sent from my U8800 using Tapatalk 2
Click to expand...
Click to collapse
Can you post here what do you do to boot your tab from USB, and then I may find something based on that... who knows...
I just can't think of a way of booting it up. I tried to make the sdcard bootable disk with cm7 but again I cannot start the phone (or make it boot from sdcard). Copying mannually the bootloader seems easy but again I have no idea who I can acces that partition of the phone....
Thank you all for the help/tips

spirosbond said:
Can you post here what do you do to boot your tab from USB, and then I may find something based on that... who knows...
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1312391
I think it will not work in u8800 because I don't believe that u8800 has iROM and OM pins.
Sent from my U8800 using Tapatalk 2

spirosbond said:
Can you post here what do you do to boot your tab from USB, and then I may find something based on that... who knows...
I just can't think of a way of booting it up. I tried to make the sdcard bootable disk with cm7 but again I cannot start the phone (or make it boot from sdcard). Copying mannually the bootloader seems easy but again I have no idea who I can acces that partition of the phone....
Thank you all for the help/tips
Click to expand...
Click to collapse
Can you try to make a partition on your sd card and dd the bootloader to that partition? After that, give the partition a bootable flag with fdisk and insert to phone. Try to start in many different variations, press the volume keys etc. If the soc bootloader has enabled a function to boot from sd card, somehow it would boot.
The emmc is soldered onto the motherboard. I don't think there are any ways to desolder it or replace.
Of course there must be another way to boot directly from sd card by using some pins, but I have not taken my phone apart to seek on that. Might do it someday though.
JTAG is the thing that would help you definately, but I don't think you have that and the box is pretty expensive too.
-EDIT-
I found this link, it says the phone should go in emergency download mode if loading flash disk fails, do you get any messages in Windows or by listing lsusb in Ubuntu do you get any result when connected with USB? There has to be a way to boot that emergency mode.

Blefish said:
Can you try to make a partition on your sd card and dd the bootloader to that partition? After that, give the partition a bootable flag with fdisk and insert to phone. Try to start in many different variations, press the volume keys etc. If the soc bootloader has enabled a function to boot from sd card, somehow it would boot.
Click to expand...
Click to collapse
I 've tried some things like that but it didn't work. I will try with the bootloader. Should I dd the bootloader.bin from here? I was using this mod since I f***** things up.
fdisk is something I'm not familiar with. Can you let me know how to "give the partition a bootable flag" please? Thanks !
Blefish said:
The emmc is soldered onto the motherboard. I don't think there are any ways to desolder it or replace.
Of course there must be another way to boot directly from sd card by using some pins, but I have not taken my phone apart to seek on that. Might do it someday though.
Click to expand...
Click to collapse
That would be so cool but I don't want to risk any chance of loosing my warranty (if I haven't already) .
Blefish said:
JTAG is the thing that would help you definately, but I don't think you have that and the box is pretty expensive too.
Click to expand...
Click to collapse
Ohh I wish I had one of these things...
Blefish said:
-EDIT-
I found this link, it says the phone should go in emergency download mode if loading flash disk fails, do you get any messages in Windows or by listing lsusb in Ubuntu do you get any result when connected with USB? There has to be a way to boot that emergency mode.
Click to expand...
Click to collapse
I don't get any indication when I connect the phone to any OS. I will send it to service tommorow and if nothing happens I will give it a try then, because it seems little complicated.
I will try the first thing you suggested (with the bootable bootloader) today. If you could answer the above question of mine it would be great
I can't thank you enough... We are lucky having you at our community.
Cheers man

I'm currently learning how to use Fdisk in unbutu to fix my own problem: http://forum.xda-developers.com/showthread.php?t=1694914
Here's something that may help you out:
https://help.ubuntu.com/community/InstallingANewHardDrive
1) Initiate fdisk with the following command:
sudo fdisk /dev/sdX
2) Fdisk will display the following menu:
Command (m for help): m <enter>
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help):
For: sudo fdisk /dev/sdX, where sdX is the disk or partition you want to modify.
If you don't know the disk or partition name, "ls /dev/sd*" should list all drives attached to the system.
From there, just use:
Command action
a toggle a bootable flag
I have not tried this, because I don't need to, but it seems to be what you're looking for. Hope it works for you.
If someone has better information, then please add to this. I just started learning unbuntu yesterday, and may not be completely correct.
If I come across anything that may help you, I'll let you know, and hope you'll do the same for me.
UPDATE: Also try disk utility in ubuntu. It's a lot easier and it has a gui.
Another UPDATE: http://www.thegeekstuff.com/2010/09/linux-fdisk/
Look for "6. Toggle the Boot Flag of a Partition Using fdisk Command a"

Thank you all. My phone has been fixed under warranty. They said that they changed the main board... Who knows... All good for now.
Thanks again!

spirosbond said:
Thank you all. My phone has been fixed under warranty. They said that they changed the main board... Who knows... All good for now.
Thanks again!
Click to expand...
Click to collapse
So there's no way for me to fix this myself without resorting to warranty?

S3nd41 said:
So there's no way for me to fix this myself without resorting to warranty?
Click to expand...
Click to collapse
Did you try the above solutions? If you did but no hope, then all you can do is send your phone to warranty.

Ideas to recover DRM

It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Ps : sorry for my bad eng
Sent from my D5803 using XDA Free mobile app

This is flash memory. If they delete it and afterwards send the command to trim or gc then it's gone for good.

The unlocking process is too fast, I do not think they are rewriting the partition. I think they only remove the DRM then dalvik cache / cache and reboot the phone.
But I could be wrong.
I tried different software, they are effective on my SD card.
But my problem is that I do not see the internal hard disk of the phone, so I can not try it.
My phone is boot unlocked. No root / No recovery

If it was possible this would have been done already.
Skickat från min LG-V500 via Tapatalk

I don't talk about "if we can, if it's possible", i talk about doing this, to trying this.
for now, no one has tried.
Being negative without trying, is the best way of failing

dahod said:
It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Click to expand...
Click to collapse
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.

cschmitt said:
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.
Click to expand...
Click to collapse
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?

matapo said:
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?
Click to expand...
Click to collapse
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.

i thought with towelroot you can root without bootloader unlock ? if not, we just need a possibility to root without bootloader unlock and than we can backup the keys ?

yelp, only that needing JUST a way to root without unlock sounds so easy while it's not.

dahod said:
The unlocking process is too fast
Click to expand...
Click to collapse
TA.img is exatcly 2MB, writing 2MB of zeros to flash memory only takes fractions of a second.

cschmitt said:
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.
Click to expand...
Click to collapse
Thanks for the explanation - much appreciated! Hopefully, someone will attempt the 'almost impossible' and find an exploit or two like towelroot, allowing for root access without compromising the bootloader then. Seems like our only option. Sony hasn't made this easy...I can understand why our fellow users are upset.

Just so people don't get confused: that doesn't mean that the DRM keys can be recovered when the phone was already unlocked, but they can be restored if a backup is made before.
PS: and restoring the keys automatically relocks the bootloader which means they can only be used by stock roms iirc. At least that was the case with RomAur I've been using, restoring the keys resulted in a bootloop.

Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app

For the root exploit on the older Z devices, did the exploit work only on certain firmware versions, or could it work on most or all of the versions?
I'm asking this because I've for the notification for a system update, but I've been holding back on installing the update, thinking that perhaps any exploit might be patch in newer versions.
Thanks.

Only specific versions. But it was possible to downgrade, root and then upgrade while keeping root. Towelroot then worked with various versions that used an affected kernel version.

My brain wouldn't let me sleep last night over this (probably stupid) idea:
If /system can be written to by certain tools (correct me if I'm wrong, but afaik you can flash .ftfs with flashtool with a locked bootloader), would it not be easier to find an exploit there (in the .ftfs)?
Much easier said than done, yes, but sounds much easier than finding an exploit in Android, imo.

I guess tampering with an FTF changes its checksum so it cannot be used anymore.

Iruwen said:
I guess tampering with an FTF changes its checksum so it cannot be used anymore.
Click to expand...
Click to collapse
Well yes, you cannot alter an ftf, but what if we somehow made a small img of system and tricked flashtool into tricking it's actually just the system part of an ftf?
Flashtool then flashes the rooted system image and viola, root achieved!
You know, just how Nexus devices have a recovery (factory) image for each partition? Why not make this work?
Ofc just a (probably wayy off) theory, but it seems plausible.

dahod said:
Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app
Click to expand...
Click to collapse
I wouldn't bet on it. The 'issue' has been there since the Xperia Z, the only solution has been to backup the partition before unlocking, else it's gone for good.

Question about PIT files

Hello everyone,
Please, just a question about repartitioning a PIT file via Odin. I´m a bit confused about information I have read about the result of the repartitioning operation.
In some forums appear to say the repartitioning operation via Odin is, first, a values rewriting of GPT entries, and after that any kind of formatting/wipe of all partitions.
In other words, if i repartition a PIT file exactly with the same values I have in my GPT table, does nothing occurs and the content of partitions keeps, or partitions data are lost?
Sorry about my english, and thank you for any answer you can give me.

D,
hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Although, if you have some experience with data/forensic recovery and can get the tools ported to your tab, it's likely
you may be able to recover a fair amount of what you lose without the data being corrupted.
That being said your repartitioning would need to succeed first.
The better approach for rescuing your data would be to pull the mmcblocks/partitions off of the device and onto
your pc [Linux] as img files through ADB [android debug bridge], BEFORE YOU PERFORM THE OPERATION.
That way if you fail in repartitioning [ which is highly likely]
your data will still be preserved on your pc. To be able to pull the information/data from the device, the device must be rooted
or have a custom recovery available with properly functioning access to/through adb for root functions and adb shell as root.
questions belong in q&a by the way.
m

hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Click to expand...
Click to collapse
Thank you for you answer. Well, what i´m trying to do is just an "experiment" resizing partitions. Of course there are other ways to do it, but what i´m thinking about is this:
Imagine the recovery partition was located in the first memory addresses, so, in one of the first GPT entries, and what i want to do is just modifiy size of last three partitions, so, three last entries in GPT table. If i create a new PIT file exactly with the same values that i have in the GPT table of the device but only modified values for the three last GPT entries, after perform a repartitioning via Odin and restart the device the recovery will be still there?
So, that is the sense of my question: Repartitioning does only write the values in the GPT table, or besides performs any kind of data lose in partitions (wipe,formatting...) ?
questions belong in q&a by the way.
m
Click to expand...
Click to collapse
Sorry and thank you, next time i´ll pay attention to it.

On older devices I had some success resizing partitions using parted in recovery mode via adb.
parted doesn't support ext4 as far as it's useful functions goes, you would have to create/resize any partition
as ext2 and reformat from there, cute approach but more hassle/trouble than it's worth.
for your experiment, be sure you can afford a new tab ! :silly:
i'm pretty sure your block layout is hardcoded in the bootloader. So you will probably end up creating
a very fashionable serving tray.
Meaning your device won't be able to find recovery partition, also there is likely a set amount of partitions allowed
by way of kernel if i remember correctly.
If your trying to get rid of that annoying no-execute permission in data thing, getting rid of FUSE would maybe get that done.
m

Thanks again for your answer. Experiment cancelled, currently no budget for a new tab.
Just a last -and sure a stupid- question, please: In your opinion, what would happen if i extract the PIT file from my device, and use itself to repartitioning via Odin? I mean, just specifying the PIT file and marking Re-Partition, other options (PDA,Phone,etc) unmarked? After restart, could work the tablet or I´ll get a brick?
Thanks again.
Regards.

D,
hi,
That's not a stupid question at all. I would suggest you read this thread all the way through
http://forum.xda-developers.com/tab-4/help/t530nu-pit-file-t2968498
also search via your preferred engine and XDA for terms/variations
samsung pit file signed odin heimdall
so far, the chances of repairing/modifying partition table on these newer devices [samsung] is slim/grim.
However maybe utilizing external/usb-otg storages to suit your needs would be a way to go. :good:
m

[DANGEROUS TOOL][DO NOT USE!][READ FIRST!!!] Trim Area Tool

Trim Area Tool​
Hello! First of all sorry for my bad english words I will try to explain what this tool mean. I am working on trim area dump .ta to .img converter. Whole idea is to dump drm key which is stored in ta unit 1046b and dump the rest of units and further convert (reconstruct) that .ta dump to fully functional .img dump. Whole idea is based on thing which I found in my trim area dump unit 1046b which is somehow doubled on my unmodified locked TA and by the way not deleted after unlocking. I thinked to root phone by unlocking device, get backup unit 1046b, reconstruct trim area, flash reconstructed trim area to make phone locked as before unlocking. Inded it can be done (unconfirmed curently) but... Later things is confirmed on other phones that not all phones have that doubled unit so that mean not all phones have the same trim area. In general my idea was to decode that mistic trim area. I have done things, its decoded partialy but not all since some devices don't have the same headers of the units, for example some device headers starts with C1E9F83Bffffffff but some with C1E9F83Bffffff32 and some with C1E9F83B32323234... I have done some tests to an device (z3) which have broken screen. That phone had that diferent unit headers which is not like on my phone c1e9f83bffffffff, I have reconstructed trim area, flashed back, and this is a report -> http://forum.xda-developers.com/showpost.php?p=69926765&postcount=117 and this one -> http://forum.xda-developers.com/showpost.php?p=69928391&postcount=119 and this one -> http://forum.xda-developers.com/showpost.php?p=70003707&postcount=153
Whole story starts at page http://forum.xda-developers.com/xperia-x-performance/how-to/dirtycow-temp-root-t3503918/page5 please read all posts if you are interesting for trim area things and things which I thinked to do! By that way you will understand better about our tool and idea about a tool!
Trim area format is explained in this post -> http://forum.xda-developers.com/showpost.php?p=69865938&postcount=64 . Problem by now is we don't know how safe is reconstructing some trim area, for example that mistic diferencies in bytes (ffffffff) on some phones and (32323234) on some phones and also some diferent on some phones is a problem by now. What that bytes mean and or why it differs on some devices, I don't know. My tool reconstruct that and makes all ffffffff. The same things can be seen in unused blocks, for example on some devices its filled with 0xff and on some devices with 0x10 and on some devices with 0x32. Why I don't know. My tool makes it all 0xff.
I can reconstruct all units from .ta and can produce .img, but I can not confirm if it will work since testers for that thing is need! Tool is in early stage and not all features is implemented with reason: need to be confirmed one by one. Curently I have done only basic reconstruction which didn't change units data.
Only change headers and unused blocks and make them all with 0xff. At the end tool regenerates hashes of the partitions, thats all by now. I don't know how safe it is at all!
I have done trimarea_tool (command line tool), and that tool nothing change in trim area dump other than unit headers (I have not implemented the rest of my tools since undocumented trim area is still undocumented and very risky is touching trim area, so I not included the rest, it will be public somedays when things gone fully tested), partition hashes and unused blocks, it cleans that 32323234 bytes and writes ffffffff instead and regenerates hashes, thats all by now. Unit data is the same. I have included ton of checks, for example if you try to modify your original ta dump, tool will not generate reconstructed trim area, if size is different, if trim area is not 0x200000 bytes long... and many more. Since we are at initial stage about trim area in general we can't know how safe is playing with trim area, @itsux is only one who flashed reconstructed trim area and reported no hard brick. I must notify you now with red words DO NOT FLASH IF YOU NO WANT TO RISK!!! THIS IS VERY DANGEROUS AND MAY HARD BRICK YOUR PHONE - MEANS KILL FOREVER!!! DO NOT USE ON A WORKING PHONE, THAT IS A RISK!!! Use only if you have broken phone for example working phone with not working or broken screen and you no need that phone, don't flash on daily phone! Itsux is only one who tested on his Z3 phone which is with broken screen, I have modified his trim area the same way, he flashed back that trim area and reported here that his phone is not hard bricked. Again I don't know how safe things is so I am not responsible if tool kills your phone, use at your own risk!! But if you realy want to risk and probably kill your own phone please report what happened at least, it would help further development on this tool!
How to run tool:
First of all this tool is not a standard application so you can't open it like a regular application by double click! Tool is a command line tool so it must be run trught your windows command prompt or trought an batch file! Tool reguires only one parameter, parameter is you TA.img file, e.g:
Code:
trimarea_tool TA.img

Great progress.
I'll think about letting you mess with my Z5s TA [emoji14] Also I'll PM you the Z3 and Z3C TA images as promised in the PM later.
Sent from my D6603 using Tapatalk

Sorry, I don't really understand the purpose of this project, since TA backup is already achieved on new series?

Yes thats a true, dump is achieved, but somedays for example when new xperia lines comes out and there was no root possible (android is more and more secure) we can use further tool to convert unlocked trim area to locked one for example. What we can do with unlocked bootloader that is a very clean I'm in hope

p0kemon said:
Yes thats a true, dump is achieved, but somedays for example when new xperia lines comes out and there was no root possible (android is more and more secure) we can use further tool to convert unlocked trim area to locked one for example. What we can do with unlocked bootloader that is a very clean I'm in hope
Click to expand...
Click to collapse
So u are trying to fix already UB phone with no ta backup to return to completely fixed drm key? wow now i understand XDD Appreciate your work

KWOKSFUNG said:
So u are trying to fix already UB phone with no ta backup to return to completely fixed drm key? wow now i understand XDD Appreciate your work
Click to expand...
Click to collapse
No...the purpose of this tool would be to reconstruct the trim area from a locked bootloader phone so you don't have to wait for an exploit to be found to root (temp root) on future firmwares to backup your TA when all known exploits are patched..
If you already unlocked there nothing that can be done

-DM- said:
No...the purpose of this tool would be to reconstruct the trim area from a locked bootloader phone so you don't have to wait for an exploit to be found to root (temp root) on future firmwares to backup your TA when all known exploits are patched..
If you already unlocked there nothing that can be done
Click to expand...
Click to collapse
Thats right! By the way we still need system user at least in order to dump unit 1046b trought libta.so Hope we get better way when it need.
One more thing, we don't know for sure if drm key is maybe just an generic key for example one which we can enter for example, right? It must be tested first before things gets comfirmed.

p0kemon said:
Thats right! By the way we still need system user at least in order to dump unit 1046b trought libta.so Hope we get better way when it need.
One more thing, we don't know for sure if drm key is maybe just an generic key for example one which we can enter for example, right? It must be tested first before things gets comfirmed.
Click to expand...
Click to collapse
Even better
By the way I got a Z3 with a detached front panel, which is just collecting dust right now as I bought a Z5p after the Z3 broke...
The Z3 is fully functional (the screen colors are just washed out), it is rooted with a locked bootloader (never was unlocked)...I can totally test things on it for you, no problem if it bricks

-DM- said:
Even better
By the way I got a Z3 with a detached front panel, which is just collecting dust right now as I bought a Z5p after the Z3 broke...
The Z3 is fully functional (the screen colors are just washed out), it is rooted with a locked bootloader (never was unlocked)...I can totally test things on it for you, no problem if it bricks
Click to expand...
Click to collapse
That would be great realy! I have done some updates to tool right now, forgot to disable "supported device" check, by now all 2mb trim areas is supported. If you going to try please report what happened!

Some updates... now tool generates two reconstructed formats .img and .ta
.img format is the same like your ta.img dump, just reconstructed
.ta format is just an text file which contains the same data like one from your dump from flashtool, one to four .ta files is created and every one contain its data coresponded to trim area partition number, just reconstructed

Today I have received xperia z1 compact with broken screen, on my supprise I started momentaly working on tests to ta, first thing which I done was reconstruction. What I have done? Since unit 8b2 is unit which is created after unlocking, unit with the same size, unit in the same partition 2 like unit 1046b which get deleted after unlocking... what I tested? Partition 020002 (mean partition 2, part 0), unit 1046b was in partition 020002, now it is in partition 020202 (which is seccond part of the partition 2, in most case), unit 1046b is now in partition 020202 as a replacement to unit 0b2, comfirmed sucess! Just replaced unit 8b2 with one 1046b, reconstructed hashes and I can finally say its success, first device successfuly relocked! Device is locked again the same like before unlocking, all drm keys is with status OK! So guys project is sucesfull! Next thing which I going to test right now is that 32323234 bytes and things...

One more thing! Next test was now:
unit headers which was on xperia z1 compact as C1 E9 F8 3B FF FF FF FF is changed to C1 E9 F8 3B 32 32 32 34, which is totaly the same like z3, and unused blocks which was filled with FF now is changed to 10, reconstructed trim area, updated hashes, flashed, what happened??
Whola!! Done.
Drm keys and thing is with status OK which mean success on z1c, comfirmed successfull reconstruct on z1 compact. I am still afraid to other device models, how safe is on other devices or newer devices I don't know! Probably these bytes which differs on other models (32 32 32 34 on some and on some diferent...), I think can be changed to whatever we want. Maybe these bytes is just an idication for unit changes. On other device I think changing these bytes to FFFFFFFF probably must work the same, I don't know realy how safe is. Be warned again, TOOL IS STILL NOT A SAFE UNTILL SOMEBODY CONFIRM SAFE, HARD BRICK CAN HAPPEN, DO IN MIND THAT! I'm still need somebody confirm before I finalize tool.

p0kemon said:
Today I have received xperia z1 compact with broken screen, on my supprise I started momentaly working on tests to ta, first thing which I done was reconstruction. What I have done? Since unit 8b2 is unit which is created after unlocking, unit with the same size, unit in the same partition 2 like unit 1046b which get deleted after unlocking... what I tested? Partition 020002 (mean partition 2, part 0), unit 1046b was in partition 020002, now it is in partition 020202 (which is seccond part of the partition 2, in most case), unit 1046b is now in partition 020202 as a replacement to unit 0b2, comfirmed sucess! Just replaced unit 8b2 with one 1046b, reconstructed hashes and I can finally say its success, first device successfuly relocked! Device is locked again the same like before unlocking, all drm keys is with status OK! So guys project is sucesfull! Next thing which I going to test right now is that 32323234 bytes and things...
Click to expand...
Click to collapse
You meant that you repair TA area of unlocked device without original TA backup?

Desperanto86 said:
You meant that you repair TA area of unlocked device without original TA backup?
Click to expand...
Click to collapse
Yes!

p0kemon said:
Yes!
Click to expand...
Click to collapse
Dude, its the epic win! In future all sony users can forget about TA backup! You should do DONATE button in your profile!

Desperanto86 said:
Dude, its the epic win! In future all sony users can forget about TA backup! You should do DONATE button in your profile!
Click to expand...
Click to collapse
There is only one problem though, reconstruction need drm key which we need to dump first

I'm analysing now cryptography and can not understand some thing. For example..
1. Unit 8b2 is unit created after unlocking.
2. Unit 1046b is unit which is deleted, it had drm key.
Unit 8b2 is just a key which hash is in unit 7DA (RCK_H= sha256 hash), if we convert 8b2 unit data which is in hex to binary and use it to get sha256 hash we get the same sha256 hash as one in unit 7DA. Unit 8b2 have size the same like unit 1046b, only main diferencie is 8b2 is hex string but 1046b is binary, booth have same size. Unit 1046b after unlocking is replaced with unit 8b2. I am pretty sure there is something tricky between unit 1046b and unit 8b2 since one is hex string and seccond is bin, booth units have the same size! What you think? Do we can reconstruct drm key somehow?

http://newandroidbook.com/Articles/aboot.html Ok. Found some articles how to disasemble aboot, tommorow I will see what aboot says about 1046b

Soo complicated for my head, can't get . Anybody look in .c what is a usage of the ta unit 1046b?? @the_laser , @Androxyde ..anybody?

p0kemon said:
There is only one problem though, reconstruction need drm key which we need to dump first
Click to expand...
Click to collapse
but to dump a BL-locked TA partition we still need a temporary root exploit right?
I can't get it, sorry XD
EDIT: reading better in the original thread, i understand that you can dump the interesting units (NOT the whole TA) using flashtool even on locked devices.
so even without a root exploit, the DRM key could be dumped using Flashtool, TA reconstructed and flashed back after unlocking the bootloader.
And, if i understand well, the TA reconstruction would not include the unit that relocks the bootloader (like it happens when you simply restore the TA backup).
Is it right?