Skip to content

Instantly share code, notes, and snippets.

@Lytes

Lytes/2.md Secret

Last active February 21, 2026 05:18
Show Gist options
  • Select an option

  • Save Lytes/571902a31a3d543da009554a82f2d00c to your computer and use it in GitHub Desktop.

Select an option

Save Lytes/571902a31a3d543da009554a82f2d00c to your computer and use it in GitHub Desktop.

Advisory: Broken Authorization in ethOS Launcher FakeAppProvider

Summary

A broken authorization vulnerability exists in the Android launcher application
org.ethosmobile.ethoslauncher on the Freedom Factory dGEN1 phone. An exported
ContentProvider (FakeAppProvider) relies on a caller-supplied value to determine
whether a request originates from a trusted application.

Because authorization is based solely on untrusted ContentValues data rather
than the actual calling UID or application signature, any local application can
impersonate the trusted dGEN App Directory and directly manipulate launcher
“FakeApp” entries.

As a result, unauthorized applications can enumerate, add, modify, or remove
launcher entries, enabling phishing and user deception.


Affected Component

  • Package: org.ethosmobile.ethoslauncher
  • Component: FakeAppProvider (exported ContentProvider)
  • Authority: org.ethosmobile.ethoslauncher.FakeAppProvider
<provider
    android:name="org.ethosmobile.ethoslauncher.FakeAppProvider"
    android:permission="android.permission.INTERNET"
    android:enabled="true"
    android:exported="true"
    android:multiprocess="true"
    android:authorities="org.ethosmobile.ethoslauncher.FakeAppProvider"
    android:grantUriPermissions="true"/>

Vulnerability Details

The DGEN1 launcher allows users to install decentralized applications (“dapps”)
from the dGEN App Directory. These dapps appear as standard launcher icons
but internally function as URL-based entries (“FakeApps”) opened via a PWA emulator.

FakeAppProvider is intended to be accessed only by the trusted directory app:

org.ethereumphone.dappstoreapp

The provider attempts to validate callers by checking a string value supplied
in ContentValues:

// FakeAppDbHelper
public static final String CALLER_PACKAGE =
    "org.ethereumphone.dappstoreapp";

// FakeAppProvider
String asString = values.getAsString(
    FakeAppService.EXTRA_CALLING_PACKAGE
);

if (!Intrinsics.areEqual(asString,
        FakeAppDbHelper.CALLER_PACKAGE)) {

    Log.e(TAG, "Unauthorized attempt to add fake app from: "
        + asString);
    return null;
}

However:

  • The callingPackage value is fully controlled by the caller.
  • No validation is performed using Binder.getCallingUid().
  • No signature-level permission is enforced.
  • The declared permission (android.permission.INTERNET) is not restrictive.
  • The provider is marked android:exported="true".

Because authorization relies entirely on a spoofable string inside
ContentValues, any unprivileged application can impersonate the trusted
package and perform database operations.


Proof of Concept

Enumerate Installed FakeApps

adb shell content query \
  --uri content://org.ethosmobile.ethoslauncher.FakeAppProvider/fakeapps

Modify All FakeApp URLs

adb shell content update \
  --uri content://org.ethosmobile.ethoslauncher.FakeAppProvider/fakeapps \
  --bind url:s:https%3A%2F%2Fkurolytes.co

Insert or Delete Entries

Any third-party app can call:

  • query
  • insert
  • update
  • delete

while spoofing:

org.ethereumphone.dappstoreapp

No special privileges are required beyond standard application permissions.


Impact

A malicious local application can:

  • Enumerate all installed FakeApps
  • Add arbitrary FakeApp launcher entries
  • Modify legitimate FakeApp URLs
  • Remove legitimate FakeApps
  • Replace trusted dapps (e.g., OpenSea, Uniswap) with attacker-controlled URLs

Because FakeApps are visually indistinguishable from legitimate launcher entries,
users cannot easily detect malicious replacements.

This may result in:

  • Phishing
  • Credential harvesting
  • Wallet compromise
  • User deception
  • Denial of access to legitimate dapps

Attack Vector

  • Local — requires installation of a malicious application on the same device
  • No special Android permissions required beyond standard app capabilities

Root Cause

  • Broken authorization logic
  • Reliance on untrusted caller-supplied ContentValues
  • Exported ContentProvider without restrictive permission enforcement
  • Failure to validate caller identity using UID or signature checks

Mitigation

  • Avoid relying on caller-supplied values for authorization decisions
  • Validate callers using Binder.getCallingUid() and package manager verification
  • Enforce a signature-level custom permission on the provider
  • Mark the provider android:exported="false" if external access is unnecessary
  • Restrict FakeApp management APIs to internal components only

Discovery

Discovered by Olaitan Ayoola (Kuro_Lytes), Maxhed LLC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment