Hi @BlackHat , could you please help me understand how you solved devirtualization for this Agile.NET challenge? I am working on kanCCAuiJp08bXx0Ho7ggqzTFqfBQ0B2.exe (CliSecure/CSVM). I can restore the file without crashes, but Form1::d0() is still semantically wrong (mostly nop/pop/ret after reconstruction). What I already did: Static-only approach (no runtime injector/tracer). Extracted runtime semantics from VMRuntime.dll (ReadPattern, ReadCalls, ExecCalls, ExecFlow). Added custom macro reader profile generation (CSVM7_READERS.recon.map). Added dedicated opcode handling and conservative stack-effect validation for problematic opcodes (0005..0008). Removed invalid CFG/max-stack failures, but final method logic is still incomplete. Could you clarify what differs between your successful approach and the usual AgileNETUnpackMe-style mapping? Specifically: Did you recover true composite semantics per opcode from runtime handlers, or use a different normalization step? For opcodes like 0005..0008, how did you decide between Ceq/Stelem/Nop without breaking stack/CFG? Did you rely on handler body signatures only, or also on operand read order + exec call patterns? Did you patch OpCodeHandlerInfoReader, composite map refinement, or both? Is there one key heuristic I am missing that turns a “stable but empty” devirtualization into a correct d0() reconstruction? Any hint, pseudo-logic, or minimal example of your mapping/refinement strategy would help a lot. Thank you!