Mobile QR Code QR CODE

  1. (School of Electronic and Electrical Engineering, Hongik University, Korea)
  2. (Department of Electrical Engineering, Korea University, Korea)

Reverse engineering, Xilinx 7-series FPGAs, flash memory, bitstream, logic analyzer


In the past, field programmable gate array (FPGA) was explicitly used in special areas, such as automotives and aerospace industry. However, it has become gradually popular as it could be reconfigured for processors and parallel operations can be achieved, unlike in CPUs or GPUs, which makes FPGAs suitable for banks, vehicles, drones, and many other diverse applications and servers. In particular, FPGAs are widely used on the Internet of Things (IoT), which has been one of the fastest growing industries in recent years. Although development is progressing in various ways because of the rapidly increasing demand for FPGAs, security is still a vulnerable aspect.

Most FPGAs are designed based on Static Random Access Memory (SRAM) technology for reconfiguration. Additionally, programmable read only memory (PROM) or flash memory is designed collectively outside the FPGA chip to store data (bitstream). Moreover, PROM or flash memory is built into FPGAs for data storage. Recently, flash memory is preferred for reading and writing massive data efficiently because of a large number of computations and data.

Data stored in the external memory are automatically read when the power of the FPGA is on. The programmed logic can be extracted without damaging the FPGA by hijacking the bitstream data when bitstream data move from an external memory (PROM) to an FPGA. Hence, the approach is suitable for areas where security is a crucial factor. The attacker can exploit the extracted data to use Trojan horse attacks by adding malicious data to the FPGA logic. To prevent the attack, FPGA manufacturers attempted to apply encryptions, such as IEEE 1735 to the designed IP. However, weak points have recently been discovered, both in existing encryption methods and in IEEE 1735 [1-6].

Reverse engineering aims to extract information from an existing programmed system with little information by exploiting these security vulnerabilities. More specifically, the configured netlist is reconfigured by comprehending the structure of the external memory. Choi et al. [7] propose a reverse engineering method to restore the internal logic of the ROM. It proposes an efficient reverse engineering method by analyzing FPGA H/W resources targeting Xilinx Spartan-3 FPGA and analyzing the mapping relationship between FPGA primitives and H/W resources.

Currently, Xilinx has the largest share of the FPGA market, and is most often used as a target for reverse engineering. Xilinx supports two design compiler tools. Vivado ISE, which was initially released, supports up to 6-series of Xilinx FPGAs, and the recently released 7-series of FPGAs are also supported by Vivado tools. In reverse engineering using the Xilinx ISE tool [8-16], a study was conducted to restore the existing logic with the copied bitstream by hijacking the moment the bitstream is transmitted from the non-volatile memory. Since then, there has been increasing focus on reverse engineering [17-20] targeting Xilinx 7-series FPGAs.

In this study, we introduce the security vulnerabilities of FPGAs [21-23], which have been recently studied, and how attackers exploit them to carry out attacks. Moreover, we introduce recently researched defense methods against trojans. We introduce the structure of FPGAs before the Xilinx 7-series and the corresponding reverse engineering method.


1. Structure of Xilinx ISE and Vivado Tool

In general, an FPGA consists of a configurable logic block (CLB) as a logic block, switch matrix (SM) as a connection block, and input/output block (IOB) as an input/output block as shown in Fig. 1 CLB (Fig. 1(b)) constitutes the basic block of FPGA and serves to store logic, and its structure comprises two blocks called SLICE. There are two types of SLICE, called SLICEM or SLICEL, and each CLB contains a SLICEM and a SLICEL or two SLICELs. These SLICEs include four look-up tables (LUTs), eight flip flops (FFs), a carry logic network, and three types of multiplexers (MUXs). The SM shown in Fig. 1(c) connects the BLOCKs, and the points at both ends of the rectangular or square grid are implemented in the form of a single wire. The IOB in Fig. 1(d) provides a bi-directional interface between logics inside the FPGA for IO. Xilinx includes programmable logic point (PLP), programmable interconnect point (PIP), and programmable contents point (PCP) in each block so that designers can change the internal circuit of these three types of blocks. The PLP is responsible for the logical functions of the circuit, the PIP selects the internal connections, and the PCP maintains the stored values.

Fig. 2 illustrates the bitstream generation process of Xilinx ISE tool. RTL design uses -ngd build to generate Xilinx internal netlist (NGD file). Subsequently, -map is used to convert the NGD file to NCD file for mapping. Additionally, -par places circuit primitives on the actual FPGA chip and connects each circuit primitive to create a place and routing (P&R) NCD file. Fully P&R’d primitives (P&R’d NCD file) are converted to bitstream files using -bitgen. The bit file is converted into an MCS file and stored in the external memory, PROM. The P&R NCD file can generate an XDLRC file and XDL file via -ncd2xdl to convert into a xdl file format. The description of each file is as follows.

• NGD (Native Generic Database): A file that synthesizes RTL input in binary format with a generic gate.

• NCD (Native Circuit Description): Netlist file that maps the generic gates of the NGD file to the target FPGA in binary format.

• XDL (Xilinx Design Language): A file converted binary NCD file into text format the user can read.

• XDLRC (Xilinx Design Language Routing and Configurable logic block): A file that illustrates the chip architecture of the target FPGA and all available hardware resources in text format.

• BIT (bitstream file): A file that converts an NCD file to bitstream in binary format.

• MCS (Configuration Memory file): Converted from a bit file into a form that that can be stored in an external memory.

While existing Xilinx ISE supports 6-series FPGAs, Xilinx Vivado supports the latest series such as Virtex-7, Kintex-7, and Artix-7. Although Xilinx discontinued support for the ISE design tool in 2014, ISE continues to be widely used for FPGA programming because Vivado primarily supports high-performance and advanced devices.

Fig. 3 illustrates the Vivado Design Suite bitstream generation process, including the design of RTL, synthesis, floorplan, and implementation followed by design check and bitstream generation. In the RTL design stage, designers create RTL using hardware description language (HDL) tool or high-level synthesis (HLS) tool. In the case of HDL, there is no need for additional work because it is a hardware language; however, HLS requires converting to HDL after coding in C language. When the coding design is completed, verification is performed through simulation. It does not matter if it is verified with FPGA after synthesis; however, if an error occurs, it takes longer because it needs re-checking. Following the simulation, a netlist file is generated, and design optimization and P&R are performed in the implement design stage. The tool automatically performs this process, while it can also be modified by the designer. At the final design check point, the tool can be used to check how much H/W resources the designer has used, which resources are used in which location, and how they are connected. Once all the steps are complete, the configuration bitstream generation stage creates the bitstream file containing all information on the design. The created bitstream file is stored in the external memory.

Fig. 1. Internal Structure of FPGA.
Fig. 2. Conceptual diagram of the Xilinx ISE Design Suite flow.
Fig. 3. Conceptual diagram of the Xilinx Vivado Design Suite flow.

2. Bitstream File Format

FPGAs are composed of binary files called bitstreams. The bitstream contains information on which logical elements to configure, how to implement the target design, and how to operate the FPGA. The file format of bitstream is architecture dependent; however, most FPGAs from the same vendor use the same file format. The bitstream file encrypts sensitive parts, such as actual logic data or configurate data in a specific way, for security. Xilinx's bitstream file uses bit swapping when saving configurate data.

The bitstream file format of Xilinx 7-series FPGA is the same as shown in Fig. 4. The header part contains various information about the source and contents of the entire bitstream, such as the bitstream generation date, FPGA chip name, and tool version. It is saved in Tag-Length-Value (TLV) format when a bitstream file is generated using the Vivado tool.

The bus width auto detect plays a role in determining the bus width providing configuration data, and for this purpose, a specific byte pattern is included at the beginning of the bitstream file. The configuration logic checks the lower 8 bits of the parallel bus and sets the appropriate external bus width according to the received sequence. The synchronization word (Sync word) must find configuration logic before a configuration packet can be processed by the FPGA, where the configuration logic is used to align within the 32-bit word boundary. Synchronization word of most Xilinx FPGAs is set to 0xAA995566.

Bitstream commands all Xilinx 7-series FPGAs to operate as the way of reading or writing configuration registers and are divided into two packet types. The first type of packet is used to read and write registers. In the case of the 7-series, it uses only 5 out of 14 registers addresses. The second type of packet extends the number of words field in packets of type 1. Since the address is used in the type 1 packet, the address is omitted here, but it must be used the same as the type 1 packet that delivers address information.

The addresses specified in the configuration packet are mapped to registers that provide low-level control over the chip. Not all these registers participate in the programming sequence; some participate in the programming sequence and others control the physical aspects. Key registers used during programming are as follows:

• IDCODE: A register that stores the device ID code before writing to configuration memory.

• CRC: When the device receives a packet, it automatically updates the internal CRC calculation to include the contents of the packet. The write CRC register checks that the calculated CRC matches the expected value written in the register, and if there is no error, the flag is initialized to zero. It is possible to set whether the designer will use it or not.

• command: A register that store works that can be triggered immediately by the work being requested or delayed until other conditions are satisfied.

• FAR (Frame Address Register): Set address for next frame read or write.

• FDRI (Frame): When a frame is written to the FDRI, the frame data are written to the configuration memory address specified in FAR.

Fig. 4. Bitstream file format of Xilinx 7-series FPGA.

3. Flash Memory Structure

FGPA requires nonvolatile memory that can maintain data even when power is turned off to store bitstream files. PROM, which was widely used in the past, is a nonvolatile memory that enables users to read/write contents in byte units. However, a delay of approximately a millisecond per byte occurs in the writing time. Therefore, it is infeasible to be used as a memory or stack memory to store data and variables used in real time; however, it can be used to store nonvolatile for a long time once written, so it is primarily used for reading only or for data backup. Conversely, flash memory can read freely in bytes, and the memory cell structure is simpler than PROM. So, it can be made into a mass storage, and it displays a much faster speed when writing the entire block.

Recently, most Xilinx FPGA had flash memory outside the FPGA chip, and the extracted bitstream file is stored in this external flash memory. However, bitstream files contain unnecessary data, such as headers, including file creation date and tool version, and noop (no operation), which is an unused part. Therefore, when writing a bitstream file to memory, only the actual data are saved, and unnecessary data are excluded.

Fig. 5 and 6 illustrate the structure between the FPGA chip and flash memory. Most Xilinx FPGAs are designed with similar structures. The pins of the FPGA chip are different for each FPGA; however, in the case of flash memory, most of the same flash memory is used and the pin information is the same. When the generated bitstream file is stored in flash memory, data are entered via SDI/DQ0 pin. Subsequently, when power is applied to the FPGA, data are exported via SDO/DQ1 to retrieve the bitstream file data stored in flash memory.

Fig. 5. Conceptual diagram of the Xilinx Vivado design flow (Artix-7)[17].
Fig. 6. A simplified of Xilinx Vivado design flow.


1. Trojan Attack using FPGA Security Issue

FPGA is encrypted in special patterns and methods, such as bitstream files, external memory, and IP to enhance security. Most FPGA encryption is a black box; however, many vulnerabilities are still found. There are many Trojan attacks that exploit these vulnerabilities to maliciously modify circuits or penetrate malicious code.

Cahill et al. [1] revealed vulnerabilities n the compile process and presents solutions. The compile tools used in the FPGA CAD process are black box systems. Moreover, the generated bitstream file is exclusive and encrypted, so the designer does not know if the bitstream file is correctly implemented. Therefore, it is difficult for the designer to know even if the manager of the tool maliciously fixes it or a bug in the tool causes sensitive data to leak and significantly affects the system.

Yoon et al. [2] proposed a reverse engineering tool that detects Trojan horses to compensate for vulnerabilities in Virtex-5, a Xilinx FPGA5 series. Since FPGA is reconfigurable, malicious modification is possible in both the development and deployment stages (Fig. 7). Therefore, to effectively detect Trojan horses, detection should be possible in the development stage and in the netlist and deployment stages. The proposed tool learns various Trojans using machine learning as samples to detect Trojans in both stages. Machine learning consists of a learning stage that proceeds only in the forward direction and a hardware Trojan horse detection stage that proceeds in the forward and backward directions. In the forward-only direction, only netlists containing third-party IP cores are provided, and source files specified in HDL are not provided. In the reverse direction, only bitstream files are provided, and sources and netlists produced in the development stage are not available. When learning the Trojan horse, we focus on Trojan triggers rather than the Trojan payload. Hardware Trojan payloads may vary based on functionality and target, while hardware Trojan trigger logic has unique features that prevent hardware Trojan from being easily activated and detected. Therefore, we apply the learned data to logic to find the trigger of the Trojan horse.

Speith et al. [3] describes the structural problems of existing IEEE 1735. Specifically, IEEE 1735 uses a digital envelope to protect the IP itself and the rights granted by the IP author. Therefore, a unified format is specified for the protected IP to ensure security and compatibility between standard specifications and tools. The structure of a digital envelope contains parts that specify access rights and additional attributes, and parts that include encrypted real IP data, which are encrypted using the Session Key. The part that specifies access rights and additional attributes consists of a common block that grants permission to all supported tools and a tool block that grants permission to a specific tool. This encryption structure designs an attacker that can fully control the EDA tool execution environment based on the existing Man-at-the-End (MATE) attack model [6]. In the design of the attacker, the symmetric session key is decrypted using the RSA private key within the digital envelope of the IP. Subsequently, the session key is used to decrypt the protected IP data. An attacker designed this way can completely analyze the EDA tool software and manipulate and extract values during execution. Protected IPs of FPGAs can be attacked, decrypted, and maliciously modified and reconfigured in a short time using the IEEE 1735 encryption structure. The method targets the EDA tools of representative companies in the FPGA market, such as Inter Quartus Prime, Cadence Xcelium, Lattice Radiant, Microsemi Libero SoC, Siemens Medelsim, and Xilinx Vivado Design Suite. The vulnerabilities for each EDA tool are as follows.

Intel Quartus Prime searches program memory for documented RSA key names to identify the interest Dynamic Link Library (DLL) at runtime. The identified DLL provides only IEEE 1735 encryption and includes a portion containing public keys from other vendors and symbols supporting the reverse engineering process by providing human-readable names to library functions. It automatically searches using key\_keyname to identify the encrypted subroutine. According to IEEE 1735, the key\_keyname is located before the actual key identifier within the digital envelope. It prepares the assembly key by analyzing a string reference, and an RSA private key for decryption. Publishing the RSA private key is straightforward because the private key is only protected by the XOR of two hard-coded byte arrays.

Cadence Xcelium is a logic simulation-based verification tool. To identify the target keys of Cadence, refer to the user guide document to identify the two target keys. One of them is the now obsolete 512-bit RSA key. Owing to the availability of symbols and the absence of code obfuscation, automatic scanning of executables for documented RSA key names reveals target functions. When a function is called, it calls one of two other functions depending on the selected encryption key. The function returns a static memory address pointing to the private key, all stored in plaintext. Therefore, it is relatively simple to reverse engineer and recover RSA private keys.

Latice Radiant automatically searches the documented key name again and identifies the target library [20] to find a function that loads the security key. A reference to the caller of the corresponding function is followed to extract the RSA private key from the decryption context. The searched decryption function then calls the RSA decryption function provided by OpenSSL. Subsequently, it inserts a custom code that triggers decryption of the target private key and extracts the RSA private key from the OpenSSL decryption at runtime.

In the Microsemi Libero SOC, automatic scanning of RSA key names represents 2048 bits of RSA private key in program memory. However, there is no access right to the encrypted IP or its RSA public key. Therefore, we execute Microsemi Libero SoC, import the manufactured IP, execute the RSA decryption routine, and verify the behavior at runtime. Consequently, we confirmed that Libero SoC first supplies encrypted soft IP to the synthesizer to generate synthetic and re-encrypted IP at the netlist level. Additionally, the Libero SoC itself interacts with encrypted files via a dedicated executable file and is dynamically linked to DLLs with a code obfuscation function in this executable file. This complexity invalidates all anti-debugging measures that protect DLLs using ScyllaHide [21]. Moreover, it uses integrity checks across the library to prevent software breakpoint insertion and uses hardware breakpoint to invalidate this protection. The RSA encryption session key is found in the memory when it is passed as an input to a function called very close to the searched RSA key name.

Siemens ModelSim is generally bundled with other EDA tools and encrypted IPs for these tools include additional tool blocks for ModelSim. Therefore, extracting private RSA keys from Siemens ModelSim is fatal to other FPGA vendors. Since the encryption function cannot be identified within the main ModelSim executable file, so we connect the debugger and trace all subprocess calls. Therefore, it identifies the subprocess processing the decryption of the protected IP, as shown in the console output. Moreover, static analysis is used to check if encryption libraries within this subprocess are used; however, it cannot check all cryptographic functions. Therefore, we match the file name and line number with the implementation of the open-source encryption library to identify the missing encryption function. To recover session keys, we reconstruct the white box algorithm with high-level language so that the oracle executes the white box decryption. As a result, we found three separate RSA key pairs, two 1024 bits, and one 2048 bits pair. These RSA keys use the same decryption routine. Given the white box data associated with each key, the protected IP can be decrypted without knowledge of the key.

Fig. 7. System overview[2].

2. Reverse Engineering

While comprehensive review of general reverse engineering techniques was studied in [8], this paper focuses on exploring more recent reverse engineering approaches which were applied to the latest FPGAs based on the Vivado design suite. Choi et al. [7] analyzed the mapping relationship between FPGA primitives and FPGA hardware resources targeting Xilinx Spartan-3 FPGA and proposes reverse engineering using them. Generally, FPGAs provide a primitive library written in HDL for easy RTL implementation. In the case of the target, ROM of Xilinx XC3S50, there are five types of primitive libraries, as shown in Fig. 8. To analyze FPGA hardware resources, it analyzes all bitstreams generated by synthesizing and implementing each ROM primitive library. Analysis of the generated bitstream is as follows.

• Bitstream generation for each primitive

• ROM location search

• Extract ROM data for target bitstream

• ROM data rearrangement

Through the above steps, it is revealed that all ROMs are internally assigned to SLICE's LUTs, and the ROM data of the S-BOX are completely recovered using the most widely used algorithm, advanced encryption standard (AES). Additionally, the proposed reverse engineering can be applied to all types of primitive libraries.

Zhang et al. [13] proposed a new FPGA reverse engineering toolchain. It compiled an integrated database containing FPGA architecture information and bitstream mapping information. Two tools were developed: Bitstream Reversal Tool (BRT) and Netlist Reversal Tool (NRT). It can search for RTL code in FPGA bitstream using two tools.

The proposed toolchain includes all reverse engineering from bitstream to netlist and from netlist to code without the support of other tools. The overall reverse engineering is shown in Fig. 9. Connect the configuration lines of the PCB (Print Circuit Board) and apply power to the target FPGA. Hijack when FPGA reads bitstream from external non-volatile memory. The obtained bitstream is then supplied to the toolchain. Our BRT, supported by the database containing FPGA architecture information and bitstream mapping information, decompiles the bitstream into a netlist, and then NRT converts the netlist into RTL code. Using this reverse engineering method, the netlist is restored to 100%. However, there is a limitation in that the encrypted bitstream file cannot be applied.

Yu et al. [16] revealed that the bitstream file swaps in a certain pattern and proposes a method of extracting a complete circuit by combining signal connection data of programmable interconnect point (PIP) after identifying the pattern. In the Vivado tool, the logic is generated with a MUX and converts the input to the LUT into an output signal. The LUT is set as default; however, the user can use the LUT at the desired location. Therefore, the configuration position of each LUT can be determined by analyzing the bitstream generated by the LUT. LUT is written in a specific order at intervals of 404 bytes and is written in units of 2 bytes at a time. When power is supplied to the FPGA and the use of the LUT is activated, a total of 8 bytes are extracted in units of 2 bytes at intervals of 404 bytes based on the active start bit. A specific pattern was found in the extracted data. Accordingly, a 100% restoration rate was achieved using an in-house tool.

Fig. 8. Implementation S-box of AES on FPGA.
Fig. 9. An overview of reverse engineering flow[13].


Table 1 presents a summary of the characteristics and strengths and weaknesses of recent reverse engineering studies. Choi proposed a method of restoring ROM data using the mapping relationship between FPGA primitives and FPGA hardware resources. The proposed reverse engineering has the advantage of being verified for Xilinx FPGA Spartan-3 and additionally applicable to all types of basic libraries of ROM data; however, verification for recent FPGAs has not yet been made.

The reverse engineering tool proposed by Zhang designed a highly accurate tool for spartan-6. However, it cannot be applied to an encrypted bitstream file, and it is time consuming to invert the bitstream. Yu's reverse engineering tool extracts a complete circuit by combining the signal connection data of the PIP and verifies 100% accuracy for Artix-7 using a self-developed verification tool. However, there is a disadvantage that the application range of the tool for verification is limited.

Table 2 summarizes FPGA security vulnerabilities. Cahill et al. [1] stated that modifications can be made during compilation. Yoon at al. In [2] revealed that although FPGA has the advantage of being reconfigurable, it has vulnerabilities in the development and deployment stages. Moreover, Spieth et al. [3] revealed that there is a problem with the IEEE 1735 encryption structure itself, which has been commonly used.

Table 1. Comparison of recent reverse engineering methods.


Research Objective

Target Device



Choi [7]

ROM data RE


Applicable to various default libraries.

Lack of verification on recent FPGA

Zhang [13]



High accuracy

Not applicable to encrypted files, time consuming for bitstream reversal

Yu [16]

All device


High accuracy

Limited target devices

Table 2. FPGA security issues.


Target FPGA

Weak Point

Cahill [1]

All device

Malicious modification is possible during compilation.

Yoon [2]


Malicious manipulation and modification are possible even after the deployment stage.

Speith [3]

All device

Security issues with the IEEE 1735 encryption scheme itself.


The possibility of a trojan attack using FPGA vulnerabilities is extremely high. Spieth explains security vulnerabilities using IEEE 1735 and security vulnerabilities for FPGAs from FPGA vendors using this security method. Various studies have been conducted for reverse engineering using these FPGA security vulnerabilities, such as a method using the mapping relationship between FPGA primitives and FPGA hardware resources and designing a new toolchain. Additionally, Yu conducted research on the LUT location of Xilinx's bitstream file and how it is recorded through reverse engineering. Further research on FPGA reverse engineering should be conducted in a wider scope as well as what is introduced in this paper, and efforts are still needed to study the latest versions of each FPGA.


This work was supported as part of the Military Crypto Research Center (UD210027XD) funded by Defense Acquisition Program Administration (DAPA) and Agency for Defense Development (ADD). This work was supported by Korea Institute for Advancement of Technology (KIAT) grant funded by the Korea Government (MOTIE) (P0012451, The Competency Development Program for Industry Specialist).


E. Cahill, B. Hutchings, and J. Goeders, "Approaches for FPGA design assurance," ACM Transactions on Reconfigurable Technology and Systems (TRETS), vol. 15, no. 3, pp. 1-29, 2021.DOI
J. Yoon et al., "A bitstream reverse engineering tool for FPGA hardware trojan detection," in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 2318-2320.DOI
J. Speith, F. Schweins, M. Ender, M. Fyrbiak, A. May, and C. Paar, "How Not to Protect Your IP-An Industry-Wide Break of IEEE 1735 Implementations," in 2022 IEEE Symposium on Security and Privacy (SP), 2022: IEEE, pp. 1656-1671.DOI
S. Mal-Sarkar, R. Karam, S. Narasimhan, A. Ghosh, A. Krishna, and S. Bhunia, "Design and validation for FPGA trust under hardware trojan attacks," IEEE Transactions on Multi-Scale Computing Systems, vol. 2, no. 3, pp. 186-198, 2016.DOI
A. Moradi, D. Oswald, C. Paar, and P. Swierczynski, "Side-channel attacks on the bitstream encryption mechanism of Altera Stratix II: facilitating black-box analysis using software reverse-engineering," in Proceedings of the ACM/SIGDA international symposium on Field programmable gate arrays, 2013, pp. 91-100.DOI
A. Akhunzada et al., "Man-At-The-End attacks: Analysis, taxonomy, human aspects, motivation and future directions," Journal of Network and Computer Applications, vol. 48, pp. 44-57, 2015.DOI
S. Choi, J. Yeo, and H. Yoo, "Extraction of ROM Data from Bitstream in Xilinx FPGA," in 2020 International SoC Design Conference (ISOCC), 2020: IEEE, pp. 97-98.DOI
H. Yu, H. Lee, S. Lee, Y. Kim, and H.-M. Lee, "Recent advances in FPGA reverse engineering," Electronics, vol. 7, no. 10, p. 246, 2018.DOI
F. Benz, A. Seffrin, and S. A. Huss, "Bil: A tool-chain for bitstream reverse-engineering," in 22nd International Conference on Field Programmable Logic and Applications (FPL), 2012: IEEE, pp. 735-738.DOI
S. Y. Choi, J. W. Park, and H. Y. Yoo, "Reverse engineering for Xilinx FPGA chips using ISE design tools," Journal of Integrated Circuits and Systems, vol. 6, no. 1, 2020.URL
J.-B. Note and É. Rannaud, "From the bitstream to the netlist," in FPGA, 2008, vol. 8, pp. 264-264.URL
Z. Ding, Q. Wu, Y. Zhang, and L. Zhu, "Deriving an NCD file from an FPGA bitstream: Methodology, architecture and evaluation," Microprocessors and Microsystems, vol. 37, no. 3, pp. 299-312, 2013.DOI
T. Zhang, J. Wang, S. Guo, and Z. Chen, "A comprehensive FPGA reverse engineering tool-chain: From bitstream to RTL code," IEEE Access, vol. 7, pp. 38379-38389, 2019.DOI
M. Ender, P. Swierczynski, S. Wallat, M. Wilhelm, P. M. Knopp, and C. Paar, "Insights into the mind of a trojan designer: the challenge to integrate a trojan into the bitstream," in Proceedings of the 24th Asia and South Pacific Design Automation Conference, 2019, pp. 112-119.DOI
H. Yu, H.-M. Lee, Y. Shin, and Y. Kim, "FPGA reverse engineering in Vivado design suite based on X-ray project," in 2019 International SoC Design Conference (ISOCC), 2019: IEEE, pp. 239-240.DOI
H. Yu, M. Cho, S. Lee, H.-M. Lee, and Y. Kim, "Multi Look-up Table FPGA Reverse Engineering with Bitstream Extraction and Multiple PIP/PLP Matching," Journal of Semiconductor Technology and Science, vol. 21, no. 1, pp. 49-61, 2021.DOI
Zynq-7000 All Programmable SoC Architecture Porting Quick Start Guide. Available online: (accessed on 8 December 2021).URL
Kintex7 FPGA Family product brief. Available online: (accessed on 8 December 2021).URL
A. Chhotaray, A. Nahiyan, T. Shrimpton, D. Forte, and M. Tehranipoor, "Standardizing bad cryptographic practice: A teardown of the IEEE standard for protecting electronic-design intellectual property," in Proceedings of the 2017 ACM SIGSAC conference on computer and communications security, 2017, pp. 1533-1546.DOI
Lattice Radiant Software 3.0 User Guide. Available online: (accessed on 8 December 2021).URL
Carbon cypher mrexodia and Mattiwatti. Available online: on 9 December 2021).URL
Dongchan Lee

Dongchan Lee was born in South Korea, in 1995. He received the B.S. degree in Electronic and Electrical Engineering from the Hongik University, South Korea, in 2021. He received the M.S. degree with the School of Electronic and Electrical Engineering, Hongik University, South Korea in 2023. His research interests include FPGA SoC design, FPGA reverse engineering for hardware security and digital artificial intelligence circuit design.

Sanghyun Lee

Sanghyun Lee was born in South Korea, in 1994. He received the B.S. degree in system semiconductor engineering from the Sangmyung University, South Korea, in 2021. He received the M.S. degree with the School of Electronic and Electrical Engineering, Hongik University, South Korea in 2023. His research interests include in-memory computing, and content-addressable memory.

Mannhee Cho

Mannhee Cho was born in South Korea, 1997. He received a B.S. degree in computer engineering from Kwangwoon University, Seoul, South Korea, in 2019, and the M.S. degree in electronic and electrical engineering from Hongik University, Seoul, South Korea, in 2021. He is currently working towards a Ph.D. degree in electrical engineering at Korea University, Seoul, South Korea. His research interests include FPGA reverse engineering for hardware security and analog/mixed-signal IC design for neuromorphic computing.

Hyung-Min Lee

Hyung-Min Lee received the B.S. degree in electrical engineering (summa cum laude) from Korea University, Seoul, South Korea, in 2006, the M.S. degree in electrical engineering from the Korea Advanced Institute of Science and Technology (KAIST), Daejeon, South Korea, in 2008, and the Ph.D. degree in electrical and computer engineering from the Georgia Institute of Technology, Atlanta, GA, USA, in 2014. From 2014 to 2015, he was with the Massachusetts Institute of Technology (MIT) as a Post-Doctoral Researcher. From 2015 to 2017, he was with the IBM T. J. Watson Research Center as a Research Staff Member. In 2017, he joined the School of Electrical Engineering, Korea University, where he is currently an Associate Professor. His research area includes analog/mixed-signal IC and microsystem design for biomedical, sensor, power management, and IoT applications.

Youngmin Kim

Youngmin Kim received the B.S. degree in electrical engineering from the Yonsei University, Seoul, Korea, in 1999, and the M.S. and Ph.D. degrees in electrical engineering from the university of Michigan, Ann Arbor, in 2003 and 2007, respectively. He has held a senior engineer position in the Qualcomm, San Diego, CA. He is currently a Professor at Hongik University, Seoul, South Korea. Prior to joining Hongik University, he was with the School of Computer and Information Engineering at Kwangwoon University, Seoul, South Korea, and the School of Electrical and Computer Engineering at the Ulsan National Institute of Science and Technology (UNIST), Ulsan, South Korea. His research interests include AI circuits, embedded systems, variability-aware design methodologies, design for manufacturability, design and technology co-optimization methodologies, and low-power and 3D IC designs.