Recently, a serious vulnerability was discovered affecting certain Android devices: CVE-2024-49736. This issue arises from a logic flaw in the onClick handler within the MainClear.java source file. The problem? It allows a factory reset to be triggered without the user’s explicit consent, without their interaction, and without requiring elevated privileges.
This vulnerability could lead to a local denial of service (DoS) — essentially wiping a device back to its factory settings and causing users to lose all their data, settings, and customizations.
In this post, we'll break down exactly what’s wrong, how it can be exploited, and point you to further reading.
What is CVE-2024-49736?
CVE-2024-49736 is a vulnerability found in some Android devices, rooted in the implementation of the onClick method in the MainClear.java file. Due to how the code is structured, an attacker can remotely trigger a factory reset without needing to trick the user or gain special permissions.
Let’s take a look at a simplified and illustrative version of the vulnerable function
public void onClick(View v) {
// ... code omitted for clarity
// We expect some confirmation from user here
if (v.getId() == R.id.factory_reset_button) {
// Oops, this code triggers a reset without checking for user confirmation!
performFactoryReset();
}
}
Where’s the Problem?
The key issue: there’s no check to confirm the user approved the reset. A malicious local process or other creative method could programmatically call this function (directly or via a specially crafted Intent in some Android setups), and the device would trigger a factory reset instantly.
The intended logic likely looked like this (also simplified)
public void onClick(View v) {
if (v.getId() == R.id.factory_reset_button && userConfirmed()) {
performFactoryReset();
}
}
But in the vulnerable code, the userConfirmed() step is missing!
Exploit Details
Because the logic doesn’t verify user consent, an attacker doesn’t need much to trigger the reset. On devices where this code runs as part of a public activity or service, it may be triggered by sending an Intent or simulating a button press programmatically.
Example Exploit (PoC)
Suppose the MainClear activity is exported (not protected by permissions) and can be invoked via an Intent. Here’s how a local malicious app could wipe the device:
Intent intent = new Intent();
intent.setComponent(new ComponentName("com.android.settings",
"com.android.settings.MainClear"));
context.startActivity(intent);
// If the onClick handler is called internally (e.g., from onCreate),
// the factory reset happens instantly!
Note: The actual exploit may vary by device and app structure, but this illustrates the general issue: a reset can happen without confirmation, and no user prompt will appear.
No user action needed.
- Result: Super persistent and frustrating denial of service — may be especially bad for enterprise devices, kiosks, or critical services.
Affected Devices
This vulnerability has been seen in Android devices that ship with the affected MainClear.java logic. Exact affected models may vary; if you manage Android devices, check with your vendor and monitor for patches.
Mitigation and Patch
Vendors are addressing the bug by ensuring a robust confirmation flow — ideally, requiring genuine user affirmation before executing a factory reset. If you’re a developer:
Here’s the fixed logic
public void onClick(View v) {
if (v.getId() == R.id.factory_reset_button && userConfirmed()) {
performFactoryReset();
}
}
References
- NVD - CVE-2024-49736 Details
- Android Open Source Project: Factory Reset Code
- Android Security Best Practices
Conclusion
CVE-2024-49736 reminds us how a simple logic mistake can cause huge risk. If you’re a user, update your device as soon as possible. If you’re a developer, always double-check critical workflows — especially those that can erase user data.
Timeline
Published on: 01/21/2025 23:15:14 UTC
Last modified on: 03/24/2025 16:15:19 UTC