Hi all,
As usual I realized problems later then I made a purchase and own a SEA version of LG G4 815, after spending couple of days with the official unlock site I figured out few things and realized I can not unlock this phone by myself. Originally even the adb and fastboot were not working for me, finally I used minimal ADB and fastboot and manage to get the device ID but this time the LG said my phone is not suitable for unlocking.
So my question is how different are the official "unlock.bin" files are? Is there any way to analyze these files and see what is different for each device and possibly make custom bin files for the unfortunate devices. Possibly someone already thought about this and there is an obvious problem with it that I can not see but if it is possible to change the unlock.bin and customize it, I might still have a chance to unlock it.
Thanks in advance for all that can help.
I guess unblock.bin contains unique device identifiers such as IMEI. Encrypted.
It would take decrypting, replacing IMEI, and encrypting again. Using a private key we don't have.
That is probably why we dont have this around. Oh well I will wait for a while but already start thinking to sell this phone. Should have gone with the HTC
By the way cant we use the bin files with known IMEIs to figure out the encryption?
cagdas said:
By the way cant we use the bin files with known IMEIs to figure out the encryption?
Click to expand...
Click to collapse
Someone has already thought of that...
http://forum.xda-developers.com/showthread.php?t=3354581
Sent from my LG G4
That is great will follow sorry for opening an other topic it looks like similar minds work alike hope he can figure it out.
Hi, I understand that the G-2PW2100s all share identical hardwares, but are the bootloader partitions interchangeable between the Verizon ones & non-Verizon ones? (<- This is question #1) i.e. Can I for example use NJH47F factory image instead of NHG47Q (Verizon) from https://developers.google.com/android/images#marlin on a Verizon marlin assuming the bootloader is unlocked? Or if the stock rom is already rooted and I can overwrite the bootloader partitions via dd? Or perhaps fastboot boot twrp and then dd the bootloader partitions?
If so, can one say there are then no differences between these G-2PW2100 variants? (<- This is question #2)
Update 1: Since everyone focuses on the unlockability and ignores what's asked above, let me state that I know there's currently no way to unlock the bootloader or root the Verizon Pixel, and the purpose of this thread is to collect information in order to help those stuck with a locked bootloader on Verizon Pixels. If you have such information, feel free to share; repeating "you can't unlock/root" is not helpful. I do not own a Verizon Pixel, and I have absolutely nothing to gain from this; I merely want to give back to the community.
Rooting gives one access to read/write the partitions on the eMMC, therefore gives the ability to overwrite the bootloader partitions, which allows unlocking the bootloader.
Unlocking the bootloader also grants read/write access to the partitions on the eMMC, therefore allowing one to overwrite the partitions on the eMMC.
Sneaking an OTA pre-rooted image may or may not be possible, so is finding another way to gain access such as disabling signature check.
The point is, it comes down to the ability to write the partitions on eMMC; once it's writable, you own everything that's on the eMMC. Most people tend to think it's only about the ability to root/unlock, which isn't exactly false, but it's not exactly true either.
Update 2: According to aboot.c, the last byte of the eMMC controls whether a device can be unlocked or not (assuming the compiled aboot in your device uses this logic) For future reference, code is attached.
I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk
Nochis said:
I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk
Click to expand...
Click to collapse
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.
AncientDeveloper said:
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.
Click to expand...
Click to collapse
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.
TonikJDK said:
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.
Click to expand...
Click to collapse
The question asked in the post was that if this was doable, then there should be no differences between the 2 variants? I have not asked if unlocking the bootloader is possible at the moment.
Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.
martinez5241 said:
Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.
Click to expand...
Click to collapse
The Verizon image is obviously different than the non-Verizon one. That's a proven as the checksums are different. The question asked was that by loading the non-Verizon image into a Verizon Pixel, does it effectively make the phone non-Verizon since the hardware is the same?
Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.
If Rooted
yes on the first
NO on the second
TonikJDK said:
Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.
Click to expand...
Click to collapse
chazall1 said:
If Rooted
yes on the first
NO on the second
Click to expand...
Click to collapse
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.
AncientDeveloper said:
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.
Click to expand...
Click to collapse
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.
toknitup420 said:
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.
Click to expand...
Click to collapse
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.
AncientDeveloper said:
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.
Click to expand...
Click to collapse
Okay let me definitively explain this.
VZW Pixel's run the EXACT same software Google Store Pixel's that insert a VZW SIM get. The factory image you run doesn't affect your unlock ability at all.
A Google Store Pixel will update to the VZW build if a VZW SIM is inserted.
DISCLAIMER: From here down is conjecture based on my findings, reverse engineering, and things said/found around the forums.
/** begin my thoughts **/
A few things affect unlock ability (this isn't a catch all list, just from my findings):
1. Is the device SIM locked? - if yes, return grey out "Allow OEM Unlock" switch, if no, continue.
2. Is the device IMEI/MEID on approved by Google to be unlocked? - if this is met, allow "Allow OEM Unlock" to be checked, if not, continue checks.
3. Is the CID a non-unlockable CID (CID = Carried ID ex. VZW___001 on VZW sold Pixels) - if this is met (meaning that the CID is on a specific list of CID's like VZW's for example), grey out "Allow OEM Unlock", if not, allow "Allow OEM Unlock" to be checked.
If when the device connects to Google's servers it passes the above checks, the switch can be toggled.
If the switch can be toggled, you can unlock your device.
Hence why random VZW Pixels are unlockable for no apparent reason, their IMEI isn't VZW's or it doesn't have the VZW MEID (which comically is "vzwmeid"), then the CID being one of a locked device doesn't matter, because that check is never reached.
/** end my thoughts, back to cold hard facts **/
Though I may not be certain of the exact order/magnitude of the checks, the same basic principle applies, its a list of if/then statements. "Flashing an unlocked bootloader" doesn't even make sense in the context of 99% of devices. If you were on a VZW Pixel, and magically were able to flash a non-VZW generic factory image, bootloader set and all, you'd still be unable to unlock all the same.
Now, what else do we know? The device's switch can be toggled if /data/system/users/ 0.xml reports <restrictions> as "false".
This file cannot be edited without root, which many will say "...requires an unlocked bootloader...", but that isn't right.
Currently there are 3 main methods to root access:
- /system/ root - in which the SU binary is put in /system/, as /system/ already has the set-suid capability (which allows SU to actually work), this used to be the go to way, but as of DM-Verity's unveiling in Android 6.0 Marshmallow, we can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System Mode". This can't be used on Locked Bootloader devices (running higher than Android 6.0 Marshmallow), because DM-Verity is enforced in the kernel (which is signature checked).
- Boot Image Root - in which the SU binary is put in the ramdisk, which has the set-suid capability (which allows SU to actually work), this was ChainFire (and later everyone else's) method to root Android 6.0 Marshmallow and beyond while respecting DM-Verity, with this method, we still can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System-less Mode", or any Magisk installation. This can't be used on Locked Bootloader devices because the ramdisk is signature checked.
- Temporary Root - in which the SU binary is either put in /system/ in memory (like we saw with the DirtyCow vulnerability/exploits), or in the /data/ partition (this won't work unless we use some method to give /data/ the set-suid capability). To explain a little more, you've likely seen devices with Locked Bootloaders and /system/ write protection making use of these temp-root setups, like carrier editions of the Samsung Galaxy Note 4/5 with locked bootloaders, and of HTC phones that are S-ON/Bootloader locked. On these devices the exploit needs to be re-run after each boot (hence the "temp" part of temp-root).
The Pixel's can't be rooted with the top two methods due to the combination of DM-Verity and the bootloader being Locked. Though, temp-root can work.
All dePixel8 did was temp-root the Pixel's, remove the restrictions in that file (no proof of this one, though I believe it did), and manually set the "unlockable" bit that the "Allow OEM Unlock" sets when flipped on.
Hence why JCase (one of its creators) said "If anyone hands us a temp-root, we will release another unlock for the Pixel's.". It is literally as simple as plugging in the new temp-root exploit.
Now, the problem with finding a temp-root solution for the Pixel's is that they are one of the most secure and updated devices on the market, often getting Android's monthly security patches before any other device. What I would do it I were serious about it (and let me tell you, I am not), is surf the Android security bulletins and CVE boards for "Privilege Escalation" vulnerabilities that have public PoC's or exploits, and then either further reverse dePixel8 to figure out what bit they set, or just ask JCase, because if you can prove you have temp-root working, I'd bet he'd be friendly enough to talk it through with you. Now granted, that train of thought will only result in an unlock for a previous month's security patch level, but it is better than nothing.
As I noted above, I am not putting this here to express interest in me working on this (for those that might recognize me from my S4 research, or other security ventures), but have seen so much misinformation on these forums, and so much general misunderstanding that I felt it would be helpful to throw this out publically.
Tl;DR: Please link the confused to this post.
npjohnson said:
Tl;DR: Please link the confused to this post.
Click to expand...
Click to collapse
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.
AncientDeveloper said:
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.
Click to expand...
Click to collapse
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.
npjohnson said:
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.
Click to expand...
Click to collapse
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.
AncientDeveloper said:
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.
Click to expand...
Click to collapse
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.
mattwheat said:
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.
Click to expand...
Click to collapse
That's very brave of you. I've been exploring the possibility of using EDL (QDLoader 9008) mode to overwrite the whole eMMC with an already-unlocked image. Pixel is in an unique position to try this as all US versions share the same hardware (except marlin vs sailfish), so there shouldn't be a reason why they can't run the same image.
Shameless bump.
Ok so I just got out of prison and use to have a rooted phone actually I've rooted all my phones I cant find a single walk through for this phone matter of fact I cant find anything on it and I want to root it because I wanna get rid of ads and custom recovery possibly a rom that's more customizable its through straight talk can anyone help me please once again it's a sm-s260dl
Just bumping this to see if any response. I also have Sm-s260dl, and it's locked up tight. "oem unlock" option is hidden in settings, and I've tried tricks posted online to reveal it, but don't work. I also went to authorized Samsung service, and they couldn't do anything. They are bound by Samsung agreement that they can't flash any fw on a device except for the original stock fw (to repair only), and there is only one file officially available for Sm-s260dl, which is the same fw it has, which is Tracfone branded, (which is probably the reason it's so inaccessible).
I have network unlocked, using Samkey, and have access to freeze system apps and write secure settings, using adb and Island/appops/setedit apps, but would really like to be able to unlock the bl. I know it's made unlockable by Samsung, but how's can I get to it?
Any way to use activity manager or other adb to toggle the switch through terminal, or...?
Thanks
Hello,
I'm looking for stock firmware for this device. I'm having difficulties flashing the firmware I have found for it. I need the BIT 5 version to flash in Odin.
Thanks.
Souds as if all our s260dl need the same bit, as ive also been searching for it. It is listed as downloadable with Z3x box server, torrent file, so i dont know if there is an atual file attached to it, i dont know. I have been able to get a couple torrents to work, but not this one.I I have chimera, and it has 0 files for this model.
Interesting enough, when looking into this device, I found a post, that shows an image of the s260dl and on the screen the firmware installed is J260Axxxxx.
If i remember correctly, it was a leak before the official release /announcement for the device.
Im thinking itll be accessable soon., or I'll end up getting the z3x box soon anyway. Ill update here if found etc.
Bootloaders locked tight, no root for this device unless exploit found.
Can easily be network unlocked for use on other carriers tho.
please help with this phone
OuijaElite said:
Souds as if all our s260dl need the same bit, as ive also been searching for it. It is listed as downloadable with Z3x box server, torrent file, so i dont know if there is an atual file attached to it, i dont know. I have been able to get a couple torrents to work, but not this one.I I have chimera, and it has 0 files for this model.
Interesting enough, when looking into this device, I found a post, that shows an image of the s260dl and on the screen the firmware installed is J260Axxxxx.
If i remember correctly, it was a leak before the official release /announcement for the device.
Im thinking itll be accessable soon., or I'll end up getting the z3x box soon anyway. Ill update here if found etc.
Click to expand...
Click to collapse
Dude, what happened? Did you manage to move forward with the device?
Believe it or not I finally figured out a workaround to unlock DIAG Port without root access on my SM-G975U1 which was quite a time consuming process, I am on the most recent ETL1 FW. Dialer codes sadly weren't part of the workaround which would've made this a single step.
My device is recognized by QPST, EFS Explorerer, Service Programming, QFIL, etc... and Window's DM confirms it as 'Qualcomm HS-USB Diagnostics 90B8 (COM11)'.
During the process I took a few wrong turns, messing up my mobile data and IMS Registration, but thankfully I was able to return it to normal.
I would like to factory reset and flash with non-home CSC, but being it was such a lengthy process, I'd like to do more testing while the system is 'messy' so I don't have to flash, then test DIAG mode on a clean system then have to flash again if I make a mistake which I most likely will.
My IMEI is in no need of rescue, but does anyone have any idea if I can use any of these programs to gain further privileges to the system? I have an idea about the basic functionality of QPST, but being that I'm not root, nor have I been on a Qualcomm device, I'm not quite sure how I can take advantage of this particular opportunity to use a function that generally wouldn't benefit a root user in the same way it could potentially benefit me and other non root users.
What I'm most interested in is if QFIL can be used to flash a modified boot.img? That's definitely not the entirety of my curiosity though and would love to hear any and all advantages this could have with non rooted users.
Thank you in advance to anyone who can assist me and other's who will benefit from DIAG Port usage as non-root. The guide will be posted in this thread once I'm able to do some testing with QPST and its related programs, so all answers will be seen here, coming from their original poster.
On this current endeavour I could certainly use some much appreciated guidance from someone more knowledgeable on these programs. I've read about QFIL being used to flash modified boot images which gave me the idea; although that's not the only thing I'm interested in achieving.
***Mods, if there is anywhere acceptable this thread can be moved to where I'll get more replies would you please transfer?
I definitely could use some input about DIAG Mode, QPST, and QFIL and I'm not too sure this is the right place to find it.***
It looks like it is possible to load a boot image using QFIL, or eMMC and QPST Software Download, though I know there is more involved. I wonder if it's possible to inject root into stock FW, I have all the Samsung signatures that I assume would be needed.
I made some changes to the EFS using the Explorer just to have some fun with it, but now onto figuring out exactly how DIAG can benefit non-root users.
I'm guessing the lack of replies mostly has something to do with the development tax on US Snapdragon model's BL unlock.
I'm not too sure how many of us without root, if any, have successfully enabled DIAG. Any suggestions always welcome!
I've used QPST/QFIL recently to write factory firmware to an LG G7 One that had some bizarro retail demo firmware on it, so I'm a wee bit familiar with using it.
QPST/QFIL needs a programmer file (aka the firehose) that is at least specific to the SoC of the device and often specific to the SoC AND manufacturer. I don't even know if firehose files exist for Samsung devices.
Hai Karate said:
I've used QPST/QFIL recently to write factory firmware to an LG G7 One that had some bizarro retail demo firmware on it, so I'm a wee bit familiar with using it.
QPST/QFIL needs a programmer file (aka the firehose) that is at least specific to the SoC of the device and often specific to the SoC AND manufacturer. I don't even know if firehose files exist for Samsung devices.
Click to expand...
Click to collapse
Dude I appreciate you replying, it seems like S10+ forums are dead; besides the guys charging the developer's tax for a BL unlock.
I've seen mentions of Firehose in one or two of program's options themselves but didn't realize it was necessary for flashing with QFIL; i might as well grab it while it's on my mind.
In your opinion do you see any use of DIAG mode outside of flashing and IMEI restore and EFS backup?
I appreciate any help you can give me in advance man.
Hi
I'm new to the forum but have been doing a fair amount of research. I am stuck now though and would like a bit of help.
My situation is that I have a Xperia XA1 ultra (I know I should post in that device specific forum but not much seems to be happening there) I have a very specific problem that I have treated like a forensics problem.
The phone is locked by a pattern which has been guessed by another person so many times that the gatekeeper only allows one entry per day provided the phone is charged otherwise the timer resets.
It has not been rooted and ADB is disabled.
I have connected to it through fastboot and what I can gather is that it is running Android Oreo.
The system details are as follows:
Product: XA1 Ultra G3221
Build Number: 48.1.A.0.129
Chipset: Mediatek MT6757 Helio P20
Bootloader: Locked
My research has led me to the possibility of loading a recovery image into the RAM of the phone and accessing ADB that way. I tried this with a TWRP image but obviously it didn't work. There is a company called Cellebrite that claims to be able to load it's own boot/recovery image into the bootloader and gain entry that way, however the license is something like £10,000. I'm definitely not a commercial customer.
The final option for me would be to dump the memory via JTAG or chipoff, the contents would be encrypted but I found a blog where somebody had managed to find the location of the gesture.key file while the system was encrypted. I can't remember what the site was called though, it took me ages to find last time.
My main questions are does Sony sign the boot image with it's own keys or does it use the standard Android Verified Boot?
Does Sony reuse the same keys for signing across devices? Likely not but maybe
Is there a way to send specific instructions to the RAM via fastboot?
Does anybody know of an exploit that could be used?
Is there a way to extract the boot.img and recover the Sony keys?
If there any other docs, resources or ways to get the data that could help, I will gladly read and/or try them. I think this forum is probably the biggest resource one though but after a while the specific information needed gets harder to find.
The main thing is that I don't unlock the bootloader and flash anything. It's all got to be live and non data damaging.
I tried MTPwn on the off chance that it would work but nope, it was a no go.
If there was a way to utilise the mediatek exploit to gain entry from fastboot that would be excellent, or to use fastboot to dump the memory.
Thanks for reading, I hope someone can help.
Your thread was quite confusing at first as I wasn't sure what to look for exactly :/
That being said, you have your phone locked and you want to unlock it. However you don't want to flash or reset your device, you don't have root permission, you don't have debugger mode on and you don't want to unlock the bootloader, correct?
Basically you're asking for the impossible...
All I can think of is FROST attack. See article for details and source code.
You can also send your device to your nearest Sony service center and they can probably fix it with no memory loss.
Other than that, you MUST hard reset your phone if you want it back.
However should you come to your mind and realize the reality of the situation where you shouldn't be picky about it then you can start with flashing custom recovery. Or using third-party programs like dr.fone.
XDHx86 said:
Your thread was quite confusing at first as I wasn't sure what to look for exactly :/
That being said, you have your phone locked and you want to unlock it. However you don't want to flash or reset your device, you don't have root permission, you don't have debugger mode on and you don't want to unlock the bootloader, correct?
Basically you're asking for the impossible...
All I can think of is FROST attack. See article for details and source code.
You can also send your device to your nearest Sony service center and they can probably fix it with no memory loss.
Other than that, you MUST hard reset your phone if you want it back.
However should you come to your mind and realize the reality of the situation where you shouldn't be picky about it then you can start with flashing custom recovery. Or using third-party programs like dr.fone.
Click to expand...
Click to collapse
Thanks for getting back to me, yes I realise it is asking for the impossible. I'll have a research around that article and see if I can find some information on how to write the program to dump the contents over USB. I tried Dr Fone but that only gave me the option of a hard reset.
My current line of attack is an exploit over USB called OATmeal, whereby a Raspberry Pi is used over OTG with a filesystem label of "../../data", it allows the filesystem of the phone to be mounted and data written off. It is a little complex and so I am struggling a bit with getting it to work. The team over at Project Zero have a good write-up of it so I'm following that and the POC at exploit-db to guide me through it.
I think I will be able to get the USB part to work but I'm not sure if I have to write a Java file to automatically run when /data is mounted, or if that's even possible.
Forenzo said:
My current line of attack is an exploit over USB called OATmeal
Click to expand...
Click to collapse
Not to make you frustrated, but this is an old exploit and I highly doubt it'd work on your device, unless your device security patch is older than 9-2018.
And you can't rollback on your security patch.
You should really consider flashing TWRP or other custom recovery. You have no other option.
XDHx86 said:
Not to make you frustrated, but this is an old exploit and I highly doubt it'd work on your device, unless your device security patch is older than 9-2018.
And you can't rollback on your security patch.
You should really consider flashing TWRP or other custom recovery. You have no other option.
Click to expand...
Click to collapse
Fortunately the device hasn't been updated since around 2-2018 or 3-2018 so any exploit I can find from then onwards that I can use will be great. I really do get that the only realistic option is to unlock the bootloader and flash the recovery but the data needs to be recovered and I absolutely don't want to wipe it.
If I can't do it then it will gather dust until the end of time...
It seems that no matter what I say you won't realize the situation you are in.
I can only suggest to NEVER mess with the phone circuits or the motherboard. No matter which stupid yoututbe tutorial you saw. Those guys are douchebags who only know how to get views and don't care for whatever you/they do to your device.
Needless to say messing with the circuits or the motherboard require dexterity and experience which I'm positive you don't have.
As I said before if you send it to an authorized service center, then they can help you with it without memory loss.
Sending you device to a service center isn't an insult or an act of low self esteem. Service centers exist for a reason, and they're basically geeks who are too passionate about electronics and decided to make a living out of it.
Or maybe you can somehow use the EDL mode on the phone.
In Qualcomm devices the EDL mode is locked and can only be accessed by an authorized person who have the security code of your device. I don't know if it even exist in MTK devices.
Should you actually manage to boot into EDL mode - Assuming it exists and is unlocked - then BEWARE: EDL mode is very low level and any command can directly affect the kernel or compromise the system. Don't use commands you're not sure what do they do.
You can use EDL mode to recover the data from the phone then wipe it clean, then restore the data.
You cannot access memory with EDL mode, but you can access the current image on your device. And from which you can get the key file.
EDL mode is a very very powerful tool (Much more powerful than debugging, fastboot, or anything you may know of) as it doesn't need unlocked bootloader to use it and through which you can do anything to your device including flashing other ROMs.
Good luck on your impossible quest. Make sure to post updates should you find yourself stuck.