But nor is rooting, really but it still is being more and more accepted these days )
You just can't have everything.
Sure ) , life is definitely tough cry but maybe (not really sure if this is the case) one would need a very minimal "special flashable custom recovery" as opposed to "latest available flashable custom recovery" in order to minimize the amount of the *whatever* may be overwritten on the device? ?
jaclaz
But nor is rooting, really but it still is being more and more accepted these days )
You just can't have everything.Sure ) , life is definitely tough cry but maybe (not really sure if this is the case) one would need a very minimal "special flashable custom recovery" as opposed to "latest available flashable custom recovery" in order to minimize the amount of the *whatever* may be overwritten on the device? ?
jaclaz
You're right, I shouldn't assume people know about Android recovery partition details, my bad 😉
Basically, you have two ways of getting your custom recovery to work. Similar to rooting methodology you can flash a permanent recovery or a temporary one.
The temp one is used for devices with unlockable bootloaders, where we can't write to NAND recovery pertition. So instead we write to "userspace" (sometimes data partition, sometimes somwhere else) and have it wiped on next reboot.
This is not what the community is after, so most ready-made recoveries you find are prepared to be flashed permanently. You'd have to compile your own custom one for your specific device if you want a temp one, which is not very difficult.
But that's not neccessary for forensic examination. Obviously, writing permanent recovery to designated recovery address doesn't carry the risk of affecting user data at all since it's not interfering anywhere close to user data - as opposed to flashing to user partition adresses which is, for various reasons, more risky IMHO.
Summing up if you know how to flash custom recoveries and do it right, there should be no risk of touching any user data or critical system data. All you do really, is to replace the built-in stock recovery with custom code.
No rooting neccessary, but unlocked bootloader required if you don't want to use temp root.
Remember unlocking a bootloader wipes all user data.
edit well, sure there're exceptions. F. i. when it comes to new Galaxy generation devices with Knox enabled firmware and you want to avoid your Knox security bit to go off (i. e. because the user data you're after is inside the container), you shouldn't flash a custom recovery. This is why you should always know what you're doing…
I'm not suggesting you always should use that method, this was in response to thread opener having tried all other resorts and asking for any solutions.^^
Ben
Replacing the recovery environment maybe wouldn't change the user data partition, but the password disable zip-file is.
The zip-file will mount the userdata-partition and delete all the *.key files.
I won't say you shouldn't do that, just be aware of the changes you made and if these actions are accepted by your law.
Maybe it would be a nice research project to make a "forensic" recovery environment. It could include mounting the userdata-partition read-only, make a copy of the key-files for offline cracking or copying the userdata partition with hashing abilities.
JTAG is probably your safest bet. Not ideal but it would work.
I had a similar issue last week. I flashed a custom recovery onto a pattern locked Galaxy Discover and created a Nandroid backup that i imported to Oxygen. Oxygen handles Nandroid backups from ClockWorkMods just fine.