there is a info for others from github pageExactly!! :highfive:
Btw, check this guy's approach! (and his sources)
Unfortunately for us >>> $ lstat 'system/bin/dnsmasq' and '//init' failed: Permission denied
I've already seen that... thank you!
Hey I am able to produce right partition hash, inded its adler32 algo as mentioned in oshmoun link to the ta header, with that thing I am prety sure we can reconstruct unlocked trim area back to locked state by restoring back most important units, removing unit 8b2 and restoring back deleted unit 1046B and finaly generate right adler32 hash into partition header. I am not 100% sure in all that but 50% it is possible
Every unit contain 4 magic bytes, 4 bytes unit name, 4 bytes unit lenght, 4 bytes 0xFF, and unit data. Unit data must be 4 bytes aligned, for example if unit data contain 9 bytes in lenght 3 extra bytes must be added at the end 0xFFFFFF. Trim area contain two partitions, one is trim partition and seccond is misc partition. Every partition contain partition header, partition header contain 4 magic bytes, 4 bytes adler32 hash, and 6 extra bytes which contain partition num, partition part and partition number of blocks. Adler32 is calculated on 6 extra bytes after adler32 hash & partition data. Thats all which I know now. Sorry for being offtopic but if this is realy possible we no need any rooting tool and any tadumper, just use flash tool for dump trim area, than unlock bootloader, boot an recovery, install rooting package, dump unlocked trim area, reconstruct unlocked trim area, flash reconstructed trim area back and ooola Sure, but only ~0xA0000 bytes is used, the rest is 0x0 ! In general 15 percent of that 0xA0000 bytes is important, the rest is logs!
I have not had time to check this yet, but it is very likely that sony has patched nougat's kernel indeed!!Nougat has fixed this exploit
That's great news! God job bro!! :highfive:Hey I am able to produce right partition hash, inded its adler32 algo as mentioned in oshmoun link to the ta header, with that thing I am prety sure we can reconstruct unlocked trim area back to locked state by restoring back most important units, removing unit 8b2 and restoring back deleted unit 1046B and finaly generate right adler32 hash into partition header. I am not 100% sure in all that but 50% it is possible
Sure, but only ~0xA0000 bytes is used, the rest is 0x0 ! In general 15 percent of that 0xA0000 bytes is important, the rest is logs!
Even with the coming full TA dump, I think spending time to make this work is important for future endeavors - dirtycow is likely to be fixed soon but surely new bugs will appear that will let us grab TA units from the ta daemon through other meansHey I am able to produce right partition hash, inded its adler32 algo as mentioned in oshmoun link to the ta header, with that thing I am prety sure we can reconstruct unlocked trim area back to locked state by restoring back most important units, removing unit 8b2 and restoring back deleted unit 1046B and finaly generate right adler32 hash into partition header. I am not 100% sure in all that but 50% it is possible
Sure, but only ~0xA0000 bytes is used, the rest is 0x0 ! In general 15 percent of that 0xA0000 bytes is important, the rest is logs!
Is flashtool able to dump unit 1046B ?
Don't f*** .... That's amazing! :highfive: Please do it!
Just a message!
What can I say? Amazing!!
I must say its done! My research is based on initial research done by @munjeni, it helped me a lot, oshmoun git link helped me for hashing... and thats not all, I found backup of the unit 1046b in block which starts at offset 0x80000 which contain partition header FFFFFFFF00000000000000, its not deleted by unlocking trought .ta file but deleted if you unlock by fastbootEven with the coming full TA dump, I think spending time to make this work is important for future endeavors - dirtycow is likely to be fixed soon but surely new bugs will appear that will let us grab TA units from the ta daemon through other means
done = you can generate a valid ta.img out of the units?I must say its done! My research is based on initial research done by @munjeni, it helped me a lot, oshmoun git link helped me for hashing... and thats not all, I found backup of the unit 1046b in block which starts at offset 0x80000 which contain partition header FFFFFFFF00000000000000, its not deleted by unlocking trought .ta file but deleted if you unlock by fastboot
Yes, I can reconstruct it from locked .ta backup and unlocked .img backup and make a valid locked .img
Not tested by now and no tool by now
In that case, the flashtool code can be manipulated so as to only unlock the bootloader without wiping DRM keys. Or am I missing something?I must say its done! My research is based on initial research done by @munjeni, it helped me a lot, oshmoun git link helped me for hashing... and thats not all, I found backup of the unit 1046b in block which starts at offset 0x80000 which contain partition header FFFFFFFF00000000000000, its not deleted by unlocking trought .ta file but deleted if you unlock by fastboot
depends on whether the bootloader checks if the drm keys still exist when it finds the unlock unit.
No no, drm key is still deleted! If you do ta dump you can see drm key twiced, one is in partition 1 and seccond one is in one block which seems not a partition. If you unlock bootloader drm key is deleted but not from that block (in case unlocking was done by .ta file). Userdata doesn't wiped too. In case unlocking is done with fastboot, booth drm key is deleted and allso userdata is wiped. Thats not all, trim area is strongly modified which is not a case when it is done using .ta unlock method. Thats what I found. I can reconstruct trim area easy if unlocking is done using .ta. I am sorry if this is not a right place speaking about ta... I will need some ta dumps from X to see if things is the same on X before I start making a tool...
Please bro, feel free to use this thread for that purpose!! :good:
