- 15 Nov, 2019 2 commits
-
-
vvb2060 authored
-
Ilya Kushnir authored
-
- 14 Nov, 2019 2 commits
- 13 Nov, 2019 8 commits
- 12 Nov, 2019 1 commit
-
-
topjohnwu authored
-
- 11 Nov, 2019 2 commits
- 10 Nov, 2019 1 commit
-
-
topjohnwu authored
-
- 09 Nov, 2019 4 commits
-
-
topjohnwu authored
-
topjohnwu authored
Fix #2053
-
Ilya Kushnir authored
-
osm0sis authored
- compare against new byte[] array as a quick tell, since when streaming from a partition with an unsigned image "signature" would of course read without issue but then remain filled by zero padding, resulting in the following: java.io.IOException: unexpected end-of-contents marker at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source:14) at com.topjohnwu.signing.SignBoot$BootSignature.<init>(SignBoot.java:235) at com.topjohnwu.signing.SignBoot.verifySignature(SignBoot.java:144) at com.topjohnwu.signing.BootSigner.main(BootSigner.java:15) at a.a.main(a.java:20)
-
- 08 Nov, 2019 2 commits
- 07 Nov, 2019 1 commit
-
-
topjohnwu authored
-
- 05 Nov, 2019 1 commit
-
-
topjohnwu authored
-
- 04 Nov, 2019 4 commits
-
-
topjohnwu authored
Close #2024
-
topjohnwu authored
-
topjohnwu authored
Previously, we use either BroadcastReceivers or Activities to receive messages from our native daemon, but both have their own downsides. Some OEMs blocks broadcasts if the app is not running in the background, regardless of who the caller is. Activities on the other hand, despite working 100% of the time, will steal the focus of the current foreground app, even though we are just doing some logging and showing a toast. In addition, since stubs for hiding Magisk Manager is introduced, our only communication method is left with the broadcast option, as only broadcasting allows targeting a specific package name, not a component name (which will be obfuscated in the case of stubs). To make sure root requests will work on all devices, Magisk had to do some experiments every boot to test whether broadcast is deliverable or not. This makes the whole thing even more complicated then ever. So lets take a look at another kind of component in Android apps: ContentProviders. It is a vital part of Android's ecosystem, and as far as I know no OEMs will block requests to ContentProviders (or else tons of functionality will break catastrophically). Starting at API 11, the system supports calling a specific method in ContentProviders, optionally sending extra data along with the method call. This is perfect for the native daemon to start a communication with Magisk Manager. Another cool thing is that we no longer need to know the component name of the reciever, as ContentProviders identify themselves with an "authority" name, which in Magisk Manager's case is tied to the package name. We already have a mechanism to keep track of our current manager package name, so this works out of the box. So yay! No more flaky broadcast tests, no more stupid OEMs blocking broadcasts for some bizzare reasons. This method should in theory work on almost all devices and situations.
-
topjohnwu authored
Close #1576
-
- 03 Nov, 2019 6 commits
-
-
linar10 authored
-
topjohnwu authored
Running broadcast tests from the app does not accurately verifies whether the broadcasts can be delivered when the app is not running in the foreground, which is why we are running the test. The only sane way to verify broadcasts is to trigger the broadcast test directly from the daemon on boot complete. If it is not deliverable, then activity mode shall be chosen. In the meantime, cleanup AndroidManifest.xml
-
topjohnwu authored
-
osm0sis authored
- `!= remain` shouldn't indicate "not signed", it should indicate a read error as with `!= hdr.length` - attempt to catch unsigned images at signature read, before they make it to `BootSignature bootsig = new BootSignature(signature);` and result in the following: java.io.IOException: unexpected end-of-contents marker at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source:14) at com.topjohnwu.signing.SignBoot$BootSignature.<init>(SignBoot.java:230) at com.topjohnwu.signing.SignBoot.verifySignature(SignBoot.java:139) at com.topjohnwu.signing.BootSigner.main(BootSigner.java:15) at a.a.main(a.java:20)
-
osm0sis authored
- change to $TMPDIR in addon.d.sh since recovery addon.d-v1 backup + restore leaves you in /tmp/addon.d which the restore then deletes, which would break $BOOTSIGNER execution with the following: libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 1078 (main), pid 1078 (main) Segmentation fault - also move $BOOTSIGNER execution to after `cd $MAGISKBIN` to ensure it's in a working directory in all cases - addon.d.sh data mount wasn't doing anything since /data has to already be mounted for the script to be running, so move it into /system/addon.d/99-magisk.sh stub script where it might be useful on recoveries that don't mount /data initially Fixes #2013
-
topjohnwu authored
-
- 02 Nov, 2019 6 commits
-
-
Vladimír Kubala authored
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
Oliver Cervera authored
- updated existing strings based on english updates - added new strings
-
osm0sis authored
- increase SignBoot bootimg header version maximum from 4 to 8 (upstream AOSP is already at 3) and make a variable for future ease - hdr read size of 1024 bytes was too small as hdr_v1 and hdr_v2 have increased the used header page areas to 1632 and 1648 bytes, respectively, so raise this to the minimum page size of 2048 and also make a variable for future ease - do not return "not signed" for all caught exceptions, show StackTrace for future debugging then still return false for script purposes - correct "test keys" boot image signing strings (scripts and app) to "verity keys"
-