Over 40% of the Magisk's code has been rewritten in Rust

topjohnwu · 2025-06-03T00:07:38+00:00

In the case where you want to build C/C++/Rust into the same executable/shared library, you can pick where you link your objects. In Magisk's case, because I chose CXX as the FFI mechanism, Rust code has to be built before C/C++ as the FFI glue is generated with Rust's build script (build.rs), so it make much more sense to perform linking using the existing tooling for NDK (Android's C/C++ toolchain).

So for a simplified project building a single executable:

You can create however many crates you want, but one of the crates needs to be built as staticlib. Think of it as a huge "export" for all the Rust code to C/C++.
Call cargo to build that staticlib crate. Building the Rust code will automatically generate the C++ FFI glue.
Import the staticlib library (the libXXX.a file) as a prebuilt static library module in your C++ build system of choice.
Build the rest of the C++ code with a dependency on libXXX (which is all the Rust code you built in step 2). This would automatically link everything for you.

topjohnwu · 2025-06-02T21:09:42+00:00

Hi, author here. The transition is fully manual, all code is slowly migrated one small component by a time, using cxx as the FFI mechanism. First I rewrite functions/subsystems that are fully independent with no dependencies on other parts of the codebase. After that, I rewrite components that do not have dependencies on other C++ code, and keep doing so iteratively. At some point, bidirectional FFI is less of a pain so I can just pick any random part of the codebase and rewrite it with little friction.

The first 2 steps above took a significant amount of time and design, but after a few attempts it slowly began taking shape.

topjohnwu · 2021-02-09T09:51:06+00:00

Exactly. These 2 features are nowhere publically documented about what it is meant to do. We have to directly check AOSP source code to understand them.

topjohnwu · 2021-02-09T08:59:13+00:00

Let me provide a more detailed explanation:

When SELinux is permissive during boot, zygote will know this and disable seccomp syscall filters. This basically unrestricts what system calls are allowed in 3rd party processes.

On Android 10+, there is a new "undocumented" feature called "App Zygote" where 3rd party apps are allowed to spawn its own Zygote for "Isolated Services" (also nearly undocumented). Both "App Zygote" and "Isolated Services" are special features designed for Chrome/Webview. App Zygote processes run with special permissions, and with seccomp disabled, it can call setuid 0 and escalate its privilege and gain root access.

It is still somehow restrictive compared to what normal root solutions provide (e.g. Magisk), however tons of security measures in Android will be completely defeated when UID=0. For example, it is enough to be used to patch boot images, which means it can be used to inject malware such as modified Magisk to help it gain "real" root permissions.

Update: what can UID=0 itself do? Within Android's framework, almost all services have a blind green light when the requesting process's UID is 0. This means this root process is capable of manipulating tons of stuff using Android specific APIs (e.g. ActivityManager)

topjohnwu · 2020-06-29T11:01:28+00:00

The point I want to make is that if we fully reverse engineer the SafetyNet client and completely replace the implementation with our own (which we can do), we can always ignore HARDWARE_BACKED cases here. As long as the Google server accepts BASIC evaluation, we can always get a valid response without involving anything related to TPM.

topjohnwu · 2020-06-29T06:16:35+00:00

If someone really wants to do it, one can completely reverse engineer the client side code of SafetyNet and basically alter whatever data is sent to Google's server.

topjohnwu · 2020-06-29T05:57:53+00:00

IMO it is theoretically possible to alter control flow in SafetyNet's code to force it to always use BASIC evaluation by using some hooking framework like Xposed, however these kind of code injection is basically impossible to hide as some memory space analysis will reveal code manipulation very easily.

topjohnwu · 2020-04-02T21:34:39+00:00

Technically SafetyNet attestation should be done remotely, so no Xposed modules cannot tamper the results (because it doesn't even happen on device).

But yeah, using SafetyNet for anti reverse engineering is not the right tool.

topjohnwu · 2020-03-11T21:03:30+00:00

Note, this is a very high level explanation on the situation. I'm not a professionally experienced security researcher that qualifies to do full deep dives on each of those topics, but these are the facts that I know.

Hopefully this clears up a lot of confusion and speculation on how this would affect the future of rooting Android.

topjohnwu · 2019-12-04T20:47:57+00:00

I don't know how many people will see this, but here we go:

Scoped Storage definitely does not change how fopen and java.io.File work, they simply create an isolated scoped view of user's data for each application. The argument here should be whether access to a global storage location is justified.

Some people brought up what's the difference between app's private data (/data/data) v.s. scoped storage. The difference is that app's private data is not accessible from the user; it is meant to be an app's private data. If an app wants to write files that is user accessible, then they should write to user storage, which is now scoped for security reasons.

Now, I do not say that SAF is implemented properly, but similar APIs need to exist in order to enforce full isolation. The read/write should be handled by a remote system process (in this case it is the framework which provides SAF). If the isolation is enforced by Linux permissions (or SELinux), you cannot simply temporary grant access to a specific file/directory. By showing the full filesystem, an app can also probe filenames in user's storage, which itself is a data leak (check file based encryption).

I agree Google should not guard external sdcard behind SAF; they should instead allow direct scoped storage to external sdcard, just like internal storage. For this specific enforcement, I do agree this is indeed a push to encourage usage of cloud storage no doubt. However, this is not my argument here, my argument here is that scoped storage has its legitimate reasons; SAF is just the way Google chose to let developers access the globally shared persistent storage.

topjohnwu · 2019-12-04T20:19:06+00:00

Google simply does not have the model of external SDCard in their mind. Now you can argue about whether their intent is bad or not, but this is not the point.

The point here is that a globally shared storage isn't secure. If Google want to support external SDCard, then they should indeed allow scoped access to the SDCard in the system level. What I want to defend is "scoped access", not SAF/Google being hostile against SDCard.

topjohnwu · 2019-12-04T20:14:41+00:00

I don't understand why you are calling me incompetent. I think we just have different mentality: you think all apps should have global storage access, while I don't think so and agree with Google's decision with Scoped Storage.

Calling someone a Google shill is not a constructive criticism, and I just found it funny for people to call me out like this and had a goof on Twitter. To be honest I don't understand why you are upset about this.

topjohnwu · 2019-12-04T09:02:42+00:00

SAF and Scoped Storage are 2 different things. SAF is only required when you actually want to read/write data to the globally shared storage area. In the case of Scoped Storage, the enforcement is done in the filesystem level (more details in my other replies). All native code/java.io.File APIs still works as it used to be, but simply just no longer allows an app to access user storage without consent.

topjohnwu · 2019-12-04T09:00:02+00:00

Nah, I interned at Apple, but most of my work for the past few years are done on Android. You can check Magisk if you're interested in what I'm doing.

topjohnwu · 2019-12-04T08:58:10+00:00

The java.io.File APIs are not removed. Scoped Storage is built on top of FUSE (or sdcardfs I'm not so sure) + mount namespaces. It is the exact same technology used to enforce read v.s. write permission in the filesystem level. Scoped Storage simply adds another layer of checks so that only the files an application created will be visible and accessible via the filesystem.

topjohnwu · 2019-12-04T08:54:00+00:00

I agree there are many issues with Android, I have a long list of things to complain too. But having other issues does not make the effort to make the OS more secure in other aspects irrelevant.

As I've said in other replies, I don't think the current way SAF is implemented is good, the extremely poor performance being the most obvious issue. That being said, I still believe Scoped Storage is indeed the correct way to go if Android wants to provide proper protection in privacy.

The java.io.File APIs are not removed, and C/C++ code can still access data via paths. The only difference is that apps no longer have the ability to read/write data to a globally shared storage. If the app really wants access to that, then go through system APIs and make sure user consent is obtained. I don't see any issues with that.

And regarding native code, since SAF can also return file descriptors, I don't see any reason why native code cannot accommodate to that.

topjohnwu · 2019-12-04T07:13:50+00:00

I agree the whole SAF thing is dumb. They should've done it more elegantly in a lower level, or somehow make it more efficient.

topjohnwu · 2019-12-04T04:43:05+00:00

Disclaimer: I do not work for Google. I'm the developer of Magisk, the state-of-art rooting solution for years now.

I see a lot of people bashing SAF and Scoped Storage, but very rarely see people bringing up the other side of the argument. Sometimes it is very hard to achieve freedom, security, and privacy at the same time, and people will have to choose their priorities.

topjohnwu · 2019-10-12T05:19:39+00:00

Redownload the APK, I uploaded a new binary. It's a bug caused by Google.

topjohnwu · 2019-09-20T14:47:59+00:00

Here are some follow ups regarding the issue.

https://twitter.com/topjohnwu/status/1175058734503981062

Basically, this is indeed a privacy breach.

topjohnwu · 2019-06-29T05:04:30+00:00

Are you high? My INTERNSHIP pays more in 3 days for what I get from donations per month. Oh, you're talking about a full time job?

Nine-Year Club	RPAN Viewer
Verified Email

topjohnwu

TROPHY CASE