Useful, but not the whole trust boundary
App permissions and local policy remain important. RegenX/OS asks which decisions should also be represented beneath ordinary app processes.
Resilient & secure computing
RegenX/OS
Mobile security beneath the application layer.
RegenX/OS explores a hardened Android architecture that moves selected trust, privacy, audit, and communications controls deeper into the operating platform—reducing dependence on ordinary application-layer enforcement.
Architecture & implementation researchExplore the architecture
Research question
What changes when selected controls move below ordinary app boundaries?
RegenX/OS examines where trust decisions should live when application permissions and user-space processes are not the only boundaries that matter.
RegenX/OS treats mobile security as a platform problem: selected controls span Android services, hardware interfaces, low-level enforcement, and hardware-backed trust rather than being concentrated in one app.
RegenX/OS is designed around Google Pixel 8 hardware, Android 15 AOSP, and Titan M2-backed trust. These define the architecture and integration targets; hardware validation remains a future milestone.
Why the platform layer
Some security decisions belong deeper in the platform.
Application-level controls can be limited when the same application boundary defines both what they protect and where their authority ends.
Shared controls, closer to system state
Platform services, hardware interfaces, and low-level policy offer different points for coordinating privacy, audit, communications, and trust.
A hardware root for platform trust
The architecture targets Titan M2-backed trust, while integration behavior remains subject to implementation and hardware validation.
The RegenX/OS approach
Treat mobile security as a layered system.
The architecture places each concern at the lowest practical boundary, then connects the layers through explicit platform interfaces.
Place
Locate each trust or privacy concern at the platform layer best positioned to govern it.
Separate
Keep application, service, low-level enforcement, and hardware trust boundaries distinct.
Coordinate
Design audit, policy, communications, and response paths as related parts of one mobile architecture.
Validate
Advance from architecture to reproducible builds, then validate individual controls against defined device-level tests.
Platform architecture
A target stack from applications to hardware-backed trust.
The architecture distributes trust and enforcement across the platform while keeping security-sensitive implementation details private.
Design / architecture material
A layered architecture for platform trust.
Google Pixel 8 · Android 15 AOSP · Titan M2 target
- ApplicationsUser-facing experiences and security surfaces
- System Services & Security PolicyCoordination, identity, audit, and platform policy
- Android Framework / Platform ServicesTargeted integration with the operating platform
- HAL / Hardware InterfacesDevice-facing privacy and trust boundaries
- Kernel / Low-level EnforcementPolicy and event paths beneath user space
- Hardware-backed TrustTitan M2 provides the target hardware trust boundary.
Core research areas
Security controls designed across the platform.
Each area represents a distinct security concern within the broader RegenX/OS architecture.
Hardware-bound trust
Explore key and identity boundaries tied to the Pixel 8's Titan M2 trust target.
Sensor privacy
Study camera and microphone policy at the hardware-interface layer, beneath ordinary app permissions.
Chained audit
Design an integrity-aware event path spanning low-level signals and platform-visible security state.
Network policy
Investigate platform and low-level controls for managing outbound behavior and policy decisions.
Duress response
Model coercion-aware access and lockdown behavior as an operating-platform concern.
Secure communications
Connect protected messaging and call paths to platform trust and local key boundaries.
Current development state
Architecture defined. Hardware integration comes next.
The platform model and implementation plan are defined; reproducible runtime and device behavior remain to be demonstrated.
Architecture and technical integration work
- Pixel 8 / Android 15 AOSP target and vendor-overlay integration model
- Platform architecture spanning kernel, daemon, HAL, policy, interface, and communications concerns
- Threat model, build plan, and integration requirements
Reproducible build and hardware behavior
- A reconciled, buildable source configuration
- Compiled and signed platform images
- Flash, boot, and device identity records
- Scoped tests of each claimed control and hardware boundary
Validation roadmap
From source integration to hardware validation.
These are future validation stages, not completed milestones.
- Reconcile source
Assemble and version the exact AOSP, kernel, resources, policy, and integration inputs.
- Reproduce build
Compile in a clean environment and retain a traceable build record.
- Flash & boot
Establish the device, image, boot path, and controlled diagnostic record.
- Validate controls
Exercise one control at a time with a defined threat, environment, result, and limitation.
- Publish scoped results
Share claim-specific artifacts after security, privacy, and rights checks.
Why RegenX/OS
Security designed as part of the platform.
Mobile devices concentrate identity, communication, sensors, and private data inside a platform that applications only partially control. RegenX/OS explores whether selected protections become more coherent when they are designed into that platform architecture.
It shares the wider RegenX focus on resilience and trust, but it is a distinct Android research effort—not the same implementation as the RegenX Windows engineering prototype.
Work with Korelis Labs
Explore a deeper mobile trust boundary.
Android platform, kernel, hardware-security, and validation collaborators are welcome to start a focused conversation.