Reverse engineering interview questions

Questions and answers

5 questions with model answers

Rewrite each answer in your own words before the loop — interviewers can tell a memorized paragraph from one you can defend under a follow-up.

1. Question 1

   Static versus dynamic analysis — when do you use each?

   Static analysis inspects the artifact without running it: file type and headers, imports, strings, embedded resources, entropy, and disassembly. It is safe, complete in the sense that it can reach code that never executes, and it is the right starting point — but packing and obfuscation blunt it quickly. Dynamic analysis runs the sample in an instrumented, isolated environment and observes actual behavior: processes created, files and registry keys written, network destinations contacted. It cuts through packing because the code must unpack itself to run, but it only shows the paths that executed, and samples increasingly detect sandboxes or wait on conditions. In practice you alternate — a quick static triage to form hypotheses, a dynamic run to confirm behavior, then targeted static work on the interesting function.

2. Question 2

   How do you set up an environment to analyze an unknown sample?

   An isolated virtual machine on a host that holds nothing sensitive, snapshotted so it can be reverted after every run, with no credentials, no shared folders, and no path back to the corporate network. Network access is simulated or tightly controlled — a fake DNS and services responder so the sample believes it has connectivity — and any real egress is a deliberate, approved decision, because contacting live infrastructure tells the operator you are looking. Samples are handled in password-protected archives and never left where a scanner or sync client can move them somewhere unexpected. I would also mention the escape risk honestly: a VM is not a guarantee, so genuinely destructive or targeted samples belong on dedicated hardware or a purpose-built sandbox.

3. Question 3

   You are handed an unknown Windows binary. What do you do before opening a disassembler?

   Hash it and check what threat intelligence already knows, so I do not spend a day re-deriving a documented family. Then confirm what it actually is from its headers rather than its extension, note compilation timestamp, architecture, and whether it is signed, and check whether the signature is valid or stolen. Strings and imports give an enormous amount of cheap signal: URLs, file paths, mutex names, registry keys, and imports like CreateRemoteThread, VirtualAllocEx, or WinHttpConnect suggest capability. High entropy sections, tiny import tables, and odd section names point to packing, which tells me static analysis will need unpacking first. That triage takes minutes and decides whether the sample deserves hours.

4. Question 4

   What is packing, and how do you handle it?

   A packer compresses or encrypts the real payload and prepends a stub that reconstructs it in memory at runtime, which hides strings, imports, and code from static inspection. Common commercial packers have known unpacking routines or public unpackers, but bespoke ones do not, so the general approach is to let the sample unpack itself: run it under a debugger or in a sandbox and dump the process memory once the real code is resolved, then fix the import table to get an analyzable binary. Detection-wise, packing is a signal but not a verdict — plenty of legitimate software is packed for licensing or size reasons, so it belongs in scoring rather than as a standalone rule. This is also the clearest example of why dynamic analysis exists.

5. Question 5

   You have finished analyzing a sample. What does the defense get from it?

   The lowest-value output is a hash, which will not match the next build. More useful are the configuration details recovered from the sample — C2 domains and URL patterns, user agents, mutex names, persistence locations, and the encryption or encoding scheme it uses — because those often stay stable across a campaign. The most durable output is behavioral: a YARA rule on stable code or configuration structures rather than on volatile bytes, and a detection expressed as a sequence of host behaviors mapped to ATT&CK techniques. I would also write down what the sample does not do, since scoping an incident often turns on knowing that a family has no lateral movement capability. That progression from indicators to behavior is exactly what an interviewer wants to hear.