Industrializing the disassembly of an undocumented processor from a raw binary is a complex task that can be broken down into four key steps:For the first phase of this project, the goal is to build dedicated, lightweight disassemblers—since, for bare-metal binaries, tools like Ghidra require manual processor target selection before analysis can begin.To determine whether a binary was compiled for a specific architecture, the strategy consists of disassembling the binary (both statically and dynamically) against candidate instruction sets until:Static disassembly is the first line of defense. However, if it fails due to obfuscation, compression, or encryption, we must escalate to dynamic execution and analysis.Only after systematically eliminating all known architectures can we confidently conclude that we are dealing with a custom or undocumented processor.Before deploying heavy machinery for undocumented processors, the logical first step was to check against known architectures.Ghidra relies on the SLAgh specification language and maintains an extensive library of processor definitions. The original plan was to leverage its API to extract a normalized opcode mapping table. However, after several attempts, Ghidra proved unsuitable for this specific pipeline for two reasons:Ghidra is a remarkable tool, and its underlying codebase is a work of art. But when required metadata is missing from the .slaspec or .pspec definitions, it must be added manually. At that point, implementing a dedicated, lightweight disassembler becomes a far more practical alternative.The second attempt involved generating a raw .HEX file containing all possible byte combinations and passing it through dis51. This approach failed because dis51 is an execution-tracing disassembler: it follows control flow rather than performing linear sweeping. If a JMP instruction branches backward, any bytes immediately following the jump that are not reached by other execution paths are categorized as raw data blocks. To effectively use dis51, one cannot simply feed it a linear array of opcodes; it expects a valid, structured program flow.The winning strategy was prompting Gemini to generate the normalized instruction mapping table. After refining the prompt, the model generated a Python script containing the full opcode mapping alongside a processor-specific lookup table for Special Function Registers (SFR).Using this generated table, writing the functional static disassembler took under an hour. It also laid the foundation for the dynamic disassembly simulator. While the table contained a few minor bugs, the time saved was substantial.Although this approach is not fully generic out-of-the-box, it is straightforward. The core structure of the disassembler and execution loop remains virtually identical when porting to other architectures. Furthermore, building small, single-purpose utilities makes parallelizing multi-architecture scanning trivial.This experiment provides a clear demonstration of how Large Language Models (LLMs) can accelerate lower-level systems development and reverse engineering tasks by handling structural boilerplate without sacrificing control over execution logic.