## 3 Method of Generating Dummy Power Trace Data
### Simulation Environment Setup  
To generate realistic dummy power traces, a simulation environment is constructed based on the Quick Emulator (QEMU) and the GNU Debugger (GDB), enabling the precise extraction of execution-level data from cryptographic implementations [14]. QEMU is an open-source virtualization tool that emulates various hardware architectures, enabling embedded system code to be executed in a controlled environment without requiring physical hardware. GDB is a widely used tool for debugging programs, enabling step-by-step execution analysis and real-time extraction of assembly instructions.  
The process of dummy power trace generation consists of three main stages: cryptographic code execution (Stage 1), processing via emulation and debugging (Stage 2), and extraction of assembly data followed by power trace conversion (Stage 3), as illustrated in Figure 6. In Stage 1 (Input), cryptographic code written in assembly is executed within a simulated environment. The code is transferred to QEMU, a virtualized execution platform, where it undergoes controlled execution. In Stage 2 (Processing), QEMU functions as an ARM Cortex-M4 virtual machine, executing cryptographic operations while GDB is utilized for debugging. Through this debugging interface, assembly-level instructions are extracted in real-time, enabling precise tracking of command execution and memory access patterns. Finally, in Stage 3 (Output), the extracted assembly data--comprising memory addresses,  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Tool** & **Version** \\ \hline arm-none-eabi-gcc (include GDB) & 12.2.1 \\ QEMU & 2.8.0 \\ ELMO & Python-elmo (2020) [38] \\ \hline \hline \end{tabular}
\end{table}
Table 4: The versions of the tools used.  
Figure 5: Architecture of the MLP model.  
instruction sequences, and operand values--is processed using the ELMO simulator. This conversion generates power consumption patterns, which are then analyzed for potential vulnerabilities to SCAs [30].  
This structured approach ensures a reproducible and controlled method for assessing cryptographic security against DL-SCAs.  
Figure 7 presents the QEMU configuration and simulated execution output for the STM32F4-Discovery board. Before the emulation, each algorithm was compiled using arm-none-eabi-gcc and executed on QEMU with four types of inputs: plaintext, password, plaintext with dummy, and password with dummy.  
The QEMU targeted the STM32F4-Discovery board and the STM32F407 VG microcontroller (STMicroelectronics, Plan-les-Ouates, Switzerland). The semihosting option was enabled to support debugging. Additionally, the -s option opened a debugging port, and the -S option halted execution until GDB was connected. Once connected, GDB communicated with the running QEMU process via the opened port to execute the compiled binary and generate a detailed execution log.  
This log captured low-level execution information, including memory addresses, executed instructions, operand values, and other data generated during the execution of cryptographic operations. The raw log was subsequently preprocessed into a structured  
Figure 6: Simulation environment for generating dummy power trace data.  
Figure 7: QEMU-based simulation of the STM32F4-Discovery board execution.  
CSV file containing memory addresses, operand values, instruction types, opcodes, dummy labels, and execution contexts corresponding to each input algorithm.