I have heard that disabling it can make Oreo ROMs faster. Also, can someone help me with screenshots of using those commands on a computer?? I don't know if I'm doing it right.
Basically, tell me everything bout it.
Regards
@m00nlighter can help, he seems to know bout thjs
Dude, just wait for the Pie ROMs to become mature.
Oreo ROMs for Titan were simply not on par with Nougat ones, and a debloated stock Marshmallow ROM with ZRAM disabled will beat both Nougat and Oreo ROMs in terms of performance and stability.
So for now it's either stock or Pie, Oreo is history.
But I want to use Oreo, they ain't that bad for me. Could you please help me??
Detailed instructions are below. Please don't ask for further explanations, this is as simple as I can make it.
It's somewhat complicated and requires adb access and root permissions, so you have to be rooted.
Moreover, you have to have some free space on /system partition (I'd say around 300 megabytes) because ALL packages (apps) will be recompiled, including system apps. As for the data partition, it is hard to tell, depends on what apps you have. I recommend starting with minimum required apps.
First, disable the JIT compiler
adb root
adb shell stop
adb shell setprop dalvik.vm.usejit false
adb shell start
Click to expand...
Click to collapse
Second, clear profile data and remove compiled code for all packages
adb root
adb shell cmd package compile --reset -a
Click to expand...
Click to collapse
Third, force compile all packages using "speed" compiler profile (AOT-compiles all methods in app code)
adb root
adb shell cmd package compile -m speed -f -a
Click to expand...
Click to collapse
And finally, add/edit the following two properties to system.prop:
dalvik.vm.usejit=false
Click to expand...
Click to collapse
This will permanently disable the JIT compiler.
pm.dexopt.install=everything
Click to expand...
Click to collapse
This will force AOT compilation for apps, including updates and new installs.
After that, reboot and enjoy your FAST Oreo ROM
Why JIT compiler should be disabled on old devices like Titan?
Read the excellent post by Farhan on Stack Overflow here:
https://stackoverflow.com/questions/40336455/difference-between-aot-and-jit-compiler-android#
Where did I get this info from?
Official Android docs. See
https://source.android.com/devices/tech/dalvik/configure
and
https://source.android.com/devices/tech/dalvik/jit-compiler
m00nlighter said:
Detailed instructions are below. Please don't ask for further explanations, this is as simple as I can make it.
It's somewhat complicated and requires adb access and root permissions, so you have to be rooted.
Moreover, you have to have some free space on /system partition (I'd say around 300 megabytes) because ALL packages (apps) will be recompiled, including system apps. As for the data partition, it is hard to tell, depends on what apps you have. I recommend starting with minimum required apps.
First, disable the JIT compiler
Second, clear profile data and remove compiled code for all packages
Third, force compile all packages using "speed" compiler profile (AOT-compiles all methods in app code)
And finally, add/edit the following two properties to system.prop:
This will permanently disable the JIT compiler.
This will force AOT compilation for apps, including updates and new installs.
After that, reboot and enjoy your FAST Oreo ROM
Why JIT compiler should be disabled on old devices like Titan?
Read the excellent post by Farhan on Stack Overflow here:
https://stackoverflow.com/questions/40336455/difference-between-aot-and-jit-compiler-android#
Where did I get this info from?
Official Android docs. See
https://source.android.com/devices/tech/dalvik/configure
and
https://source.android.com/devices/tech/dalvik/jit-compiler
Click to expand...
Click to collapse
Dude, one last question. What is the output of cmd after you type :
adb shell stop
CMKdaGreatest said:
Dude, one last question. What is the output of cmd after you type :
adb shell stop
Click to expand...
Click to collapse
There should be NO output. This command effectively stops the shell.
@m00nlighter
This is the result I'm getting. Please tell me if it is what it is supposed to be
Please answer my question, pleaseeee
If you can't see the pic,
The output to adb shell stop is something like this
"stop:must be root"
Am i doing something wrong?
CMKdaGreatest said:
@m00nlighter
This is the result I'm getting. Please tell me if it is what it is supposed to be
Please answer my question, pleaseeee
If you can't see the pic,
The output to adb shell stop is something like this
"stop:must be root"
Am i doing something wrong?
Click to expand...
Click to collapse
Yes you are doing something wrong. Please go learn how to work with adb, enough info is available, just google it.
Unfortunately I'm not able to work with adb very well. adb root command is failing I think, so adb shell stop is also failing.
Someone help me please @m00nlighter @sapo_joe @Oshmar @thedeadfish59
I use magisk as su. Is that a problem for this?
Related
This little gem of a phone is a tough little thing to custom install apps on, but that didn't stop the Coburn from being able to get busybox installed.
Therefore, introducing Busybox for your HTC Click/Tattoo!
FOLLOW THIS TUTORIAL CAREFULLY. This guide may brick or NOT brick your Tattoo (most likely the latter), however I cannot assure you that it's 100% fail proof. I have installed it successfully. IN OTHER WORDS: THIS IS NOT FOR THE FAINT HEARTED! IF YOU DO NOT KNOW WHAT 'FLASH','ADB' OR 'HACK' MEANS, PLEASE DO NOT CONTINUE.
Requirements:
1 HTC Tattoo (The Victim)
1 MS Windows Powered Computer (I used Win7 64Bit)
1 HTC Tattoo -> USB Cable (Included with phone... Well, it was in the box).
Download the package attached to this post. Extract all files to a directory like C:\BUSYCLICK . (Actually, please extract them there).
Installation
Connect your Tattoo to your phone, make sure USB Debugging is enabled (Settings -> Applications -> Development) and sit back. Windows should say "New Hardware! OMG!" and ask "What is this piece of tech?" (aka New Hardware Install Wizard). On XP, allow to search Windows Update. On Vista/7, I'm going to have to get back to you on that. The installed driver will be like "HTC Dream blah blah blah ADB Interface" or something. Odd why it says it's a HTC Dream...
Anyway, go to the folder where you extracted the files, and run the Installation.bat file. It's the one that says "Installation" With the cogs icon.
You'll get a DOS Prompt and some text, PAY ATTENTION! My installer will hold your hand and explain what's happening. Should any errors occur, you may be out of space on your Tattoo's internal memory or something. If you do get errors, please post them here! I'll try to fix them for you guys and girls.
Post-install tasks
When complete, run the TestBusybox.bat script in the same folder where you extracted the BusyBox files, and you should get some output. If not, busybox failed to install... Let me know what the error is and I'll try to fix it.
Notes:
You can use the busybox commands in /data/local/bin from "adb shell" or a terminal emulator on the phone itself... /data/local/bin/sh DOES NOT work from adb shell, I don't know why. It will work using a terminal emulator. Try "/data/local/bin/free" and such for some memory read outs, etc, etc.
Feel free to love/like/hate/kill/shoot my work, you can expect to see ROMs and the like in the near future as I love hacking devices.
Cheers,
Coburn64
Ok busybox installed normally...
Do i have root acces with busybox now? I dont see su...
C:\Busybox>adb shell /data/local/busybox ls /data
ls: can't open '/data': Permission denied
I do see /data/local and under tho... including ../bin and ../rights but dont see any use of it...
Coburn Hi, this is a step closer to being root
can be root in busybox?
chmod command does?
thx
Code:
benno.id.au/blog/2007/11/14/android-busybox
chmod command is useless without su...If only su worked
Installed and worked fine, can run busybox but:
it runs with shell privileges
setting setuid bit doesn't solve, because I can chown to root
Do I miss something?
Thanks Really appreciate your work!
Do you have to install the new RUU Click HTC WWE 1.63.405.1 WWE test signed NoDriver first?
coolbits said:
Code:
benno.id.au/blog/2007/11/14/android-busybox
chmod command is useless without su...If only su worked
Click to expand...
Click to collapse
I know friend!
I asked the chmod without adb, or if they could use the chmod as root from the busibox console
leon1984 said:
I know friend!
I asked the chmod without adb, or if they could use the chmod as root from the busibox console
Click to expand...
Click to collapse
All this does is allows you to run more commands from the shell in Android, whereas the standard shell doesn't have many commands built-in. Could be used in conjuction with a root hack.
One step more, but nothing to do with root
I'm starting to believe that Click will never have a root method working because its underused compared with other android devices
MiSSigNNo said:
One step more, but nothing to do with root
I'm starting to believe that Click will never have a root method working because its underused compared with other android devices
Click to expand...
Click to collapse
The next Linux kernel root vulnerability (which works on the Tattoo) should bring us root, as well as other Android devices such as the Eris.
coolbho3000 said:
The next Linux kernel root vulnerability (which works on the Tattoo) should bring us root, as well as other Android devices such as the Eris.
Click to expand...
Click to collapse
What's the new root vulnerability? Is it something that was just discovered?
coolbho3000 said:
The next Linux kernel root vulnerability (which works on the Tattoo) should bring us root, as well as other Android devices such as the Eris.
Click to expand...
Click to collapse
Ok, where to find more info about this? :S
coolbho3000 said:
The next Linux kernel root vulnerability (which works on the Tattoo) should bring us root, as well as other Android devices such as the Eris.
Click to expand...
Click to collapse
I was able to install Busybox on my phone successfully. But the problem is I don't know what it's for. Would anyone be kind enough to post a link or a tutorial for this? Thanks.
sheik_yerbouti said:
I was able to install Busybox on my phone successfully. But the problem is I don't know what it's for. Would anyone be kind enough to post a link or a tutorial for this? Thanks.
Click to expand...
Click to collapse
Busybox just allows you to use more features at the adb shell command line. So, yeah. Heh.
You lost me at 'adb shell command line'. Is that some command line provided by the Android SDK?
sheik_yerbouti said:
You lost me at 'adb shell command line'. Is that some command line provided by the Android SDK?
Click to expand...
Click to collapse
Sorry if I lost you. Let me sum it up: It's a 'feature pack' for Android Developers, which could be used in conjunction with rooting tools.
Coburn64 said:
What's the new root vulnerability? Is it something that was just discovered?
Click to expand...
Click to collapse
zenthought.org/content/file/android-root-2009-08-16-source
This is linked in the other thread...
ivendor said:
zenthought.org/content/file/android-root-2009-08-16-source
This is linked in the other thread...
Click to expand...
Click to collapse
That code is old, and apparently won't work. It won't compile either, Paul from Modaco tried it and it just spat the dummy and gave a make error.
Coburn64 said:
That code is old, and apparently won't work. It won't compile either, Paul from Modaco tried it and it just spat the dummy and gave a make error.
Click to expand...
Click to collapse
That's the code for the old asroot exploit (used in the Hero IIRC). It's been patched in August/09 so it won't affect the kernel in stock Tattoos.
Yeah, that's what I was getting at - the exploit is too old.
We need to either:
1) Get a S-OFF bootloader
2) Find another working root exploit
3) Dig around in the test ROM and extract the SU binary out of that sucker and put it in /data/local on the working ROM.
I think I can do the latter.
First of all, Linux and OS X come with sqlite3 by default. Windows users will need to download the executable. With that said, here is how you can enable sideloading the old-fashioned way.
Code:
[[email protected] ~]$ adb shell
$ su
# busybox cp /data/data/com.android.providers.settings/databases/settings.db /data/data/com.android.providers.settings/databases/settings.db.bak
# chown system.system /data/data/com.android.providers.settings/databases/settings.db
# ls -l /data/data/com.android.providers.settings/databases/settings.db*
# busybox cp /data/data/com.android.providers.settings/databases/settings.db /sdcard
# exit
$ exit
[[email protected] ~]$ adb pull /sdcard/settings.db
sqlite3 settings.db
sqlite> SELECT * FROM secure WHERE name="install_non_market_apps";
3|install_non_market_apps|0
sqlite> UPDATE secure SET value=1 WHERE name="install_non_market_apps";
sqlite> SELECT * FROM secure WHERE name="install_non_market_apps";
3|install_non_market_apps|1
sqlite> .quit
[[email protected] ~]$ adb push settings.db /sdcard/
[[email protected] ~]$ adb shell
$ su
# busybox cp /sdcard/settings.db /data/data/com.android.providers.settings/databases/settings.db
# chown system.system /data/data/com.android.providers.settings/databases/settings.db
# ls -l /data/data/com.android.providers.settings/databases/settings.db*
# exit
$ exit
[[email protected] ~]$ adb reboot
You should be all set.
thank god for super one click
Script?
Sent from my MB860 using XDA Premium App
lsxrx7 said:
thank god for super one click
Click to expand...
Click to collapse
1) Great if you use Wind'oh!s which I refuse to do.
2) I like to know how things work.
I think this work on only rooted devices. If that case we have one already which will root it and also side load apps.
You got the phone gdanko?! Cool
I'll do it this way for kicks when I get my phone lol
gdanko said:
1) Great if you use Wind'oh!s which I refuse to do.
2) I like to know how things work.
Click to expand...
Click to collapse
Yes, it's always great to know how things work.
But it looks like SuperOneClick is not just confined to Windows.
It is compatible with:
Windows Vista
Windows 7
Ubuntu Hardy (8.04 LTS)
Ubuntu Jaunty (9.04)
Ubuntu Karmic (9.10)
Ubuntu Lucid (10.04 LTS)
Ubuntu Maverick (10.10)
Debian Lenny (5.0)
Debian Squeeze (testing)
Debian Sid (unstable)
Debian Experimental
SuperOneClick uses Mono on Linux platforms, so most any of the modern ones should work. I used it on my openSUSE box and it worked just fine for allowing non-market installs.
Can anyone do this a little more nood friendly? And/or does this require root?
phro321 said:
Can anyone do this a little more nood friendly? And/or does this require root?
Click to expand...
Click to collapse
Yeah, you basically want to get out of this thread and head here:
http://forum.xda-developers.com/showthread.php?t=960336
Follow briefmobile's tutorial. And yes, it requires root.
If I am not mistaken gdanko doesnt use any of those operating systems. He uses a mac...
Maybe his old school ways will help uncover some mysterious portal into the Atrix that will allow cracking the bootloader...
I just finished running superoneclick. I wanted to double check that my phone is now allowing unknown sources, but i dont see the checkbox where it should be. Is this normal? Thanks!
__redfox__ said:
I just finished running superoneclick. I wanted to double check that my phone is now allowing unknown sources, but i dont see the checkbox where it should be. Is this normal? Thanks!
Click to expand...
Click to collapse
I guess the check box is not added, but superoneclick did do its job. The phone is communicating with the laptop as expected.
__redfox__ said:
I guess the check box is not added, but superoneclick did do its job. The phone is communicating with the laptop as expected.
Click to expand...
Click to collapse
Follow this to add the check box: http://forum.xda-developers.com/showthread.php?t=972760
agentdr8 said:
SuperOneClick uses Mono on Linux platforms, so most any of the modern ones should work. I used it on my openSUSE box and it worked just fine for allowing non-market installs.
Click to expand...
Click to collapse
Fails on Ubuntu 64. And installing mono and a host of other things for something so trivial is pointless.
Thank you, I needed this sideloading hack since I've already updated/rooted my phone and couldn't use Gladatrix or aRoot without having to reflash 1.26
------------
edit: Actually it got my phone stuck in bootloader with my configuration (1.57 update and rooted). SBF flashing now..
marlasinger said:
Thank you, I needed this sideloading hack since I've already updated/rooted my phone and couldn't use Gladatrix or aRoot without having to reflash 1.26
------------
edit: Actually it got my phone stuck in bootloader with my configuration (1.57 update and rooted). SBF flashing now..
Click to expand...
Click to collapse
Hey How did you root your 1.57?
Spoofy said:
Hey How did you root your 1.57?
Click to expand...
Click to collapse
Go to the GladRoot thread linked in my signature below. Please use the search function in the future.
Ririal said:
Go to the GladRoot thread linked in my signature below. Please use the search function in the future.
Click to expand...
Click to collapse
Lose the attitude buddy.
Don't tell me to search, as I have been googling and searching this forum for over a week and found nothing but SuperOneClick which also required me to downgrade.
I probably missed it due to "Last edited by Ririal; 23rd April 2011 at 01:40 AM. Reason: Updates"
Unfortunately this is still not what I am looking for as I am on 1.57 and am still required to downgrade.
Please have some respect.
EDIT: I'ts also not in the sticky thread
EDIT #2: I just found [HOWTO] Easy Root 1.5.7 using GingerBreak which popped up on the 23rd. WOHOOO, no need to downgrade and risk Wifi issues.
Spoofy said:
Lose the attitude buddy.
Don't tell me to search, as I have been googling and searching this forum for over a week and found nothing but SuperOneClick which also required me to downgrade.
I probably missed it due to "Last edited by Ririal; 23rd April 2011 at 01:40 AM. Reason: Updates"
Unfortunately this is still not what I am looking for as I am on 1.57 and am still required to downgrade.
Please have some respect.
EDIT: I'ts also not in the sticky thread
Click to expand...
Click to collapse
It has nothing to do with respect, and I don't have an attitude. Relax, guy.
All the information is readily available, all you need to do is look for it. There's several threads on the first page of the development forum (which you found as you're posting in it) that contain the information you need. One of the threads is even clearly labeled: "[HOWTO] Easy Root 1.5.7 using GingerBreak"
So sorry, I get a little short with people who ask questions that are already answered. Don't take it personally. Here's the breakdown:
There's currently 2 methods of root, one is GladRoot, which requires you to downgrade first. The other is GingerBreak, which formats your phone data. Pick your poison.
Another S-Off script that was sent to me by coremark. Successfully s-off my device and supercid.
http://firewater-soff.com/
Thanks to @coremark.
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
edorner said:
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
Click to expand...
Click to collapse
I'm afraid you'll need a custom recovery for this. The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this. To work around it, you'd need a custom kernel (which is not feasible at the moment since HTC haven't released the full source tree yet, unfortunately) or the wp-mod hack (which I would be afraid of using, to be honest).
Also, why avoid custom recovery when you're already S-OFF and you can flash the stock recovey anytime?
koniiiik said:
The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this.
Click to expand...
Click to collapse
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
edorner said:
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Click to expand...
Click to collapse
To be honest, no idea. All I do know is that on my phone the write protection works the way it does and I don't really see a feasible way around it. Also, I haven't tried these exact steps. It's possible that adb remount does some extra work or something. Moreover, I'm not sure about the adb shell chmod ... command – that would require root, wouldn't it? But since I haven't tried it, I can only guess.
If you don't mind trying it, I'd be interested in the results.
edorner said:
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
Click to expand...
Click to collapse
The way I understand wp_mod works is that it monkey-patches the running kernel's filesystem driver to skip the check for the /system partition. In other words, it rewrites the code of the running kernel in-memory. This by itself is reason enough to be extremely careful around such code as it has potential for a major disaster. Missing the right memory location by any nonzero number of bytes can result in the kernel doing practically anything (most likely a crash).
Now, to make matters worse, these seem to be only a few binary versions of the kernel module and people seem to just take a binary compiled for one kernel, modify the version information within the file to make it match other kernels and load it on a completely different kernel. This, to me, is borderline insane, considering that the kernel binaries depend on the version of the kernel, used compiler and even compiler flags used when building.
Again, though, I haven't actually looked at the module's source code; can't say I'm suffering from a surplus of free time and I'm also not *that* interested in it. Most likely it's written in a robust enough way to have a high chance of success. (This seems to be backed up by anecdotal evidence – the thing appears to work for people, which is a small wonder for me.) All of the above is actually just my interpretation of stuff I read in some threads here on XDA-developers and I haven't even tried to confirm it myself.
Still, for me, using the recovery for any such changes is a sufficient and acceptable workaround, since I don't need to modify /system that often.
Wow! Thanks for the exhaustive expanation about WP-mod!
If you don't mind trying it, I'd be interested in the results.
Click to expand...
Click to collapse
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
edorner said:
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
Click to expand...
Click to collapse
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
Ah, I see. In that case I will definitely try it!
Truth is I am still an Android noob, I used ADB maybe on two occasions so far, and did not have the time yet to properly check out the documentation for these particular commands.
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
edorner said:
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
Click to expand...
Click to collapse
No idea, I haven't used firewater, but my guess would be that it won't wipe anything…
As for backing up /data/preload, you can for example use temproot to get access to the directory, copy it somewhere on your sdcard and adb pull it. In case it gets wiped, you can just push it back again and voilà. It's going to require some shell-fu, however.
Alternately, you can just download my ZIP of the latest stock ROM and extract it, it contains the latest /data/preload.
And yes, just copying the APK files into /data/preload should suffice *– Dalvik and its package manager is intelligent enough to detect something has changed in there and perform any installation steps necessary. If it doesn't work right away, a reboot should fix things.
Edorner. It won't wipe. I tried it already.
Sent from my GT-I9305 using XDA Premium 4 mobile app
koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
edorner said:
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
Click to expand...
Click to collapse
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
koniiiik said:
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
Click to expand...
Click to collapse
Thanks
Hm... Strange...
Instead of manually remounting /system as "ro", I simply rebooted the device. (What can I say, I am hopelessly lazy ) After the reboot I checked the permissions of /system by issuing the "mount" command without any parameters. It showed that it was remounted using the original settings:
Code:
/dev/block/mmcblk0p38 /system ext4 ro,noatime,data=ordered 0 0
So in theory, rebooting instead of manually remounting as "ro" should not make any difference. But who knows
After the reboot, I checked the changes I made to /system previously, and fortunately they did not disappear. (su was still there, I could successfully copy it, and execute it.)
Since then, I've performed a couple more reboots and at least one full shutdown-startup cycle as well. And I still have not lost any changes.
Please let me know if you find something out! I am very interested.
I've done a fair amount of research and am still having trouble getting this installed on an emulated device. I have tried the base adt-sdk images for 4.1.2, 4.3 and 4.4.2 none of which I was able to attain the same "rooted" functionality as a phyical device. Most of the threads I read were a lot like this: http://forum.xda-developers.com/showthread.php?t=1731095
Xposed always gives me the following error: "Failed to get root access. Make sure your device is root properly and you have not blocked shell commands."
When I
Code:
adb shell
into the device I have [email protected], so I have access to root. The su binary is in both /system/bin and /system/xbin. I have also tried remounting the /system partition as rw, but nothing seems to help.
I'm not sold on any particualr version of android as long as it is >=4.1.2. I know some SELinux stuff came in at 4.3.
Any help you could offer would be great,
Thanks!
It worked flawlessly for me using Genymotion. I'm guessing you're using the normal Android emulator - apps won't get root on that directly and I'm not familiar with it.
You could, however, manually replace the necessary files. I'd recommend changing the installation mode to "Recovery" then checking the flashable ZIP's updater-script and basically replicate it from the shell (the updater-script is a shell script).
GermainZ said:
It worked flawlessly for me using Genymotion. I'm guessing you're using the normal Android emulator - apps won't get root on that directly and I'm not familiar with it.
You could, however, manually replace the necessary files. I'd recommend changing the installation mode to "Recovery" then checking the flashable ZIP's updater-script and basically replicate it from the shell (the updater-script is a shell script).
Click to expand...
Click to collapse
Where does it drop the script?
Blackdragon1400 said:
Where does it drop the script?
Click to expand...
Click to collapse
The script is inside the ZIP, which I think I saved to /sdcard/Android/data/de.robv.android.xposed.installer/ - check the output on your screen after pressing install, it should be noted there.
GermainZ said:
The script is inside the ZIP, which I think I saved to /sdcard/Android/data/de.robv.android.xposed.installer/ - check the output on your screen after pressing install, it should be noted there.
Click to expand...
Click to collapse
Alright, I will give it a try tomorrow, and post an update on the results. Thanks for the help!
Note that there are still a few minor things that are done via root, even when using the manual recovery installation mode. So the app needs to get root access.
In case anybody cares, here's a pure C reimplementation of 'cuber.py'
(my own earlier reimplementation of @vortox's signature.py).
This is what I'm using in my '1-Click' bootloader unlock VM...
See 'grep ^gcc' for "build instructions".
Hack, you can probably build this for ARM and run it right on your very HDX tablet... (-;
UPDATE (JanuaryFebruary 2017):
OK; so, @zivimo had built this for ARM, but people still haven't noticed.
I repacked his binary from a .tar.gz to a .zip archive and decided to spell out the instructions for use.
Perhaps, this helps... With the right bootloader in place, and adb/fastboot installed (and working),
the unlock is as easy as follows...
Download and extract unlock.zip (SHA256: e40e3010f8eccfa9cbd1e73eecac30cf799099d183de23b2d256fc3407f143f6e5db0b8d82c8fd2a25a22b0a598014d22a2ec33cef27a8d4b65a36acde08f27a)
to the same directory that holds the adb and fastboot executables (unless you have added them to your PATH)
Click on get_code.bat in the extracted folder
-- optional (but commonly required) step(s) --
fix root (roll back, if you need to), flash vulnerable bootloader
[you'll definitely need to perform at least some of these if the last step fails]
Click on unlock.bat in the extracted folder
The archive also includes .sh variants of the .bat files for convenience.
You could also just click to show the hidden section and cut&paste... (-;
Code:
[STRIKE]unzip cuber.zip[/STRIKE]
adb push cuber /data/local/tmp/
adb shell chmod 0755 /data/local/tmp/cuber
adb shell 'id=$(cat /sys/class/block/mmcblk0/device/{manfid,serial}); echo "$id"; echo 0x${id:6:2}${id:11:8} | /data/local/tmp/cuber > /sdcard/unlock.code'
adb pull /sdcard/unlock.code
adb shell rm /sdcard/unlock.code /data/local/tmp/cuber
adb reboot-bootloader
fastboot -i 0x1949 flash unlock unlock.code
NOTE: download and extract the attached 'cuberunlock.zip' and run the above commands
in the directory where 'cuber' got extracted to.
Nice job! Originally I wanted to use OpenSSL BigNum too, but I hadn't enough time and Python was easier to use
hey,
made a static compile with an arm debian (jessie). seemed the easiest solution to me. compile command:
Code:
# gcc -fPIE -static cuber.c -o cuber -lssl -lcrypto
# strip cuber
# ldd cuber
not a dynamic executable
# ./cuber
Usage: cuber [RSA-bytes] < data > sig
seems to work. arm(!) binary attached.
ok draxie, you pointed me here but something seems to be missing. i downloaded unlock.zip, put the files in my adb directory. when i run get_code.bat, it pushes cuber to the kindle in the right directory, changes permissions (dont see any errors there) but then stops saying the system can't find the specified path. Whats funny is i used es file explorer to check the paths in the script, and they are there so not sure where the hang up is.
chin_bone said:
ok draxie, you pointed me here but something seems to be missing. i downloaded unlock.zip, put the files in my adb directory. when i run get_code.bat, it pushes cuber to the kindle in the right directory, changes permissions (dont see any errors there) but then stops saying the system can't find the specified path. Whats funny is i used es file explorer to check the paths in the script, and they are there so not sure where the hang up is.
Click to expand...
Click to collapse
Did you check all three paths?
/data/local/tmp
/sdcard
/sys/class/block/mmcblk0
The 2nd one _may_ be problematic if you're on SafeStrap.
I don't know why. I'm yet to install that on one of my test
devices to investigate. (Or, was that the 1st... )
The 0 in the 3rd one may actually be a 1 on some systems.
I have a few extra lines in my VM script to work around
that, I can easily add that here as well, if that turns out
to be the issue.
BUT, to try and troubleshoot: how far does the script get?
If it didn't complain with the permissions, the 1st path is probably OK.
Does it print your manfid/serial?
If so, mmcblkX would be right as well.
Any chance that you're on SafeStrap?
Can you push/pull to/from /sdcard?
- - - - -
On a second thought: I've only ever tested this on Linux.
String quoting on Windows may work differently, and could *royally* mess up how that more complex command is interpreted.
I'll test tomorrow; it's like 20 past 1am here. I need to get some sleep.
In the meantime, as a workaround, you could just hard-code your manfid/serial, and replace this line:
Code:
adb shell 'id=$(cat /sys/class/block/mmcblk0/device/{manfid,serial}); echo "$id"; echo 0x${id:6:2}${id:11:8} | /data/local/tmp/cuber > /sdcard/unlock.code'
by the decidedly much simpler:
Code:
adb shell 'echo 0xmmssssssss | /data/local/tmp/cuber > /sdcard/unlock.code'
draxie said:
Did you check all three paths?
/data/local/tmp
/sdcard
/sys/class/block/mmcblk0
The 2nd one _may_ be problematic if you're on SafeStrap.
I don't know why. I'm yet to install that on one of my test
devices to investigate. (Or, was that the 1st... )
The 0 in the 3rd one may actually be a 1 on some systems.
I have a few extra lines in my VM script to work around
that, I can easily add that here as well, if that turns out
to be the issue.
BUT, to try and troubleshoot: how far does the script get?
If it didn't complain with the permissions, the 1st path is probably OK.
Does it print your manfid/serial?
If so, mmcblkX would be right as well.
Any chance that you're on SafeStrap?
Can you push/pull to/from /sdcard?
- - - - -
On a second thought: I've only ever tested this on Linux.
String quoting on Windows may work differently, and could *royally* mess up how that more complex command is interpreted.
I'll test tomorrow; it's like 20 past 1am here. I need to get some sleep.
Click to expand...
Click to collapse
It's all good draxie, i figured out what i was doing wrong with the other procedure, that damn STEP 2, once i did it, everything fell into place. Bootloader unlocked and now just trying to figure out which rom to try first. Thanks again, you guys are great and i know how valuable everyones time is. :good:
I keep hitting road blocks, I am rooted and on Fire OS 4.5.5.2 I click get code a screen flashes up then I click Unlock and my Kindle boots to the Grey Kindle screen with Fastboot underneath and nothing else happens. Same happens when I copy and past the code into ADB. What step am I failing at? Thanks for the help!
pdanforth said:
I keep hitting road blocks, I am rooted and on Fire OS 4.5.5.2 I click get code a screen flashes up then I click Unlock and my Kindle boots to the Grey Kindle screen with Fastboot underneath and nothing else happens. Same happens when I copy and past the code into ADB. What step am I failing at? Thanks for the help!
Click to expand...
Click to collapse
@draxie - I have no experience with this tool; python/gmpy2 works reliably for me. Sorry to pull you in ...
Davey126 said:
@draxie - I have no experience with this tool; python/gmpy2 works reliably for me. Sorry to pull you in ...
Click to expand...
Click to collapse
I am up and running now, unlocked and running kk-fire-nexus-rom-thor-20161017. Play store is also up and running.
pdanforth said:
I am up and running now, unlocked and running kk-fire-nexus-rom-thor-20161017. Play store is also up and running.
Click to expand...
Click to collapse
Did you end up using some other method, or did these scripts work for you in the end?
Either way, others may find useful if you could share whatever worked for you. (-;
Unfortunately, I still haven't had a chance to test these scripts in Windows;
so, I couldn't answer your first call for help in a good way. If there's something
wrong and there's enough interest, I'll be happy to fix it as soon as I can.
draxie said:
Did you end up using some other method, or did these scripts work for you in the end?
Either way, others may find useful if you could share whatever worked for you. (-;
Unfortunately, I still haven't had a chance to test these scripts in Windows;
so, I couldn't answer your first call for help in a good way. If there's something
wrong and there's enough interest, I'll be happy to fix it as soon as I can.
Click to expand...
Click to collapse
@stangri did my unlock file and I used this thread to unlock https://forum.xda-developers.com/kindle-fire-hdx/general/thor-unlocking-bootloader-firmware-t3463982
I had trouble making the Unlock file, once that was done and some help from other users I am now up and running!