StackGuard+ : Interoperable alternative to High

canary-based protection of stack smashing Argument

1 2,✉
Kangmin Kim, Jeong-Nyeo Kim,
and Seungkwang Lee1,✉
1
Department of Cyber Security, Dankook University, Yongin, South Ko- Return address

Buffer grows
rea
2
Cyber Security Research Division, ETRI, Daejeon, South Korea Saved frame pointer
✉ E-mail: jnkim@[Link] and [Link]@[Link]

Buffer
This paper introduces a novel software-based approach to enhancing
stack smashing protection in C/C++ applications, specifically targeting
return-oriented programming attacks, which remain a significant threat
to firmware and software security. Traditional canary-based protections
are vulnerable to brute-force and format string attacks. Additionally, Fig. 1 Previous stack structure vulnerable to buffer overflow
many stack protection mechanisms require access to the source code
or recompilation, complicating the security of existing binaries. This
paper proposes a new method, aptly named StackGuard+ , that modifies
the canary-based protection mechanism by altering the code responsible
• We maintain the same size of machine code during the code replace-
for canary insertion and verification. This change ensures the integrity ment to ensure interoperability. This allows our method to be applied
of the return address while maintaining the original code size, allowing without requiring binary recompilation.
for seamless interoperability without the need for recompilation or addi- • Consequently, our approach does not introduce any additional time or
tional hardware. The approach can be automated using a Python script, space overhead.
which modifies existing canary-based binaries with only 26 bytes of
machine code on the ×86-64 platform. Moreover, this approach can be Related work: In this section, we present a concise overview of current
easily adapted to other platforms, including ×86 and ARM64.
stack protection methods, which can be broadly categorized into two
main groups: compiler-based techniques and static analysis methods.
Introduction: Stack buffer overflow, sometimes referred to as stack Most of these approaches necessitate access to the source code. How-
smashing, is a type of software vulnerability that occurs when a pro- ever, it is important to note that some techniques involve modifications
gram writes more data into a stack-based buffer than it can hold, causing at the binary level.
the excess data to overflow into adjacent memory locations. This can
lead to unintended consequences, including the potential for an attacker Compiler modifications: StackGuard [2]: StackGuard is a widely rec-
to execute malicious code or manipulate the program’s behaviour. An at- ognized software-based countermeasure that modifies the C compiler to
tacker causes a buffer overflow by placing data to be used to overwrite insert a random value, known as a canary, between the frame pointer
the return address in the stack or sensitive control data. and the return address on the stack. By verifying if this canary value has
The return-oriented programming (ROP) attack [1] is used by at- been altered, StackGuard can effectively detect buffer overflow attacks.
tackers to run malicious code by using existing pieces of code within Since GCC version 4.1, StackGuard has been implemented by default,
a program. Typically, this attack exploits either stack buffer overflows applying a random canary to all binaries created thereafter.
or memory vulnerabilities to gain control over the execution flow of the The functionality of StackGuard can be demonstrated with the fol-
target system. Since malicious instructions cannot be directly injected in lowing source code, which implements the echo command. A critical
memory areas, an attacker looks for executable code fragments to craft a aspect to note is that the strcpy function does not check the length of
sequence of instructions that perform specific actions, such as bypassing the source, making it vulnerable to buffer overflow. To mitigate this vul-
countermeasures, gaining unauthorized access to a system, or executing nerability, the canary value is placed above the buffer space (between 1
malicious code. and 2 in Figure 1), allowing for the detection of buffer overflow.
C/C++ applications are particularly vulnerable to ROP attacks due
to their lack of memory protection and reliance on writable memory for #include <stdio.h>
implementing call-return abstractions. When data is stored beyond the #include <string.h>
buffer’s capacity, as illustrated in Figure 1, the stack structure allows
an attacker to easily corrupt the return address, facilitating code reuse void echo(const char* input){
for ROPattacks. char buffer[30];
To effectively mitigate ROP attacks, it is crucial to ensure the strcpy(buffer, input);
integrity of the return address. Traditional mitigation techniques in- printf("Copied string: %s\n", buffer);
clude stack canaries [2], control flow integrity [3], and separate se- }
cure stacks. However, many of these countermeasures are challenging
to apply directly to existing binaries due to their high costs and de- int main(int argc, char* argv[]){
pendency on source code or recompilation. Additionally, some meth- if(argc == 2){
ods require hardware-assisted elements in the device. To address this echo(argv[1]);
issue, we propose a secure software-based approach, aptly named }else{
StackGuard+ , for stack smashing protection that guarantees the in- printf("no argument provided. \n");
tegrity of the return address without having to recompile the existing }
binaries. return 0;
To achieve this goal, we revisit the canary-based approach and ad- }
dress its limitations. Specifically, we leverage the existing canary-based
protection structure to enhance security without affecting unrelated Below is the assembly code corresponding to the source code pro-
code. Our main contributions can be summarized as follows: vided earlier. At lines A–B, a random value 8 bytes in length (including
a leading zero) is fetched from fs:40. This value, known as the canary,
is placed at the top of the buffer as explained previously. Before the
• We replace the existing canary insertion and verification code with our function returns to its caller, the integrity of the canary is verified by
own, protecting against bypassing the canary value. comparing it with its original value at lines C–D. If the size of the source

ELECTRONICS LETTERS October 2024 Vol. 60 No. 19 [Link]/iet-el 1

being copied exceeds the destination buffer size, the canary is overwrit- a separate stack for each function call. When a function returns, the top
ten, which is detected as stack smashing at line E. address in the RAS is popped, and the control flow integrity is verified
by comparing the return addresses.
echo: However, RAS is also a hardware-based solution. Additionally, RAS
.LFB1: overflow can occur if the stack is deeply nested or contains a recursive
.cfi_startproc function because the stack size is static. This overflow causes the proces-
endbr64 sor to waste time waiting for the RAS data to clear. To alleviate this per-
push rbp formance overhead, encryption engines may be used [10]. Specifically,
.cfi_def_cfa_offset 16 the RAS monitors its capacity and, when nearing full, pops the oldest
.cfi_offset 6, -16 return address, encrypts it, and stores it in memory. If the stack later
mov rbp, rsp empties, the RAS reads and decrypts the stored address, then pushes it
.cfi_def_cfa_register 6 back to the bottom of the stack. This proactive approach helps minimize
sub rsp, 64 delays caused by RAS overflow.
mov QWORD PTR -56[rbp], rdi LsStk [11]: The LsStk algorithm prevents the exploitation of return
mov rax, QWORD PTR fs:40;A addresses through buffer overflow by employing a Feistel cipher model
mov QWORD PTR -8[rbp], rax;B with two encryption keys and a rotation step. This two-level encryption
xor eax, eax scheme enhances security over simple XOR. The encryption algorithm
can be integrated into GCC compilers by modifying function prologue
; omitted and epilogue procedures for both 32-bit and 64-bit system architectures.
Although LsStk incurs some computational overhead comparable to the
call printf@PLT RC5 algorithm, it still represents a cost-effective solution for preventing
nop buffer overflow attacks.
mov rax, QWORD PTR -8[rbp];C
sub rax, QWORD PTR fs:40;D
Static analysis: VMcanary [12]: This countermeasure focuses on en-
je.L3
hancing WebAssembly (Wasm) applications with canary-based protec-
call __stack_chk_fail@PLT;E
tion to mitigate buffer overflow vulnerabilities. It introduces two new
.L3:
instructions, [Link] and [Link], which are integrated
leave
into the Wasm binary through a binary instrumentation process. Af-
.cfi_def_cfa 7, 8
ter binary instrumentation, a type checker validates the correctness of
ret
operand types, particularly ensuring that the canary values inserted are
However, stack canaries do not guarantee perfect security due to of the appropriate 8-byte size (i64 type). The execution engine in-
several vulnerabilities. First, format string vulnerabilities [4] can cause terprets the instrumented Wasm code, executing the canary instruc-
memory leakage, allowing attackers to extract all types of canaries, ex- tions as part of its operational flow while maintaining compatibility
cept possibly the random XOR type. Second, brute-force attacks [5] can with Wasm.
be feasible because of the canaries’ short lengths (i.e. three or seven To ensure that the protection layer does not disturb the expected pro-
bytes). To protect memory from ROP attacks, some techniques employ gram behaviour, an automated validator conducts experiment by com-
dynamic canaries generated using dedicated physical unclonable func- paring the execution results before and after canary insertion. Addition-
tions (PUF) [6]. However, this hardware-based countermeasure is costly ally, regression testing verifies that the return values of functions re-
and challenging to implement on low-cost devices. main consistent across different test cases, further ensuring the enhanced
Return address defender (RAD) [7]: This is a compiler patch de- Wasm applications against buffer overflow vulnerability.
signed for GCC. RAD adds protection code to the prologues and epi- KIUWAN [13]: This tool scans the source code for various buffer
logues of function calls. It operates by storing a copy of return address overflow vulnerabilities, which are categorized by different types, pro-
in a data segment called return address repository (RAR) and using it gramming languages, and priority levels. If the analysis tool finds a
in two different ways. The first method, called MineZone RAD, declares vulnerable module, it is converted into a standardized rule according to
a global integer array and divides it into three parts. The first and third the strategy of the vulnerability store. The vulnerabilities are then trans-
parts are set to MineZone, which are read-only areas protected by the formed by the source code healing module. Specifically, unsafe functions
mprotect() system call, while the middle part of the array is set to like strcpy and sprintf are replaced with more secure counterparts
RAR. The second method, called Read-only RAD, is similar to Mine- such as strncpy and snprintf using regular expressions. The modi-
Zone RAD but instead of setting up MineZone, it sets the RAR itself fied source code, obtained through the source code healing module, is
as a read-only area to protect it. Although MineZone RAD is more then subjected to a reevaluation using KIUWAN. If the issue with the
efficient, ReadOnly RAD is more secure. However, with the security vulnerability is not resolved, the public repository will be updated.
of RAD, some computational overhead and additional memory space Rewriting binary [14]: When the compiler and source code are not
are required. available, the binary code is disassembled to prevent buffer overflow at-
Shadow stack [8]: To guarantee the integrity of return addresses, tacks. After disassembling, the next step is to find the boundary of a
shadow stack prevents control-flow hijacking attacks by employing two user-defined function and the position of the strcpy function calls. The
distinct methods as follows: One approach involves comparing the re- proposed countermeasure uses a stack frame to protect the return ad-
turn address stored in the program stack with its corresponding entry dress. The return address is protected using the direction in which the
on the shadow stack. This method facilitates immediate detection of string is written to the local variable.
any discrepancies between the two addresses, effectively identifying any First, the user-defined function is rewritten to detect buffer overflow.
corruption in the program’s return address. Such immediate detection Prior to the function call, the stack frame size is expanded, and the re-
proves particularly useful during debugging and testing phases. turn address is inserted into this newly expanded stack space, which is
Alternatively, the shadow stack mechanism can opt to rely directly on positioned below the local variables. After the user-defined function is
the return address stored within the shadow stack itself. In this approach, executed, the return address stored in the expanded space is retrieved
the mechanism completely mitigates control-flow hijacking attacks, as it and compared with the original return address. Since the copied return
bypasses the attacker-controlled return address. Moreover, this method address is protected from being overwritten by a string, any mismatch
avoids the computational overhead associated with the process of com- between the two addresses will result in the termination of the program.
paring return addresses while offering an equivalent level of security. Second, this approach involves rewriting the strcpy function. The
However, this needs hardware support, which can be difficult to support modified strcpy function compares the value of the base pointer register
all systems at the moment. with the position of the inserted buffer before returning to the calling
Return address stack (RAS) [9]: The return address stack (RAS) function. If the buffer’s address value exceeds the base pointer register
operates similarly to a shadow stack by maintaining return addresses in value, it signals a buffer overflow.

2 ELECTRONICS LETTERS October 2024 Vol. 60 No. 19 [Link]/iet-el

 elif file_class == ‘2’:
return ‘64-bit’

def modify_binary(hex_data, architecture):

if architecture == ‘32-bit’:
replacement_dict = replacement_dict_32
elif architecture == ‘64-bit’:
replacement_dict = replacement_dict_64

for old_hex_string, new_hex_string in

replacement_dict.items():
hex_data = [Link](old_hex_string,
new_hex_string, hex_data)
Fig. 2 Overview of the proposed method
binary_data = [Link](hex_data)
return binary_data
So far, we have explained the existing countermeasure against buffer
overflow vulnerabilities. As previously mentioned, the main disadvan-
replacement_dict_64 = {
tage of these methods is their difficulty in achieving interoperability;
"64488b042528000000488945f8":
without the source code, recompilation is not a practical solution.
"488b4508644889042528000000",
"488b45f864482b042528000000":
Proposed method: In this section, we propose a StackGuard+ for
"488b450864482b042528000000"
securely storing and restoring return addresses by replacing the
}
existing machine code which inserts and verifies canaries. Because our
replacement occupies exactly the same size of machine code, this can be
replacement_dict_32 = {
adopted as an alternative to the canary-based countermeasures. More-
"65a1140000008945f4": "8b450465a314000000",
over, this involves binary-level modifications that eliminate the need for
"8b45f4652b0514000000": "8b4504652b0514000000"
recompilation, and does not require any modifications to libraries or the
}
use of separate modules. It is noteworthy that the vulnerabilities of ca-
naries can be addressed without run-time overhead.
hex_data = [Link]().strip()
Previously, the existing method of canary-based protection can be by-
architecture = binary_architecture(hex_data)
passed if the attacker overwrites the exact value of the canary in the
modified_binary =
correct location during the stack smashing, such as brute-forcing [5].
modify_binary(hex_data, architecture)
Here we note that the purpose of canary bypassing is to alter the re-
with open("vuln_modified", "wb") as output_file:
turn address to attacker’s malicious code. To guarantee the integrity of
output_file.write(modified_binary)
the original return address, we take advantage of the existing code for
inserting and restoring the canary in such a way to eliminate the need For given a binary to be protected, the 13-byte machine code at lines
for recompilation. A and B, where the canary is inserted into the stack, is uniquely found
StackGuard+ can be implemented by modifying just only three lines whereas, the remaining 4-byte the machine code at line C is not unique.
of the assembly code marked as A–C as follows. Here, it is noteworthy that the 13-byte machine code at lines C–D can be
uniquely identified. For these reasons, we performs the replacements as

• (A → A ): the return address at +8[rbp] is moved into rax. follows: (A, B) → (A , B ) and (C, D) → (C , D). Since our modified code

• (B → B ): the return address is now saved at fs:40. uses the same sequence of the opcode, we can protect against the stack

• (C → C ): before returning the function, the return address at +8[rbp] overflow attacks bypassing the canary without additional run-time over-
is copied to rax. head.
• D: the current value of the return address is compared to the saved
return address, which is obtained from fs:40. Security analysis: To evaluate the effectiveness of StackGuard+ , an ex-
periment was conducted on an Ubuntu 20.04 and Python 3.10. A target
In case that the buffer overflow disturbs the return address, it calls binary was compiled in the form of an ×86-64 ELF format with the ca-
__stack_chk_fail@PLT, enforcing the process to terminate at line E. nary protection. The overall experiment was conducted in the following
Figure 2 presents the overview of the proposed method by comparing steps:
with the original code. As mentioned previously, there is no difference
in the code size after applying our protection to A–C. To be specific, the 1. The bellow code was compiled to be attacked against the stack
total size of the machine codes from A to B is 13 bytes, and this remains smashing attack.
the same after changing them to A –B . In addition, the four-byte machine
code at C also occupies the same size of the space after modifying it to #include <stdio.h>
C . For this reason, our proposed method does not cause any misalign- void overflow_trigger() {
ment and therefore can be easily applied to the existing binaries without char buffer[64];
having to recompile.
In order to automate the modification on the existing binaries, we puts("Get canary");
first read the original binary in hexadecimal by using xxd and pipe it gets(buffer);
to the following program written in Python ([Link]), creating a new
binary without recompilation. Furthermore, by reading the ELF header printf(buffer);
information, it distinguishes between ×86 and ×86-64 architectures. puts("");

import sys puts("Try to disturb");

import re gets(buffer);
import subprocess }
def binary_architecture(hex_data):
file_class = hex_data[9] void unsafe_func() {
if file_class == ‘1’: puts("Control flow has been disturbed");
return ‘32-bit’ }

ELECTRONICS LETTERS October 2024 Vol. 60 No. 19 [Link]/iet-el 3

 [Link](payload)

print([Link]().decode(‘latin-1’))

3. By applying the following command to the target binary

xxd -p <target>|tr -d ‘\n’|python3 [Link]
we patched the target binary with StackGuard+ and obtained a new
binary named vuln_modified.
4. By using vuln_modified, we repeated the same attack to demon-
strate the security against the aforementioned vulnerability.

As a result, the experiment gives us the followings. First, the original

target binary cannot detect the manipulation of the control flow from
Fig. 3 Proposed method on the GCC optimization level -O2 overflow_trigger to unsafe_func. To be specific, the canary value
was successfully bypassed, printing the message

‘‘Control flow has been disturbed’’

On the other hand, the same attack on the vuln_modified was prevented
by StackGuard+ . The return address manipulation was detected, leading
to the internal calling of __stack_chk_fail@PLT, and the process ter-
minated with the message

‘‘*** stack smashing detected ***: terminated’’.

Discussion: So far, we have demonstrated that StackGuard+ is more ef-

fective against ROP attacks compared to canary-based protection. In this
section, we will further discuss the scalability of the proposed method
across different platforms and compilation optimization levels, as well
as an additional security issue.
In ARM64 assembly code using StackGuard, a random canary value
from __stack_chk_guard is copied to the x1 register and then inserted
into the stack at sp:0x28 during the insertion process. To detect stack
smashing attacks, the canary values stored in __stack_chk_guard and
Fig. 4 Stack structure of vuln_modified sp:0x28 are compared.
To implement StackGuard+ on ARM64, instead of inserting the ca-
nary into sp:0x28, the value of the link register x30, which stores the
int main() {
return address, must be inserted into __stack_chk_guard. In the func-
overflow_trigger();
tion prologue, the value of x30 is stored at sp:0x30. By copying the re-
}
turn address located at sp:0x30 into __stack_chk_guard, the integrity
2. By performing a buffer overflow attack bypassing the stack canary, of the return address can be verified by comparing the value stored in
the return address of overflow_trigger was overwritten with the sp:0x30 with that in __stack_chk_guard.
address of unsafe_func. To demonstrate the buffer overflow sce- The GCC optimization level introduces slight variations in the code
nario, we implemented an exploit using pwntools. It utilizes a for- area for canary insertion and verification. With the default optimization
mat string vulnerability to obtain the canary value and then uses it level -O0, the address for inserting a canary is determined by subtract-
to bypass the canary protection. Below is the python code used to ing an offset of 8 from rbp. At higher optimization levels such as -O1,
achieve this purpose: -O2, -O3, and -Os, this address is calculated by adding an offset to rsp.
Additionally, at optimization levels above -O1, the canary retrieved from
from pwn import * fs:0x28 might be stored in rsi instead of rax during the insertion steps.
p = process(‘<target>’) Importantly, these changes do not affect the machine code size.
Even in these optimized codes, the return address can always be
[Link]([Link]()) found by adding 0x10 to the address, where the canary was originally
[Link](‘%23$p’) inserted. For these reasons, the proposed scheme can be adapted to the
optimized binary code with a simple adjustment by copying the return
canary = int([Link](), 16) address to fs:0x28. Figure 3 illustrates the application of the proposed
[Link](f‘Canary: hex(canary)’) method to existing binaries compiled with -O2, while maintaining the
original machine code size. It is important to note that simply copying
payload = b’A’ * 64 the return address into the FS segment does not provide the attacker
payload += p32(canary) with any additional information through static analysis. This is because
payload += b’A’ * 12 the FS segment, code section, and stack frame all share the same
payload += p32(<target_addr>) access permissions.
Since StackGuard+ no longer inserts the canary value, as illustrated
[Link]() in Figure 4, the designated canary location is filled with either a garbage

Table 1. Comparison with existing countermeasures. The ‘-’ symbol indicates that the additional costs have been analysed based on Stack-
Guard

StackGuard [2] RAD [7] Shadow stack [8] LsStk [11] StackGuard+

Need for recompilation — Yes Yes Yes No

Additional overhead — RAS and its verification HW module Approx. RC5 Same as StackGuard

4 ELECTRONICS LETTERS October 2024 Vol. 60 No. 19 [Link]/iet-el

value or 1, depending on the execution environment. This allows for the distribution in any medium, provided the original work is properly cited,
possibility of overwriting the saved frame pointer, as shown in Figure 4, the use is non-commercial and no modifications or adaptations are made.
through a buffer overflow vulnerability. Let x represent the start address Received: 29 November 2023 Accepted: 25 July 2024
of the attacker’s shellcode. By replacing the saved frame pointer with x- doi: 10.1049/ell2.13310
8, the instruction pointer will move to the shellcode’s start address if both
the callee’s and caller’s epilogues are executed sequentially. However, References
this attack is limited to scenarios where there is no access to the caller’s
1 Roemer, R., et al.: Return-oriented programming: systems, languages,
stack frame between the callee’s and caller’s epilogues.
and applications. ACM Trans. Inf. Syst. Secur. 15(1) (2012). [Link]
Table 1 compares the costs of StackGuard+ with existing coun-
org/10.1145/2133375.2133377
termeasures. Compared to StackGuard, applied by default from GCC
2 Cowan, C., et al.: StackGuard: automatic adaptive detection and preven-
version 4.1, StackGuard+ requires no recompilation, introduces no tion of buffer-overflow attacks. In: USENIX Security Symposium. Vol.
additional run-time overhead, does not need hardware modules, and 98, pp. 63–78. ACM, New York (1998)
is adaptable to other platforms. While StackGuard can be bypassed, 3 Abadi, M., et al.: Control-flow integrity principles, implementations,
StackGuard+ effectively detects and terminates such attacks. and applications. ACM Trans. Inf. Syst. Secur. 13(1), 1–40 (2009)
4 Newsham, T.: Format string attacks (2000). Accessed July 2024. http:
Conclusion: Canaries are an effective method for preventing stack //[Link]/[Link]
smashing. However, they are not immune against brute-force attacks and 5 Marco-Gisbert, H., Ripoll, I.: Preventing brute force attacks against
can also be extracted due to format string vulnerability. In this study, we stack canary protection on networking servers. In: 2013 IEEE 12th In-
address these vulnerabilities of canaries while maintaining their simplic- ternational Symposium on Network Computing and Applications, pp.
ity and high efficiency. Importantly, our approach does not require the 243–250. IEEE, Piscataway, NJ (2013)
use of additional modules, compiler modifications, or recompilation. It 6 Roodsari, M.S., et al.: A secure canary-based hardware approach against
simply involves replacing the existing binary code pertaining to canaries ROP. Paper presented at the Italian conference on cybersecurity, Rome,
with our code of the same size. Specifically, this replacement involves 20–23 June 2022
only a total of 26 bytes and therefore can be automated using a simple 7 Chiueh, T.C., Hsu, F.H.: RAD: a compile-time solution to buffer
python script. In this process, recompilation is not necessary and this overflow attacks. In: Proceedings 21st International Conference on
Distributed Computing Systems, pp. 409–417. IEEE, Piscataway, NJ
gives us interoperability from a practical point of view. By doing so,
(2001)
our improvement is able to depend against the existing attacks on the
8 Burow, N., Zhang, X., Payer, M.: SoK: shining light on shadow stacks.
canary-protected executables thereby preventing various ROP attacks.
In: 2019 IEEE Symposium on Security and Privacy (SP), pp. 985–999.
Author contributions: Kangmin Kim: Software; writing—original IEEE, Piscataway, NJ (2019)
9 Cho, B., Kim, H.: Return address stack for protecting from buffer over-
draft. Jeong-Nyeo Kim: Formal analysis; methodology. Seungkwang
flow attack. J. Korea Acad.-Ind. Coop. Soc. 13(10), 4794–4800 (2012)
Lee: Supervision; writing—review & editing.
10 Bruner, G.J.: A secure architecture for defense against return address
Acknowledgements: This work was supported by Korea Research In- corruption. Master’s Thesis, University of Tennessee (2021)
stitute for defense Technology planning and advancement(KRIT) grant 11 Ahsan, M., Ali, M.: LsStk: lightweight solution to preventing stack from
buffer overflow vulnerability. In: 2023 17th International Conference
funded by the Korea government(DAPA(Defense Acquisition Pro-
on Open Source Systems and Technologies (ICOSST), pp. 1–7. IEEE,
gram Administration)) (No. 22-407-H00-001-002(KRIT-CT-22-051),
Piscataway, NJ (2023)
Board/Chip Anti-Tampering Technology Development, 2023).
12 Zhang, Z., et al.: VMCanary: effective memory protection for we-
Conflict of interest statement: The authors declare no conflicts of inter- bassembly via virtual machine-assisted approach. In: 2023 IEEE 23rd
International Conference on Software Quality, Reliability, and Security
est.
(QRS), pp. 662–671. IEEE, Piscataway, NJ (2023)
13 Shahab, A., et al.: An automated approach to fix buffer overflows. Int. J.
Data availability statement: The data that support the findings of this
Electr. Comput. Eng. 10(4), 3777 (2020)
study are available from the corresponding author upon reasonable re-
14 Eun-Sun, C.: Efficient buffer-overflow prevention technique using bi-
quest.
nary rewriting. KIPS Trans.: Part C 12(3), 323–330 (2005)
15 Mangard, S., Oswald, E., Popp, T.: Power Analysis Attacks: Revealing
© 2024 The Author(s). Electronics Letters published by John Wiley & the Secrets of Smart Cards. Springer New York, NY (2007)
Sons Ltd on behalf of The Institution of Engineering and Technology. 16 Rivest, R.L.: The RC5 encryption algorithm. In: International Workshop
This is an open access article under the terms of the Creative Commons on Fast Software Encryption, pp. 86–96. Springer, Berlin, Heidelberg
Attribution-NonCommercial-NoDerivs License, which permits use and (1994)

ELECTRONICS LETTERS October 2024 Vol. 60 No. 19 [Link]/iet-el 5