https://redd.it/59n5r9
If its possible to do on other phones that run the un-patched kernel I suppose it can be done on the Spring G5. If so that would be the luckiest break ever lol.
Not sure if its really going to be a root method and let super user work because the owner of the repo said "I put 'root' in quotes, because technically, it isn't rooting. However, it creates a binary called 'run-as' that can execute packages as root.".
He also he mentioned it has'sent been tested on 64-bit
I'm working on trying to understand how exactly the bug works, and to see if it can be replicated. In theory, it should work because even 64-bit desktop kernels are affected. Additionally, the bug still exists in the kernel upstream, so all Android devices should be affected.
Update on this. The exploit does work on the LG Stylo 2, which is running very similar software to the LG G5, but I am having issues installing su, but I do have root...temp root at least.
this will not root your phone to let you run titanium backup or Xposed APIs. If you lucky you can maybe make changes to build.prop and only if the system partition is not signed like the kernel is. So I would not bet on this.
with temp root can you mount system as rw and make changes? if not it's completly pointless
can you provide binary, so we do not have to compile. I would try it as well
lg phone ever not get root?
I have the exploit running on my Stylo 2, but I can't do anything. SELinux is set to enforcing, but I do have a root shell.
Code:
λ adb -d shell
[email protected]:/ $ run-as exec whoami
Warning: setcon transition to 'u:r:init:s0' failed (is SELinux Enforcing?)
root
[email protected]:/ $ run-as exec dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.img
Warning: setcon transition to 'u:r:init:s0' failed (is SELinux Enforcing?)
dd: /dev/block/bootdevice/by-name/boot: Permission denied
1|[email protected]:/ $
can you mount system partition as r/w to modify system files?
We can use the Dirtycow exploit to replace any file in the system memory with a file of the same size, but All files will revert once rebooted thanks to SELinux as mentioned, it enforces whatever file you replaced with same security. Escalated privileges doesn't seem possible while SELinux is enforcing. There is a thread dedicated for more discussion from others with more knowledge below:
http://forum.xda-developers.com/general/security/dirty-cow-t3484879
Believe me many people are working for this to be our Savior.
Couldn't we use this method, modify the update file to be rooted, then let the 7.0 install itself?
Related
Anyone have or know where I can download the telnetd binary for Android? I think I might have a way to get root privileges on the Samsung Moment...and if it works, I see no reason why it wouldn't work on the Hero.
Just need that darn telnetd binary and any of the support files so I can install it into my phone (as long as the root exploit works.) It's running Android 1.5 btw if that makes a difference.
Why not ssh?
Download dropbear
telnet is an open invitation to get hacked, since the connection is not encrypted.
I know telnet is not encrypted...that's why I'll turn off the radio and enable wifi when I do this.
I was on the IRC (#android-root on freenode) and was pointed in the direction of JesusFreke's build environment, in which (s)he has built a veritable ****-ton of ARM binaries that are *extremely* useful.
http://jf.andblogs.net/2009/05/24/jfv151-images-are-out/
I found JFV1.51 CRB43 US BuildEnvironment (1324) to be particularly useful. Once extracted, I found binaries for a very full busybox, and a few dozen other useful goodies, including telnetd.
From the extracted tar, the binaries are under 'Build/System/ModifiedFiles/xbin'. adb push them to /data/local on the device, then call them via adb shell.
Example:
With device connected, and with the Android SDK installed and in your PATH:
Code:
# tar xvf JFv1.51_CRB43-US_BuildEnvironment.tar.gz
# cd Build/System/ModifiedFiles/xbin
# adb push <program of your choice> /data/local
# adb shell
# /data/local/<program of your choice>
Just out of curiosity...what is your hunch for getting root on the Moment?
@gargarxp - Thanks for the info!
gargarxp said:
Just out of curiosity...what is your hunch for getting root on the Moment?
Click to expand...
Click to collapse
I was looking through all of the recent kernel privilege level escalation reports, and ran across this one:
http://seclists.org/fulldisclosure/2009/Nov/105
It works on kernels up to 2.6.31...which the Moment runs 2.6.27. My plan is to use an Android app to execute this exploit contained in a native executable (which I have confirmed I can execute native code), which will then trigger a shell script I will write to copy the telnetd files into the proper places and start the service as root. From there, I'll telnet in...see if the root user has a password...and go from there.
Actually, if you get this to execute as root, the procedure from there is fairly simple.
From my understanding, the other root exploits have a singular goal: to gain a root shell for the purpose of creating a suid su for the system to use to gain root in the future. From the CDMA Hero process, once a root shell is gained:
Code:
# mount -o remount,rw -t rfs [COLOR="Red"]/dev/stl5[/COLOR] /system
# cd /system/bin
# cat sh > su
# chmod 4775 su
They:
Remount the /system fs as read-write
Go to the /system/bin directory
Copy sh to (a new) su
Set the permissions on that to 4 (SetUID) 775 (User-Group: RWX, Other: RX)
* The bit in red is what I observed the device mounted to /system to be on my Moment. I obtained this information by running adb shell mount and seeing what /dev device was next to /system. Should be the same for every Moment, but the procedure is useful for any Android (or Linux for that matter) device.
Once this is done, any user executing this su will do so as the user/group that the owns executable, which in this case is root:shell.
So, via this method, if you can manage to get a root shell on *any* Android device, bada bing bada boom: rooted.
...At least that is my understanding of it all.
Well...the problem is I can't get my Moment connected to my computer to run adb. I'm on Windows 7 64-bit...and the drivers won't load...and Samsung's PC Studio won't install properly. So, I found source code online for executing native code via an Android app...which should work to execute the native exploit.
And you'll have to excuse me...I've been using Linux for the past 10 years...programmed some projects on the platform...but this is pretty much my first time developing on Android.
Oh no problem at all. Frankly, I'm being overtly descriptive so as to make this post useful to the community in general and not be Moment-specific. I don't wish to encouter the ire of the XDA mods Just trying to do a public service.
So, do you have an ARM binary of the exploit built already (ImpelDown.c)? And if so, could you post a link to download it? I've never cross-compiled before and am currently going 10 rounds with gcc and the android-2.6.27 source tree.
Thank you! I know...it's kinda risky for me posting stuff about the Moment in an XDA forum...but I figure this could help the Hero efforts as well...and XDA was so good to me back when I was using my DIAM500...I wanted to contribute something back.
I'm still trying to get my cross-compiler built. I initially started out with Cygwin and a tool for building a cross-compiler...but that went horribly wrong...tons of compiler errors. I attempted to use Scratchbox on OpenSuse 11.2...but Scratchbox wants to run on a Debian system...ugh...haha.
And as I was typing my response to you...I decided to Google for "arm compiler windows" and found http://www.gnuarm.com/
But rest assured...once there's a working binary...I'll upload it here.
From the Gnash project's dev wiki....
http://wiki.gnashdev.org/Building_for_Android
They raise some issues with using a standard cross-compiler (GNUARM uses Newlib, which isn't the Android libc implementation Bionic...which is apparently a problem)
I grabbed the toolchain they link to on the page and am trying that.
Yeah...I found that out as well after I installed gnuarm...
I also just loaded the native toolkit.
Well gargarxp...I compiled it...ran it...didn't work. I'm going to try another one tomorrow.
I know Paul over at MoDaCo announced he has root but I think that should not prevent us from trying to figure it out ourselves.
I have been fiddling around with the device and its filesystem and, as some might have tried, most commands are very restricted and you can't even list the /system folder.
Recently I found a directory which has write permissions and installed busybox there through adb, here are the instructions:
Download a precompiled busybox binary from http://benno.id.au/blog/2007/11/14/android-busybox
Push it using adb: adb push busybox /data/local/rights
Start a shell: adb shell
Change directory to the folder: cd /data/local/rights
Give it execution permissions: chmod 755 busybox
Play around with it: ./busybox ls /system
Figure out how we can use the new capabilities to root the phone
Any thoughts?
I was trying something also.. although I dont really know what I am doing mostly, I was trying to use some kernel exploits to get root access without luck. Good learning experiece though..
It would be nice if he gave a hint..
Hello.
I have rooted my phone using
http://htc-one.wonderhowto.com/how-to/unlock-bootloader-root-your-htc-one-m8-0154444/
(in short, it's using SuperSU 2.00)
After some efforts, Root Checker says i am fine. I can get id 0 from adb, and via ssh.
But ... Busybox fails to install.
And if I remount /system RW, and mess in there a bit (like mkdir /system/tmp ), the mess is removed after reboot. Changes are not permanent.
Must I change my su app for superuser mentionned in the FAQ of the section (via recovery) ? Are there things to do before this migration ?
Other possible issues ?
I am used to fully unlocked HTC Sensation, where I changes to /system are easily permanent. But it was done using an exploit, few before HTC allowed rooting officially. Rooted M8 does not seem as much friendly ...
I *really* need busybox to work, and make permanent changes to /system. I am stuck.
Thanks.
doublehp said:
Hello.
I have rooted my phone using
http://htc-one.wonderhowto.com/how-to/unlock-bootloader-root-your-htc-one-m8-0154444/
(in short, it's using SuperSU 2.00)
After some efforts, Root Checker says i am fine. I can get id 0 from adb, and via ssh.
But ... Busybox fails to install.
And if I remount /system RW, and mess in there a bit (like mkdir /system/tmp ), the mess is removed after reboot. Changes are not permanent.
Must I change my su app for superuser mentionned in the FAQ of the section (via recovery) ? Are there things to do before this migration ?
Other possible issues ?
I am used to fully unlocked HTC Sensation, where I changes to /system are easily permanent. But it was done using an exploit, few before HTC allowed rooting officially. Rooted M8 does not seem as much friendly ...
I *really* need busybox to work, and make permanent changes to /system. I am stuck.
Thanks.
Click to expand...
Click to collapse
The /system partition is write protected on stock, meaning you can't add, modify, or delete files there. To disable this, you need to flash a kernel or rom with this disabled. Pretty much all sense based roms/kernels will state this in the features. I believe S-Off also disables it if you want to go the extra mile.
PS: Write protection is disabled in recovery. That is why superuser/root could be installed there.
PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613
akitten007 said:
The /system partition is write protected on stock, meaning you can't add, modify, or delete files there. To disable this, you need to flash a kernel or rom with this disabled. Pretty much all sense based roms/kernels will state this in the features. I believe S-Off also disables it if you want to go the extra mile.
PS: Write protection is disabled in recovery. That is why superuser/root could be installed there.
PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613
Click to expand...
Click to collapse
So, is there a way to install busybox via recovery ?
I did 3 things in recovery: all in /system/xbin
- chmod +s su
- touch t
- mkdir tmp
after reboot to normal mode, SUID bit was removed, but t and tmp are still here.
So, how do I install busybox ?
New issue: /data has the nodev flag; is it possible to remove it ?
I did not found /dev/shm ; was it moved somewhere else ? Any other place for similar use ? (world write temp folder in RAM).
akitten007 said:
PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613
Click to expand...
Click to collapse
If your kernel allows me to install busybox, can i backup my original kernel to restaure it afterwards ?
Can I install busybox manually via recovery+adb ? I don't have any dev suite, but a good linux station; so, I can unzip, list, copy, and so on ... if there is not too much work to do.
doublehp said:
If your kernel allows me to install busybox, can i backup my original kernel to restaure it afterwards ?
Can I install busybox manually via recovery+adb ? I don't have any dev suite, but a good linux station; so, I can unzip, list, copy, and so on ... if there is not too much work to do.
Click to expand...
Click to collapse
Now you're starting to go over my head. If you want to keep your current kernel, I would try using this method here to manually add the module that disables the protection http://forum.xda-developers.com/showthread.php?t=2702575. I usually just install busybox using rom toolbox or any other busybox app. You could search for a busybox zip, but just disabling the write protection is a better option in my opinion. And I have actually 0.00 idea what flags mean on folders (sorry).
I rooted using TWRP recovery and super su. That guide you posted gives unnecessary instructions. TWRP automatically installs the SU binary and Super su the first time you boot into it. I was able to update Super su via google play, no need for the update zip. Just follow the instructions after rebooting to system from TWRP recovery.
I'm s-off, unlocked, my kernel, firmware and os are stock, only thing that isn't is recovery. I have write access to system and external sd card. All I did was make it writable with root explorer and have installed busy box no problem using this app https://play.google.com/store/apps/details?id=stericson.busybox.
I was given a better fix.
http://forum.xda-developers.com/showthread.php?t=2701816
In short:
adb push /mnt/big/tmp/wp_mod_m8.ko /mnt/sdcard/Download/
insmod /mnt/sdcard/Download/wp_mod_m8.ko
mount -o remount,rw /system
cd /system
touch z
mkdir zz
reboot
[email protected]_m8:/storage/emulated/legacy # cd /system/
[email protected]_m8:/system # ls
app
bin
build.prop
customize
etc
fonts
framework
lib
lost+found
media
priv-app
tts
usr
vendor
xbin
z
zz
[email protected]_m8:/system #
The miror is on maintainance for now. So, the guy on IRC gave me his local backup. I will push it here for 30 days:
http://dl.free.fr/gSha53ljz
(server will delete it after 30d nobody downloads it)
Busybox still fails to install; don't know why.
I am not sure if this should go here or the Android Development section, but here goes..
I modify boot images for some android phones, and I add custom services to the init.rc to execute some shell scripts when some property is set..
Code:
service myservice /system/bin/sh /myservice.sh
oneshot
disabled
on property:log.myservicestart
start myservice
I also add myservice.sh file in the boot image with some code I need to execute. This has always worked well for me. In certain cases where I had selinux issues, I used to patch the sepolicy file using supolicy before making the boot image (or I just copy the supolicy from Autoroot recovery images sometimes).
Somehow, this doesn't seem to work for Android N. It listens to property changes (if I had a setprop in there to set another property, it works), but it never executes the shell script. I don't see any selinux denial errors, or any other error in logcat either!
I unpack and repack images using AIK-Linux, and I have the latest code (and the binaries).
Anyone has any idea about this?
Edit: Never mind, it looks like I needed seclabel to be explicitly set for Android N.
Hi all -
I have made updated scripts before, but something isn't working out for me. I started with this guys script here:
https://forum.xda-developers.com/showpost.php?p=19093919&postcount=20
Purpose is to add lines to build.prop from the script (also does a backup).
First time through I was getting an error which I resolved by updating to a different updater-binary.
I know that the .sh script that I am copying over is running (using some simple touch statements), however it never seem to touches my build.prop.
I think the issue is that somehow it can't access the build.prop file, possibly because it isn't mounting /system properly.
It seems to use busybox commands which I don't have on my device (and I'd rather not install, as I don't want to have to depend on it after clean flash).
Can someone help me out or point me to another script/method of updating build.prop via updater-script?
thanks
Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?
TraderJack said:
Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?
Click to expand...
Click to collapse
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.
Tulsadiver said:
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.
Click to expand...
Click to collapse
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.
TraderJack said:
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.
Click to expand...
Click to collapse
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.
Tulsadiver said:
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.
Click to expand...
Click to collapse
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.
TraderJack said:
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.
Click to expand...
Click to collapse
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Edit:. That code in bptweaks.sh and that you posted is not mine either. It came from one of the links in your original post. I thought you were indicating that you could not get a script to install. All I did was try and make a vehicle for a script that could modify the build.prop.
Tulsadiver said:
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Click to expand...
Click to collapse
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?
TraderJack said:
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?
Click to expand...
Click to collapse
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.
Tulsadiver said:
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.
Click to expand...
Click to collapse
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/
TraderJack said:
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/
Click to expand...
Click to collapse
Yes, it's in the mounting. Pixel 3's don't seem to use BusyBox. They've looks like they've gone to toybox. What this dumbed down version of magisk util_function.sh appears to be doing is installing BusyBox and setting it to be used instead. This one is more like you are used to seeing. The only way I could get it to work is still by using magisk util_function.sh for mounting purposes. I would not be able to write a script like that myself.
I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.
HesThatGuy said:
I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.
Click to expand...
Click to collapse
Thanks, but 100% not relevant - not only to the replies, but also to the OP.
TraderJack said:
Thanks, but 100% not relevant - not only to the replies, but also to the OP.
Click to expand...
Click to collapse
Sounds like you need to disable dm-verity to edit build prop without using Magisk. Magisk is one big overlay seems to be the way of the future tho. I personally been disabling verity then adding xbin folder to root then linking to system then installing BusyBox to xbin. I don't like using Magisk to install BusyBox module or any module that alters the system because you will have to use Magisk to modify system from there on out instead of jus manully doing it yourself with a root explorer.
Also if you was to flash a open gapps zip it would add a addon.d folder to system. which open gapps and Magisk will install their backup scripts to the addon.d folder. would be a good place for you to add your own backup script as well.
Yeah, you need to disable verity to properly mount /system, /vendor, and /product partitions. It is not hard. In magisk manager just go to advanced options, untick verity, then install magisk from the app. After changes you can put verity back if that bugs you.