hi!
is there any way to replace the bootanimation binary on samsung devices before it gets loaded? i've dived into the magisk documentary a lot already and tried many methods to make a working module, but in every case the file either got replaced after the boot is done or just didn't get replaced at all.
if someone would please point me to the right direction, i was planning to release this module for other samsung phone owners to use!
Magic mounting often happens too late for the boot animation to successfully be replaced. There used to be an early mount stage, but that was buggy and therefore dropped a long time ago...
The earliest you could get away with is probably if you use a script in post-fs-data.d to bind mount the file from the module directory. Although, it is bad practice for modules to be placing scripts in post-fs-data.d, this could be necessary to get the earliest possible excecution. Just make sure to use the module uninstall.sh to delete the script and also leave in a self-destruct in the script if the module is removed without utilising the uninstall.sh file.
Also, bind mounts can trigger SafetyNet, but that depends a bit on what is actually mounted so keep an eye out for that.
No guarantees the above will work.
Related
Hello everyone,
I am trying to create a CWM flashable zip that will disable the charge led. My wife hates the led shinning all night long on the bedside table.
Consider this a 1.0 version that does not work.
Any help correcting the zips would be greatly appreciated!
http://dl.dropbox.com/u/56179974/Disable green charge LED.zip
http://dl.dropbox.com/u/56179974/Disable red charge LED.zip
http://dl.dropbox.com/u/56179974/Enable charge LEDs.zip
Thanks!
You shouldnt be modifying /sys files in that manner, you should be echoing values into them via a script.
Unfortunately there's no particularly reliable way of execing scripts on boot,
not all the kernels have the init script or install-recovery.sh
Depending on the kernel you could plug the entries into that and have them feed values into /sys
Edit: /sys is a virtual filesystem, it gets built on boot at every boot. You cant write to it during recovery as it disappears when you reboot.
What would be a good kernel to try?
From what I gather I could for instance use a terminal emulator to change the value or I could modify the init script to apply the value at boot?
It's not the kernel specifically, it's the ramdisk it includes.
Here's a quick rundown of how booting works:
Device is powered on -> bootloader starts loading kernel -> kernel loads ramdisk -> ramdisk scripts start loading android core -> boot time scripts and services are loaded
Dell devices have an init.device.post-boot.sh (or something along those lines), but a quick peek though the stock 5xx ramdisk shows that it's not enabled in it (I believe)
They also have flash-recovery.sh, but it might be missing in the HS kernels, so it's the same situtation.
I'd say the simplest way is to make them in scripts and just use a script pharser (like gscript) and load them that way.
Otherwise you would need ramdisk mods and reflash the kernel with the new ramdisk that lets you load more scripts at boot.
/data, /cache, and /system are mounted
/dev and /sys are spawned as they're virtual FS's containing telemetry from the kernel.
Thank you again for the useful information!
When you say "the stock 5xx ramdisk shows that it's not enabled in it (I believe)" does that mean that the init scripts are inaccessible after boot? I am working with the devs on getting Boot Manager working for the DS7 and we keep running into issues building the file system.
The ramdisk has a whitelist of scripts to exec:
The init.<device>.post-boot.sh script was added by dell in most kernels, they simply didnt add it into the stock 5xx ramdisks as they didnt have anything to put into them apparently.
If you check init.<device>.rc or init.rc on "/", look for these two entries:
Code:
service streak-post-boot /system/bin/sh /system/etc/init.streak.post_boot.sh
user root
disabled
oneshot
and
Code:
on property:init.svc.bootanim=stopped
start streak-post-boot
As it demonstrates, it feeds /system/etc/init.streak.post_boot.sh to sh when the boot animation has completed.
But they removed those entries from the stock 5xx ramdisk, they're simply not there anymore.
It still loads /system/etc/install-recovery.sh, you could use that as it does get loaded by the stock kernel.
At least on my rom the file doesnt exist at all, so you could simply replace it.
But if you were to do that the right thing to do is simply have the user modify it themselves, if they already have one with things they added. (this isnt that likely though)
Thanks again TheManii!
I would be working on this but unfortunately my DS7 bent a pin so as of now it is out of commission
I have new connectors on order (10 pack was the minimum) so I am hoping to have it going again soon
why not just implement duct-tape over the light? low-tech solution to your high-tech approach
Because that wouldn't involve me learning to code, etc
Too bad it isn't a problem now anyway considering my DS7 is a goner....
Wetzel402 said:
Because that wouldn't involve me learning to code, etc
Too bad it isn't a problem now anyway considering my DS7 is a goner....
Click to expand...
Click to collapse
check batterystats.bin, it might be related, didnt get a good look at it with my battery dying on the train home
I would but as I stated my DS7 took a dive. The charging port bent a pin and is now shot. A parts tablet on ebay maybe....
Wetzel402 said:
I would but as I stated my DS7 took a dive. The charging port bent a pin and is now shot. A parts tablet on ebay maybe....
Click to expand...
Click to collapse
How much would you want for parts?
PM sent
suggest removing block "# Eric Liu+" -> "# Eric Liu-" in init.rc might help those who are still using their S7.. the nexus7 probably stole the interest though
Anything proceeded with a "#" is a comment and doesnt do anything
Samsung Xposed Safe Mode script v1.0
What does it do?
This is an init.d script which emulates the xposed safe mode where you can press any button during boot, get a vibrate (to know it detected you), and it will disable all your xposed modules. To be used in case of bootloops because of incompatible modules.
This only disables all modules so that you can boot. It does NOT actually uninstall or disable xposed itself.
Why would I need this?
I talked with the developer of xposed for Samsung, wanam, and apparently, xposed safe mode was disabled for Samsung devices due to a Knox issue (if you disabled xposed, Knox will hate you and refuse to boot the phone). This is good, but if you have a bootloop, AND you're on a bootloader locked device, you have NO CHOICE but to wipe your data. Ouch!! That's a heavy penalty for accidentally installing one malfunctioning module!
Or maybe your phone still is bootloader unlocked, but you're running Samsung xposed and safemode is still disabled for you. Then you'd rather have xposed safemode back just for the ease of not having to go through recovery to fix things.
How does it work?
1. Press any of three buttons during boot (volume keys, or home button). You have 10 seconds from bootup to choose to do this.
2. System will give you 2 short vibrates to tell you it detected it.
3. Press any button 4 more times, each time will give you another short vibration.
4. One long vibration will signal to you that xposed has been disabled.
5. The script will automatically reboot your device in 6 seconds. This is because we can't disable xposed, so xposed will STILL load modules on this bootup, which means you'll still see the bootloop momentarily until you reboot.
Great! How do I install it?
This is an init.d script, so you need init.d support in your phone. Obviously, if you have a bootlocked device, you probably don't have init.d support. This is not a guide on how to get init.d support, but I'll offer you a few tips you can use to search yourself.
- install-recovery.sh, since it's called by init.rc during boot, can be hijacked in order to create an init.d system.
- If install-recovery didn't work, SuperSU also includes an su.d directory which is executed at a similar time. Just throw a script in there, or throw a script in there which enables use of the init.d folder (run-parts /system/etc/init.d).
Anyways, here's how you install it:
- Place the script you downloaded into
Code:
/system/etc/init.d
OR
Code:
/system/su.d
Give the script proper permissions for the folder it's in
- For su.d folder, it is root:root 0700 (rwx------)
- For init.d folder, it could be a variety of permissions. My init.d folder runs as a result of su.d, so I gave it same permissions as su.d. If yours doesn't, then you might want to try root:root 0755 (rwxr-xr-x)
- The important point here is to make sure it's at least root user and group, readable and executable, rwxr-xr-x
Will it work on my device?
It should work on any device really, if you follow the simple instructions. But I've only tested it on the ATT S4 (Lollipop 5.0.1), so I can't guarantee it will work on your device. Test it out and see if it works for you! It probably will!
You saved me!
I'm glad to hear that! I love to hear and see a thanks, so make sure to click the thanks button and maybe write a post too!
Bugs and problems
You know how to report bugs and issues. State all relevant information related to the problem; device, problem in clear detail, with reproducible steps, and anything else you might need.
Related custom xposed builds
Here are a list of Samsung custom xposed builds I know this "safe mode problem" to be present in. (Don't forget, this problem is likely to be in any and all Samsung xposed custom builds due to the nature of the Knox problem).
[UNOFFICIAL] Xposed for Samsung Lollipop by arter97
[UNOFFICIAL][5.0][v87.1][03 Dec] Xposed for Samsung Lollipop 5.0.x
[UNOFFICIAL][5.1/6][v87.1][28 Nov]Xposed for Samsung Lollipop/Marshmallow
Disclaimer: As usual, while I've made every attempt to make it perfect, there are no guarantee it will work for you. By using this, you agree not to hold me accountable in case something bad happens to you (or it didn't save your device)! Do your own testing to make sure it works before you actually need to use it in an emergency!
FAQ
It didn't vibrate
You probably have a different device which places the vibrator in a different location. I don't have your device, so maybe you'll need to help me debug and find where the vibrator is located at.
It didn't work!
What happened? Give me some detailed information about exactly what you did, what happened, and the device you're on!
Some possible problems to investigate are:
Does the script have correct user: owner and permissions?
Is your init.d or su.d system even working? Make sure it is first
Nice work!
It should help with incompatible modules leading to a bootloop, but it won't prevent Xposed from loading, the flag "/data/data/de.robv.android.xposed.installer/conf/disabled" is ignored on my Xposed version, done here for a reason, i got many bootloop reports in the past by people accidentally triggering safe mode by physical buttons, leading to Knox refusing to deal with modified binaries.
Fortunately it does not seem to be the same with TouchWiz 7.0, so i will bring it back later for Nougat.
wanam said:
Nice work!
It should help with incompatible modules leading to a bootloop, but it won't prevent Xposed from loading, the flag "/data/data/de.robv.android.xposed.installer/conf/disabled" is ignored on my Xposed version, done here for a reason, i got many bootloop reports in the past by people accidentally triggering safe mode by physical buttons, leading to Knox refusing to deal with modified binaries.
Fortunately it does not seem to be the same with TouchWiz 7.0, so i will bring it back later for Nougat.
Click to expand...
Click to collapse
Thank you!
It certainly will help a lot for disabling incompatible modules. Yes, although it doesn't technically disable xposed itself. It's really great that future versions aren't that way!
I actually thought of creating another script which utilizes back and menu key buttons to actually uninstall xposed from backups (an actual disable xposed script of sorts), but I thought it was too much.
Unreal.... can a group of professionals get together and spend a day cracking the bootloader and root the Verizon version note 5 not even one custom rom for this device all other models have gotten there attention we need to crack this note 5 please
so far no one can hack n920v bootloader. Me also waiting for this info. Until now my n920v still not root yet. huhuu
It does not bypass bootloader
It's funny, in the UART logs running an engineering s-boot, it will say that an invalid image was detected, and it will reboot to avoid tripping Knox. A t-mobile phone I got, I accidentally flashed a Verizon image, and there went Knox, before I had intended to. Verizon has probably drastically reduced the unexplained returns, with the lies suggested on here to use by doing that. That might be a main motivation to consider.
But back to the subject, before I ever tried attempted to understand Magisk (which I used on my XT1575), which sort of does the same thing I did, but still allows selinux, was to use the engineering kernel, and did the following:
& Mount /system as loopback in /data/systemmirror
& Mount a loop back image over /system, which effectively hides it
& Link to each file in the loopback to the mirror, except for what I didn't want, and add what I did want. I even got xposed, microg/unifiednlp working like that. I didn't want to use supersu, but I imagine it can be done too. Some files had to be on the loopback system because uh I think it didn't like dynamic linking some library files that were links, that was fun to debug again and again and again until it worked.
& Set selinux permissive, because links aren't normally allowed, and I couldn't figure out how to make that work in the policy, and I could have reloaded it with the tools in the supersu apk if I knew what I was doing.
Thus, a tethered root is made. Tethered. Every boot up, you have to log in with adb to run the shell script that mounts everything, changes selinux, and kills system_server, effectively rebooting it. I could not figure out another way. It worked, minus samsung pay.
While that doesn't sound so bad, I went into the subway, was playing my hacked up version of shattered pixel dungeon, and the kernel crashed. Man, I that was a bummer. Still haven't rooted it properly.
If there's a fwbl1 or something that breaks the chain of trust from a developers SDK, sboot could be modified to load any binary without tripping Knox into an existing sboot probably.
I've removed so much stuff from this post so many times while preparing the draft to submit to my comment editor, I wonder how many times before I'm forced to decide whether a sign post visible in 1/9th of a picture is part of a street sign or not.
I was noticing some weird slowdowns on my OnePlus 6 and with a little research I found out that in the last 6 months of releases, OxygenOS keeps a ~2GB swap file and actively uses it. Even if the Smart Boost option is off! More info here: https://forums.androidcentral.com/oneplus-6-6t/949148-open-betas-14-6-oneplus-6-6t.html
Basically in order to de-activate swap we need to add two lines to build.prop. This works successfully on my OnePlus 6, the swap file disappeared and the slowdowns are gone; but I cannot make a module because my only PC has blown it's PSU
persist.vendor.sys.memplus.enable=false
ro.vendor.qti.config.swap=false
Click to expand...
Click to collapse
There's absolutely no need to make a module for something that simple. A couple of options:
Make a boot script (in /data/adb/service.d or /data/adb/post-fs-data.d, start with service.d and if that doesn't work try post-fs-data.d) that uses the resetprop tool. Should look something like this:
Code:
#!/system/bin/sh
resetprop persist.vendor.sys.memplus.enable false
resetprop ro.vendor.qti.config.swap false
Don't forget to make the file executable.
Or, you can use MagiskHide Props Config (shameless plug disclaimer).
Thank you, added the script in service.d, put execute permissions and it works perfectly. I totally forgot Magisk could use bootscripts
Instantly noticed how the interface is way smoother without swap.
I tried MagiskHidePropsConfig before but even after installing everything it needed it still didn't work ("those props don't exist" or something along those lines). Probably too specialized for me to understand.
Glad you got things working. And thank you for the feedback...
That message in the module ui is simply information (if a prop does exist it'll show the current prop value). If you had entered the new value it would have updated the module scripts with your new prop and prompted you to reboot. I'll make sure to make that clearer for the next release...
Does magisk already utilize any of the methods used in this project on Github? (Traitor)
Methods used are:
Nearly all of GTFOBins
Writeable docker.sock
CVE-2022-0847 (Dirty pipe)
CVE-2021-4034 (pwnkit)
CVE-2021-3560
I was considering compiling Traitor and this Dirty Pipe method, that actually injects Magisk. Together, all in one APK, could be utilized in such a way to try every realistic method to get escalated privileges, if it found one, it would simply pop a GUI root shell for end user to then do what they need/want.
I then realized that you guys are likely already doing 80-90% of this stuff already and would make way more sense to try to get with you and see what we could do.
Thoughts?
@topjohnwu
-k0mraid3