Daniel Jensen ← Home
Project

Inside a Shenzhen Translator Phone: Translation Logging and a Hidden Debug Menu

I recently purchased a cheap, dedicated hand-held translation phone in Shenzhen. Given the nature of low-cost, off-brand hardware, I wanted to audit the device to see how it handled data and whether it exposed any undocumented access points.

After dumping the MT6737 firmware and decompiling the pre-installed system APKs, I found that the translator app logs every translation locally and periodically uploads that log — tagged with the device's hardware serial number — to the vendor's server. I also found a pair of undocumented tap-gestures in the Settings app that unlock hidden system access behind a hardcoded passcode. Here is the step-by-step technical breakdown of how I reversed it.

Target device technical specs

The device presents itself as a generic language translation smartphone. Looking under the hood at the system configuration (build.prop), I extracted the actual specifications:

The hardware spoofing (faked RAM/storage)

As is common with low-cost Shenzhen clones, the device is configured to report inflated memory and storage capacity in Android settings, regardless of the actual hardware installed. In build.prop, I found custom OEM override configs hardcoded to display these numbers:

Part 1: Translation logging and upload

Online translation inherently requires sending audio/text to a server — that's not unusual on its own, and isn't evidence of anything malicious by itself. What stood out during my audit of the main translator package (link.zhidou.translator) is how the data is handled after the fact. I found a local database table called correct_report persisting the following fields: the original speech transcription, the translated text result, the device's hardware serial number, and the source/target languages.

The class link.zhidou.correct.a periodically performs a batch synchronization, uploading this stored translation history as raw JSON via HTTP POST to https://translate.zhidou.link/correct/reportBatch.

In other words: rather than treating each translation as a one-off, stateless request, the app is persisting a running log locally and shipping it upstream tied to a specific device identifier, with no visible user-facing opt-out.

That's a data-handling/privacy practice worth being aware of if you use this device — it does not, on its own, establish that the vendor is doing anything with that data beyond normal service operation.

Part 2: Finding the hidden Settings triggers

To inspect the device's running processes and network calls live, I needed ADB/USB debugging access. However, standard Android settings were completely overridden and locked down by the custom launcher (LauncherLight.apk, link.zhidou.launcher).

By auditing AboutActivity.smali in the Settings activity, I uncovered two custom click listeners:

Both prompts required a passcode returned by the JNI method SecretProvider.logCmd(Context).

A tap-count gesture plus a hidden passcode is a fairly common (if user-unfriendly) way manufacturers gate diagnostic/service menus; it's undocumented here, but I don't have evidence it's intended for anyone other than the OEM/factory technicians.

Part 3: Reversing the native passcode library (libddgif.so)

The SecretProvider Java class dynamically loads a native companion library called libddgif.so (extracted from lib/armeabi-v7a/libddgif.so in the APK).

Before releasing the passcode, logCmd performs signature and package integrity validation. It programmatically queries the Android package manager, hashing the app's signatures to ensure they match:

If validation checks succeed, it returns a hardcoded passcode from its read-only data (.rodata) section. By disassembling the Thumb-2 instruction stream of the logCmd function, I resolved the PC-relative string loads — tracing the instruction ldr r1, [pc, #0x54] loading a pointer offset relative to PC. In the .rodata section, I found a collection of candidate strings, including MD5 hashes and a 6-digit number: 959023.

Conclusion

Entering 959023 into both prompts successfully unlocked the device:

To be clear about what this does and doesn't show: I have no evidence this device is deliberately spying on users, and sending translation requests to a server is expected behavior for an online translator. What's worth flagging is (1) translations are persisted locally and uploaded tied to the device's serial number, with no visible way to opt out, and (2) there's an undocumented hidden menu gated by a hardcoded PIN rather than a disclosed service/debug mode. Neither is proof of malicious intent, but both are worth knowing if you're using or reselling this hardware.

Always take a look under the hood — especially with hardware bought off the shelf in electronics markets!