Been trying for over a month and can't get root on LG Phoenix 5

Been trying for over a month and can't get root on LG Phoenix 5 - General Questions and Answers

So I've always had a rooted heavily moded android phone but the situation I find my self in all I'm probably going to have acsses to is a cheap LG Phoenix 5 LM-K300AM and very limited acsses to a PC. I could handle that if this phone was rooted. it is so loaded down with BS that the caches accumulated 1.5gb of junk every 2 to 3 hours and there a 1 to 2 second delay most of the time in registering my finger taps on the screen
I need this rooted desperately but I can't find real information about rooting it anywhere and when it comes to computer access I'm so limited I'll only get one shot so it's got to work the first time. I'm even willing l to throw money at this problem
Any ideas let me know

Zantetsukens-cut said:
So I've always had a rooted heavily moded android phone but the situation I find my self in all I'm probably going to have acsses to is a cheap LG Phoenix 5 LM-K300AM and very limited acsses to a PC. I could handle that if this phone was rooted. it is so loaded down with BS that the caches accumulated 1.5gb of junk every 2 to 3 hours and there a 1 to 2 second delay most of the time in registering my finger taps on the screen
I need this rooted desperately but I can't find real information about rooting it anywhere and when it comes to computer access I'm so limited I'll only get one shot so it's got to work the first time. I'm even willing l to throw money at this problem
Any ideas let me know
Click to expand...
Click to collapse
OK so I think I get the idea behind magisk but I need my phones boot.Img file extracted and the phones bootloader will only unlock when the phone it self is unlocked. any ideas?

Nothing not even a "we don't help with prepaid phones" I get it's cheap but it is att's current top prepaid device. but it is also the first phone I've seen where the access to the bootloader is blocked by the network/carrier lock.

Zantetsukens-cut said:
Nothing not even a "we don't help with prepaid phones" I get it's cheap but it is att's current top prepaid device. but it is also the first phone I've seen where the access to the bootloader is blocked by the network/carrier lock.so here
Click to expand...
Click to collapse
Zantetsukens-cut said:
OK so I think I get the idea behind magisk but I need my phones boot.Img file extracted and the phones bootloader will only unlock when the phone it self is unlocked. any ideas?
Click to expand...
Click to collapse
So I had i weird thought the Phoenix 5 comes stock with an AT&T device unlock app and I managed to extract it now in the past I've messed around with an apk editor and and managed to remove ads and activate app that require payment. so is it possible to edit the device unlock app to ignore at&t's condition for unlocking and just do it. If anyone has some app modifying skills I could really use the help

I have a phoenix 5 also. I was under the impression the apk calls home for approval and the unlock code. Can I get a copy of the device unlock apk?

Since Android 6 by default Toybox is part of any Android distribution. This Toybox release is restricted, means SU subcommand isn't supported. Hence all you have to do to get Android rooted is to replace pre-installed Toybox version by Toybox v0.8.5 what isn't restricted, will say contains SU support.

Thanks jwoegerbauer!! Ok, I downloaded toybox-x86_64 from http://landley.net/toybox/downloads/binaries/0.8.5/
I found a method of installing the binary. >
adb push LOCAL_FILE /data/local/tmp/ # replace LOCAL_FILE with the file path of toybox/busybox binary in PC
adb shell
chmod 755 /data/local/tmp/FILE # setting appropriate permission on pushed binary file. Replace FILE with the name of the binary you pushed in first step. Recommended is to use a single word as a name with all lower-case letters
box=/data/local/tmp/FILE # setting up a local variable for usage in next step. Replace FILE as appropriate
$box | $box sed 's/\ /\n/g'| $box sed '$d'| while read line; do $box ln -sf /data/local/tmp/FILE /data/local/tmp/$line; done # We're executing the binary referenced by $box to list all utilities, followed by creation of a list and then for each item in the list, we're creating a symlink in a directory.
I've successfully executed the first 3 commands above. Before I push the button and make symlinks I'd like to know if the binary I downloaded should work .
TIA

Worked great! I got root and removed carrier lock and all the bloat.

deleted

Tacoma56 said:
Thanks jwoegerbauer!! Ok, I downloaded toybox-x86_64 from http://landley.net/toybox/downloads/binaries/0.8.5/
I found a method of installing the binary. >
adb push LOCAL_FILE /data/local/tmp/ # replace LOCAL_FILE with the file path of toybox/busybox binary in PC
adb shell
chmod 755 /data/local/tmp/FILE # setting appropriate permission on pushed binary file. Replace FILE with the name of the binary you pushed in first step. Recommended is to use a single word as a name with all lower-case letters
box=/data/local/tmp/FILE # setting up a local variable for usage in next step. Replace FILE as appropriate
$box | $box sed 's/\ /\n/g'| $box sed '$d'| while read line; do $box ln -sf /data/local/tmp/FILE /data/local/tmp/$line; done # We're executing the binary referenced by $box to list all utilities, followed by creation of a list and then for each item in the list, we're creating a symlink in a directory.
I've successfully executed the first 3 commands above. Before I push the button and make symlinks I'd like to know if the binary I downloaded should work .
TIA
Click to expand...
Click to collapse
What did you do after this? I pushed all the commands and successfully got the older version of toybox installed but SuperSU says I don't have root.

Related

New Root Security Model?

I saw in the SDK this permission for apps to request:
public static final String FACTORY_TEST
Run as a manufacturer test application, running as the root user. Only available when the device is running in manufacturer test mode.
Constant Value: "android.permission.FACTORY_TEST"
Click to expand...
Click to collapse
Our current model with superuser whitelist is not very secure because a malicious person could bundle their own su binary and circumvent the restrictions. It would seem that having our custom roms run in test mode would provide a great solution: using Android's own permission/security model for apps to run as root. This should force all apps to visibly request root permissions at install time.

I am in favor of anything that will improve the security of my phone. It concerns me that anyone who knows what they are doing can so easily boot into recovery mode on my phone, wipe and flash any ROM they want. Granted, they would not have access to my information if the wipe and flash. But, it makes it trivially simple to hijack my phone. I would like to have some password protection for Recovery and Fastboot.

i am by no means a dev, but it seems to me that this probably just has to do with the adp devices

what's a adp device? and explain how they could possibly do this again?

android developer phone.

jaaronmoody said:
i am by no means a dev, but it seems to me that this probably just has to do with the adp devices
Click to expand...
Click to collapse
well, technically, if we have root, dont have an "ADP" device?
when I do a fresh install, it says welcome to Android Developer Phone 1 (in most ROMs)

the adp device was a specific phone release for developers to be used with the sdk.

jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
I know that, but the hardware is the same as ours (they just get the awesome battery cover)

jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
Most roms especially cyanogen Roms are based on SDK/ADP1 directly and thus making our devices recognizable as ADP Devices.

Simple solution could be to restore the original su binary at boot.
1) keep a copy in the boot image ramdisk
2) scan the path at boot for su
3) compare md5sum with the original
4) delete if md5sum is different
5) restore original trusted su
and also just for paranoia:
6) scan system for setuid binaries and report to the user

This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.

lbcoder said:
This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
Thanks for clearing that up.
The idea posted earlier about recovery menu password should be lofted at Cyanogen (or anyone willing to take that on). Should we make a thread for it?

Keep in mind that it is physically impossible to secure your phone against somebody who gets their hands on the actual device. You can only make it harder to get at it. If somebody wanted to they could just read the flash chip directly or use JTAG to get at it. However, I agree that adb could be made a bit more secure.

And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.

nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how

nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
I have one thing to say to you:
http://en.wikipedia.org/wiki/Setuid
Now that you've made a complete and utter fool of yourself, how do you feel?
FYI: your regular user can NOT chown root. Go ahead and try it.

alapapa said:
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how
Click to expand...
Click to collapse
It is a moot point whether the setuid bit can be restored since a regular user doesn't have the ability to change the owner to anything but self, which means that the best they could do is create an su binary that will give other users THEIR OWN permissions.
A regular user can change ownership *only* to self -- i.e. if they have group or other write permission, then they can chown the file. They can also change the group, but only to groups to which they are members -- and this requires that they already have some form of write permission on the file.
Note that extracting a file is no different than actually *creating* the file, which means that if the user couldn't simply MAKE the file, then they can't *extract* the file either.
If any of this was untrue, there would be nothing to stop any user from doing something like this to take over any Linux computer (except from within a chroot jail, but that doesn't apply here);
cp `which sh` ~/su; chown root:root ~/su; chmod 4755 ~/su
** but that most definitely won't work.

[Hack] remove a lockscreen pin via adb with sqlite3

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

[ROOT] ZTE z990g Merit (An avail variant?)

Root for ZTE z990g aka ZTE Merit
by jcase - [email protected] - http://twitter.com/TeamAndIRC
June 16 2012 - Copyright 2012 CunningLogic
Do Not Distribute or republish without permission. (Sad that this is needed, but people/blogs like to profit off the work of others without credit)
Want to support my work? Donations are always appreciated, but never required:
Paypal: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=LZ62YFU3XCEK8
Amazon Giftcards: [email protected]
Required files:
http://dl.dropbox.com/u/8699733/chainsdd-su.zip
Unzip chaindsdd-su.zip and then get a shell with adb
Code:
adb shell
Set up the dirs, so shell owns them prior to logging. If shell does not own them then we can not control them. If the logs dir already exists, you may have to do a factory reset to remove them. They should not exist unless someone attempted this previously.
Code:
mkdir /data/local/logs
mkdir /data/local/logs/kernel
Open emode's logset activity. First button should be for enabling log set, enable it. Do not exit the activity, but if you do just repeat the below command.
Code:
am start -a android.intent.action.MAIN -n com.zte.emode/.logset
Confirm the log_kernel.txt file exists, if it does not wait a minute and check again.
Code:
ls -l /data/local/logs/kernel/log_kernel.txt
If it exists, delete it and immediately symlink it to /data/local.prop, logset may recreate it, if it does delete and try symlinking again.
Code:
rm /data/local/logs/kernel/log_kernel.txt
ln -s /data/local.prop /data/local/logs/kernel/log_kernel.txt
Now we want to wait for /data/local.prop to be created, it may take a minute or two. Keep checking until it exists.
Code:
ls -l /data/local.prop
Now once /data/local.prop exists, go back to the logset activity and disable logset. If you don't disable it, it will slowly eat away at all the disk space, and possibly overwrite the local.prop before you get root. Now lets set qemu=1 then reboot.
Code:
echo 'ro.kernel.qemu=1' > /data/local.prop
exit
adb reboot
Once you have rebooted, remount, install su.
Code:
adb remount
adb push su /system/xbin/su
adb shell chown 0.0 /system/xbin/su
adb shell chmod 06755 /system/xbin/su
Clean up your mess!
Code:
adb shell rm /data/local.prop
adb shell rm -r /data/local/logs
Reboot, install the Superuser app from the market and enjoy
Code:
adb reboot

Might Not Work As Expected
I just tried this procedure from JCase at the RootzWiki dot com site with mixed results. The phone is a ZTE Merit Z990G from Straight Talk.
I went through all the steps and everything performed as expected. When I start start an app that requires superuser permissions, the app reports that the device has not been properly rooted. I have repeated the process as outlined four times, including downloading the SU file, and have the same results. Titanium Plus, Busy Box Pro and Root Check Basic report that the device is not rooted.
However, a couple of the Google apps - music, movies and reader seem to think the phone is rooted. Any ideas or suggestions will be very appreciated.

bitshifter52 said:
I just tried this procedure from JCase at the RootzWiki dot com site with mixed results. The phone is a ZTE Merit Z990G from Straight Talk.
I went through all the steps and everything performed as expected. When I start start an app that requires superuser permissions, the app reports that the device has not been properly rooted. I have repeated the process as outlined four times, including downloading the SU file, and have the same results. Titanium Plus, Busy Box Pro and Root Check Basic report that the device is not rooted.
However, a couple of the Google apps - music, movies and reader seem to think the phone is rooted. Any ideas or suggestions will be very appreciated.
Click to expand...
Click to collapse
Sounds like band permissions on su, try
adb shell ls -l /system/xbin/su
if the permissions come out as "-rwsr-sr-x" then you are rooted, try updating su with the suepruser app, or finding a different copy of su.
If the permissions are different or it says it doesnt exist, then you need to repeat the instructions as you missed one or two

jcase said:
Sounds like band permissions on su, try
adb shell ls -l /system/xbin/su
if the permissions come out as "-rwsr-sr-x" then you are rooted, try updating su with the suepruser app, or finding a different copy of su.
If the permissions are different or it says it doesnt exist, then you need to repeat the instructions as you missed one or two
Click to expand...
Click to collapse
Thank you for the fast response. Here are the permissions for the SU file and based on what you are saying they look good:
C:\SDK>adb shell ls -l /system/xbin/su
-rwsr-sr-x root root 22364 2012-06-17 12:47 su
I have located and downloaded a couple of "su" files from XDA and similar sites and the files are identical. I will continue searching for a different "su" file and see if that makes a difference.
---------- Post added at 06:15 PM ---------- Previous post was at 05:43 PM ----------
bitshifter52 said:
Thank you for the fast response. Here are the permissions for the SU file and based on what you are saying they look good:
C:\SDK>adb shell ls -l /system/xbin/su
-rwsr-sr-x root root 22364 2012-06-17 12:47 su
I have located and downloaded a couple of "su" files from XDA and similar sites and the files are identical. I will continue searching for a different "su" file and see if that makes a difference.
Click to expand...
Click to collapse
I looked around and did not find any "su" files that were different than what I downloaded according to the root process. Just for grins I copied the "su" file from my Noot Tablet which is rooted and tried that file. Sadly, it did not make a difference.
Please let me know if there is any other information I can provide or if you would like me to try something else.

What happens when you open the Superuser app (note this is not supersu) and go to settings/options and attempt to update su?
bitshifter52 said:
Thank you for the fast response. Here are the permissions for the SU file and based on what you are saying they look good:
C:\SDK>adb shell ls -l /system/xbin/su
-rwsr-sr-x root root 22364 2012-06-17 12:47 su
I have located and downloaded a couple of "su" files from XDA and similar sites and the files are identical. I will continue searching for a different "su" file and see if that makes a difference.
---------- Post added at 06:15 PM ---------- Previous post was at 05:43 PM ----------
I looked around and did not find any "su" files that were different than what I downloaded according to the root process. Just for grins I copied the "su" file from my Noot Tablet which is rooted and tried that file. Sadly, it did not make a difference.
Please let me know if there is any other information I can provide or if you would like me to try something else.
Click to expand...
Click to collapse

It Worked - But Don't Know Why...
jcase said:
What happens when you open the Superuser app (note this is not supersu) and go to settings/options and attempt to update su?
Click to expand...
Click to collapse
I re-installed Superuser and Superuser Elite and now the phone says it's rooted. I've been in IT for over 35 years and it makes me nervous when software "magically" fixes itself. But now that it's working I won't question it and proceed from here. I appreciate your help and your effort.
Cheers

bitshifter52 said:
I re-installed Superuser and Superuser Elite and now the phone says it's rooted. I've been in IT for over 35 years and it makes me nervous when software "magically" fixes itself. But now that it's working I won't question it and proceed from here. I appreciate your help and your effort.
Cheers
Click to expand...
Click to collapse
Generally you have to run superuser once to get it to work I've found, at least recent builds (or maybe its recent android builds)

Problem.
Hello, i have followed this entirely but at parts it says "Access denied" when im on certain parts when i tryed to check if the Kernel log was there it said "access denied" same with some folders.

root or no root
followed steps, ended up with this...
$ ls -l /system/xbin/su
ls -l /system/xbin/su
-rw-rw-rw- root root 22364 2012-07-15 09:25 su
the superuser app shows all blank under apps and logs, when i try to update it, it says "checking" for a few secs and then nothing... also wondering how to do a factory reset cuz if i didn't screw the phone up yet, i will thx in advance

Has you can see I'm new here. I'm old and retired I would love to root my ZTE Merit 2.3.5 but this is over my head.
I was wondering if there's any accomplished phone rooters in the NC area that would be willing to walk me through this or do this for me
I'd be more than willing to make a donation to make this happen,

custom recovery
I was wondering if someone would make q custom recovery for this phone because the stock recovery is really bad

Not working
I can't even get past step 2, I have the file installed and unzipped on both my computer and my smart phone. The only thing I can find to put in the codes is command prompt which says "error: device not found" when I type in adb shell. My ZTE Merit phone has very low internal memory due to all the retarded system apps that came on the phone, I would very much like some assistance removing them from my phone. I also downloaded superuser elite onto my phone and it doesn't show up with ANYTHING. The first page says
superuse v3.1.3(46)
tap to display changelog
elite installed
su binary not found
a check in the box "outdated binary notification
unchecked box, temp unroot (When tapped it does nothing)
unchecked box ota survival (Again when tapped it does nothing)
I scroll over to the apps section of the program and it says "No apps in list"
What am I doing wrong? This lack of space is quite irritating

Worked!
omg I've wanted to root my phone. Thank you thank you! I thought I would brick my phone at first.

SIM Carrier unlock a ZTE Merit Z990G Straight Talk
I'm currently a T mobile prepaid customer and received the Merit from a friend of mine for doing some painting. I have looked for a month now and had a few unlock websites fail at attempting to unlock the phone via the IMEI (which the phone does have ). I have attempted to put my tmobile sim in the Merit but there is NO place to enter an unlock code. I really DONT wanna change my service to straight talk and would be willing to pay a decent amount to anyone that is capable of unlocking this phone for use with tmobile. If you think you have what it takes PM me and i will give you the IMEI and we can work out a deal. I challenge ANYONE achieve the impossible and get me the unlock code and a way to input it into the phone.

Cannot get local.prop
I have waited 20 minutes after trying to create the local.prop file and it simply won't create it. Any suggestions?

Can't get SU to upload
Hey I'm new to rooting android. I get to the point of installing SU but windows keeps telling me file not found. Would really like some help in fixing this issue. I have installed SU file to C:\Android\android-sdk\SU. Up to this point everything works fine.
adb push su /system/xbin/su
adb shell chown 0.0 /system/xbin/su
adb shell chmod 06755 /system/xbin/su
Any help would be really appreciated.
Thnks

Help getting Started
Hey Anyone and everyone that may be online, I have a real quick and probably REALLY EASY question for ya... I'm trying to get started Rooting my ZTE Merit and I need to find out how to get to or where to find the screen where I type in the commands. I already downloaded the chainsdd zip file. So now I'm supposed to get shell with adb. If someone would be so kind and put me in the right general direction, I sure would
be grateful.
Thanks in advance,
Jason

Not a Damn thing...
Rather sad....I have everything going as it should....all input correct...still no root after final reboot...I followed every step to a T several times -rw-rw-rw- grrr...ive rooted many devices none this big of a pain in tha butt!
Used updated su binary on root just for fun...same result

Help plz!
im a noob to this but have been messing around with ubuntu for some time now can someone show me step by step on how to root my zte merit plz? is there a video tut on how? i tried all the quick methods but they don't work, this one obviously does on this page, can someone help start me out plz, im learning still and love to learn more!
---------- Post added at 08:59 AM ---------- Previous post was at 08:45 AM ----------
Univarseman said:
I can't even get past step 2, I have the file installed and unzipped on both my computer and my smart phone. The only thing I can find to put in the codes is command prompt which says "error: device not found" when I type in adb shell. My ZTE Merit phone has very low internal memory due to all the retarded system apps that came on the phone, I would very much like some assistance removing them from my phone. I also downloaded superuser elite onto my phone and it doesn't show up with ANYTHING. The first page says
superuse v3.1.3(46)
tap to display changelog
elite installed
su binary not found
a check in the box "outdated binary notification
unchecked box, temp unroot (When tapped it does nothing)
unchecked box ota survival (Again when tapped it does nothing)
I scroll over to the apps section of the program and it says "No apps in list"
What am I doing wrong? This lack of space is quite irritating
Click to expand...
Click to collapse
help me, whats the first step then i can get the gearz in motion, i have not a clue on how to start this but if i do i can usually figure it out from them sometimes

Start menu
jjflappy said:
Hey Anyone and everyone that may be online, I have a real quick and probably REALLY EASY question for ya... I'm trying to get started Rooting my ZTE Merit and I need to find out how to get to or where to find the screen where I type in the commands. I already downloaded the chainsdd zip file. So now I'm supposed to get shell with adb. If someone would be so kind and put me in the right general direction, I sure would
be grateful.
Thanks in advance,
Jason
Click to expand...
Click to collapse
Start menu then type CMD hit enter

[ROOT][SamPWND][N960U][WIP-Combo Needed]

Hello XDA!
Samsung has been semi SamPWND again!
Disclaimer:
This root method was developed and tested on the N960U model. This is the only model I have that is a Samsung device. I do have friends and other devs however that have tested this method on various other Samsung devices on both Qualcomm and Exynos chipsets and it has worked on a good number of them meaning this method is not limited to the Note 9. With that being said, due to all the time I have already spent on this and not having any other devices, I will ONLY be supporting the N960U. So do not get upset if I do not respond to you if you have a Samsung A8934839K312 on 7.1 Android (aka a device I have never even heard of before.)
Disclaimer 2:
This root method is mainly for dev's or those who like to tinker and figure things out. The reason I say this is because at this time, you are REQUIRED to be on a factory/combination firmware to mess with the root method. I will ignore any comments/questions for people who do not read this disclaimer and ask me how to root stock etc. as that is what I have been trying to do for over a month now. If you need your phone for work or a daily then I suggest only messing with this root method if you have a lot of spare time since it involves flashing combo firmware at which mobile services and other stuff will not be functional. You have been warned!
Disclaimer 3:
This thread/poc are essentially to get you the ability to use root apps and have a root shell, that is it. If I have time and see some questions that are legit questions I will try to provide help in a timely manner. This POC simply pushes busybox binary from Magisk.zip and SuperSU (the last version chains released before retirement) and installs it in sbin/daemon mode. There is also a way to install MagiskSU in daemon mode as well as ways to install root to /system/xbin for example and do mods such as Xposed that typically need to modify the system partition but that is not the purpose of this thread and these methods are a bit more involved (require modifying the root script as well as setting up bind mounts and other stuff.) Hopefully once this is released and some devs chime in I hope there will eventually be others contributing with various root scripts, install methods etc. and of course HOPEFULLY find a way to write to system/odm/vendor partitions so we can eventually run root on stock!
Disclaimer 4:
I am NOT responsible if you break your phone, wipe your IMEI, hard brick etc. etc.! Also, I spent months to get to this point and already had someone steal my files from AFH (I know, my fault for not hiding them) so please do not take my work as your own. If you want to use it in any way/shape/form just ask for permission and/or give credits in your thread is all I ask! If you are however using someone else's modified files and in here trying to get help I might turn you away (back to the person who provided the modified files) just an FYI!
I think that is enough disclaimers for now!
Note: This thread will most likely be ugly for a bit as I am terrible with making these things look pretty... Hopefully as time goes I will keep improving it or find someone who is trustworthy I can make a "contributor" so they can fix it up for me haha.
Now, Let's Get To It!
Technical Details:
This is sort of a spawn from an exploit I found and reported to Samsung back on the Tab S3 that I never released on XDA. That method (long story short) involved modifying the Persist partition and flashing it in ODIN as ODIN did not check it for integrity. Of course it was patched by Samsung who gave me some $$$ and gave me a shout out on their security bulletin which was pretty cool!
This method is similar to "Persist Root" except we are not flashing any modified partitions in ODIN. Instead, on many Samsung combination firmwares there is an init rc script on /system. If you want to know if your device is compatible a good starting point would be to look for a file called "init.lab.rc" which is typically located at "/system/etc/init/init.lab.rc" like so:
-rw-r--r-- 1 root root ubject_r:system_file:s0 14784 2008-12-31 10:00 init.lab.rc
As it stands, we cannot edit this script. I noticed something cool however when I was reading it one day. Specifically one thing that caught my eye was this:
chmod 777 /data/lab/run_lab_app.sh
There are MANY files and scripts at /data/lab. Luckily, the init.lab.rc sets permissions to "0777" and sets ownership to system on the entire /data/lab directory! If you are still with me, this means all the contents of this directory are world readable/writeable and we can modify any of the files in this DIR without elevated privileges!
Now I am showing the "run_lab_app.sh" script specifically for a reason. We know we can modify any scripts on /data/lab, but how can we execute it with elevates privileges? Going back to the init.lab.rc, if you scroll to the bottom of the rc file you will see this:
service start_abc /system/bin/sh /data/lab/run_lab_app.sh factory abc+
user system
group system
disabled
oneshot
on property:sec.lab.abc.start=1
start start_abc
setprop sec.lab.abc.start 0
Now what that means is, when you set the property "sec.lab.abc.start" to "1" it executes the abc service as system user and more specifically it will start by executing the "run_lab_app.sh" script! Therefore, after you modify the script to your liking, push it to /data/lab/run_lab_app.sh, then do a "setprop sec.lab.abc.start 1" your script will be executed as system user!
Now system obviously is not "root". Now that we can execute as system user we have more attack vectors to elevate privileges even more. Ideally, I remembered how I rooted the Tab S3 about a year ago using Persist partition. As it stands, we are not able to read/write on persist. If we were to set permissions however on /persist using the run_lab_app.sh script, then we can gain access to it! Therefore, one would only need to add this command to the run_lab_app.sh script and execute it using the setprop command:
chmod -R 0777 /persist
As soon as you modify the script, push it and execute the setprop command, it will change permissions on the /persist DIR to be world readable/writeable!
Now, the reason why I like to use Persist, there is a script that is executed by INIT on every reboot automatically (this means it is executed by root!) The script in question is this one "/persist/coresight/qdss.agent.sh." (I am not sure if this script itself is a Qualcomm specific script or not.) Modifying this script has no ill effects on anything from what I have seen.
Now to see how the script is executed you can look in "/vendor/etc/init/hw/init.qcom.test.rc" and you will see some interesting stuff including this:
crownqltesq:/vendor/etc/init/hw # cat init.qcom.test.rc | grep persist
service cs-early-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh early-boot /vendor/bin/init.qcom.debug.sh
service cs-post-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh post-boot /vendor/bin/init.qcom.debug.sh
write /persist/coresight/enable 1
write /persist/coresight/enable 0
crownqltesq:/vendor/etc/init/hw #
As I stated earlier, due to this init script, the qdss.agent.sh script is executed by init context/root user automatically during early boot and post boot. This means once you get everything set up, you won't need to keep reinstalling root (unless you mess something up) on each reboot. This is ideal since we don't have a way yet to modify system/vendor/odm partitions yet. Think of it as a "systemless" root.
For the POC I have provided in this thread for example, it contains the bare minimum SU files. The files in the attached zip are simple: SamPWND.bat, sampwnd1.sh, sampwnd2.sh, /sampwnd which contains su, sukernel, supolicy, libsupol.so and busybox. The way it works is this:
1) You double click the .bat file and it should do everything for you! The .bat file will:
- Push sampwnd1.sh to /data/lab/run_lab_app.sh
- Execute the lab script by doing "setprop sec.lab.abc.start 1"
- Push sampwnd2.sh to /persist/coresight/qdss.agent.sh
- Push root files in "sampwnd" folder to /persist/coresight/sampwnd
- Set permissions on the files we just pushed to Persist to 0777
- Reboot the device (Note: The .bat file reboots the device at this point since everything is in place to root when the device reboots, it's that simple!)
After the device reboots, you should now be able to use a root shell as well as sideloading any root apps will work (apps such as TiBu, Root Explorer, Flashfire etc. etc.)
When the device reboots, the qdss.agent.sh script does the following automatically:
1) Mounts rootfs and sets permissions to 0777 so we can access /sbin
2) Pushes the contents of the root files folder "sampwnd" to /sbin
3) Sets permissions to the files we just moved to /sbin
4) Exports the LIB path to /sbin due to the libsupol.so being needed to patch the sepolicy with supolicy
- The export command is "export LD_LIBRARY_PATH=/sbin"
- Once the script is over and you use another app or go into a shell etc. the LIB path will be gone/reset so you don't need to
worry.
5) Patches the sepolicy for SU
6) Installs SU by executing "su --install"
7) Executes the SU daemon by running "su --daemon"
8) Lastly, remounts rootfs back to RO.
As stated earlier, these commands are all automatically executed by init/root each time you reboot the device. Essentially, whatever we put into the qdss.agent.sh script will be executed on boot by init/root. If for some reason permissions are lost, we should still have our lab script and we would only need to run "setprop sec.lab.abc.start 1" to change permissions on persist again!
The initial files I provide today are just a simple root install script. I have successfully used the root script to install MagiskSU, Xposed (using bind mounts to overlay on /system) and other tests. I also at one point made a backup script that backed up all the partitions on the device into a folder which I extracted to my PC for safe keeping, you get the picture! Once you have root however, you can do these things easier as you will have root access.
Now that you know the workings of the exploit (err exploits?) I will explain briefly what is needed and how to test it.
Pre-requisites:
1) Download links will be in 2nd post.
2) For the purpose of this thread and the only device I personally have, you should have a N960U/U1/W on a rev1 bootloader (there isn't a rev2 BL yet so most should be good to go.)
3) A vulnerable Combo Firmware. I linked the one I use in Post 2. I use 1ARG4 Factory/Combo firmware. Of course you will need ODIN to flash the combo.
4) The root files/7z linked in post 2.
5) Stock firmware for when you are done playing, testing, etc. etc.
6) Almost forgot, you will need ADB. I will not go into details on this, if you don't have a working ADB Google is your friend. I recommend setting it to your path so you can use ADB from anywhere on the PC.
Install Instructions:
1) Extract the root files 7z into a DIR of your choice.
2) Flash whichever vulnerable combo firmware you are using via ODIN.
3) Once it boots up, make sure your device is seen by adb by running "adb devices"
4) Double click the .bat file.
5) That's it! Your device will reboot and you should be rooted!
If for some reason it is not working and you are on a N960U/U1/W, there could be a number of reasons. If you are not using the 1ARG4 combo I linked then it's possible the combo you are using is not vulnerable. It could also be an issue with ADB. Sometimes if things get crazy throughout your testing you might need to reflash /persist in ODIN or reflash the combo firmware in ODIN then re-run the .bat file (I only experience this typically when I get crazy with the root script and end up losing permissions to everything or something I added in the root script is causing the device to boot-loop etc. etc.)
Now donations are not required but feel free to throw me some beer money if you want! My paypal email/link is in a few places, you shouldn't have any trouble finding it!
TELEGRAM GROUP IS COMING REAL SOON!
We will use the TGRAM to provide support, ideas, share scripts/files and HOPEFULLY, we can all figure out together how to turn this into rooting the stock firmware as this is the goal and will be the primary focus of the chat!
Credits:
@samsung - for letting us PWND them time and time again!
@chainfire - SuperSU of course
@topjohnwu - MagiskSU of course
@me2151 - For all the time and help he is going to be putting in with us! Such a great guy! lol
@jrkruse - For everything! Everything from EDL support, ROM support, Root support you name it!
@partcyborg - For also spending countless hours helping answer questions in here so I don't have to hahah
@mweinbach - He writes great articles for XDA! He is a good kid who gets his hands on cool things frequently
@"mysecretfriendfromfaraway - I will not name him haha, he knows who he is. He always helps out and gets great things!
XDA:DevDB Information
SamPWND N960U Root, Tool/Utility for the Samsung Galaxy Note 9
Contributors
elliwigy
Version Information
Status: Testing
Created 2019-05-05
Last Updated 2019-05-05

Database Info

welcome