Nuke Device: Remote Android Wipe System via Firebase

Nuke Device is a remote device management system I built for enterprise security scenarios where you need the ability to remotely wipe, lock, or verify connectivity of Android devices in the field. The system uses Firebase Realtime Database and FCM push notifications to deliver commands even when the app is killed — making it reliable for high-stakes security operations.

Why I Built Nuke Device

Corporate device management is a real problem. Devices get lost, stolen, or compromised. Traditional MDM solutions are expensive and bloated. I needed something lightweight, reliable, and deployable in minutes — not weeks. Nuke Device solves this with a two-component architecture: a Flutter Android app that registers as Device Admin, and a Python control panel that sends commands through Firebase.

The critical requirement was that wipe and lock commands must work even when the app is killed. This is achieved through FCM high-priority data messages that wake the device and execute commands via a background Kotlin service — no user interaction required.

Architecture: How Nuke Device Works

The system operates on a simple but robust principle: Firebase Realtime Database acts as the command bus, and FCM push notifications ensure delivery even when the app process is terminated.

The Android app (Flutter + Kotlin) registers as a Device Admin on the target device, obtains an FCM token, and starts listening for commands on the commands/{device_id} path. Every 30 seconds it sends a heartbeat with device status — battery level, Wi-Fi state, IP addresses, screen lock status, and admin permissions.

The Python control panel reads the device registry from devices/, displays status dashboards, and writes commands to Firebase. Both CLI and GUI (Tkinter) interfaces are available. When a command is sent, an FCM push with high priority is also dispatched to ensure the device wakes up.

Three Core Commands

Nuke Device supports three operations, each with acknowledgement tracking:

• Hello Test — verifies connectivity. The device writes an acknowledgement back to Firebase, and the prefix indicates whether it was delivered via the database listener (app open) or FCM service (app killed)
• Lock — remotely locks the screen using DevicePolicyManager.lockNow(). Works instantly in both foreground and background
• Wipe — the nuclear option. Calls DevicePolicyManager.wipeData(0) for a complete factory reset. Before wiping, the FCM service synchronously writes an acknowledgement using a CountDownLatch with a 3-second timeout — because after wipeData(), the process dies

Firebase Security Architecture

The system uses Firebase Anonymous Auth for device authentication. Each device is identified by its ANDROID_ID from Settings.Secure, which is unique per device and persistent across app reinstalls. The database structure separates concerns cleanly:

• devices/{id} — device writes status, control panel reads
• commands/{id} — control panel writes commands, device reads and executes

The FCM service takes a WakeLock for 10 seconds on each message to ensure command execution completes before Android puts the device back to sleep. For wipe commands specifically, the acknowledgement is written synchronously before calling wipeData() — a critical design decision since the factory reset terminates the process immediately.

Technology Stack

• Android App: Flutter (Dart UI) + Kotlin native (Method Channel for DevicePolicyManager, FCM Service, device info APIs)
• Control Panel: Python + firebase-admin SDK, CLI and Tkinter GUI
• Backend: Firebase Realtime Database (command bus + status), Firebase Cloud Messaging (push delivery), Firebase Anonymous Auth
• Android APIs: DevicePolicyManager (lock, wipe), Device Admin Receiver, WakeLock, ConnectivityManager, WifiManager

The Flutter-Kotlin bridge uses a Method Channel (com.example.wipe/admin) exposing 10 native methods — from getDeviceInfo (battery, Wi-Fi, lock type) to wipeDevice (factory reset).

Real-World Application

In my work as a Fractional CTO, I’ve implemented device management solutions across multiple industries. Corporate fleets of Android tablets in restricted network environments need remote wipe capability. Retail POS devices, warehouse scanners, field service tablets — all represent data breach risks if lost or stolen.

Nuke Device demonstrates a lightweight approach compared to full MDM platforms. For organizations managing 10-100 devices with basic security requirements, this architecture provides the essential controls — remote wipe, lock, and health monitoring — without the overhead of enterprise MDM licensing.

Key Design Decisions

• FCM data messages vs notification messages: Data messages bypass Android’s notification tray and execute silently in the background service — critical for security operations
• CountDownLatch for pre-wipe ack: Synchronous write before wipeData() guarantees the control panel knows the command was received, even though the device is about to be erased
• Firebase onDisconnect handler: Automatically sets device status to “offline” when the connection drops, providing accurate fleet monitoring
• 30-second heartbeat: Balances real-time status updates with battery conservation
• WakeLock on FCM receipt: 10-second lock ensures Android doesn’t kill the process mid-execution

Source Code

The source code is available upon request. Contact me for access to the repository. The repository includes the Flutter app, Kotlin native services, Python control panel (CLI + GUI), and Firebase configuration.

For security consulting and enterprise device management solutions, get in touch — I bring over 15 years of experience in information security across 38 countries.

FAQ

Does Nuke Device work when the app is force-closed?

Yes. FCM high-priority data messages are delivered to the Kotlin background service even when the Flutter app is killed. The service takes a WakeLock to execute the command (wipe, lock, or hello test) without requiring the app to be in the foreground.

How is the factory reset confirmed?

Before calling wipeData(0), the FCM service synchronously writes a wipeAck to Firebase using a CountDownLatch with a 3-second timeout. This ensures the control panel receives confirmation that the command was delivered before the device erases itself.

What permissions does the app need?

The app requires Device Admin privileges (for lock and wipe), notification permission, battery optimization exemption (to stay alive in background), and network access. Device Admin must be explicitly activated by the user through a system dialog.

Can this be used for fleet management?

Yes. The Python control panel supports multiple devices through the Firebase device registry. Each device is identified by its unique ANDROID_ID and reports status every 30 seconds including battery, Wi-Fi, IP addresses, and admin permissions. For large fleets (100+ devices), I recommend upgrading to a full MDM solution.

Ilya Arestov — Fractional CTO | Dubai Airport Free Zone (DAFZ), Dubai, UAE | Almaty, Zenkov Street 59, Kazakhstan | +971-585-930-600 | https://t.me/getmonolith