In November 2025, Google's Threat Intelligence Group reported something malware analysts had long expected and not yet seen in live operations. Its AI Threat Tracker described, for the first time, malware families that use large language models during execution. PROMPTSTEAL, linked to the Russian state-backed group APT28 and observed against Ukraine, queries a language model through the Hugging Face API to generate the commands it runs, instead of carrying them inside the file. PROMPTFLUX, an experimental VBScript dropper, calls Google's Gemini API to request obfuscation code so it can rewrite itself. A third family, FRUITSHELL, carries hard-coded prompts designed to get past security tools that use language models for analysis.
For an analyst, that changes the job in a specific way. The binary on disk is no longer the complete picture of what the malware does, because part of its logic now lives in a remote model and arrives at run time. Reverse engineering, the discipline of taking a program apart to learn what it really does, has to follow the behavior across the network as well as through the code. The fundamentals still apply, but the work now includes capturing what the sample asks for and what it receives.
The wider data shows why the discipline matters. Verizon's 2026 Data Breach Investigations Report found ransomware in 48% of breaches and exploitation of vulnerabilities as the most common initial access vector at 31%. Behind each of those statistics sits an unknown binary, a suspicious file, or a patched flaw that someone had to understand before a defense could be built.
Reverse engineering in cyber security is often described as a specialist art, and it is. The point most overviews miss is where its value is realized. An analysis that ends in a report nobody acts on has produced knowledge and no protection. The measure of a good analysis is what it changes: a detection rule, a containment decision, a patch priority, a risk estimate, a supplier question. This guide covers what reverse engineering is and where it is used, how static and dynamic analysis work, the main tools, safe handling practices, the legal position in India, how artificial intelligence is changing the work, the skills involved, and how to turn findings into defenses. It is written for security leaders, SOC and incident response teams, and engineers who want to understand what the discipline offers and what it requires.
Talk to Our Security Experts →
What Reverse Engineering in Cyber Security Is
Reverse engineering is the process of analyzing a finished product, usually compiled software or firmware, to understand how it works without access to its source code. In cyber security, the product under study might be a malware sample, a vulnerable application, a device firmware image, a mobile app, a network protocol, or a software update. The goal is defensive understanding: what the program does, how it communicates, what it targets, how it hides, and how it can be detected or fixed.
The discipline sits close to several others, and the differences are worth stating.
| Discipline | Core question | How reverse engineering differs |
|---|---|---|
| Reverse engineering | What does this program actually do, and how? | Works on the code or binary itself |
| Digital forensics | What happened on this system, and when? | Works on evidence of activity, not on the logic of a program |
| Penetration testing | Can this system be compromised? | Tests systems for weaknesses, often without needing to take the code apart |
| Threat intelligence | Who is behind this, and what do they do? | Uses reverse engineering outputs, among other sources, to describe actors and techniques |
| Automated sandbox verdict | Does this file behave maliciously when run? | Gives a fast verdict, while reverse engineering explains the reasons and finds what the sandbox missed |
Where It Is Used
| Use case | Question it answers | Typical output |
|---|---|---|
| Malware analysis | What does this sample do, what does it target, and how can it be detected? | A behavior and capability summary, indicators, and detection content |
| Vulnerability research and patch analysis | What is the flaw, and how serious is it? | A technical description, an exploitability assessment, and mitigation advice |
| Threat intelligence support | How does this tooling connect to known activity? | Technique mappings and links to known families |
| Firmware and embedded device assessment | Does this device contain hidden functions, hard-coded secrets, or insecure update paths? | Findings for the vendor or the buyer |
| Mobile and application assessment | What does this app collect and transmit, and how does it protect data? | Security findings and privacy observations |
| Software supply chain verification | Does this binary match what was expected, and what does it contain? | Integrity findings and component insight |
| Protocol and file-format analysis | How does this undocumented format or protocol work? | Parsers, detection signatures, and monitoring rules |
| Detection engineering | What behavior or artifacts distinguish this threat reliably? | Rules that fire on the threat and not on normal activity |
How an Analysis Works: Static, Dynamic, and Hybrid
Analysts work with two broad approaches, and nearly every serious analysis combines them.
| Approach | What it involves | Strengths | Limits |
|---|---|---|---|
| Static analysis | Examining the file without running it, through disassembly and decompilation, inspecting structure, strings, imports, and embedded resources | Safe, shows code paths that never run in a sandbox, and reveals intent | Obfuscation and packing can hide the real code, and large programs take time |
| Dynamic analysis | Running the sample in a controlled environment and observing behavior, with a debugger, and monitoring files, processes, registry, and network traffic | Shows real behavior quickly and reveals decrypted or unpacked content | Malware may detect the environment and change behavior, and it only shows paths that actually execute |
| Hybrid | Using each to answer the questions the other cannot | The most reliable picture | Needs more skill and time |
A typical workflow moves through stages, and each stage produces something the next one needs.
| Stage | What happens | What it produces |
|---|---|---|
| 1. Triage | Identify the file type, compute hashes, check reputation, and extract obvious strings and metadata | A quick decision on priority and a first set of hypotheses |
| 2. Static analysis | Read the disassembled and decompiled code, map the structure, and identify key functions | An outline of what the program is built to do |
| 3. Dynamic analysis | Run the sample in isolation and observe | Observed behavior, network indicators, and artifacts |
| 4. Unpacking and deobfuscation | Remove the layers that hide the real logic | Readable code and configuration data |
| 5. Capability summary | Describe what the sample can do, mapped to a framework such as MITRE ATT&CK | A behavior profile that other teams can use |
| 6. Indicators and detection content | Extract indicators and write rules that detect the sample and its relatives | Rules for the SOC and endpoint tools |
| 7. Reporting and handoff | Document findings, confidence levels, and recommendations | A report that supports decisions |
Attackers know all of this and build their code to resist it. Packers compress and encrypt the real payload, obfuscation scrambles names and control flow, and anti-analysis checks look for debuggers and virtual machines. Analysts respond by combining approaches, such as running the sample under a debugger to let it unpack itself, then examining the result. The cat-and-mouse nature of the work is the reason it rewards experience.
The Toolbox
| Category | Examples | Notes |
|---|---|---|
| Disassemblers and decompilers | Ghidra, IDA Pro, Binary Ninja, radare2 with Cutter | Ghidra was released as open source by the US National Security Agency in 2019, while IDA Pro and Binary Ninja are commercial |
| Debuggers | x64dbg, WinDbg, GDB | Used to step through code and inspect memory during execution |
| Mobile analysis | jadx, apktool, Frida | For examining Android applications and instrumenting them at run time |
| Network analysis | Wireshark | For capturing and inspecting what a sample communicates |
| Sandboxes | CAPE and commercial services | Automated behavioral analysis that speeds triage |
| Pattern matching | YARA | A rule language for describing and detecting families of files |
No tool replaces judgment. Decompiler output is a reconstruction and can be wrong, and sandboxes can be evaded. Most of the skill lies in knowing what a tool is likely to get wrong.
Working Safely
Handling live malware is hazardous, and a mistake can infect the analyst's own environment or alert the attacker.
| Practice | Why it matters |
|---|---|
| An isolated analysis environment with snapshots | Contains the sample and allows a clean reset after each run |
| No connection to production networks | Prevents spread and accidental damage |
| Controlled or simulated network access | Lets behavior be observed without giving the sample a route to real infrastructure |
| No real credentials, personal accounts, or sensitive data in the lab | Stops a sample from stealing anything of value |
| Hashing and documented handling of samples | Preserves integrity and supports later sharing or legal use |
| Sharing samples only through approved channels | Avoids accidental distribution and keeps within law |
Reverse Engineering and the Law in India
Reverse engineering for security work is generally lawful when it stays within defined limits, and those limits deserve care. This section is general information and not legal advice, and a qualified lawyer should review a specific project.
The Copyright Act, 1957 addresses software specifically. Section 52(1)(ab) permits acts necessary to obtain information essential for interoperability of an independently created program, by a lawful possessor of a program, where the information is not otherwise readily available. Section 52(1)(ac) permits observing, studying, or testing the functioning of a program to determine the ideas and principles underlying its elements, while performing acts necessary for the functions for which it was supplied. The general fair dealing exception in Section 52(1)(a) expressly excludes computer programs, so the software exceptions are narrow, and in practice both assume a legitimately obtained copy. Licence terms may also restrict analysis, and contract law operates alongside the Act.
Two other points complete the picture. The Information Technology Act, 2000 treats unauthorized access to computer systems as a civil and, with dishonest intent, criminal matter under Sections 43 and 66, so analysis should never extend to systems the analyst has no authority over, for example by letting a sample touch third-party infrastructure. And discovered vulnerabilities should go through proper channels. CERT-In's Responsible Vulnerability Disclosure and Coordination Policy sets out how researchers report to CERT-In, which validates a report and tells the discloser whether it will coordinate. The policy is subject to the IT Act, and reporting does not exempt anyone from compliance.
Organizations that find malware on their own systems have a separate duty. Under CERT-In's Directions of 28 April 2022, malicious code attacks, including ransomware, are among the listed incident types to be reported within six hours of noticing, and analysis of the sample should not delay the report.
Artificial Intelligence and Reverse Engineering
AI affects the discipline from both sides. On the attack side, the Google findings show malware that generates behavior at run time. For analysts, that means capturing the prompts and responses the sample exchanges with a model, and recognizing that a static reading of the file may show only a thin loader. It also means that a captured sample may no longer reproduce the same behavior twice.
On the defense side, language models can help analysts work faster by summarizing decompiled functions, suggesting names for variables, and drafting notes. The same GTIG report describes malware with prompts built to mislead language-model-based analysis, so the output of such tools has to be treated as a lead and checked against the code. The sensible division of labor lets automation do first-pass explanation while a human decides what is true. Organizations that route samples to external AI services should also confirm that doing so does not leak sensitive material or breach confidentiality.
Example: REA, an Open-Source Toolkit That Connects AI Agents to Analysis Tools
One concrete example of the defense-side trend is REA, short for Reverse Engineer Anything, an MIT-licensed open-source project on GitHub at morluto/rea with a website at rea.tools. According to its documentation, REA connects an AI agent to reverse engineering tools through the Model Context Protocol (MCP), so the agent can inspect a target, trace the relevant code, and report what it found together with the evidence and limitations behind each conclusion. The same workflows can be run from a command line. Setup is a single command, npx rea-agents setup, which registers REA with supported agents, including Claude Code, Codex, Cursor, and Gemini CLI.
The project lists the following targets, along with the tools each depends on.
| Target | What REA returns, according to its documentation | Requirement noted by the project |
|---|---|---|
| Native binaries | Pseudocode, assembly, strings, symbols, calls, and references | Hopper, Ghidra, or IDA |
| JavaScript and Electron applications | Modules, imports, source maps, and inter-process communication relationships | Node.js and npm |
| .NET assemblies | Metadata, CIL instructions, and declared native dependencies | None, static analysis only |
| Android APKs | Manifest declarations, classes, and decompiled methods | Headless JADX and a full JDK |
| Firmware images | Regions, extraction results, and handoffs to native analysis | Binwalk or Unblob on Linux |
| Network captures and recorded packets | Requests, responses, endpoints, and protocol fields | HAR or SAZ files, and TShark for packet analysis |
| Websites | Page structure, scripts, and network observations | A Chrome-family browser |
The list continues with many further formats, such as Go and Rust binaries, WebAssembly, and Unity metadata, which shows how far the tool-assisted approach has spread beyond a single file type.
The design matches the division of labor described above: the agent drives the tools and produces a first-pass explanation, and a person decides what is true. The project's published case studies concern ordinary software, such as reconstructing a game's sound calculation and tracing an Electron application's clipboard bridge, and it describes itself as general-purpose. Any use of a tool like this on hostile samples is therefore the analyst's own design and risk, and the points below deserve attention before it is adopted.
| Consideration | Why it matters |
|---|---|
| Confirm the official source | The project states that similarly named repositories and copied READMEs are not official, and points to its GitHub repository, its website, and the rea-agents npm package. Verifying the source before installing is basic supply chain hygiene |
| Keep suspect samples in the isolated lab | The documentation notes that runtime capture runs or interacts with the selected target using the user's permissions. For suspicious files, that belongs only inside the isolated environment described earlier, never on a workstation |
| Understand where data goes | Analysis is described as running locally, but the agent receives the tool results, and the agent's model provider has its own data policy. Client or sensitive material needs a decision on that before use |
| Review what setup changes | The setup command modifies agent configuration. The project says it shows proposed changes for approval and keeps backups, and the changes should still be read before they are approved |
| Respect licensing and lawful use | The project states that commercial tools such as IDA Pro and Hopper must be obtained legally, and its disclaimer limits use to lawful research, education, interoperability, preservation, and software the user owns or is authorized to examine, which is consistent with the Indian legal limits above |
| Verify the conclusions | An agent's explanation of a function is still a lead. Key findings should be confirmed in the disassembler before they appear in a report or a detection rule |
| Re-check after updates | The project says it changes quickly with frequent releases, so behavior on known samples should be re-tested after an update before the output is relied on |
This section describes the project from its public documentation. It does not test or endorse the tool's accuracy or security, and a team that wants to use it should evaluate it on its own samples under its own controls.
Skills and Learning Path
Interest in learning the field is strong. Skills build in layers.
| Skill area | Why it matters | How it is typically built |
|---|---|---|
| Computer architecture and assembly language (x86-64 and ARM) | Disassembly is the raw material of the work | Study instruction sets and write small programs, then read their compiled output |
| Operating system internals (Windows PE files, Linux ELF files, Android) | Malware relies on OS mechanisms | Learn executable formats, processes, memory, and system calls |
| C, C++, and a scripting language such as Python | Most targets are written in C or C++, and scripting automates analysis | Practice reading and writing code |
| Networking | Samples communicate, and traffic reveals behavior | Learn protocols and capture analysis |
| Debugging and tool practice | Tools only help when used fluently | Work through lab exercises and capture-the-flag challenges on legal samples |
| Reading published analyses | Shows how experienced analysts reason | Study public reports and reproduce their findings |
Turning Analysis into Defense
| Output | Where it goes | What changes |
|---|---|---|
| Indicators of compromise | SOC blocklists and threat intelligence platforms | Known infrastructure and files are blocked or alerted on |
| Behavioral findings | Detection rules for endpoint and SIEM tools | Detection covers behavior, not just one file |
| Technique mappings | Purple team plans and attack simulation scenarios | Detections are tested against what attackers do in practice |
| Vulnerability details | Patch prioritization and compensating controls | Fixes are ordered by real exploitability |
| Supplier or firmware findings | Vendor management and procurement | Questions go back to the supplier with evidence |
| Incident learnings | The risk register | Likelihood and impact estimates reflect reality |
The last column is the test. A finding that does not change a rule, a priority, a test, or an estimate has not yet delivered its value.
What Weak Analysis Capability Costs
| Gap | Consequence |
|---|---|
| Relying only on automated verdicts | Evasive samples pass as benign and nobody learns why |
| No analysis of incident samples | The same technique returns because detection never improved |
| Findings that stay in reports | Detection rules and priorities do not change |
| Unsafe handling | Lab compromise, spread, or alerting the attacker |
| Ignoring legal limits | Contract disputes or unauthorized-access exposure |
| Trusting unverified AI summaries | Wrong conclusions in reports and rules |
A Maturity Model for Threat Analysis Capability
Level 1: Antivirus and sandbox verdicts are the only analysis, and suspicious files are deleted or ignored ↓ Level 2: A sandbox is used for triage and results are logged, with no deeper analysis ↓ Level 3: Analysts perform static and dynamic analysis on priority samples in a controlled lab ↓ Level 4: Analysis feeds detection engineering, threat intelligence, and purple team scenarios, and detections are tested ↓ Level 5: A repeatable pipeline combines automation with expert review, shares findings responsibly with peers and CERT-In, and measures what each analysis changed
The step from Level 3 to Level 4, where findings are tested as detections, is where most of the defensive value appears.
A Readiness Playbook
- Decide what decisions the analysis must support. Containment, detection, patching, and supplier action each need different depth.
- Set up an isolated lab and handling rules before the first live sample.
- Agree legal and licence boundaries, including lawful possession and what may be shared or sent to external services.
- Define triage criteria so that only samples that warrant deep analysis receive it.
- Use both static and dynamic methods, and record confidence levels.
- Convert every analysis into specific outputs, such as indicators, rules, and technique mappings.
- Test the resulting detections with a purple team exercise or attack simulation.
- Record what each analysis changed, and report malicious code incidents on time regardless of analysis status.
Common Mistakes and Edge Cases
Running a sample on a machine connected to the real network. A mistake of this kind turns an analysis into an incident.
Trusting decompiler output as fact. It is a reconstruction, and it can mislead.
Treating a sandbox verdict as the end. Evasive samples can behave innocently in an automated environment.
Skipping the detection step. Understanding a threat without improving detection leaves the organization exposed to its next variant.
Delaying the incident report for analysis. The CERT-In clock runs from noticing, not from understanding.
Sharing samples carelessly. Distribution of live malware is a risk to others and may breach law or contract.
Over-reliance on language models. Their summaries can be wrong, and malware can be written to mislead them.
When to Use What: A Few Decision Points
Building an in-house capability versus using an external specialist. An organization with a steady flow of unusual samples and a mature SOC can justify its own analysts. One that sees such samples rarely is usually better served by an external team called when needed.
Automated sandbox versus manual analysis. Sandboxes suit volume and speed. Manual analysis suits samples that matter, that evade automation, or that must be understood in detail.
Open-source versus commercial tools. Open-source tools such as Ghidra are capable and widely used. Commercial tools may offer features or support that a team values. Skill with the tool matters more than the label.
Depth of analysis. A triage-level review may be enough to block and alert. A full analysis is warranted when the sample is novel, targeted, or tied to a significant incident.
Which findings to share externally. Indicators and detection rules help peers. Anything that identifies the victim or reveals sensitive internal detail needs careful review first.
Where Reverse Engineering Findings Go Next at SecNinjaz
Reverse engineering produces understanding, and the practices that put it to work sit across SecNinjaz's Cybersecurity practice: Purple Teaming and Breach and Attack Simulation test whether detections built from an analysis fire, Penetration Testing and Vulnerability Assessment examine whether the weaknesses it exposes exist in a given environment, and AI SOC Automation supports the monitoring where the resulting rules run. The governance side connects to SecNinjaz's GRC and DPDP practice, including Risk Management and Regulatory Compliance, which help turn what analysis reveals into risk estimates and into reporting duties such as the CERT-In six-hour rule.
SecNinjaz holds ISO/IEC 27001:2022 and ISO/IEC 27701:2025, relevant because malware samples, analysis notes, and findings about weaknesses are sensitive and need the same access control and confidentiality discipline as any other security evidence. For organizations that want threat understanding to end in tested defenses and not just a report, that pairing of validation and governance is the one worth looking for, whether the organization works with SecNinjaz or anyone else.
Talk to Our Security Experts →
Frequently Asked Questions
What is reverse engineering in cyber security?
It is the process of analyzing compiled software, firmware, or protocols to understand how they work without the source code. In cyber security, it is used defensively to understand malware, find and assess vulnerabilities, verify software, and build detections.
What is the difference between static and dynamic analysis?
Static analysis examines a file without running it, through disassembly, decompilation, and inspection of its structure. Dynamic analysis runs the file in a controlled environment and observes its behavior. Each answers questions the other cannot, so serious analyses combine them.
Which tools are commonly used for reverse engineering?
Common choices include disassemblers and decompilers such as Ghidra, IDA Pro, Binary Ninja, and radare2 with Cutter, debuggers such as x64dbg, WinDbg, and GDB, mobile tools such as jadx, apktool, and Frida, Wireshark for network analysis, sandboxes for automated behavior capture, and YARA for detection rules.
Is reverse engineering legal in India?
Within limits, yes. The Copyright Act, 1957 permits a lawful possessor of a program to observe, study, or test its functioning under Section 52(1)(ac), and to obtain interoperability information under Section 52(1)(ab). Licence terms, the IT Act on unauthorized access, and rules on sharing can still apply, so a specific project should be reviewed by a lawyer.
How is AI changing malware reverse engineering?
Google's Threat Intelligence Group reported malware families that query language models during execution, so part of their behavior is generated at run time and arrives over the network. Analysts need to capture those exchanges. Language models can also help analysts summarize code, but their output must be verified, since malware can contain prompts intended to mislead such tools.
Is assembly language knowledge needed to start?
For hands-on malware and binary analysis, a working knowledge of assembly for x86-64 or ARM is central, since disassembly is the raw material. Some mobile and managed-code analysis relies more on higher-level decompiled code, but assembly knowledge remains valuable across the field.
How does reverse engineering help a SOC?
It explains what a sample does, which lets analysts write behavior-based detection rules, extract indicators for blocking and hunting, and map the activity to known techniques. Those outputs can be tested through purple team exercises to confirm that the rules fire.
What should an organization do when it finds suspected malware?
Contain the affected systems, preserve the sample and evidence, and report in line with the CERT-In Directions, which list malicious code attacks among incidents to be reported within six hours of noticing. Analysis can proceed in an isolated lab, but it should not delay the report.
