FPGA Bitstream Extraction: Xilinx, Altera & Lattice Guide

What Is FPGA Bitstream Extraction and Why Does It Matter?

Every FPGA is a blank slate at power-up. Its behaviour — routing, logic, I/O mapping, clock trees — is defined entirely by a bitstream loaded from an external configuration memory or a JTAG/SPI interface. FPGA bitstream extraction is the process of reading that bitstream back out of the device or its companion storage, so the design can be analysed, duplicated or ported to a replacement part.

The need arises in several real-world scenarios:

• End-of-life recovery. The original designer is gone, source HDL is lost, and a production line depends on the board. Extracting the bitstream is the first step toward industrial control board reverse engineering.
• Failure analysis. A field-return board behaves differently from the golden unit; comparing bitstreams reveals whether configuration corruption is the cause.
• Security auditing. Penetration testers extract bitstreams to evaluate whether proprietary IP inside the FPGA is adequately protected.
• Board-level duplication. When the FPGA is one component in a larger board-level duplication service, the bitstream must be captured alongside MCU firmware, EEPROM data and schematic files.

Before attempting extraction, you need to understand what the vendor allows, what it blocks and where the bitstream physically resides.

Where the Bitstream Lives: Configuration Paths

An FPGA can be configured through several paths. The extraction method depends on which path the original designer chose.

The simplest case is an external SPI flash. The bitstream sits in a standard NOR chip (often a Winbond W25Q or Micron N25Q). You can read it with any SPI programmer, and the process is identical to recovering configuration data from EEPROM or flash storage. The bitstream file is unencrypted unless the designer explicitly enabled AES encryption.

Xilinx (AMD) FPGA Bitstream Extraction

Readback via JTAG

Xilinx Spartan, Artix, Kintex and Virtex families all support a JTAG readback command defined in the configuration logic. In Vivado or ISE, the readback flow captures the contents of the configuration memory frames while the device is running. This is the official path for verifying a programmed device.

However, the designer can disable readback by setting specific bits in the bitstream header:

• Security bit (SBITS). In older Spartan-3 and Spartan-6 parts, setting the security register to “11” disables both readback and reconfiguration.
• BitStream.Security = Level1 or Level2. In 7-Series and UltraScale, Level 1 disables readback; Level 2 disables readback and restricts reconfiguration.
• AES-256 encryption. 7-Series devices store a 256-bit key in battery-backed BBRAM or eFUSE. The bitstream in external flash is ciphertext; even if you dump the flash, you get encrypted data.

Attacking Xilinx Protections

If readback is disabled but encryption is not enabled, the bitstream in the external flash is still plaintext. Reading the flash chip directly bypasses the FPGA’s readback lock entirely — the lock only prevents JTAG readback from the running device.

If AES encryption is active and the key is stored in BBRAM (volatile), removing the backup battery erases the key and bricks the device — the bitstream in flash becomes useless. If the key is burned into eFUSE, it is permanent but not directly readable through any documented interface. Academic attacks (DPA, electromagnetic side-channel analysis) have demonstrated key recovery on 7-Series parts under laboratory conditions, but these require expensive equipment and deep expertise. For most practical recovery projects, an encrypted Xilinx bitstream with an eFUSE key is a hard stop.

For a broader look at FPGA security cracking across vendors, see our FPGA cracking and bitstream recovery overview.

Intel (Altera) FPGA Bitstream Extraction

Cyclone, MAX 10 and Stratix Families

Altera’s configuration architecture differs from Xilinx’s in several ways. Cyclone II/III/IV devices load from serial or parallel configuration memory (EPCS/EPCQ chips). Like Xilinx, the simplest extraction path is reading the external configuration flash.

Altera offers these protection mechanisms:

• Design Security (Cyclone III LS, Stratix III and later). AES-128 or AES-256 encryption with a volatile key stored in on-chip battery-backed RAM.
• Tamper Protection. Stratix V and Arria 10 add tamper-detection circuitry that zeroes the key if physical intrusion is detected.
• Configuration Disable (MSEL pins). Some boards hard-wire MSEL to prevent JTAG configuration, but this is a board-level control, not a silicon lock.

Practical Extraction Steps

1. Identify the configuration device. Look for an EPCS, EPCQ or generic SPI flash near the FPGA. Check the MSEL pin strapping to determine the boot mode.
2. Read the configuration flash. Desolder the chip or use a test clip. Dump the full contents with a universal programmer.
3. Check for encryption. An unencrypted Altera bitstream starts with a recognisable preamble (0x6AF3). If the header is garbled, encryption is likely active.
4. If encrypted, assess the key storage. Volatile key in SRAM — removing backup power erases it. Non-volatile key in eFUSE — permanent but not extractable through normal channels.

Many Cyclone IV and MAX 10 designs in industrial equipment ship without encryption enabled. In those cases, FPGA bitstream extraction is straightforward: read the flash, load the .rbf or .sof into Quartus, and you have the functional bitstream.

Lattice FPGA Bitstream Extraction

MachXO, ECP and iCE40 Families

Lattice devices are popular in smaller designs — power management, I/O expansion, LED control. Many Lattice parts (MachXO2, MachXO3, iCE40) integrate on-chip flash, so there is no external configuration memory to read.

Lattice provides these security features:

• Readback Disable. A one-time programmable (OTP) bit that permanently blocks JTAG readback.
• AES-128 Encryption. Available on ECP3, ECP5 and MachXO2/3 devices. The key is stored in on-chip non-volatile memory.
• Password Protection. MachXO2 supports a 64-bit password that must be supplied before JTAG operations are allowed.

For unprotected Lattice devices, the Lattice Diamond programmer can read back the bitstream directly over JTAG. If the readback-disable bit is set but encryption is not enabled, physical attacks (FIB or glitching) may be possible, though the cost is rarely justified for the small designs these parts typically implement.

Lattice CPLDs (ispMACH, MachXO) share some of these protection mechanisms. If your target is a CPLD rather than an FPGA, our guide on unlocking protected CPLD devices covers the MAX, XC9500 and MachXO families in detail.

Vendor Protection Comparison at a Glance

The Extraction Workflow: Step by Step

Regardless of vendor, FPGA bitstream extraction follows a consistent decision tree:

1. Visual inspection. Identify the FPGA part number, configuration flash (if external), and JTAG header.
2. Attempt JTAG readback. Connect a JTAG programmer and try the vendor’s readback command. If it succeeds, you have the bitstream.
3. Read external configuration memory. If JTAG readback is locked, desolder or clip the SPI/BPI flash and dump it.
4. Analyse the dump. Check the file header for encryption markers. An unencrypted dump is immediately usable.
5. If encrypted, evaluate key storage. Volatile key? Battery removal may erase it. eFUSE/OTP key? Side-channel or invasive analysis is the only remaining path, and success is not guaranteed.
6. Reconstruct or reverse-engineer. Even with a raw bitstream, you may need to convert it back to a netlist for meaningful analysis. Open-source tools like Project X-Ray (Xilinx 7-Series) and Project Trellis (Lattice ECP5) can partially reverse bitstreams into gate-level netlists.

When the FPGA sits on a board alongside protected microcontrollers, the full recovery project may also require protected microcontroller firmware recovery and DSP chip decryption for co-processors.

Open-Source Bitstream Reverse Engineering Tools

A growing ecosystem of open-source projects can convert raw bitstreams into human-readable netlists or even back into HDL:

• Project X-Ray — documents Xilinx 7-Series bitstream format; used by the SymbiFlow/F4PGA toolchain.
• Project Trellis — does the same for Lattice ECP5.
• Project IceStorm — fully reverse-engineered bitstream format for Lattice iCE40; the most mature of the three.
• bitstream-to-netlist converters — scripts that map configuration bits back to LUT equations, routing muxes and I/O settings.

These tools do not crack encryption. They work on unencrypted bitstreams and translate the binary blob into a form an engineer can audit or modify.

Common Pitfalls and Failure Modes

Assuming Readback Lock Equals Encryption

Many designers disable JTAG readback but forget to enable encryption. The bitstream in external flash is still plaintext. Always check the flash chip before declaring the design unrecoverable.

Destroying Volatile Keys

If the encryption key is battery-backed, disconnecting or draining the battery before reading the flash renders the encrypted bitstream permanently useless. Document the power architecture before touching anything.

Ignoring Companion Devices

An FPGA rarely works alone. The board may carry EEPROMs with calibration data, MCUs with control firmware, or a second CPLD handling boot sequencing. A complete recovery means capturing everything — not just the FPGA bitstream. For boards where the full schematic is also needed, a complete PCB reverse engineering workflow ensures nothing is missed.

When FPGA Bitstream Extraction Fails: What Next?

If encryption is active and the key cannot be recovered, the options narrow to:

• Functional cloning. Treat the FPGA as a black box. Probe its I/O behaviour with logic analysers and oscilloscopes, then re-implement the logic in new HDL. This is expensive and time-consuming but sometimes the only path.
• Die-level analysis. Decapsulate the FPGA and image the configuration cells with a scanning electron microscope. Feasible for older, smaller devices; impractical for modern 28 nm or 16 nm parts with billions of configuration bits.
• Negotiation with the original vendor or designer. Sometimes the cheapest solution is a licensing agreement rather than a technical attack.

For legacy boards where the FPGA is one part of a broader obsolescence problem, a redesign that modernises the board without losing its behaviour may be more cost-effective than brute-force extraction.

Key Takeaways

• FPGA bitstream extraction difficulty is almost entirely determined by whether encryption is enabled — not by the readback-disable flag alone.
• External configuration flash is the easiest target. Read it before attempting anything invasive.
• Xilinx, Intel and Lattice each offer AES encryption, but key storage type (volatile vs. eFUSE/OTP) dictates the practical attack surface.
• Open-source tools can convert unencrypted bitstreams into netlists, closing the gap between raw binary and usable design data.
• Always map the full board — FPGA, MCU, EEPROM, CPLD — before starting. Partial recovery is rarely useful.

If you need professional FPGA bitstream extraction or a full board-level recovery, contact our engineering team for a free feasibility assessment. We handle Xilinx, Intel, Lattice and Microsemi devices across commercial, industrial and aerospace applications.

Related reading

• Sep 2026BOM Reverse Engineering | Parts Lists You Can Order
• Sep 2026Renesas RH850 Crack | Protection Levels Explained
• Sep 2026PCB Copy Lead Time | 3 Days vs 3 Weeks Explained