At first glance it presents as a lightweight utility — the kind of unremarkable system component that manages transitions between states or handles switching logic in the background. Its name suggests nothing out of the norm. Its icon is absent. Its presence in the app drawer is nonexistent. Like other packages on this device, it is designed to be invisible. But the static analysis tells a completely different story.

com.kst.switchapp is the component responsible for one of the most technically revealing behaviors found on this device — the active, runtime rewriting of the phone's own identity. Through direct calls to SystemProperties.set(), it can dynamically overwrite the device's reported model, hardware identity, and system characteristics. This is how a 4GB MediaTek budget device tells Android, tells the apps, and tells anyone who asks that it is a Samsung Galaxy S25 Ultra. Not through a static label applied at build time — but through live, ongoing manipulation controlled by this package.

Beyond identity spoofing, SwitchApp serves as the coordination layer between the other malicious components on the device. It reaches directly across app boundaries to invoke com.kingsentime.factorytest, using it as an execution surface for privileged hardware and system actions. It monitors device state through imports of ActivityManager, WifiManager, and BluetoothAdapter. It can issue system-level broadcasts — including a factory reset trigger — effectively giving it the ability to wipe the device and destroy forensic evidence on demand.

It is the component that turns passive monitoring into active behavior. Without it, the other pieces accomplish nothing visible. With it, the system has a purpose — control.

com.kst.switchapp is not a utility. It is the control the control center of a coordinated surveillance architecture, hiding in plain sight inside a $57 phone.

Code Evidence — com.kst.switchapp (SwitchApp)

1. Built as a spoofing and configuration console

MainActivity.java is not a normal launcher or utility screen. It is a PreferenceActivity with a long list of configurable properties controlling model, CPU, RAM, ROM, LCD, cameras, signal state, Android version, IMEI count, and writeable model name. The code defines property keys like:

• choose_model_value
• key_cpu_value
• key_ramtype
• persist.sys.fakeromtype
• statusbar_3g
• com.android.model

That alone shows this component was designed as a device-identity manipulation panel, not a consumer-facing settings page.

2. Direct system property and settings rewriting

One of the clearest pieces of evidence is the write-model flow:

This shows SwitchApp is not merely displaying spoofed values. It is actively writing model identity into NVRAM, system settings, and persistent system properties. Basically, this looks like a central spoofing control engine.

3. Explicit device-faking categories

The preference screen initialization makes the intent of the app unmistakable. It registers controls for:

• rom
• ram
• fake_signal
• model
• camerafront
• cameraback
• lcdpix
• imei
• factory
• version
• cpu
• cpu_core
• imei_num

This is not diagnostic telemetry; It is a menu of identity and presentation variables that can be changed.

4. Launches FactoryTest directly

SwitchApp contains a direct bridge into FactoryTest:

This proves com.kst.switchapp can call com.kingsentime.factorytest on demand.

That is one of the strongest code-level links in the whole ecosystem, because it shows the control engine can directly activate the execution component.

5. Sends system-level factory reset broadcast

SwitchApp also includes:

That is a highly privileged action path. It means the component is wired to emit a system reset broadcast, not just manipulate cosmetic values.

Whether that action succeeds depends on environment and privilege, but the fact that the ability is even present at all in the code is itself a major concern.

6. IPC, activity launching, and process control

The Android API analysis for SwitchApp flags the following behaviors in MainActivity.java:

• Get System Service
• Inter Process Communication
• Kill Process
• Sending Broadcast
• Starting Activity

That combination is what you would expect from a control and coordination component, not an ordinary UI app.

7. Environment control imports

The imports in MainActivity.java include:

• ActivityManager
• BluetoothAdapter
• WifiManager
• WifiConfiguration
• SystemProperties
• ComponentName
• Intent

Basically, SwitchApp has the scaffolding needed to observe or alter device environment, wireless configuration, and cross-app behavior.

8. Writes to NVRAM

The presence of KSTNvRAMPROINFOPRO is important. This is not a generic app pattern. It indicates interaction with persistent low-level configuration storage, which is consistent with vendor firmware customization and spoofing. Why does this matter? becasue it means changes may survive reboots and act more like firmware-state changes than ordinary app preferences.

9. Permission profile supports system modification role

MobSF flagged SwitchApp's abused permissions:

• WRITE_EXTERNAL_STORAGE
• ACCESS_WIFI_STATE
• ACCESS_NETWORK_STATE
• WRITE_SETTINGS
• plus, Bluetooth and Wi-Fi change permissions

That is not enough to prove maliciousness by itself, but it is consistent with a component intended to modify system behavior and coordinate device presentation/state.

10. What this proves

With everything in mind, the code shows that com.kst.switchapp:

• is a device spoofing control panel for model, RAM, ROM, CPU, signal, version, camera, and IMEI presentation.
• writes spoofed values into system settings, persistent properties, and NVRAM.
• directly launches com.kingsentime.factorytest.
• can issue a factory-reset broadcast.
• has IPC, broadcast, process, and activity-control behavior consistent with a central orchestration layer.

Bottom-line assessment

com.kst.switchapp is best characterized as the central spoofing and execution-control component in the counterfeit firmware environment.

Code Evidence — com.kingsentime.factorytest (FactoryTest)

1. Broadcast receiver accepts external test flags with no validation

FactoryReceiver.java is one of the most important files in this component:

This means another component can send a broadcast carrying a testflag array, and FactoryTest will immediately launch its MainActivity with that external input. There is no validation or permission gating shown here. That makes FactoryTest an externally triggerable execution surface.

2. Secret-code engineering hook into MediaTek logger

MtklogTestReceiver.java listens for a special telephony secret-code action:

The URI used is:

That is clearly evidence of a hidden engineering entry point that can launch the MediaTek logging toolchain.

3. Main activity consumes external testflag input

MainActivity.java confirms that the app's main flow reads the externally provided flags:

This is important because it shows the FactoryReceiver is not just launching the activity. The main controller actually accepts and uses the injected flags.

4. Full hardware test harness exposed through activities

The activity inventory includes 33 activities such as:

• TestGPS2
• TestCamera
• TestWifi
• TestBluetooth
• TestBattery
• TestSIM
• TestPhone
• TestMic
• TestNFC
• TestOTG
• HardwareInfoActivity
• TestVersion
• TestVersion2

This shows that FactoryTest is not a narrow test app. It is a broad hardware and identity interaction suite.

5. Programmatic call initiation

TestPhone.java shows direct phone-call construction:

This is the basis for a programmatic dialing path. Combined with the CALL_PHONE permission found earlier, it shows FactoryTest can execute real telephony actions, not merely display status.

6. IMEI, SIM serial, and identity access

TestVersion2.java reads IMEI and SIM serial values directly:

Obvious evidence of device-identity harvesting capability.

TestSIM.java goes further by pulling active subscription records, numbers, carrier names, ICCIDs, slot indexes, and signal strength.

7. Explicit spoofing logic visible in TestVersion.java

TestVersion.java contains hardcoded model-selection logic:

It also maps CPU selections to misleading high-end labels before falling back to the real board platform.

That is strong code-level confirmation that FactoryTest participates in the broader spoofing framework, not just hardware validation.

8. GPS location tracking

TestGPS2.java uses LocationManager, LocationListener, GpsStatus.Listener, and updates current latitude/longitude and satellite counts. It logs precise location changes:

Log.e(TestGPS2.this.TAG, "onLocationChanged location->" + location.getLatitude() + "|" + location.getLongitude()); Now we have real-time location access.

9. Hardware introspection

HardwareInfoActivity.java contains arrays of expected component identifiers for LCD, touch panel, main/sub cameras, fingerprint, accelerometer, ALS/PS, and charger compatibility.

This means the component can compare or display actual hardware composition, which is relevant in a counterfeit device because it shows awareness of the hardware-vs-marketing mismatch.

10. Exported and externally reachable manifest surface

The MobSF manifest analysis flagged:

• FactoryReceiver exported and unprotected
• many test activities exported with intent filters
• allowBackup=true

This is important context for the code above because it shows the exposed code paths are not theoretical — they are part of a manifest surface accessible to other apps.

11. What this proves

In context together, the code shows that com.kingsentime.factorytest:

• accepts external broadcasts with behavior flags and launches its main execution flow from them.
• includes a hidden secret-code engineering path into MediaTek logger infrastructure.
• can perform telephony actions, including call initiation.
• can read IMEI, SIM serial, ICCID, carrier, slot, and signal data.
• can access GPS location and hardware configuration.
• participates in the same broader spoofing environment as SwitchApp.

Bottom-line

com.kingsentime.factorytest is best described as an externally triggerable hardware/telephony execution framework that expands the firmware attack surface and can be leveraged by other components in the counterfeit ecosystem.

SwitchApp

com.kst.switchapp rewrites device identity through system properties, settings, and NVRAM; launches FactoryTest directly; and issues system broadcasts, making it the most credible central control engine in the counterfeit firmware stack.

Final assessment

com.kingsentime.factorytest accepts external trigger flags, exposes hardware and telephony test flows, reads IMEI/SIM/location data, and includes a secret-code engineering hook, making it a highly capable execution surface in the same system. In the final entry, I will bring all this information together to paint a clearer, recapped picture of what I have found.

QuantumFeed is a cybersecurity and engineering news platform designed to surface emerging threats, vulnerability research, and real-world attack patterns. Stay ahead of what's actually happening beneath the surface.