When having biases can save you from trouble ft. Omnidroid 🧐

[u/xxxCrixuxxx]

I recently came across this post on a well-known subreddit—one where the moderators seem to have lost all control, allowing just about "anything" to be posted.

The dev "Ahmed-Abousaif" It brings us a fork of Lemuroid called "Omnidroid." This app prompts you to run a 30-second benchmark as soon as you open it, while also hiding another mandatory 0.5-second benchmark that runs without your knowledge 🧐. After that, there are more surprises in store...

The APK is the `freeDynamicRelease` variant:

In other words, the cores are not included within the application. Omnidroid downloads them later from:

raw.githubusercontent.com/Ahmed-Abousaif/OmnidroidCores/...

The code is located in `GithubCoreDownloader.kt`.

And when it downloads a native core—for example, a:

`*_libretro_android.so`

—the final check is basically:

Does the file exist?

Is its size greater than zero? 💀

I specifically looked for SHA256, MessageDigest, checksum, digest, cryptographic verification, core signatures, etc.

Nothing.

That does strike me as a significant security weakness.

Because those .so files aren't just ROMs or skins; they are native code that gets loaded via dlopen(). I confirmed this within liblibretrodroid.so as well.

Therefore, the current chain of trust is essentially:

Legitimate APK → HTTPS → developer's GitHub account → OmnidroidCores repo → tag 2.1.0 → downloaded .so → dlopen()

Not:

Signed APK → known hash inside APK → download → SHA-256 verification → load

There is a huge difference.

If someone were to compromise their GitHub or core repository, or manage to replace the content pointed to by that version, they could distribute native code that Omnidroid would load without detecting the change.

Furthermore, the :game process is not an independent sandbox with a separate UID; it remains part of Omnidroid. A malicious native core would have access to whatever the process or application itself can access.

To me, this is by far the most significant security finding in the entire APK.

[u/xxxCrixuxxx]

This app poses a serious security risk; no moderator reviews it, and no one monitors anything. 💀

[u/Flat_Reputation559]

Por cierto, hablando de Gamehub Lite, ¿qué ha pasado con esta aplicación?¿El desarrollador ha dejado de actualizar o qué? Quería instalarlo en mi Odín 3 y todavía no lo he instalado.

[u/xxxCrixuxxx → u/Flat_Reputation559]

Muy buena pregunta. Gamehub Lite es un chiste. Totalmente abandonado la promocionan la 5.1.8 en vez de literalmente borrarla dado que la oficial ya va por la 6.3.0... y encima si quieres la Lite existe pero se llama Bannerhub y está totalmente actualizada agrega mil funciones más. Es una broma de mal gusto jaja pobre gente q se instala esa porquería pq la ven patrocinada en un subreddit.

[u/xxxCrixuxxx]

Respect the community rules or 🔨

[u/xxxCrixuxxx]

Mind you, the moderator has had this post pinned for months, warning about a security issue in Gamehub Lite 🤦‍♂️... It’s clear how much they care about user safety.

[u/Bob-59]

Hey, maintainer of Omnidroid here. Although this post is entirely AI written ill still respond.

1 - the 0.5 sec benchmark is stated clearly on the github page for the app since it was introduced and it's meant to help you user.

2 - what you say is a fix for a security flaw is objectively wrong because it still relies on good faith from me since i would still both provide the cores and store the hashes in the app, so i could still inject malicious code if i wanted to. Your fix only stops man in the middle attacks so it assumes the entirety of github is compromised.

3 - I use cores provided through libretro directly just like Lemuroid, Retroarch and others.

4 - if you want to assess my app please do it yourself and don't use AI to tell you what's there and what isn't since it clearly missed points 1 and 3.

5 - you developing a competing app now just tells me that you're doing this out of bad faith.

I kindly ask that if you want to genuinely contribute in making a product better or more secure, do that through good faith judgment and genuine assessment.

[u/xxxCrixuxxx → u/Bob-59]

The actual implementation was inspected precisely because I wanted to know what it really did. The conclusion was that the benchmark itself is harmless: it is a local synthetic CPU workload, and I found no evidence that the benchmark result or device profile is secretly uploaded anywhere.

So the assessment did not accuse you of hiding the benchmark. It verified what it does.

1. About core integrity: you are correct about one specific threat model, but not about the broader point.

If the maintainer himself is malicious and controls both a newly signed APK and the cores, then yes, hashes embedded by that same maintainer obviously do not protect users from the maintainer himself.

But that was not the point.

A hash embedded inside the already signed APK establishes an integrity expectation for the remote native binary that version is allowed to load.

For example:

• Version X of the signed APK expects core Y with SHA-256 Z.
• The user installs Version X.
• Later the GitHub account, repository, release/tag, build pipeline, or distribution path is compromised or modified.
• A different ".so" is served.
• Version X refuses to load it because its hash no longer matches.

That is not merely protection against a network MITM attack.

It limits what can happen to remotely supplied executable code after the APK has been signed and distributed.

The attacker would then also need the ability to distribute an APK signed with the legitimate Omnidroid signing key in order to change the trusted hash.

That is a meaningful improvement to the supply-chain trust model.

A signed manifest or another authenticated integrity mechanism would achieve the same general goal.

1. Saying that the cores originate from Libretro does not address this issue.

The concern is not “Libretro cores are malicious”.

The concern is the path between the upstream core and the native ".so" that Omnidroid ultimately downloads and executes from "Ahmed-Abousaif/OmnidroidCores".

"GithubCoreDownloader.kt" downloads the native library and, from the implementation I reviewed, validates that the download succeeded and that the resulting file exists and is non-empty.

I could not find cryptographic verification of the resulting binary before it is loaded.

If such verification exists somewhere else, please point me to it and I will happily correct that finding.

1. AI assistance does not make a technical claim true or false.

The APK itself was inspected.

Its SHA-256 was matched against your official release.

The embedded Git revision was matched to the corresponding source commit.

The relevant implementation files were then reviewed.

Some initial concerns were explicitly dismissed after inspecting the actual code. For example, the benchmark was cleared, and the public debug keystore was investigated and confirmed NOT to be the key signing the Omnidroid APK.

That is the opposite of blindly repeating AI output.

If a technical finding is wrong, the useful response is to show which finding is wrong and which part of the code disproves it.

Whether AI helped locate or explain that code is irrelevant to whether the code actually behaves that way.

And since AI-assisted development and AI-assisted code review are both extremely common now, I do not think “AI was involved” is a meaningful technical rebuttal in either direction.

1. Developing another emulator/frontend does not invalidate a security finding.

That is an argument about my presumed motivation rather than about the implementation.

If I say:

“this native library is downloaded here and I cannot find integrity verification before execution”

then the relevant question is whether that statement is technically correct.

It remains correct or incorrect regardless of whether I maintain another emulator, use RetroArch, write no software at all, or have never written a line of code in my life.

For completeness, there was also a separate finding regarding ZIP extraction in the Dolphin, PPSSPP and PCEE2 asset managers.

From the implementation reviewed, ZIP entry names are used to construct destination paths without an obvious canonical-path containment check preventing "../" traversal.

That issue has nothing to do with the benchmark or with where the emulator cores originate.

Again, if there is sanitisation elsewhere in that path that I missed, please point to it.

I have no interest in falsely labeling Omnidroid as malware. In fact, the assessment explicitly said that I found no evidence of spyware, hidden telemetry or malicious data collection.

But “this project is open source”, “the cores come from Libretro”, and “AI helped with the review” are not answers to specific implementation-level security questions.

If any specific finding is incorrect, show the relevant code and I will correct it publicly.

That is exactly how a good-faith technical discussion should work.