Getting Started with KernelSU: Installing a Minimal App Hiding Module on Pixel 6

Mon, 05 Jan 2026 00:00:00 +0000

Having spent time with iOS jailbreaking, I decided to explore process injection and app hiding on Android. This article walks through building a minimal working module chain (app hiding) based on KernelSU from scratch on a Pixel 6 running Android 15.

Note that this app hiding implementation is fairly basic—it simply hooks Java-level APIs for retrieving the app list. Regardless, this workflow provides a direct way to experience app hiding capabilities.

What is KernelSU

KernelSU is a root solution designed for Android GKI devices. The official homepage is:

https://kernelsu.org/

Unlike traditional root solutions that primarily operate in userspace, KernelSU’s core logic runs in kernel space, directly granting root privileges to userspace applications from within the kernel.

From an implementation perspective, KernelSU doesn’t rely on modifying init, zygote, or the system partition. Instead, it provides capabilities through the kernel itself. This allows it to access interfaces that userspace solutions have difficulty utilizing stably.

In terms of capabilities, KernelSU provides kernel-level interfaces, such as:

Setting hardware breakpoints for arbitrary processes in kernel space
Accessing a process’s physical memory with lower visibility
Intercepting system calls (syscalls) in kernel space
Intervening earlier in the process execution flow

These capabilities don’t directly correspond to specific functional modules, but they form the technical foundation of KernelSU.

Metamodule Mechanism

KernelSU also introduces a module system called Metamodule. Related documentation can be found in the official docs:

https://kernelsu.org/guide/what-is-kernelsu.html

KernelSU itself only provides low-level capabilities and interfaces. Specific mounting and systemless modification logic aren’t hardcoded into the core, but are instead implemented by Metamodules.

For example:

meta-overlayfs provides systemless modification capabilities for the /system partition
Different types of modification behaviors are split into independent modules
This prevents core functionality from bloating as module requirements grow

Module lists and available Metamodules can be viewed on the official site:

https://modules.kernelsu.org/

Test Environment

The test environment for this experiment:

Device: Pixel 6 (oriole)
System: Android 15 (BP1A.250505.005, May 2025)
Root solution: KernelSU (LKM mode)
Module chain: KernelSU → Zygisk Next → LSPosed
Verification target: Hide My Applist

Flashing Official Android 15

No customizations were made to the system. We used Google’s official Factory Image, flashed via the Web Flash Tool.

After flashing, the device was in a completely clean Android 15 state, with only the bootloader unlocked for subsequent experiments.

KernelSU (LKM Mode) Installation Notes

KernelSU’s LKM mode installation process is similar to Magisk’s approach. The overall steps are as follows:

First, extract boot.img from the Factory Image and push it to the device:

adb push boot.img /sdcard/Download/

Then use KernelSU Manager on the device to patch boot.img, generating a patched boot image.

Pull the patched image back to the local machine and flash it:

adb pull /sdcard/Download/kernelsu_patched.img
adb reboot bootloader
fastboot flash boot kernelsu_patched.img
fastboot reboot

After rebooting, KernelSU Manager can properly detect the root status, indicating that the kernel-side changes have taken effect.

Basic Tools Setup

To facilitate subsequent operations, we installed some basic tools:

adb install MT_File_Manager.apk
adb install F-Droid.apk
adb install Termux.apk

These tools are only used to assist with viewing files, installing applications, and executing commands. They don’t affect how KernelSU itself works.

Zygisk Next and LSPosed

KernelSU doesn’t implement Zygisk itself, so we need to load Zygisk Next separately, then use LSPosed (Zygisk version) on top of it.

The LSPosed module is pushed and loaded as a zip file:

adb push LSPosed-zygisk-release.zip /sdcard/Download/

After enabling the module in KernelSU Manager and rebooting, LSPosed Manager shows the Framework as Active, indicating that the hook chain has been established.

Verifying Hook Capabilities with Hide My Applist

As the first verification point, we chose Hide My Applist:

Project repository: https://github.com/Dr-TSNG/Hide-My-Applist

The module’s behavior is straightforward: It controls whether target applications can retrieve the complete list of installed applications.

After installing Hide My Applist, enable the module for specific applications in LSPosed and configure hiding rules. After restarting the target application, the app list behavior changes, and the results match expectations.

This result verifies that the following chain is functional in the current environment:

KernelSU → Zygisk Next → LSPosed → Application behavior changes

Summary

Some straightforward conclusions:

Using KernelSU on Pixel 6 with Android 15 is feasible
The LKM mode installation path is clear and the process is stable
Zygisk Next + LSPosed can serve as a basic hook combination under KernelSU
Hide My Applist provides a simple, direct verification entry point

Alma: Reverse Engineering an AI Provider Orchestration Desktop App

Sun, 04 Jan 2026 00:00:00 +0000

What is Alma?

Alma is a desktop AI Provider orchestration and management application. It has recently received widespread praise on X, and the author is very active. The development pace is extremely fast, with releases coming like rain. I’ve been playing around with this software recently and deeply appreciate the author’s solid technical foundation.

On its official website (https://alma.now/), it positions itself very directly:

Elegant AI Provider Orchestration

In other words, Alma doesn’t aim to be just a “chat window”—it wants to become a desktop workbench that uniformly schedules, combines, and runs multiple AI capabilities.

Based on the official website and actual code structure, Alma focuses on these areas:

Unified management of multiple AI Providers (OpenAI, Anthropic, Google Gemini, DeepSeek, and custom APIs)
Conversation-centric UI with Markdown support, code highlighting, and streaming output
Memory and context management, visualized in the UI
Browser-based capabilities like WebFetch / WebSearch
Composable extensions through Prompt Apps and Skills
Extensive direct integration of local capabilities, rather than “cloud-only”

Overall, it feels more like an “AI capability orchestration layer + desktop IDE-like experience”: It handles models, credentials, and protocols, while also actually running tools locally.

Author and Project Source

Alma is developed and maintained by yetone. The project is closed-source, though the source code appears to be hosted on GitHub (inferred from configuration files): https://github.com/yetone/alma.git The author’s GitHub is https://github.com/yetone, with multiple high-starred projects, showing strong technical passion and worth learning from for developers.

Back to Alma. Based on code scale, engineering organization, and continuous version evolution, this isn’t a one-off demo—it’s a long-term evolving desktop AI project. The author demonstrates solid engineering practices in the following areas:

Electron / macOS desktop application architecture
Node.js / TypeScript engineering
Unified abstraction of multiple AI Providers
Local tool integration (PTY, Playwright, Whisper)
Emerging model protocols like MCP / ACP
Complete OAuth / PKCE authorization lifecycle

1. Shell and Release Information

Info.plist shows Bundle ID as com.yetone.alma, version 0.0.170, minimum system macOS 12.0, main class AtomApplication, clearly belonging to the Electron / Atom shell family.
NSAllowsArbitraryLoads is enabled along with local network access exemptions, indicating the app needs to freely communicate with various model services, proxies, or local services.
Auto-update configuration is located at Resources/app-update.yml, with update source pointing to a self-hosted feed: https://updates.alma.now/, meaning the official team maintains a complete update publishing backend.
Core logic is packaged in app.asar, which unpacks to a typical Electron structure: out/, node_modules/, package.json.

2. Project Structure and Dependencies

package.json defines Alma as an “AI Provider Management Desktop App”, using pnpm for dependency management, with onlyBuiltDependencies enabled for Electron native modules. It also fixes the node-abi version via overrides to match the built-in node-pty beta.

Dependencies can be roughly divided into four categories:

2.1 AI Provider SDK

@ai-sdk/* (openai / anthropic / azure / google / deepseek / openrouter)
@ai-sdk/provider
@mcpc-tech/acp-ai-provider
@aihubmix/ai-sdk-provider

Used to uniformly abstract generation, streaming output, and tool calling across different models.

2.2 Desktop Local Capabilities (Key Focus)

better-sqlite3, sqlite-vec
[email protected]
playwright@^1.57.0
chromium-bidi
@fugood/whisper.node

This group of dependencies is crucial—it clearly shows: Alma isn’t “pretending to be desktop”—it actually runs tools locally.

2.3 Document and Content Preview

PDF, Excel, Word, tokenization, image dimensions, Emoji processing capabilities for multi-format content display.

2.4 UI and Monitoring

Radix, framer-motion, sonner, PostHog, Sentry, forming a modern React desktop UI and observability system.

3. Main Process (`out/main/index.js`) Deep Dive

The main process is Alma’s “control tower,” bringing together system capabilities, local services, databases, and AI Providers.

3.1 Environment Setup and Dependency Injection

Electron core module loading
Uses fix-path to fix CLI environment on macOS
Starts local Express API + WebSocket server
Uses zod for interface schema validation
Initializes Sentry and AI Tool middleware

3.2 Database Layer (Drizzle + SQLite)

Covers core tables: Prompt, Workspace, Chat, Provider, Skill, MCP, Theme
Version 0.0.170 adds subscription types (like claude-subscription) and configuration fields to the Provider table
Uses Drizzle relations to explicitly express complex UI relationships

3.3 AI Provider / Tool System

Uses ai package to unify text and streaming output across different models
Integrates ACP tool system with UI tool stream support
Built-in Proxy + Retry + Timeout, supports HTTP / SOCKS5

3.4 Local API + MCP / OAuth

Local REST API + WebSocket push
Complete MCP OAuth lifecycle (authorization, refresh, revocation)
Claude Subscription authorization flow built into IPC

3.5 Playwright: Not an Afterthought, but Explicit Infrastructure

Playwright in Alma is explicitly present, explicitly used, and explicitly lifecycle-managed—not a future placeholder option.

First, at the dependency level:

package.json directly declares "playwright": "^1.57.0"
Placed in the same group of “desktop automation dependencies” as node-pty and chromium-bidi
This means Playwright is installed into the app during the build phase (not via runtime npm install)

Second, installation and state management logic in the main process:

The main process maintains a complete Playwright installation detection flow:
- Checks ~/Library/Caches/ms-playwright/ (macOS) or %LOCALAPPDATA%/ms-playwright
- Determines if chromium-* directories already exist
If not installed:
- Pulls browser kernel via playwright-core/cli.js install chromium
- Installation status recorded in ta = { installed, installing, progress }
Exposes complete control surface via IPC:
- playwright-get-status
- playwright-install
- playwright-install-status (real-time progress events)

The purpose of this mechanism is very clear:

To provide Alma’s WebFetch / WebSearch / automated scraping capabilities with a controllable, stable, version-fixed Chromium kernel.

Therefore:

The app calls ra() during startup to attempt silent installation
UI allows users to view installation status or manually trigger again
Only when the Playwright browser is ready will background web scraping and script execution capabilities actually be enabled

This also explains why Alma must be a desktop application: These capabilities are almost impossible to reliably implement in a pure web environment.

3.6 System Capabilities and IPC Interfaces

IPC covers almost all desktop capabilities:

Multi-window management
Global and dynamic keyboard shortcuts
Clipboard and file system
Microphone, Whisper, Playwright status
Auto-updates
Copilot / Claude token management
MCP OAuth
WebFetch / WebSearch debug windows

4. Renderer Layer (React + Vite)

React + Vite + SWR + jotai
An aggregated Context as the UI logic bus
Chat, tool management, multi-window control
Full-format content preview
Radix UI + animations
PostHog / Sentry monitoring

All capabilities uniformly call the main process via IPC injected through preload.

5. Development and Debugging

Supports Vite DevServer hot reload
TypeScript + pnpm workspaces
Official GitHub source code is more suitable for reading and secondary development than the bundle

6. Security, Privacy, and System Permissions

Requests microphone, Bluetooth, camera permissions
Supports proxy configuration
Telemetry (Sentry / PostHog) should be evaluated based on deployment scenario
MCP OAuth uses PKCE, supports token revoke / refresh

7. Summary

Alma 0.0.170 demonstrates a very “substantial” desktop AI application form:

Upper layer: Multi-window, conversation-driven UI
Middle layer: Unified orchestration of Provider, Prompt, Skill, MCP
Lower layer: Real local infrastructure—database, terminal, Playwright Chromium, voice models

Combining the official positioning with actual engineering implementation, Alma is more like an AI capability scheduling and execution platform, not just a chat tool. In the direction of “AI desktop applications,” it provides a structurally complete, engineering-solid implementation sample that clearly has room to grow.

Dia: A Technical Deep Dive into The Browser Company's macOS Browser

Fri, 02 Jan 2026 00:00:00 +0000

If you’ve been following Arc, you’ve probably heard of Dia. It’s another browser product from The Browser Company, currently targeting macOS.

From a user experience perspective, Dia continues some of Arc’s design philosophy; but if you dig into the Dia.app bundle contents, you’ll find that its engineering structure and system integration are quite “traditional” and interesting.

This article doesn’t discuss whether the experience is good or bad, nor does it predict future directions. It does one thing:

Examine how Dia is actually built from a technical perspective.

The Company Behind Dia: The Browser Company

Let me provide some brief background.

The Browser Company was founded in 2019, headquartered in New York, and first gained attention with the Arc browser. The company’s public mission has been clear: explore new interaction patterns and usage models around the “browser” as a platform.

Regarding funding, based on publicly available information:

The company has raised approximately $128 million in total
This includes a $50 million round in 2024
Investors include both venture capital firms and individual investors with backgrounds in internet products

As of now, The Browser Company has not been acquired and continues to operate independently, with Dia being part of its in-house product line.

What Kind of Application is Dia?

Open Contents/MacOS/Dia in Dia.app, and you’ll see something familiar:

arm64 Mach-O
Built with Xcode 16.4
Minimum system version: macOS 14
Entry point is AppKit’s MainMenu.nib

This pretty much tells you everything:

Dia is a standard native macOS application.

It’s not Electron, and it’s not a “wrapped web page.” This is also evident from its use of system capabilities, such as:

AppleScript (Dia.sdef)
Dock Tile plugins
NSUserActivityTypeBrowsingWeb
Native registration of http / https schemes
Declarations for camera, microphone, Bluetooth, location, desktop, downloads, and other permissions

These are all standard operations in the AppKit world, but they’re typically cumbersome in cross-platform frameworks.

Browser Engine: Not WebKit, but ArcCore

At the rendering layer, Dia doesn’t follow Safari’s WebKit path.

It relies on a private framework called ArcCore.framework. From the Info metadata, you can see:

Version: 143.0.7499.170
Corresponding Chromium: branch-heads/7499@{#3400}

In other words, Dia embeds a Chromium branch maintained by the Arc team.

If you look at dependencies with otool -L, you’ll find a typical combination:

UI / System layer: AppKit, SwiftUI, Combine
Rendering / Scripting: Chromium (via ArcCore), JavaScriptCore
Performance: Metal, Accelerate

The overall architecture can be understood as:

Native macOS application + Chromium as web rendering component

Browser windows, animations, and interactions are handled at the native layer, while Chromium primarily handles web content itself.

A Notable Design: Extensive Use of Bundles

The truly “engineering-focused” part is in Contents/Resources.

This isn’t just a simple resource directory—it’s packed with bundles, such as:

BoostBrowser_TabUI.bundle
Download panel-related bundles
Personalization modules
Supertab-related components
A series of ARC_* bundles

What these bundles have in common:

Each has its own Info.plist
Built separately by Xcode
Each declares its minimum macOS version

This indicates that Dia uses a modular architecture at the functional level: Features like tab UI, downloads, and personalization aren’t all compiled into one large binary.

From an engineering perspective, this approach makes it easier to:

Develop and debug independently
Control feature loading
Manage complex UI components

Data, Updates, and Stability: Conventional Choices

For infrastructure, Dia uses mature solutions:

GRDB.framework (SQLite ORM) For local data storage
Sparkle.framework For automatic application updates Update source is explicitly declared in Info.plist
Sentry.framework For crash and performance monitoring

You can also see dependencies like Datadog, ZIPFoundation, and SDWebImage, all focused on logging, resource handling, and stability.

Overall, this layer doesn’t have much “experimental design”—it leans toward stable, proven implementations.

Local AI: Infrastructure Already in Place

In the resources directory, there’s another notable group of bundles:

swift-transformers_Hub.bundle
mlx-swift_Cmlx.bundle
AIInfra_LocalClassification.bundle
OnDeviceLoRAadaptors.bundle

Based on their names and Info metadata, these components involve:

Swift Transformers
Apple MLX
Local model inference
LoRA adapters

They’re also built with Xcode, with minimum support for macOS 13. This shows that Dia has already prepared the engineering foundation for local ML inference in its architecture; what specific features use it depends on product-level implementation.

Closing Thoughts

If we only look at the application bundle and dependency structure, Dia’s architecture is quite clear:

It’s a native macOS application
Uses a custom Chromium branch as its web rendering engine
Employs a bundle-based modular organization for features
Infrastructure choices lean toward mature and stable solutions
Has already prepared the engineering foundation for local ML capabilities

Not radical, not conservative—more like a serious approach to “building a browser” within the macOS ecosystem.

JavaScript Runtime with deno_core

Sun, 31 Jul 2022 00:00:00 +0000

If you’re not familiar with Deno, check out the official website at https://deno.land/. In short, Deno is a more secure alternative to Node (the name is literally Node reversed: no_de -> de_no), created by the same founder as Node.

A couple of days ago, the Deno blog published an article titled “Roll your own JavaScript runtime”

https://deno.com/blog/roll-your-own-javascript-runtime

I was inspired to write this learning note after reading the article. Note: This is not a word-for-word translation, but rather a learning record with minor modifications while preserving the original meaning. The “inspiration” came from the fact that about six months ago, I looked at Deno’s documentation on Embedding Deno (https://deno.land/manual/embedding_deno), but it didn’t have much content—it just pointed to the deno_core documentation (https://crates.io/crates/deno_core) without any getting started tutorial. At the time, my Rust skills weren’t strong enough, so I didn’t continue exploring.

Without further ado, let’s get started.

Main Content

This article explains how to create a custom JavaScript runtime called runjs. Think of it as a very simple version of Deno. The goal is to develop a command-line program that can execute local JavaScript files, with the ability to read, write, and delete files, plus a console API.

Let’s begin.

Prerequisites

This tutorial assumes you have knowledge of:

Basic Rust
Basic understanding of JavaScript event loops

Make sure you have Rust installed (cargo is automatically installed with Rust) with version 1.62.0 or higher. Visit https://www.rust-lang.org/learn/get-started to install it.

$ cargo --version
cargo 1.62.0 (a748cf5a3 2022-06-08)

Creating the Project

First, let’s create a new Rust project called runjs:

$ cargo new runjs
     Created binary (application) package

Navigate to the runjs folder and open it in your editor. Make sure everything works:

$ cd runjs
$ cargo run
   Compiling runjs v0.1.0 (/Users/ib/dev/runjs)
    Finished dev [unoptimized + debuginfo] target(s) in 1.76s
     Running `target/debug/runjs`
Hello, world!

Perfect! Now let’s start building our own JavaScript runtime.

Dependencies

Next, add the dependencies deno_core and tokio:

$ cargo add deno_core
    Updating crates.io index
      Adding deno_core v0.142.0 to dependencies.
$ cargo add tokio --features=full
    Updating crates.io index
      Adding tokio v1.19.2 to dependencies.

Your Cargo.toml file should now look like this:

[package]
name = "runjs"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
deno_core = "0.142.0"
tokio = { version = "1.19.2", features = ["full"] }

deno_core is a Rust crate developed by the Deno team that abstracts the V8 JavaScript engine interface. V8 is a complex project with many APIs. To make V8 easier to use, deno_core provides the JsRuntime struct, which wraps a V8 engine instance (also called an Isolate) and supports event loops.

tokio is an asynchronous Rust runtime that we’ll use to implement the event loop. Tokio can interact with system sockets and the file system. Together, deno_core and tokio enable mapping JavaScript Promises to Rust Futures (i.e., JS async/await maps to Rust async/await).

With a JavaScript engine and an event loop, we can create a JavaScript runtime.

Hello, runjs!

Now let’s write an async Rust function that creates a JsRuntime instance for executing JavaScript:

// main.rs
use std::rc::Rc;
use deno_core::error::AnyError;

async fn run_js(file_path: &str) -> Result<(), AnyError> {
  let main_module = deno_core::resolve_path(file_path)?;
  let mut js_runtime = deno_core::JsRuntime::new(deno_core::RuntimeOptions {
      module_loader: Some(Rc::new(deno_core::FsModuleLoader)),
      ..Default::default()
  });

  let mod_id = js_runtime.load_main_module(&main_module, None).await?;
  let result = js_runtime.mod_evaluate(mod_id);
  js_runtime.run_event_loop(false).await?;
  result.await?
}

fn main() {
  println!("Hello, world!");
}

There’s a lot to unpack here. The async run_js function creates a JsRuntime instance that uses a file system-based module loader (deno_core::FsModuleLoader). Then, we load a module (main_module) with js_runtime, evaluate it (mod_evaluate), and run an event loop (run_event_loop).

The run_js function encompasses the entire lifecycle of JavaScript code execution. But first, we need to create a single-threaded tokio runtime to execute the run_js function:

// main.rs
fn main() {
  let runtime = tokio::runtime::Builder::new_current_thread()
    .enable_all()
    .build()
    .unwrap();
  if let Err(error) = runtime.block_on(run_js("./example.js")) {
    eprintln!("error: {}", error);
  }
}

Let’s execute some JavaScript code. Create an example.js file that outputs “Hello runjs!”:

// example.js
Deno.core.print("Hello runjs!");

Note: example.js is in the project root folder. cargo run uses the root folder as the working directory.

Note that we’re using the print function from Deno.core. Deno.core is a globally available built-in object provided by deno_core.

Now let’s run it:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/runjs`
Hello runjs!⏎

Success! We’ve created a simple JavaScript runtime that can execute local files with just 25 lines of code. Of course, this runtime can’t do much yet (for example, it doesn’t support console.log). We’ve now integrated the V8 JavaScript engine and tokio into our project.

Adding the Console API

Let’s implement the console API. First, create a src/runtime.js file that implements the global console object:

// src/runtime.js
((globalThis) => {
  const core = Deno.core;

  function argsToMessage(...args) {
    return args.map((arg) => JSON.stringify(arg)).join(" ");
  }

  globalThis.console = {
    log: (...args) => {
      core.print(`[out]: ${argsToMessage(...args)}\n`, false);
    },
    error: (...args) => {
      core.print(`[err]: ${argsToMessage(...args)}\n`, true);
    },
  };
})(globalThis);

Note: This runtime.js file is in the src folder.

The console.log and console.error functions can accept multiple arguments, serialize them to JSON (so we can view non-native JS objects), and prefix each message with “log” or “error”. This is a somewhat “old-school” JavaScript file, like writing JavaScript in the browser before ES modules existed.

We use an IIFE to execute the code to avoid polluting the global scope. Otherwise, the argsToMessage helper function would be globally available in our runtime.

Now let’s execute this code every time we run:

let mut js_runtime = deno_core::JsRuntime::new(deno_core::RuntimeOptions {
  module_loader: Some(Rc::new(deno_core::FsModuleLoader)),
  ..Default::default()
});
+ js_runtime.execute_script("[runjs:runtime.js]",  include_str!("./runtime.js")).unwrap();

Note: include_str! reads the contents of runtime.js from the same directory as main.rs (i.e., the src directory).

Finally, we can call the new console API in example.js:

- Deno.core.print("Hello runjs!");
+ console.log("Hello", "runjs!");
+ console.error("Boom!");

Run it:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/runjs`
[out]: "Hello" "runjs!"
[err]: "Boom!"

Adding File System APIs

First, update the runtime.js file:

};

+ globalThis.runjs = {
+   readFile: (path) => {
+     return core.opAsync("op_read_file", path);
+   },
+   writeFile: (path, contents) => {
+     return core.opAsync("op_write_file", path, contents);
+   },
+   removeFile: (path) => {
+     return core.opSync("op_remove_file", path);
+   },
+ };

})(globalThis);

We’ve added a new global object runjs with three methods: readFile, writeFile, and removeFile. The first two are async, and the last one is synchronous.

You might be wondering what core.opAsync and core.opSync are. They’re mechanisms provided by deno_core to bind JavaScript and Rust functions. When called from JavaScript, deno_core will look for a Rust function with the same name marked with the #[op] attribute.

Let’s update main.rs to see it in action:

+ use deno_core::op;
+ use deno_core::Extension;
use deno_core::error::AnyError;
use std::rc::Rc;

+ #[op]
+ async fn op_read_file(path: String) -> Result<String, AnyError> {
+     let contents = tokio::fs::read_to_string(path).await?;
+     Ok(contents)
+ }
+
+ #[op]
+ async fn op_write_file(path: String, contents: String) -> Result<(), AnyError> {
+     tokio::fs::write(path, contents).await?;
+     Ok(())
+ }
+
+ #[op]
+ fn op_remove_file(path: String) -> Result<(), AnyError> {
+     std::fs::remove_file(path)?;
+     Ok(())
+ }

We’ve defined three ops that JavaScript can call, but to make them available to JavaScript code, we need to register an extension with JsRuntime:

async fn run_js(file_path: &str) -> Result<(), AnyError> {
    let main_module = deno_core::resolve_path(file_path)?;
+    let runjs_extension = Extension::builder()
+        .ops(vec![
+            op_read_file::decl(),
+            op_write_file::decl(),
+            op_remove_file::decl(),
+        ])
+        .build();
    let mut js_runtime = deno_core::JsRuntime::new(deno_core::RuntimeOptions {
        module_loader: Some(Rc::new(deno_core::FsModuleLoader)),
+        extensions: vec![runjs_extension],
        ..Default::default()
    });

We can configure JsRuntime with Extensions to expose Rust functions to JavaScript, and do more advanced things (like loading additional JavaScript code).

Update example.js again:

console.log("Hello", "runjs!");
console.error("Boom!");
+
+ const path = "./log.txt";
+ try {
+   const contents = await runjs.readFile(path);
+   console.log("Read from a file", contents);
+ } catch (err) {
+   console.error("Unable to read file", path, err);
+ }
+
+ await runjs.writeFile(path, "I can write to a file.");
+ const contents = await runjs.readFile(path);
+ console.log("Read from a file", path, "contents:", contents);
+ console.log("Removing file", path);
+ runjs.removeFile(path);
+ console.log("File removed");
+

Run it:

$ cargo run
   Compiling runjs v0.1.0 (/Users/ib/dev/runjs)
    Finished dev [unoptimized + debuginfo] target(s) in 0.97s
     Running `target/debug/runjs`
[out]: "Hello" "runjs!"
[err]: "Boom!"
[err]: "Unable to read file" "./log.txt" {"code":"ENOENT"}
[out]: "Read from a file" "./log.txt" "contents:" "I can write to a file."
[out]: "Removing file" "./log.txt"
[out]: "File removed"

🎉 Congratulations! Our runjs runtime now supports the file system. Notice how we implemented JavaScript calling Rust code with very little code: deno_core handles all the communication between JavaScript and Rust.

Summary

In this brief example, we’ve implemented a Rust project that integrates a powerful JavaScript engine (V8) with an efficient event loop (tokio).

For the complete example code, check out denoland’s GitHub:

https://github.com/denoland/roll-your-own-javascript-runtime

LLDB Breakpoint All UIPasteboard Methods

Thu, 25 Jun 2020 00:00:00 +0000

iOS14 added a privacy protection feature, when current App reads content other Apps copied to clipboard, will have a brief prompt. As below:

Can breakpoint all UIPasteboard methods to check all clipboard-related behaviors in App.

Breakpoint all UIPasteboard methods can use command below:

breakpoint set -r '\[UIPasteboard .*\]$'

First breakpoint at main, then input above command in lldb terminal.

(Figure above only screenshotted part of UIPasteboard methods)

Summary

Hmm, everyone try～ Will discover besides our own calls, system also occasionally triggers UIPasteboard related calls.

Very interesting～

How to List All +load Methods in App

Tue, 28 Apr 2020 00:00:00 +0000

Objective C +load method is a magical and evil method.

When beginners get it, will be amazed by its magic.
When experts get it, will be addicted unable to extricate.
When veterans get it, will be terrified by its evil.

Most large Apps already or are trying to get rid of it. Then, how to quickly see how many +load methods in your App, see how deep the poison.

Assume scenario below:

One day you happily debugging program with Xcode,

Open Xcode, press F5,

Suddenly, you want to see how many +load methods in App?

Click Pause, then input

br s -r "\+\[.+ load\]$"

Then input

br list

Perhaps you’ll be surprised, turns out my App has so many (or few) +load methods

Principle

Used lldb’s breakpoint command.

br s -r "regex"
is 
breakpoint set -r "regex"

Set breakpoint through regex matching symbols.

Small Question

Then think, if code in these +load methods crashes, can your crash monitoring (bugly, etc.) monitor it?

Of course 90% answer is: Won’t Crash.

Makes me think of Trump’s words: My “code” is perfect.

Haha :)

Summary

Very interesting:)

Ah, I’m so inexperienced, I need to learn “Bridge-based Full Method Hook” now

http://satanwoo.github.io/2020/04/26/TrampolineHookOpenSource/

If everyone likes, follow subscription account to encourage:

How to Breakpoint at Function's return

Thu, 23 Apr 2020 00:00:00 +0000

Has a complex function with many code lines, internally has many returns, step debugging very slow, how to quickly find which line returned?

For example code:

void foo() {
    int i = arc4random() %100;
    
    if (i > 30) {
        if (i < 40) {
            return;
        }
        if (i > 77) {
            return;
        }
        if (i < 66) {
            return;
        }
    }
    
    switch (i) {
        case 0:
            return;
        case 1:
            return;
        case 2:
            return;
        case 3:
            return;
        case 4:
            return;
        default:
            return;
    }
}

int main(int argc, const char * argv[]) {
    foo();
    return 0;
}

Assume foo is a very long complex function with many returns, how to know which line returned?

Can use lldb’s breakpoint

breakpoint set -p return
or
br set -p return

First add breakpoint at foo’s first line

After breakpoint triggers, console input br set -p return

Then continue, will breakpoint at function’s return line.

Very interesting~

If everyone likes, follow subscription account to encourage:

When Does ObjC Object in C++ Class dealloc

Fri, 17 Apr 2020 00:00:00 +0000

When using Objective C++, can use C++’s struct or class to store Objective C objects.

For example:

struct CppStruct {
    MyObject *obj;
};

Then suddenly think, if CppStruct destructs, will MyObject dealloc? Don’t need to think much, definitely will. But how is it done?

Write code to verify,

@interface MyObject : NSObject
@end
@implementation MyObject
- (instancetype)init {
    self = [super init];
    if (self) {
        NSLog(@"MyObject init");
    }
    return self;
}
- (void)dealloc {
    NSLog(@"MyObject dealloc");
}
@end

struct CppStruct {
    MyObject *obj;
    CppStruct() {
        NSLog(@"CppStruct constructor");
    }
    ~CppStruct() {
        NSLog(@"CppStruct destructor");
    }
};

CppStruct * CreateStruct() {
    CppStruct * s = new CppStruct();
    s->obj = [[MyObject alloc] init];
    return s;
}

void FreeStruct(CppStruct *s) {
    delete s;
}

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        CppStruct *s = CreateStruct();
        FreeStruct(s);
    }
    return 0;
}

Output below

Can know, MyObject indeed dealloced.

Then, breakpoint at dealloc, see how called.

See figure above has two ~CppStruct(), one called objc_storeStrong, objc_storeStrong further triggered MyObject’s dealloc.

From figure above can know, compiler must generated objc_storeStrong call code.

Look at Disassembly, indeed generated objc_storeStrong call code.

Further confirmed.

How LLVM generates this logic, won’t search ha.

References

Above debugging used compilable objc runtime, GitHub has many, can search corresponding objc version:

https://github.com/search?q=objc+779.1 https://github.com/LGCooci/objc4_debug

Summary

In future can boldly use C++ struct to store Objective C objects.

Very interesting :)

If everyone likes, follow subscription account to encourage:

Hidden Symbol in ?WhatsApp App Name

Mon, 30 Mar 2020 00:00:00 +0000

Welcome everyone to watch this episode of “Approaching Science: WhatsApp Mysterious Symbol”～

Crime Scene

About half a year or even longer ago, when using frida-ios-dump, accidentally discovered WhatsApp app’s name a bit strange.

frida-ios-dump is a jailbreak iOS App decryption tool (can also list iOS app list). Address: https://github.com/AloneMonkey/frida-ios-dump

Carefully look at WhatsApp in figure below:

WhatsApp’s name left alignment different from other Apps.

… How many times hurriedly passed by … How many times treated as non-existent …

Until today I finally got curious once, want to see why not aligned here.

Start

Smash, try smashing.

python dump.py net.whatsapp.WhatsApp

After smashing, as below. Appears a question mark. ?WhatsApp.ipa, what is question mark.

Prepare mv to other folder to research, at this moment…

Mysterious character \342\200\216 appeared, just curious…

Search

Casually searched … really found :)

https://graphemica.com/200E

Open to see, really has meaning～ left-to-right mark

Truth Revealed

Wikipedia also has explanation

The left-to-right mark (LRM) is a control character (an invisible formatting character) used in computerized typesetting (including word processing in a program like Microsoft Word) of text that contains a mixture of left-to-right text (such as English or Russian) and right-to-left text (such as Arabic, Persian or Hebrew). It is used to set the way adjacent characters are grouped with respect to text direction.

https://en.wikipedia.org/wiki/Left-to-right_mark

Paste translation:

Left-to-right mark (Left-to-right mark,LRM) is a control character, or invisible typesetting symbol. Used in computer bidirectional text typesetting.

I say in plain language. Left-to-right mark is an invisible symbol, used to include left-to-right text in right-to-left typesetting languages (for example Arabic).

Example in figure below is clearer: after using LRM symbol, Arabic (right-to-left) contains displayed C++ (left-to-right).

Extended Reading

Has Left-to-right mark, also has Right-to-left mark.

https://en.wikipedia.org/wiki/Right-to-left_mark

Further

Take WhatsApp’s Info.plist file out to look, seems nothing special.

Look with binary editor.

\342\200\216 is 0xE2 0x80 0x8E (e2808e)

This way in code getting CFBundleDisplayName and concatenating with other localized languages, can ensure WhatsApp’s order from left to right.

Very interesting :)

If everyone likes, follow subscription account to encourage:

Running Android on iPhone

Fri, 06 Mar 2020 00:00:00 +0000

First time in history to make Android system run on iPhone. Currently (March 6, 2020) version only supports iPhone7/7 Plus. (iOS system version no requirement)

Project Sandcastle: Android for the iPhone Project address: https://projectsandcastle.org/

Happened to have an iPhone7, experienced it. Steps simply summarized, share with everyone. Ideal steps below, but due to macOS security mechanisms, steps 2 and 3 not so smooth and pleasant.

Use checkra1n to jailbreak
Run start_mac.sh
Run setup_mac.sh

Jailbreak

Download https://checkra.in/ follow steps to jailbreak. (iPhone connect to Mac using USB.)

After jailbreak, enter iOS.

Download Android Build

Download Android Build at https://projectsandcastle.org/status.

Extract downloaded file.

setup_mac.sh

iPhone connect to Mac using USB. Ideally, execute ./setup_mac.sh on macOS. But my execution not smooth. Built-in iproxy and two dynamic libraries’ signatures first execution still need trust. But actually functionality is iproxy’s functionality, so below manually execute steps in setup_mac.sh.

Can first ssh connect to iOS, ensure manual connection succeeds. Then reference steps below.

(1)

iproxy 2222 44

(2) Copy isetup to iOS’s /tmp/setup.sh

scp -P2222 -o StrictHostKeyChecking=no isetup root@localhost:/tmp/setup.sh

(3) Two methods:

One, FQ. Or, modify network connection test address in setup.sh, for example specifically test if internet works baidu (looks like foreigners also correspondingly use google to test ha)

Recommend using FQ method, because this script will download 470MB file, my home Wi-Fi without FQ, downloading this file very slow, after FQ seems few minutes done.

(4) Execute /tmp/setup.sh

Enter DFU Mode

iPhone power off.
Simultaneously press volume down + power button, 10 seconds (strictly 10 seconds).
Release power button, continue holding volume down.
At this time phone screen will stay black, indicates entered DFU mode.

Then in DFU mode, execute ./start_mac.sh.

Ideally, after execution completes done. But reality cruel, I saw popup below (ten thousand alpacas running in heart, afraid phone broken…), of course click Cancel.

Enter System Preferences -> Security & Privacy -> General, click Allow Anyway.

At this time still not OK, to prevent just in case, first command then execute once

./load-linux.mac

Then can click Open.

But at this time re-executing start_mac.sh seems can’t “resume continue”, heart X#@%$$. “Smart” me looked at start_mac.sh’s code, looks can execute this step.

./load-linux.mac Android.lzma dtbpack

Finally succeeded, Android system started on iPhone.

Screenshots

Summary

Runs quite laggy.
Restart returns to iOS.

Still quite interesting, video can search everettjf on Douyin to view.

If everyone likes, follow subscription account to encourage:

Getting Started with KernelSU: Installing a Minimal App Hiding Module on Pixel 6

What is KernelSU

Metamodule Mechanism

Test Environment

Flashing Official Android 15

KernelSU (LKM Mode) Installation Notes

Basic Tools Setup

Zygisk Next and LSPosed

Verifying Hook Capabilities with Hide My Applist

Summary

Alma: Reverse Engineering an AI Provider Orchestration Desktop App

What is Alma?

Author and Project Source

1. Shell and Release Information

2. Project Structure and Dependencies

2.1 AI Provider SDK

2.2 Desktop Local Capabilities (Key Focus)

2.3 Document and Content Preview

2.4 UI and Monitoring

3. Main Process (out/main/index.js) Deep Dive

3.1 Environment Setup and Dependency Injection

3.2 Database Layer (Drizzle + SQLite)

3.3 AI Provider / Tool System

3.4 Local API + MCP / OAuth

3.5 Playwright: Not an Afterthought, but Explicit Infrastructure

3.6 System Capabilities and IPC Interfaces

4. Renderer Layer (React + Vite)

5. Development and Debugging

6. Security, Privacy, and System Permissions

7. Summary

Dia: A Technical Deep Dive into The Browser Company's macOS Browser

The Company Behind Dia: The Browser Company

What Kind of Application is Dia?

Browser Engine: Not WebKit, but ArcCore

A Notable Design: Extensive Use of Bundles

Data, Updates, and Stability: Conventional Choices

Local AI: Infrastructure Already in Place

Closing Thoughts

JavaScript Runtime with deno_core

Main Content

Prerequisites

Creating the Project

Dependencies

Hello, runjs!

Adding the Console API

Adding File System APIs

Summary

LLDB Breakpoint All UIPasteboard Methods

Summary

How to List All +load Methods in App

Principle

Small Question

Summary

How to Breakpoint at Function's return

When Does ObjC Object in C++ Class dealloc

References

Summary

Hidden Symbol in ?WhatsApp App Name

Crime Scene

Start

Search

Truth Revealed

Extended Reading

Further

Running Android on iPhone

Jailbreak

Download Android Build

setup_mac.sh

Enter DFU Mode

Screenshots

Summary

3. Main Process (`out/main/index.js`) Deep Dive