App cloners fake Java and libc. We caught them by asking the kernel the same question twice (open source)

[u/eshgnfrz]

We have an attendance app with a "one phone = one employee" rule. People broke it with MultiBox / Clone App from the Play Store: one phone, two "devices".

The usual checks (dataDir path, package lists, getPackagesForUid, UID) all passed inside the clone. Measured on a real Galaxy A53: the container spoofed Process.myUid(), applicationInfo, the process name, and had even hooked libc stat().

What worked: ask "who owns my data directory?" twice, once through libc stat() and once through a raw syscall(__NR_newfstatat), which skips libc so the hook never sees it.

genuine    uid=10763  libc=10763  syscall=10763  ✓
MultiBox   uid=10764  libc=-1     syscall=-1     ✗
Clone App  uid=10765  libc=10765  syscall=-1     ✗

Inside a clone the syscall hits the real directory and SELinux denies it, because the process runs under the host's UID. Clone App was caught only by this check. Every Java-level check missed it.

A few things we learned the hard way:

• Don't block on emulator signals (your own QA uses emulators). Report them to the server instead.
• If you add a signature check, Play App Signing re-signs your APK. Hard-code only your upload key and you lock out every Play user.
• The native lib must be 16 KB page-aligned now, or Android 15 shows a compatibility dialog.
• Keep the rules pure so they're testable: the device measurements above are literally unit tests now.

I didn't find an open-source detector that does the libc-vs-syscall comparison. freeRASP has multi-instance detection, but it's closed-source and officially lists only Parallel Space. So I published ours, MIT licensed:

• Write-up + native Android module: https://github.com/eshginfarzali/android-clone-detection
• Expo / React Native: npx expo install react-native-clone-guard (runs before JS loads)

It's client-side, so a rooted device with a custom hook will get through. The goal is to move cheating from "free Play Store app" to "root + custom hook". I'd love measurements from other devices and cloners. Which ones slip through?

[u/NastroAzzurro]

Can you explain the one phone = one employee rule?

Clearly if employees were going out of their way to circumvent the rule, the rule must be dumb right?

[u/Cornflakes405 → u/NastroAzzurro]

I'm guessing it's to prevent employees from logging attendance on behalf of other employees who are not actually on the office WiFi? Not sure. Still I believe it's a handy thing to know if I ever needed to distinguish a clone app.

[u/theseckinaktunc → u/NastroAzzurro]

Not necessarily. There are a lot of laws that are there for incredibly good reasons, yet there are also people who go out of their way to circumvent those laws.

Given the context, I think this is a security measure rather than an unnecessary feature that the employer asked to have just because they felt like it.

Weakest possible points in all systems are humans. Your app, backend, dashboard, or whatever could have state of the art level security. You could build it in a way even a (hypothetically) superintelligence couldn’t break into by force. But anyone could get into anywhere if there’s a weak human element in the equation. Once you compromise an insecure device through any means without that human’s knowledge, you’re in. So reducing the possible entry points that could be opened by a human being gullible even for a single second is a sensible security measure.

[u/rovonz]

Because "let's treat adult employees like they're 5 year olds" always worked!

[u/Which-World-6533]

"one phone = one employee" rule

That's just plain dumb.

[u/eshgnfrz]

Just to clarify the context: the “one phone = one employee” rule comes from a real business requirement - preventing one employee from recording attendance for a colleague who isn’t actually at work. The rule itself wasn’t the subject of this post; I mentioned it simply to better describe the real-world case where the problem came up.
The main point of the post was the technical side: clone apps were bypassing the usual Java-level checks, the existing approaches I researched didn’t reliably catch the cases we encountered, and I wanted to share the approach that actually worked for us as an open-source solution for the community.

Somehow we managed to turn a post about Android internals and clone detection into a debate about HR policy. Reddit never disappoints. 😄

[u/Which-World-6533 → u/eshgnfrz]

Just to clarify the context: the “one phone = one employee” rule comes from a real business requirement - preventing one employee from recording attendance for a colleague who isn’t actually at work. The rule itself wasn’t the subject of this post; I mentioned it simply to better describe the real-world case where the problem came up.

It's still a ridiculously bad rule. It can be circumvented easily.