Hi all, after many attempts to unlock pattern my phone says:
Please enter your google account and password. I´ve attempt enter my google account and password and don´t work..
What i do now? Any idea?
Try this...
So it happens, that my brother locked me out of my own phone :O and i didnt want to wipe, so i searched and searched, until i found this solution which worked flawlessly
Method 1 :
Step 1. Download the Android SDK (http://developer.android.com/sdk/)
Step 2. Make sure to configure the ADB usb interface drivers
Step 3. Plug your G1 into your computer (via usb). (Settings -> Application -> Development -> USB Debugging, must be enabled [it is enabled by default in JesusFreke/CM's releases i think])
Step 4. Open command prompt and enter the following:
Code:
adb -d shell
sqlite3 data/data/com.android.providers.settings/databases/settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen_lockedoutpermanently';
.exit
exit
reboot
Thats it, you'r gh0od :clap:
Method 2 :
Code:
adb -d shell
su
sqlite3 data/data/com.android.providers.settings/databases/settings.db
.header on
.mode column
select * from system;
Now, in the table, find the ID of the two lines called lockscreen.l and lock_pattern, in my case; 3125 and 3126
Code:
update system set value=0 where _id=(replace with your id and remove brackets);
update system set value=0 where _id=(replace with your id and remove brackets);
.exit
reboot
Click to expand...
Click to collapse
Instructions from a slightly dodgy, copyright infringing site, so I copied and pasted them to avoid linking to warez. If you google search for a small part of it, you'll find the original source.
Obviously instructions to be followed at your own risk, since they are for the G1, but I reckon the G2 would be the same (same underlying android code).
If poss, make a nandroid backup first
anon2122 said:
Try this...
Instructions from a slightly dodgy, copyright infringing site, so I copied and pasted them to avoid linking to warez. If you google search for a small part of it, you'll find the original source.
Obviously instructions to be followed at your own risk, since they are for the G1, but I reckon the G2 would be the same (same underlying android code).
If poss, make a nandroid backup first
Click to expand...
Click to collapse
Thanks to u advanced answer...but i make wipe.
Related
Let me first say that I have read every post I could find on this subject and tried them all with no success. I rooted my Aria using the Ubuntu Live CD so I could use Titanium backup and eventually try different roms. My phone is still using the stock rom. I then installed Titanium backup which reports "your system settings will prevent you from restoring applications. to correct this go to your phone's settings, then in "applications" and tick the "unknown sources" check box."
The unknown sources check box is of course not there because I have not been able to successfully run the code for allowing non-market apps.
From terminal in the Ubuntu Live CD with USB cable connected and set to charge only. I tried and got "remount failed: operation not permitted." at the adb remount step.
Linux Code:
sudo su
adb remount
adb pull /data/data/com.android.providers.settings/databases/settings.db settings.db
echo "update secure set value = 1 where name = 'install_non_market_apps';"|sqlite3 ./settings.db
adb push settings.db /data/data/com.android.providers.settings/databases/settings.db
adb reboot
I downloaded the android-sdk_r07 and extracted it to my C drive. From a Windows command prompt, I changed to the sdk\tools folder. Adb devices sees the phone but adb remount fails with "remount failed: operation not permitted."
Windows Code:
adb remount
adb pull /data/data/com.android.providers.settings/databases/settings.db settings.db
echo update secure set value = 1 where name = 'install_non_market_apps';|sqlite3 settings.db
adb push settings.db /data/data/com.android.providers.settings/databases/settings.db
I found a post from attn1 that I have not tried that said:
"Put your phone in recovery mode. Go to advanced>mount system and mount data. Follow steps in post #13 (using the windows or linux code above) in cmd screen and you'll be fine." I am not comfortable in trying this approach as there are not enough specific step details and I don't want brick my phone.
I would really appreciate the correct detailed steps to enable non-market apps using the supplied code either from Windows or the Ubuntu Live CD. Thank you in advance.
You are rooted, so boot into recovery and create a nandroid backup; if something goes wrong when pushing settings.db and you cannot boot, restore your nandroid backup. Then, as attn1 stated, perform the same steps you mention above, but while the phone is in recovery and you have mounted the system and data folders.
winsettr said:
You are rooted, so boot into recovery and create a nandroid backup; if something goes wrong when pushing settings.db and you cannot boot, restore your nandroid backup. Then, as attn1 stated, perform the same steps you mention above, but while the phone is in recovery and you have mounted the system and data folders.
Click to expand...
Click to collapse
Thank you winsettr for your post. It looks like running the commands from recovery did indeed work. Titanium backup no longer reports the "your system settings will prevent you from restoring applications. To correct this go to your phone's settings, then in "applications" error.
However, I expected to see the settings\applications unknown sources check box check box and it is not there. I guess I will have to try side-loading an app to confirm that it will work.
I think that gui option would be part of the rom, a part that AT&T has removed... So yeah, see if side- loading works now.
Sent from my Liberty using XDA App
FYI, I am indeed able to side load now from an .apk copied to the sd card. However, I am not able to install from an internet link. Trying to do so generates a "your phone is not authorized" error message.
Until you get a custom rom running, I wouldn't worry too much. Sounds like you can get any app you want (just download internet apps to sd then install). There may be an additional setting in settings.db but that's beyond my knowledge...
Sent from my Liberty using XDA App
Since the phone is Japanese, it is hard to find information if there is a way to root the phone or information about it.
Can anyone direct me to the right path , google is not helping >_<
The typical "me too" reply
dharkness said:
Since the phone is Japanese, it is hard to find information if there is a way to root the phone or information about it.
Can anyone direct me to the right path , google is not helping >_<
Click to expand...
Click to collapse
As per subject, me too. Got this phone on the 1st of April, switched from iPhone thinking I was now free in the world of rooting and custom roms. Guess the joke was on me as there seems to be no support for modern Japanese phones.
Weird considering this is the country of the tech obsessed. Maybe I should learn Japanese, there must be local hackers
puckman said:
As per subject, me too. Got this phone on the 1st of April, switched from iPhone thinking I was now free in the world of rooting and custom roms. Guess the joke was on me as there seems to be no support for modern Japanese phones.
Weird considering this is the country of the tech obsessed. Maybe I should learn Japanese, there must be local hackers
Click to expand...
Click to collapse
2ch might have the answer, it is just in Japanese and I do not know what to search for. Sharp might be the motorola of Japan lockin their phones >_<
puckman said:
As per subject, me too. Got this phone on the 1st of April, switched from iPhone thinking I was now free in the world of rooting and custom roms. Guess the joke was on me as there seems to be no support for modern Japanese phones.
Weird considering this is the country of the tech obsessed. Maybe I should learn Japanese, there must be local hackers
Click to expand...
Click to collapse
http://ameblo.jp/mee-now/theme-10072066016.html
dharkness said:
http://ameblo.jp/mee-now/theme-10072066016.html
Click to expand...
Click to collapse
Yep, this link seems to list the instructions for rooting the 203SH. And there are pretty straightforward and easy, I think.
I don't speak Japanese, I use Google Translate, but I have already rooted a few Sharps (SoftBank and Docomo) and have studied the rooting methods so I am pretty sure I understand the instructions.
Here's what you need to do:
1. You need a 64-bit Windows 7.
2. The build version needs to be S0012, and Android version needs to be 4.1.2.
3. Install the Sharp ADB driver. Get it from here: https://sh-dev.sharp.co.jp/android/modules/driver_eng/
4. Obtain the following files/apps:
・su
・Superuser.apk
・busybox
・unlock_security_module (*** The value "1" will remove the MIYABI lock first and the the NAND lock. However, I can't make full sense of everything in the note so you'll probably need to research this on your own, or experiment.)
5. Turn on USB Debugging on the 203SH. Disable "sleep mode" (I haven't seen this setting before but it should be somewhere in the Settings > Development menu).
6. Using command prompt on your Windows PC, transfer the "unlock" program to the phone:
Code:
> adb push unlock_security_module /data/local/tmp/unlock_security_module
7. Execute the program:
Code:
> adb shell
$ cd /data/local/tmp
$ chmod 777 ./unlock_security_module
$ ./unlock_security_module 1
8. The above should unlock both MIYABI and NAND. You'll see various results being printed for about one minute before the entire operation completes. But this is the result you will be looking for:
Code:
Unlocked LSM.
Do setresuid...
OK.
9. The cursor should change from "$" to "#' which means you have root access.
10. And you will be able to push "su" and "busybox" to the /system folder, and install "Superuser.apk" as a system app (also push it to the /system/app folder).
11. More instructions are to follow (that's that the last note says).
MY ADVICE: Perform the above very carefully and do not forget that you might end up bricking your phone and the responsibility for this will be all yours. If you are not comfortable with executing shell commands (meaning you can understand what's going on), it's best not to try this.
If this method works, please post here. I will publish these instructions on my website.
I cant risk bricking my phone >_< already on my 2nd 203sh, i lost my first one and the deductable for a new phone is expensive >_<
cheeseus said:
Yep, this link seems to list the instructions for rooting the 203SH. And there are pretty straightforward and easy, I think.
I don't speak Japanese, I use Google Translate, but I have already rooted a few Sharps (SoftBank and Docomo) and have studied the rooting methods so I am pretty sure I understand the instructions.
Here's what you need to do:
1. You need a 64-bit Windows 7.
2. The build version needs to be S0012, and Android version needs to be 4.1.2.
3. Install the Sharp ADB driver. Get it from here: https://sh-dev.sharp.co.jp/android/modules/driver_eng/
4. Obtain the following files/apps:
・su
・Superuser.apk
・busybox
・unlock_security_module (*** The value "1" will remove the MIYABI lock first and the the NAND lock. However, I can't make full sense of everything in the note so you'll probably need to research this on your own, or experiment.)
5. Turn on USB Debugging on the 203SH. Disable "sleep mode" (I haven't seen this setting before but it should be somewhere in the Settings > Development menu).
6. Using command prompt on your Windows PC, transfer the "unlock" program to the phone:
Code:
> adb push unlock_security_module /data/local/tmp/unlock_security_module
7. Execute the program:
Code:
> adb shell
$ cd /data/local/tmp
$ chmod 777 ./unlock_security_module
$ ./unlock_security_module 1
8. The above should unlock both MIYABI and NAND. You'll see various results being printed for about one minute before the entire operation completes. But this is the result you will be looking for:
Code:
Unlocked LSM.
Do setresuid...
OK.
9. The cursor should change from "$" to "#' which means you have root access.
10. And you will be able to push "su" and "busybox" to the /system folder, and install "Superuser.apk" as a system app (also push it to the /system/app folder).
11. More instructions are to follow (that's that the last note says).
MY ADVICE: Perform the above very carefully and do not forget that you might end up bricking your phone and the responsibility for this will be all yours. If you are not comfortable with executing shell commands (meaning you can understand what's going on), it's best not to try this.
If this method works, please post here. I will publish these instructions on my website.
Click to expand...
Click to collapse
dharkness said:
I cant risk bricking my phone >_< already on my 2nd 203sh, i lost my first one and the deductable for a new phone is expensive >_<
Click to expand...
Click to collapse
I want to know. Can I use CWM on 203SH or not. I want to Hard reset phone. thank you.
last i check its only temp root
are you a Chinese too？ i got it from wp7bar in tieba
Sent from my SBM203SH using XDA Premium 4 mobile app
i can not execute chmod 777 ./unlock_security_module
It shows some error, how to proceed ?
Do you have rooting methods for Sharp Aquos 506sh?
I have been experimenting with flashing, etc. and somehow the lockscreen were corrupted and the pattern I was using was not longer valid. I had the fingerprint already setup so I could enter using the rear sensor, but having a corrupted lockscreen is annoying. THis method requires TWRP custom recovery. It is compatible with locked bootloaders and doesn't modify the stock boot or system. It is also compatible with all the AAXON 7 models.
If you have the stock ROM and need TWRP and ADB interface:
A. Setup ADB interface in your PC and device drivers. and connect your terminal to the PC.
B. Setup axon7tool in your computer. Enter into EDL mode by running the command "adb reboot edl" in the command prompt. The terminal will seen to be off.
C. Disable the antivirus and then backup your recovery image using axon7tool running "axon7tool -r recovery". Save the created file in a safe place.
D. Flash tenfar's signed TWRP as a new recovery using axon7tool. It will reboot to system again.
E. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
1. In TWRP , and with the ADB interface properly installed run these the commands from your computer:
Code:
adb devices
adb shell mv /data/system/locksettings.db locksettings.db.old
adb reboot
Now the system will allow you to pass lockscreen without security. In that case you do not need to apply the rest of the steps. Should you continue experimenting issues with the lockscreen, then you should apply the full procedure. Just add the following 2 steps:
2. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
3. When TWRP had fully loaded, run in the command prompt the following commands:
Code:
adb devices
adb shell mv /data/system/gatekeeper.pattern.key gatekeeper.pattern.key.old
adb shell mv /data/system/locksettings.db locksettings.db.old
adb shell mv /data/system/gatekeeper.password.key gatekeeper.password.key.old
adb shell mv /data/system/locksettings.db-shm locksettings.db-shm.old
adb shell mv /data/system/locksettings.db-wal locksettings.db-wal.old
adb reboot
If you want to restore the stock recovery, you just need to rename the recovery-backup.bin file created in step C back to recovery.bin and run the command "axon7tool -w recovery". after that you can enable your antivirus software again. axon7tool can't connect with some antivirus software. I will be editing this OP with links to the procedures required for each step. All of them are in this forums.
Enjoy
@Oki
To fix either " Wrong Pattern " , " Wrong Pin " users only need to delete " /data/system/locksettings.db " from either Terminal/File Explorer with root or TWRP File explorer then Reboot and you'll be good to go .
DrakenFX said:
@Oki
To fix either " Wrong Pattern " , " Wrong Pin " users only need to delete " /data/system/locksettings.db " from either Terminal/File Explorer with root or TWRP File explorer then Reboot and you'll be good to go .
Click to expand...
Click to collapse
Sure! but this guide is intended for people with the stock, unrooted, blocked bootloader who want to remain with a pure stock experience. Usually people without experience rooting devices. This is why I will edit the guide to add all the details to every step.
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
twilighttony said:
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
Click to expand...
Click to collapse
Yes, the procedure deletes everything. If you have problems just do the same also with:
gatekeeper.password.key
locksettings.db-shm
locksettings.db-wal
I have updated the OP just to describe the full procedure.
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.
I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.
Of course, I am rooted with twrp, so this comes after setting that up.
Masterjuggler said:
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.
I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.
Of course, I am rooted with twrp, so this comes after setting that up.
Click to expand...
Click to collapse
The problem of this method is that it only works if the bootloader is unlocked and the phone has the No-verify patch installed.
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.
So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
Masterjuggler said:
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.
So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
Click to expand...
Click to collapse
No-Verify is an additional security system implementend in the kernel. When No-Verify is active, it checks for the signature of the system partition. If the system was modified, then the system won't boot. This is why after unlocking the bootloader you have to apply No-Verify Patch or any package with the integrated patch such as SuperSU. As you can see, it has nothing to do with the app signature or the lockscreen at all.
The method presented in the OP is valid for most Android phones, and the only prerequisite is to have TWRP installed. It is safe and a lot more recommended than patching the system partition. Patching system or kernel should always be your last resort. usually deleting locksettings.db is enough, and it is a general method that works for almost any locking method.
On B25 and have followed all instructions. Seems this method no longer works :/
After breaking the screen on my phone I spent the following months reading about how to extract data. It all comes down to enabling ADB debugging and having your computer authorised. Usually this can be done from recovery and you're good to go. However, if you have a broken phone that is fully stock, with ADB disabled and with no custom recovery support then your data is as good as bricked. Such was the case with me when I broke my rare Samsung G360G. However, my phone was supported by CF-AutoRoot by Chainfire, and this gave just the opening I needed to go full wide.
Prerequisites:
Your phone needs to be supported by CF-AutoRoot. Check on there and the new site linked for support of your phone. If it's not there then you will need to download a stock ROM and use the CF-AutoRoot site tool to generate a root package for you. But that is outside the scope of this tutorial. This procedure has only been tested on Samsung. Your phone should have a minimal working charge.
https://autoroot.chainfire.eu/
This tutorial is also based on Linux. It should be translatable to Windows and Cygwin. But for simplicity I'll just use the method I used on Linux. However, if using Odin like I do, you'll need Windows to finish it off.
Aside from this it assumes files in are named in a particular format with a certain file format.
Tutorial:
1. First you need to download a CF-AutoRoot package for your phone. Won't get far without it.
2. Open up a terminal in Linux. We need to download some depends so enter this command:
Code:
sudo apt-get install android-tools-adb android-tools-fsutils
3. We need to extract the archive contents out. Create a suitable folder inside your home folder to build the patch in and cd to it. This uses an example file named CF-AutoRoot-example.tar.md5. Substitute with your actual archive name. Like so.
Code:
mkdir cfar-adb
cd cfar-adb
tar -xf CF-AutoRoot-example.tar.md5
4. There should be a recovery.img and a cache.img.ext4 extracted out. We just need to modify the cache.img.ext4. But first we need to convert it to a workable format. From a sparse to a raw image.
Code:
simg2img cache.img.ext4 cache.raw.ext4
5. We need to mount the cache image
Code:
mkdir cache
sudo mount -t ext4 -o loop cache.raw.ext4 cache
6. The big one. Doing the mod. So now we need to modify the cfar cleanup script. We need to insert commands on the end to enable ADB and add the key to authorise the computer. The following will do just that in this fashion.
a)
You will need to load in the cfar-cleanup.sh file inside the cfroot folder from the cache point mounted. Locate the end and paste the following lines before the reboot and exit commands on the end. Don't save yet.
Code:
echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
mount -o remount,rw /system
echo '' >> /system/build.prop
echo 'persist.service.adb.enable=1' >> /system/build.prop
echo 'persist.service.debuggable=1' >> /system/build.prop
echo 'persist.sys.usb.config=mtp,adb' >> /system/build.prop
chmod 644 /system/build.prop
mount -o remount,ro /system
mkdir -p /data/misc/adb/
echo '' >/data/misc/adb/adb_keys
chmod 640 /data/misc/adb/adb_keys
b)
Load up the ~/.android/adbkey.pub file in a text editor and copy the entire contents in the clipboard. Now back at the script locate that last echo command you pasted into it and set the cursor just after the first single quotation mark. Now paste the clipboard in! This will add your key in. Make sure it's only between the single quotes with no extra characters or line feeds. The lines will naturally split if they don't fit on screen. Otherwise it should be good to go.
c)
Okay now save the file. The above will enable ADB and authorise your computer on the main Android system after the rooting script has done it's work. Before it reboots normally.
7. We need to unmount the cache so it's ready for use.
Code:
sudo umount cache
8. We need to convert the raw image back into a sparse image.
Code:
img2simg cache.raw.ext4 cache.img.ext4
9. Okay were almost done. Now we repack the files into a new Odin archive. Choose a suitable new filename. Like I have done here with my example file.
Code:
tar -H ustar -c recovery.img cache.img.ext4 > cfar-adb.tar
md5sum -t cfar-adb.tar >> cfar-adb.tar
mv cfar-adb.tar cfar-adb.tar.md5
10. The final step! So now the new package is ready for use. We just to use Odin and flash it to the phone. Save the package to a USB stick if needed.
a)
Reboot into Windows. Or you can run it virtualised from Linux. But I prefer to use the real things when dealing with things of a delicate manner and working blindly. Unplug your phone from the computer if connected. Now load up Odin in admin mode.
b)
Just to make sure pull the battery from your phone. Give it a few seconds then put the battery back in and click the back cover on. Now hold down volume down, then home key, and finally hold down power. Wait for the vibration. Then release power after a few moments. Finally release the other keys. At this point press volume up briefly. You should have just put your phone blindly into download mode. I've done this numerous times.
c)
Plug your phone into your computer. After a moment you should see Odin respond with a device added. Usually the phone can vibrate also when it connects giving more positive signs. If nothing happens disconnect the phone from the computer and retry the last step again to put it into download mode. Took me a few tries before I could do it blindly. It helps if you have a working Samsung to test it out on so you can see what happens before you can only feel it.
d)
Now in Odin press the PDA (or AP) button. Select the cfar-adb.tar.md5 package you made up. If the package is fine it will pass the md5 test. Now press the Start button and watch it go! If all goes well it will upload recovery, cache, give you a pass and then the phone will reset. At this point it will be in the process of being rooted, enable ADB, then reboot. If something goes wrong then you may need to go back and check all the patched files. Then rebuild the package again. But be careful, if the ADB has been enabled in the build.prop file one time, you don't want to add it in again and create duplicates, no matter how keen. Once I had it added the only other major problem I encountered was using the correct adb key.
e)
Hopefully now your phone is rooted, has ADB enabled and is booting up normally. Give it a few minutes. You can even see signs of life in Odin with adds and removes on USB activity. Your phone should also vibrate at times. And making noises is also a good sign.
1.1. So I just cranked it up to eleven. Open a Linux terminal again and give it a test. With your phone plugged in.
Code:
adb devices
If all goes well then adb will find your phone as well as list your device as authorised. You can now open shell to the inside. USB debugging is now enabled.
Conclusion:
Well I hope this helps those who have their app data stuck under a broken screen. As long as it was to type in this tutorial It still took me less time to write this tutorial than to learn all that was needed and apply it to my phone. This ends here but for you it may be only the beginning. A next step would be a screen mirroring app which I think is a must have for visual feedback. And USB debugging opens up these possibilities. One thing to be careful of, in a related issue, is that just because you can use adb and the phone is also rooted doesn't mean it will all work at once. If you are tempted to "su" it in an adb shell and get right in there then SuperSU will ask for permission on a blank screen. As will also happen if you try to do an adb backup, it will ask for confirmation on screen. So just expect to work with USB debugging blindly unless you already have a screen mirroring app installed. If you don't have one installed that is your next step.
And on that note. Good luck!
Hi there,
Your tutorial on how to achieve this on Linux looks real neat and complete. Unfortunately, i'm on Windows and i would like to know if you would be able to rewrite this totorial for a Windows user?
I've been reading online for about a week and i've never saw such a complete guide to help newbies to ADB to be able to retrieve data on their locked broken devices.
Cheers!
Hi RaiM1986 and thanks for your kind words. Yes I wrote it so it would be useful to newbies and seasoned hackers alike. Plus I needed to write down some instructions in case I need to do it all again.
Looking at the tutorial it is a bit Linux-centric. I don't know how well it would translate to Windows. Though there would be Windows version of the tools used the main problem would be mounting the filesystem image and making modifications without corrupting it. Because of things like Linux file modes.
However the following tools may be of assistance.
ADB tools:
https://wiki.lineageos.org/adb_fastboot_guide.html
Cygwin provides Linux tools if needed:
http://www.cygwin.com
simg2img:
https://github.com/KinglyWayne/simg2img_win
For mounting the ext4 image:
https://www.osforensics.com/tools/mount-disk-images.html
img2simg and other tools:
https://forum.xda-developers.com/showpost.php?p=49235638&postcount=5
For the ADB key it should be in %USERPOFILE%\.android and other spots I've read of are C:\Windows\System32\config\systemprofile\.android
In case any of the above fails, since I haven't tested them, the easiest alternative might be to just download a Linux live CD, boot it and do the steps inside. Of course any work is lost when you shut it down. You could also boot it in VM program running on Windows.
Amazing guide, Hypexed! The amount of work you put in to figure this out is incredible.
However, I'm stuck on step 6c, where I'm supposed to save the cfar-cleanup.sh file. It's not letting me save it at all, either within the mount point or to another location, it says that I don't have permissions to save the file. I tried the 'sudo chown' to change ownership to try to edit the permissions, but that didn't work either with it still saying I can't have access to the file. Any ideas? There is probably a simple solution, but this is my first time really using Linux so I'm a noob. I'm using Ubuntu 18.04.1LTS installed, not live, dual-booted with Windows, if that's important to know
SpinningQyarks said:
Amazing guide, Hypexed! The amount of work you put in to figure this out is incredible.
Click to expand...
Click to collapse
Thank you for noticing. It really was the culmination of months of hacking and cracking. Not to mention research. I decided I had to write a guide so I could document what I did in case I needed to do it again. And of course if it helped anyone else.
However, I'm stuck on step 6c, where I'm supposed to save the cfar-cleanup.sh file. It's not letting me save it at all, either within the mount point or to another location, it says that I don't have permissions to save the file. I tried the 'sudo chown' to change ownership to try to edit the permissions, but that didn't work either with it still saying I can't have access to the file. Any ideas? There is probably a simple solution, but this is my first time really using Linux so I'm a noob. I'm using Ubuntu 18.04.1LTS installed, not live, dual-booted with Windows, if that's important to know
Click to expand...
Click to collapse
Sorry you got stuck. I can see some issues in my guide. Especially after trying to do 6c again. First I notice I didn't specify where to store all the folders. Somewhere in the home folder obviously but it looks like you sorted that out fine.
I have tested a working solution to the permissions problem. In fact two:
1. Locate cf folder in the cache mount point on the desktop and go into it. Now right click in the window to bring up the context menu and select "Open as Root". Open up the editor as before.
2.. In the terminal run the editor as root. For example:
sudo gedit cfar-cleanup.sh
I've tested this on Mint which is a "relation" of Ubuntu so should work the same.
Now the original permissions should be left intact. I checked and they didn't have the execute bit set which is unusual. It may help here to save your work on the file to a place you can save to in the meantime. So you don't get stuck again. And then unmount your cache mount point, extract the raw image again as per step 4 and remount as per step 5, if the permissions need restoring. They really should be as they are originally set in the image.
Then continue through to step 6 and beyond as you were.
Good luck!
This guide will walk you through deleting your security PIN via several methods. This guide is for those who have forgotten your security PIN and cannot do a Google reset for some reason. Have restored your phone from an old backup that had a different PIN than your current PIN, and now the Android system is completely confused which PIN to use and isn’t accepting any of them.
You should have a custom recovery installed on your phone, or ADB installed on your computer, but that is beyond the scope of this guide as custom recovery installation methods varies by device. Check Appuals for how to install TWRP on your specific device, or how to install ADB on Windows.
There are two situations you may encounter after restoring from a backup that contained a different PIN than the one you are most recently using.
Device Uses Two Different PINs
This will happen when you have a recent boot PIN, and your backup contains an old screen-lock PIN. So now the device will have two different PINs, which may in fact add to overall device security, but be a headache when you need to remember both PINs.
To resolve this you simply need to reset your PIN in the Android settings. Just go to Settings > Security > Screen Lock, and enter a new PIN. It will overwrite the boot PIN and default back to using just one PIN.
The Device Won’t Accept Any PIN
This is where things get frustrating. In certain cases, your phone may accept the boot PIN, but not a screen unlock PIN. For this, we are going to completely delete the files that store your PIN (yes, your PIN is stored in system files that can be deleted – shocking?).
Delete your Android PIN – TWRP Method
Boot your phone into TWRP recovery.
Go to Advanced > File Manager and navigate to /data/system.
Find the files that end in the .key extension and any files that have “locksettings” in the filename. They will typically be (but vary by manufacturer):
Code:
Gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksettings.db-shm
locksettings.db-wal
After you’ve deleted those files, reboot your phone. You will be greeted by a lock screen, but it will not prompt you for any password or PIN. If it does, you did not delete all the necessary files.
Set a new PIN in your security settings!
Delete your Android PIN – ADB Method
Note: This requires a rooted phone and USB debugging enabled. If USB debugging is not enabled and you are locked out of your phone, you need to try and flash a custom recovery such as TWRP, which can also grant an ADB sideloader.
Connect your phone to your computer via USB and launch an ADB terminal.
Type the following commands into the command prompt:
Code:
adb devices
adb shell
cd /data/system
su
rm *.key
rm *.key
adb reboot
Delete your Android PIN – ADB/SQL Method
Note: This is an alternative ADB method for those who have SQLite3 alongside their ADB installation.
Type the following commands into your ADB/SQL terminal:
Code:
adb shell
cd /data/data/com.android.providers.settings/databases
sqlite3 settings.db
update system set value=0 where name=’lock_pattern_autolock’;
update system set value=0 where name=’lockscreen.lockedoutpermanently’;
.quit
Delete your Android PIN – Flashable Pattern Password Disable.Zip Method
Note: This is for those who have a custom recovery (it doesn’t matter which) installed and want to flash a .zip that will do the work for you.
Download the Pattern Password Disable .zip from here and transfer it to your phone’s SD card.
Reboot into your custom recovery of choice.
Flash the zip and reboot your phone.
I have phone that I am and "owner" user. I've created a user accounts for kids. They used fingerprint to unlock the screen for the user account, but then once the phone asked the PIN to "improve" security, but they forget the pin.. of course. It also looks like the phone switched to FBE (file based encryption) with some OS update. Removing locksettings.db makes the phone unbootable, ale also the owner pin disappears. Is there a way how owner can reset the pin for a user?
I have a root also on this device..