-
-
Batch mode scans many APKs at once and summarizes clean, suspicious and malicious counts for large-scale triage.
-
A structured dossier per case: executive summary, evidence references and deterministic score, built for legal review.
-
From APK upload to court-ready verdict: decompile, detonate, reconstruct the attack, score, report.
-
Built-in sandbox containment, authentication and RBAC. Clearly separates what works today from what is planned.
-
FastAPI orchestration, static and dynamic engines, risk engine and AI layer, with a React SOC dashboard. Auth and RBAC throughout.
-
Four pillars: static analysis, dynamic sandbox, deterministic risk scoring, and evidence-constrained intelligence.
-
Every verdict traces to evidence records across static, runtime, visual and network sources. Rules engine labels it; no AI involved.
-
A searchable case ledger with risk score, classification and timestamp, so SOC teams can revisit any investigation.
-
A structured dossier per case: executive summary, evidence references and deterministic score, built for legal review.
-
Drop in an APK and ask: is this app safe to trust? Analysis, sandbox, threat intel and scoring run automatically.
-
Risk is a transparent 0-100 rules-based score. Same evidence, same score; the AI layer cannot alter it.
-
Sudarshan hunts fake banking apps: decompile, sandbox, correlate, then a deterministic fraud verdict backed by evidence.
-
Fraud apps move faster than analysts. Sudarshan turns raw malware signals into evidence-backed fraud intelligence.
-
Suspect apps run in an isolated Android sandbox with Frida, capturing permission abuse, overlays, network calls and credential theft.
-
Findings are correlated with known malware families, showing confidence, reasoning and the recommended response.
Inspiration
It starts with a message.
It's 9:47 PM. Your phone buzzes.
"Your bank account requires an urgent KYC update. Download the attached application to avoid suspension."
The message looks convincing. The logo is familiar. The colours look right. The application even behaves like the banking app you already trust.
You install it.
It asks for Accessibility permission.
You allow it.
For the victim, everything may still look normal. Behind the scenes, however, a malicious Android application can abuse Accessibility services, imitate banking interfaces, intercept sensitive messages, capture credentials, interact with other applications, and automate parts of a fraud workflow.
And for the security team at the other end?
It may simply be another suspicious APK waiting in a queue.
This is the problem that inspired SUDARSHAN.
Mobile banking fraud is a global problem, and India provides a particularly relevant example because of its large mobile-first financial ecosystem and widespread digital payments. But the underlying attack is not limited to one country, one bank, or one payment system.
The difficult question is no longer simply:
"Is this APK malicious?"
A security analyst needs to know:
Who is this application targeting?
What is it capable of doing?
Did those capabilities actually execute?
What evidence proves what happened?
And what should the security team do next?
Traditional reputation systems, static analysis and manual reverse engineering each answer parts of these questions. But investigating modern banking trojans often requires combining all of them, navigating the application, observing runtime behaviour, reconstructing the attack and turning the resulting evidence into an actionable investigation.
We wanted to build a system that could do that automatically.
That became SUDARSHAN — Autonomous Banking Fraud Intelligence.
What it does
SUDARSHAN turns a suspicious Android application into a structured investigation.
Instead of relying on a single detection technique, it combines multiple layers of analysis.
1. It opens the APK
SUDARSHAN performs static analysis using Androguard, APKTool and JADX.
It examines manifests, permissions, components, code, resources, layouts, suspicious indicators, obfuscation characteristics and concealed payloads.
It can also attempt to repair deliberately malformed APK structures so that analysis can continue.
2. It executes the application in an isolated environment
Static analysis cannot reveal everything.
Some malware waits until a user reaches a particular screen. Some asks for permissions first. Some activates only after login or other victim-like interactions.
SUDARSHAN therefore uses an isolated Android analysis environment with sandbox controls, ADB and Frida-based runtime instrumentation.
3. It explores the application
A malicious banking application may require a sequence such as:
Permission → Login → PIN → OTP → Confirmation → Banking interaction
Instead of stopping at the first screen, SUDARSHAN's autonomous explorer navigates through the application's workflow.
It combines UI hierarchy, activity information, runtime signals, logcat and visual/OCR fallback.
It maintains a screen graph, detects loops, selects actions, verifies state changes and tracks investigation goals.
4. It observes runtime behaviour
Frida instrumentation allows the platform to observe sensitive runtime activity around areas such as:
- Accessibility
- SMS interception
- Overlay behaviour
- Banking-app targeting
- Code execution
- Network communication
- Persistence
The objective is not to collect events for the sake of collecting events.
The objective is to turn runtime activity into evidence.
5. It detects banking impersonation
SUDARSHAN includes the Visual Impersonation Detection Engine (VIDE).
VIDE analyses suspicious applications using multiple signals including:
- Layout structure
- Colour similarity
- Text similarity
- Signing information
- Banking UI baselines and corpus evidence
This allows the investigation to ask not only "Is this malware?", but also:
"Which banking identity is this application attempting to imitate?"
6. It reconstructs the attack
Static findings, runtime events, network indicators, screenshots and UI transitions are converted into structured evidence.
SUDARSHAN can reconstruct relationships between events, extract indicators of compromise and map observed behaviour to MITRE ATT&CK for Mobile techniques.
7. It produces a deterministic risk assessment
SUDARSHAN combines static evidence, runtime behaviour, threat-intelligence correlation and banking-impact signals through its deterministic risk engine.
Its scoring system includes STEI, BFCI and the overall Fraud Risk Score (FRS).
A key design principle is:
AI does not decide the risk score.
The scoring engine is deterministic, so the same evidence produces a reproducible result. Safety mechanisms also prevent an inconclusive dynamic investigation from simply being treated as proof that an application is safe.
8. It explains the investigation
SUDARSHAN includes Ask Sudarshan, an evidence-grounded AI investigation assistant powered by Gemini.
An analyst can ask questions such as:
"Did this application attempt to intercept SMS?"
"Why was this application considered high risk?"
"What evidence suggests banking impersonation?"
The AI works from the investigation's evidence rather than independently determining the verdict.
Our core principle is:
The engine decides.
The evidence proves.
The AI explains.
How we built it
We built SUDARSHAN as a layered system rather than a single malware classifier.
The analyst-facing layer is built with React, TypeScript, Vite and Tailwind CSS.
The backend and orchestration layer uses FastAPI and Python, handling authentication, RBAC, case management, analysis orchestration, batch processing and reporting.
The analysis engine contains the security-critical investigation components:
Androguard + APKTool + JADX
for static analysis,
Frida + ADB + Android sandbox providers
for dynamic analysis,
VIDE
for banking-app impersonation,
agentic exploration
for deep application navigation,
runtime event and evidence pipelines
for reconstruction,
and a deterministic risk engine
for final scoring.
Threat-intelligence integrations provide additional context through services such as VirusTotal, AlienVault OTX and AbuseIPDB.
Gemini is used only after the investigation has produced structured evidence, allowing the AI layer to explain the case without controlling the risk engine.
The system also produces operational outputs including PDF and HTML reports, STIX 2.1 bundles, IOC exports, YARA rules, network detection rules and MITRE mappings.
Challenges we ran into
Building an autonomous malware-analysis system was significantly harder than simply connecting a few analysis tools.
One of our biggest challenges was dynamic analysis.
Modern Android runtimes, Frida instrumentation, application launch behaviour and emulator differences created situations where hooks could attach too late, applications could crash before exploration, or malware could detect the analysis environment.
Frida 17 also changed the Java instrumentation model, requiring us to adapt our architecture around the compiled frida-java-bridge hook bundle rather than relying on the older Java API assumptions.
We therefore had to build a more defensive dynamic pipeline around:
- ART deoptimization
- Exact PID attachment
- Spawn/attach decisions
- A multi-step launch fallback ladder
- Permission orchestration
- Runtime preflight checks
- Sandbox containment
- Crash and ANR recovery
- Session checkpointing
- Anti-analysis detection
Another challenge was making the autonomous explorer go beyond simply clicking buttons.
A useful investigation needs to understand what screen it is on, what actions are meaningful, whether an action actually changed the state, whether it has already explored that path, and whether it is still inside the target application.
That led us to build a screen graph, semantic screen classification, goal tracking, action verification, adaptive budgets and scope controls.
We also had to solve a fundamental trust problem:
How do you use AI in a security product without allowing the AI to become the source of truth?
Our solution was to separate intelligence from judgement.
The deterministic engine owns the verdict.
The evidence pipeline owns provenance.
The AI explains the investigation.
This separation became one of the most important architectural decisions in SUDARSHAN.
Accomplishments that we're proud of
We are proud that SUDARSHAN evolved from an idea into a multi-layer investigation platform rather than remaining a static APK scanner.
The current implementation includes:
- Static APK analysis and APK repair
- APKTool and JADX integration
- Visual banking impersonation detection
- Frida-based dynamic instrumentation
- Android sandbox provider abstraction
- Autonomous deep UI exploration
- Anti-analysis and resilience mechanisms
- Time-warp support
- Synthetic victim profiles
- Runtime evidence collection
- Workflow reconstruction
- IOC extraction
- Threat-intelligence correlation
- MITRE ATT&CK mapping
- Deterministic STEI/BFCI/FRS scoring
- Evidence-grounded Gemini investigation
- Prompt-injection sanitization
- PDF, HTML and STIX 2.1 reporting
- YARA and network-rule exports
- Analyst case management
- Batch analysis
- Runtime telemetry
- Investigation history and audit capabilities
Most importantly, we designed the system around a principle we can explain and audit:
The AI can explain the evidence, but it cannot change the verdict.
What we learned
The biggest lesson was that malware analysis is not a single-model problem.
Static analysis tells us what an application contains.
Dynamic analysis tells us what happens when it runs.
Autonomous exploration tells us what happens when we interact with it.
Threat intelligence gives those observations external context.
Evidence reconstruction tells us how the observations relate to each other.
And deterministic scoring turns those observations into a reproducible assessment.
We also learned that failure is itself information.
If malware crashes, detects the emulator, hides its behaviour, or the investigation cannot reach a required state, the correct response is not to silently treat the absence of evidence as evidence of safety.
The system must understand the difference between:
"Nothing malicious happened."
and
"We were unable to observe what happened."
That distinction shaped our dynamic-analysis state machine, execution assertions and safety floors.
Finally, we learned that building an autonomous security system requires more than making it intelligent.
It needs to be observable, reproducible, constrained and auditable.
What's next for Sudarshan: Autonomous Banking Fraud Intelligence
Our next goal is to take SUDARSHAN from an isolated investigation platform toward a scalable security-infrastructure model.
The architecture is designed to evolve from:
Analyst Console
→ API & Authentication Layer
→ Durable Investigation Queue
→ Multiple Analysis Workers
→ Dedicated Android Sandbox Pool
→ Shared Evidence & Case Database
→ Threat Intelligence
→ Enterprise SIEM / SOAR
This would allow multiple suspicious applications to be investigated concurrently while keeping malware execution isolated from the surrounding infrastructure.
We also want to expand the Android sandbox ecosystem, improve second-stage payload analysis, expand banking baselines and corpus coverage, improve dynamic-analysis portability, and strengthen the empirical validation of the investigation pipeline.
The long-term vision is simple:
A fraud analyst should not have to spend hours manually discovering what a suspicious APK does.
They should be able to submit the sample and receive an investigation that answers:
Who is being targeted.
What the application is doing.
What happened during execution.
What evidence proves it.
What remains uncertain.
And what the security team can do next.
That is SUDARSHAN.
Not just malware detection.
An autonomous investigation system for mobile banking fraud.
Log in or sign up for Devpost to join the conversation.