Database Users

Quick Idea about permanent root

I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse

Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything

thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.

File under "I'm no expert but..."

Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.

I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App

heyy, I'm not punchie, I've got what the doctor calls a relaxed brain

I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...

deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck

deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.

HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.

[Q] N7 APX mode only - full recovery?

Hi all,
Has anyone followed Rayman's excellent article the-inner-workings-of-secure-boot-key-and-nvflash and fully recovered a N7 from APX only mode?
I have this situation which I think resulted from the battery dying during the 4.4.2 update - Doh I know, but thought I had enough juice to complete the update.
Rayman says the required files will be made available but I cannot find them anywhere

Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.

Erovia said:
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Click to expand...
Click to collapse
Did you read the article? Sounds like you can use the sbk which is a hash of the cpuid...

Nope, but why don't you ask around in the flatline topic?

Erovia said:
Nope, but why don't you ask around in the flatline topic?
Click to expand...
Click to collapse
too much of a noob to post on the forum, but thanks for the pointer.
FYI Raymans article. It does sound possible to bring it back, but there was no follow up with the required files;
What is Secure Boot Key and how does it work?
I've been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It's a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more "secure".
When the SBK is set, it's stored in a one-time-programmable "fuse". This also means that now that the key is out, they can't change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.
So what happens when it boots into APX/Nvflash mode?
The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that's not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded "0x4" error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won't be available. I'm still not entirely sure why (and I can't rule out it will change).
What *is* available, is the nvflash --create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.
So what do we need for nvflash?
In order to get a working (e.g. --create) nvflash, we need a few bits of information as well as some files:
◦Secure Boot Key
◦BCT file (boot device setup, ram configuration and a bit more)
◦ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
◦flash.cfg (e.g. list of settings and names/identifiers of partitions.
On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools
The first four peices aren't readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don't expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.
I hope this helps give a better understanding of how and what secure boot key is and what it gives us.

[REPAIR HARD BRICK] Test Point For Xperia Z1 Compact

Hi! Yesterday I done stupid thing to my phone which hard bricked my phone Played with GPT gdisk, restored wrong gpt backup which killed my device, phone was dead after reboot, had no fastboot, had no bootloader, only had led blinking red-green . But good news I have repaired my phone sucesfully ! Was a bit lucky since I saved my GPT backup so after unbricking I restored my GPT, than restored TA, rebooted and flashed everything normaly. Device finaly booted :highfive:
WARNING TO ALL:
1. DO NOT PLAY WITH FDISK OR GDISK IF YOU NOT KNOW WHAT YOU ARE DOING SINCE YOUR DEVICE WILL BE HARD BRICKED !!! If you mess your gpt table or change them your device can not be flashed using pc companion or flashtool!!! If you brick gpt table than you will notice hard brick, so my segestion is: do not be stupid like me!!! I was very stupid yesterday and done very bad thing to my new phone using these tools.
2. DO NOT PLAY WITH TRYING TO ENTER YOU PHONE INTO DIAG OR ENGINERING MODE IF YOU HAVE NO RIGHT QCOM USB DRIVERS, IT WILL HARD BRICK YOUR PHONE
3. NEVER TOUCH YOU TA PARTITION SINCE YOU WILL NOT BE ABBLE TO UNBRICK YOU PHONE IN ANY WAY!!!
If trim area is damaged you can try this tool -> http://forum.xda-developers.com/showpost.php?p=56571770&postcount=53 to repair your TA partition if possible
Searched for about an hour for pins on my phone and finaly found test point pins, hope picture will save your time, nerve and your device! Use my tool to unbrick you phone, enjoy!
Download Z1C_hard_brick_repair.exe :
- https://mega.co.nz/#!8FBQkbqK!GK2gQgq1li5Ez4lzijMMMUTkuOz0fowUHB1n1NItEaY

Which part is the testpoint @munjeni ? Is it the top one or the one below? Just curious what are you doing with GPT partition? lol!
Also since you opened your Z1C already... Mind if I ask but is there any trigger button or something on the hooks of the flaps? Can't really tell how the phone detects the flap cause on my device it keeps on popping up even when flaps are closed. I think I have some broken flap sensor or something lol!
munjeni said:
Hi! Yesterday I done stupid thing to my phone which hard bricked my phone Played with GPT gdisk, restored wrong gpt backup which killed my device, phone was dead after reboot, had no fastboot, had no bootloader, only had led blinking red-green . But good news I have repaired my phone sucesfully ! Was a bit lucky since I saved my GPT backup so after unbricking I restored my GPT, than restored TA, rebooted and flashed everything normaly. Device finaly booted :highfive:
WARNING TO ALL:
1. DO NOT PLAY WITH FDISK OR GDISK IF YOU NOT KNOW WHAT YOU ARE DOING SINCE YOUR DEVICE WILL BE HARD BRICKED !!! If you mess your gpt table or change them your device can not be flashed using pc companion or flashtool!!! If you brick gpt table than you will notice hard brick, so my segestion is: do not be stupid like me!!! I was very stupid yesterday and done very bad thing to my new phone using these tools.
Searched for about an hour for pins on my phone and finaly found test point pins, hope picture will save your time, nerve and your device! I will not write full tutorial, but if some one need help than please ask here I will help you! ENJOY!
Click to expand...
Click to collapse

Riyal said:
Which part is the testpoint @munjeni ? Is it the top one or the one below? Just curious what are you doing with GPT partition? lol!
Also since you opened your Z1C already... Mind if I ask but is there any trigger button or something on the hooks of the flaps? Can't really tell how the phone detects the flap cause on my device it keeps on popping up even when flaps are closed. I think I have some broken flap sensor or something lol!
Click to expand...
Click to collapse
Test point is "right pin", "left pin" is gnd. To get into emergency flashmode you need to connect gnd with testpoint.
What I done? I tried to resize userdata + create vfat on remaining free space so after unsucesfull atempt I restored wrong gpt backup thats killed my phone.
About flap... I captured only one picture and I no looked into hook on the flaps, my phone is asembled, hope I will not open them again

Ahh I see thanks for this valuable info! Yeah I know about the gnd thing I usually make the usb port the ground when I do testpoint in the past haha! Hopefully though this info won't come in handy to me in the near future! Are you trying to split userdata so you're able to create a mountable internal storage? Hmm I'm not sure if thats possible just by splitting userdata partition though... I think bootloader checks for the hex size and partition list of the partitions. Altering it might hard brick your device. You would have to reverse engineer the bootloader first before you'll be able to alter partitions in mmcblk0 I think.
munjeni said:
Test point is "right pin", "left pin" is gnd. To get into emergency flashmode you need to connect gnd with testpoint.
What I done? I tried to resize userdata + create vfat on remaining free space so after unsucesfull atempt I restored wrong gpt backup thats killed my phone.
About flap... I captured only one picture and I no looked into hook on the flaps, my phone is asembled, hope I will not open them again
Click to expand...
Click to collapse

Riyal said:
Ahh I see thanks for this valuable info! Yeah I know about the gnd thing I usually make the usb port the ground when I do testpoint in the past haha! Hopefully though this info won't come in handy to me in the near future! Are you trying to split userdata so you're able to create a mountable internal storage? Hmm I'm not sure if thats possible just by splitting userdata partition though... I think bootloader checks for the hex size and partition list of the partitions. Altering it might hard brick your device. You would have to reverse engineer the bootloader first before you'll be able to alter partitions in mmcblk0 I think.
Click to expand...
Click to collapse
On Xperia Go it was possible without needs for patching bootloader, so I thinked its possible on Z1C but I was fataly wrong. On X-Go I have resized system,cache,userdata and increased internal storage with sucess. You are right about Z1C since there is a check by bootloader, and allso there is check by bootloader about gpt! So if your gpt is not original than your phone will have fastboot and s1boot but you will not be abble to flash since you will get internal error message by flasher (tried sony pc companion, tried sony flasher, tried s1tool, tried flashtool and no one was abble to flash, only had a luck after restoring my gpt backup which I had saved)! So guys do not touch partitions!

As far as I know this bootloader security thing already exist on Xperia 2011 line so really weird that Xperia Go doesn't have such. I actually did what you have done on Z1C before on the Xperia Pro since that device has a large system partition and no userdata partition. Thankfully though I noticed the bootloader security before doing anything. It's a little bit possible to hex edit the bootloader to adjust the partition size but I didn't pursue it Don't have guts
munjeni said:
On Xperia Go it was possible without needs for patching bootloader, so I thinked its possible on Z1C but I was fataly wrong. On X-Go I have resized system,cache,userdata and increased internal storage with sucess. You are right about Z1C since there is a check by bootloader, and allso there is check by bootloader about gpt! So if your gpt is not original than your phone will have fastboot and s1boot but you will not be abble to flash since you will get internal error message by flasher (tried sony pc companion, tried sony flasher, tried s1tool, tried flashtool and no one was abble to flash, only had a luck after restoring my gpt backup which I had saved)! So guys do not touch partitions!
Click to expand...
Click to collapse

good to hear that i restored wrong TA partition and had the same problem
how u restored ur TA Files ???
my device is Z1 and i know where is the testpoint

escoda said:
good to hear that i restored wrong TA partition and had the same problem
how u restored ur TA Files ???
my device is Z1 and i know where is the testpoint
Click to expand...
Click to collapse
Huh, I don't know how you can restore TA back to phone! I had broken gpt disk and not TA! Since your TA is broken probably you will need jtag since testpoint method can not restore TA, I don't have jtag pinouts so I can not help you, sorry!

munjeni said:
Huh, I don't know how you can restore TA back to phone! I had broken gpt disk and not TA! Since your TA is broken probably you will need jtag since testpoint method can not restore TA, I don't have jtag pinouts so I can not help you, sorry!
Click to expand...
Click to collapse
is there any way to restore TA with testpoint ???

escoda said:
is there any way to restore TA with testpoint ???
Click to expand...
Click to collapse
Maybe if you have flashtool based TA_backup.ta so maybe you can inject that into fota-reset.ta for example. If you have no these backup we can try to generate them based on your raw ta backup, I think thats not hard generating them!

munjeni said:
Hi! Yesterday I done stupid thing to my phone which hard bricked my phone Played with GPT gdisk, restored wrong gpt backup which killed my device, phone was dead after reboot, had no fastboot, had no bootloader, only had led blinking red-green . But good news I have repaired my phone sucesfully ! Was a bit lucky since I saved my GPT backup so after unbricking I restored my GPT, than restored TA, rebooted and flashed everything normaly. Device finaly booted :highfive:
WARNING TO ALL:
1. DO NOT PLAY WITH FDISK OR GDISK IF YOU NOT KNOW WHAT YOU ARE DOING SINCE YOUR DEVICE WILL BE HARD BRICKED !!! If you mess your gpt table or change them your device can not be flashed using pc companion or flashtool!!! If you brick gpt table than you will notice hard brick, so my segestion is: do not be stupid like me!!! I was very stupid yesterday and done very bad thing to my new phone using these tools.
Searched for about an hour for pins on my phone and finaly found test point pins, hope picture will save your time, nerve and your device! I will not write full tutorial, but if some one need help than please ask here I will help you! ENJOY!
Click to expand...
Click to collapse
Whats is gpt gdisk

munjeni said:
Maybe if you have flashtool based TA_backup.ta so maybe you can inject that into fota-reset.ta for example. If you have no these backup we can try to generate them based on your raw ta backup, I think thats not hard generating them!
Click to expand...
Click to collapse
You can make a TA backup in FlashTool? How? Also, how do you run gdisk on your phone?

If you're not aware about it then don't even bother asking for it cause I'm pretty sure you won't have any proper use of it Regardless it's a partition on your phone.

Riyal said:
If you're not aware about it then don't even bother asking for it cause I'm pretty sure you won't have any proper use of it Regardless it's a partition on your phone.
Click to expand...
Click to collapse
To know something its not necessary that u must need to have some work with it.. And who know what knowledge will be needed in future??
Sent from my Xperia Z1 Compact (D5503)

Riyal said:
If you're not aware about it then don't even bother asking for it cause I'm pretty sure you won't have any proper use of it Regardless it's a partition on your phone.
Click to expand...
Click to collapse
Yeah because it's impossible to learn about new things and everyone knows that those who have any use for it are all born with intimate knowledge about the filesystem on the Xperia Z1 Compact... I'm a curious guy, and believe me I'm quite technical.
So "partition-image.sin" is just a GPT partition map?

Rekoil said:
Yeah because it's impossible to learn about new things and everyone knows that those who have any use for it are all born with intimate knowledge about the filesystem on the Xperia Z1 Compact... I'm a curious guy, and believe me I'm quite technical.
So "partition-image.sin" is just a GPT partition map?
Click to expand...
Click to collapse
Actually GPT partition is so basic that I would assume people without that much knowledge should not touch that part of the phone. I once tried giving knowledge to a basic user here in xda that he decided to do it on his phone and permanently brick it then ended up blaming me lol!
Anyways no! GPT is the same as MBR(Master boot record) on windows OS. GPT means GUID Partition Table which stores the details of the partitions in the device. It is the data which tells the hardware for example that partition 1 = userdata, partition 2 = system, partition 3 = cache and so on.
To make it plain and simple don't use fdisk on mmcblk0 Cause there's another security check in the phone that verifies the partition table.

Riyal said:
Actually GPT partition is so basic that I would assume people without that much knowledge should not touch that part of the phone. I once tried giving knowledge to a basic user here in xda that he decided to do it on his phone and permanently brick it then ended up blaming me lol!
Anyways no! GPT is the same as MBR(Master boot record) on windows OS. GPT means GUID Partition Table which stores the details of the partitions in the device. It is the data which tells the hardware for example that partition 1 = userdata, partition 2 = system, partition 3 = cache and so on.
To make it plain and simple don't use fdisk on mmcblk0 Cause there's another security check in the phone that verifies the partition table.
Click to expand...
Click to collapse
Man next time please quote the user whom u r replying.. Ur text was confusing and I thought u have replied to the peeson who have asked about ta backup using flashtool.. Anyway thank for ur explanation about gpt..
Sent from my Xperia Z1 Compact (D5503)

Riyal said:
Actually GPT partition is so basic that I would assume people without that much knowledge should not touch that part of the phone. I once tried giving knowledge to a basic user here in xda that he decided to do it on his phone and permanently brick it then ended up blaming me lol!
Anyways no! GPT is the same as MBR(Master boot record) on windows OS. GPT means GUID Partition Table which stores the details of the partitions in the device. It is the data which tells the hardware for example that partition 1 = userdata, partition 2 = system, partition 3 = cache and so on.
To make it plain and simple don't use fdisk on mmcblk0 Cause there's another security check in the phone that verifies the partition table.
Click to expand...
Click to collapse
I know what GPT and MBR are, I'm just wondering how you're interacting with the map on mmcblk0. Are you running gdisk on the phone itself, or are you just dd'ing the first blocks of mmcblk0, modifying them on the computer and writing them back?
Also, this whole thing about protecting noob users I don't buy. Give ample warning and if they break their phones then tough ****, nobody learns anything if we're all being treated like a piece of glass.
coolkoushik07 said:
Man next time please quote the user whom u r replying.. Ur text was confusing and I thought u have replied to the peeson who have asked about ta backup using flashtool.. Anyway thank for ur explanation about gpt..
Sent from my Xperia Z1 Compact (D5503)
Click to expand...
Click to collapse
I did ask that initially, haven't had time to check it out myself so an answer to that would be appreciated as well.

Rekoil said:
I know what GPT and MBR are, I'm just wondering how you're interacting with the map on mmcblk0. Are you running gdisk on the phone itself, or are you just dd'ing the first blocks of mmcblk0, modifying them on the computer and writing them back?
Also, this whole thing about protecting noob users I don't buy. Give ample warning and if they break their phones then tough ****, nobody learns anything if we're all being treated like a piece of glass.
I did ask that initially, haven't had time to check it out myself so an answer to that would be appreciated as well.
Click to expand...
Click to collapse
"dd" command on linux won't alter the partition table though... Like you can't dd a 2gb dump into a 1gb partition it would mess up the content of the dump cause allocated data on a disk is scattered throughout random blocks. And yes the only way to alter it is thru gdisk, gparted, fdisk,fsdisk or there might be some other programs other than I mentioned.

Riyal said:
"dd" command on linux won't alter the partition table though... Like you can't dd a 2gb dump into a 1gb partition it would mess up the content of the dump cause allocated data on a disk is scattered throughout random blocks. And yes the only way to alter it is thru gdisk, gparted, fdisk,fsdisk or there might be some other programs other than I mentioned.
Click to expand...
Click to collapse
No but if you run "dd if=/dev/mmcblk0 of=gpt.img count=10" you'll get the first 10 blocks of mmcblk0, which should contain the partition map. That's what I was referring to. Or are you simply running gdisk on the phone itself?

[Q] Google Nexus 4: photo recovery -safest ROOT possible (pun) 4.4.2

In short, i deleted my photos by accident, and deeply desire to recover them.
Data Recovery programs wont work on my Google Nexus 4, for a combination of reasons. Namely, because it is not a usb mass storage device, it is internal memory, and because the phone has not ever been rooted. If it is possible to recover the photos without rooting the phone, this would be favorable. But i doubt this is possible.
Is there a way to root my phone without causing a "factory wipe/reset"? Perhaps by avoiding unlocking the bootloader?I am not even 100% sure if this can be achieved on 4.4.2. as of now. I am continuing to investigate, but if anyone has the know-how, please let me know.
this forum here, suggests something that might work, but at the end of the forum, it suggests that 4.4.2 is still impossible to root without wiping.
-There are methods of scanning the phone after it has been rooted, but i can't find the right kind of rooting i need.
-There are methods of copying the phone's hard drive -bit-by-bit- to my PC in .RAW format, and then converting this into something that can be mounted like a real drive, which could be scanned and from which photos could be recovered., but this method requires a rooted phone as well
-there is a possibility of trying to mount the phone on a linux OS, and then scan it possibly. but i don't know if this is impossible.
i am reading the basics in the meantime.
LG Google Nexus 4, 4.4.2
Build:KOT49H
kernel:
3.4.0-perf-g2cae413
[email protected] #1
wed Nov20 14:54:28 PST 2013
Desktop PC: Windows 7 Professional 64bit, service pack 1.
Laptop: mac...
you can read more about things i have tried and my other concerns, in greater detail below.
LOTS OF METHODS, LITTLE CLARITY
I just came back from visiting some dear friends in china and purchased an upgraded version of dropbox. Before I uploaded my photos, I accidentally deleted my entire album.
What is the safest and surest attempt for recovery?
1. i need to avoid installing anything on my phone as much as possible - (lest it overwrite the empty areas where the "deleted" photos reside.)
2. i need to keep my phone off as much as humanly possible (lest it overwrite the empty areas where the "deleted" photos reside.)
3. almost without saying - id like to avoid bricking my phone, (lest it destroy my "deleted" photos)
SOFTWARE RECOVERY SECTION
All known software recovery programs won't find any data on my phone because either they are made for scanning mountable drives, USB mass storage devices, or some simply cannot scan the device unless i root my phone (although I am not sure if rooting is directly correlated with successful scanning, or if rooting the phone simply allows me to carry on with other necessary steps prior to "successful scanning"- like allowing me to installing apps that allow me to mount the internal memory as a scannable drive). Enabling USB Debugging, or enabling/disabling MTP is not the same as enabling USB mass storage mode. Seeing the Nexus 4 as "portable Device" under my computer does not mean it is a mounted drive that i can scan with a recover program. No matter what, nothing seems to work with the Google Nexus 4 as it is now.
***I first tried installing the driver's through the ANDROID SDK, by unzipping the contents from the downloaded zip file and by double clicking the .exe file. Double-clicking the .exe file resulted in a cmd dos-style window popping up and immediately disappearing. Perhaps i needed to put the extracted folder on "C:\"?
REGARDLES....later, I have used WugFresh Nexus Root Toolkit v1.8.2 for ensuring proper driver installation for my phone. I have only used this software to install drivers. It walks you through bad-driver uninstallation/clean up, it retrieves the latest drivers, installs them, and then tests their workability for you and lets you know if the drivers were successfully installed.
I have not used Wug's toolkit to root or hack my phone... yet....
Below is a list of software I have used on my Windows machine and my mac. These simply will not work with the phone as it is right now.
Remo
TenorShare
Bycloud android data recovery
Android Data Recovery
Dr. Fone
Recuva
- i havent tried disk digger. but it requires a rooted phone.
SO simple methods will simply not work? Please correct me if I am wrong.
BIT BY BIT CLONE METHOD
This seems to be the most tedious (but thorough) method for actually preparing something that can be truly scanned for photo-recovery. This method seems to create a bit-by-bit copy of the phone to my computer, which can be converted and mounted and then scanned.
However, it requires rooting. Not to mention, it recommends non-destructive rooting. Which leads me to the next section ...
ROOTING section (and its problems)
In the fruitless sections listed above, it always seems to lead towards rooting as a requirement. Most people say you should root your phone when you first get it, because, i suppose rooting is "synonymous" with a wipe/reset. I believe this reset happens as a result of the bootloader being unlocked. According to MY limited understanding, this unlocking process essentially causes a "factory reset" which wipes the phone, and then catastrophically overwrites the precious space where the deleted photos currently reside. this is unacceptable. I imagine, this "reset" is for security reasons.
Most people seem to suggest that you make a back up before you root. This isn't helpful for my situation because we are talking about retrieving deleted data. I cannot make a back-up of deleted data.
Is it really possible to root without wiping the Google Nexus 4?
Is it even profitable to consider rooting a viable option? I don't imagine myself enjoying a rooted phone as much as others on this forum. I would hate to be creating a black hole for malicious software to breed. i am only concerned with data retrieval for this one time in my life. Is rooting the only viable option? If i root, won't that make the previously mentioned software-scanning section (e.g., Dr. fone), more viable than the BIT-BY-BIT section tedious and pointless by comparison?
All in all, I think it most likely that i will need to root my phone and do the bit by bit copy. If a rooting-first-step is the final conclusion, then I am looking for clear and careful advice for my specific phone on how to root it without jeopardizing the deleted photos (e.g., avoiding a "factory reset" from unlocking the bootloader, or perhaps avoiding unlocking the bootloader altogether) and how to hopefully carry on from there. I don't even know if avoiding "unlocking the bootloader" will virtually guarantee a non-destructive root method
Rooting gets crazy because it leads to necessary installations of SuperUser, busybox, kernels, roms, etc... There are so many unfamiliar vague terms for a beginner like me and it is taking tons of time to break through. I am uninterested in keeping my phone rooted, or maintaining a lifestyle with a rooted phone. if we can move expeditiously from point A to B and then back, (get in, get the photos, and get out,) that would be the most awesome plan.
LINUX METHOD?
is there another way to get to the deleted photos?.
I do not know if 'mounting' the phone is akin to 'mounting' a scannable drive. http://www.youtube.com/watch?v=fw2MKGIgyF4
maybe this is another wild goose chase?
IN SUMMARY
1. It would be helpful if there was a root-free photo-recovery software solution that actually works (this is unlikely to be in existence) with an unrooted nexus 4
2. It would be helpful if it is possible to root without destroying my chances of recovering my deleted photos, with the goal of allowing recovery software access (deeper access) to my phone, i.e. disk digger or if necessary... a bit-by-bit copy to my PC.
3. it would be interesting if the nexus 4 can be magically mounted and scanned on the linux operating system
4. It would be MOST HELPFUL if there was a clear consensus on what direction to take, because there is a lot of misinformation out there. One wrong step and i could end up shooting myself in the foot twice (if i inadvertently reset my phone), or three times (if i brick my phone).
5. can the phone be put back to normal (i.e. unroot) after rooting? or does this require that i make a full backup of the phone in its current state? ( i tried using WUGS toolkit to backup my media, but it wont do it unless i unlock the bootloader... back to that problem again )
I'm sorry for sounding like an idiot. I have been at this for a more than a few hours. I sincerely appreciate any help and consideration towards this specific situation in advance, and the hope that this forum has already offered me.

Impossible to root 4.4.2 without unlocking the boot loader and wiping the device.

DrFredPhD said:
Impossible to root 4.4.2 without unlocking the boot loader and wiping the device.
Click to expand...
Click to collapse
Same problem.... There isn't a solution yet? :crying:

fabrollo said:
Same problem.... There isn't a solution yet? :crying:
Click to expand...
Click to collapse
Nope, you have to unlock the bootloader and that wipes the device
Sent from my SAMSUNG-SGH-I727 using XDA Free mobile app

jd1639 said:
Nope, you have to unlock the bootloader and that wipes the device
Sent from my SAMSUNG-SGH-I727 using XDA Free mobile app
Click to expand...
Click to collapse
And after i should try to recover all the wiped files with diskdigger for example? Maybe the datas that we was searching will be found?
Thanks... if i must try this way to solve my problem i will bite the bullet...

fabrollo said:
And after i should try to recover all the wiped files with diskdigger for example? Maybe the datas that we was searching will be found?
Thanks... if i must try this way to solve my problem i will bite the bullet...
Click to expand...
Click to collapse
The chances of recovering anything is very small
Sent from my Nexus 5 using XDA Free mobile app

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