First of all, I want to thank @pulsoid<\/a> and @tieknimmers<\/a> for their excellent Fault inject advanced<\/em> course (TAoFI – The Art of Fault Injection<\/a>) that I attended. In their training, they provide great insights and ideas, thanks to their pioneering work and passionate pursuit of these topics. One of the mantras of the course was “Don’t glitch and pray<\/strong>” (\u00a9 Raelize<\/a>), and I tried to internalize this concept as much as possible. These articles were born precisely from that.<\/p>\n The term glitching<\/em>\u00a0refers to an external behavior that causes a chip to enter an anomalous state<\/strong>, allowing for the creation of a fault<\/strong>, which is an internal error that enables the execution of something different from what was expected. Let’s start with the basics. There are four main techniques for performing fault injection on a chip:<\/p>\n I will focus on the voltage glitching part, as it is one of the most approachable techniques with limited hardware. The basic concept is that we “deprive” the chip of power, making it “unstable”.<\/p>\n There are several ways to perform voltage glitching, primarily:<\/p>\n For now, we will use the crowbar to ground<\/strong> technique, which is used by ChipWhisperer<\/a>\u00a0devices. During the tests, I mainly used ChipWhisperer-Husky<\/a>. A detailed description of the technique can be found at: https:\/\/eprint.iacr.org\/2016\/810.pdf<\/a><\/p>\n As for the target of these attacks, I have chosen to work on ESP32<\/strong> for various reasons, primarily:<\/p>\n The main past works<\/strong> on these chips are the following (hoping to mention them all):<\/p>\n I encourage you to read them to get familiar with the topic, otherwise you will likely struggle to understand the rest of this article.<\/p>\n Let’s now try to create a “clean” situation that allows us to better explore what happens with glitching.<\/p>\n Unlike many examples found online, our goal is not to skip an instruction but to understand what else can happen and why. Thus, trying to make a “world” considered non-deterministic a little more deterministic.<\/strong><\/p>\n To do this, we need to:<\/p>\n So:<\/p>\n Now let’s try to create an environment that is as clean as possible, and see how to improve the code that is normally used as a starting point.<\/p>\n Generally, when working on glitching examples, a trigger signal<\/strong> is used, which is when the code of our interest is executed. This helps us explore the data more precisely by narrowing down the scope.<\/p>\n This method is often used to change a trigger PIN:<\/p>\n However, if we look at how this is translated at the assembler level, it generates:<\/p>\n Essentially, the function “0x40009B24” (gpio_output_set) is called, which is present in the ROM. By disassembling the ROM, we can see what happens:<\/p>\n In the documentation, you can find details about the addresses used:<\/p>\n And, more specifically:<\/p>\n According to the reference manual, we can use GPIO_OUT_W1TS_REG to activate the pin and GPIO_OUT_W1TC_REG to deactivate it, thus eliminating a call and a series of unnecessary instructions that could cause problems during glitching.<\/p>\n The final assembler code will be:<\/p>\n This way, we save instructions and tamper only with a very limited number of registers.<\/p>\n Once we have solved the initial problem, we need to find a simple way to maintain the context while losing as little information as possible<\/strong>.<\/p>\n My idea is to use CPU exceptions that allow to get a complete context<\/strong> (https:\/\/docs.espressif.com\/projects\/esp-idf\/en\/latest\/esp32\/api-guides\/fatal-errors.html#illegal-instr-msg). The initial idea was to execute the code at the bootloader level to “speed up” the boot phase. However, the exceptions are directly handled by the ROM, and the classic “Guru meditation” has not been implemented yet:<\/p>\n The advantage is having a complete context, but the downside is that each attempt would require resetting the CPU, resulting in fewer tests. However, at this moment, I prefer to have a clearer understanding of what is happening rather than being fast.<\/p>\n After conducting a search, I found out that the ROM uses the following code:<\/p>\n During boot, it sets up a series of exception handlers that point to a function that prints some information. However, these exceptions only provide partial information and are only available for certain types.<\/p>\n I have made various attempts to correctly implement the complete exception handlers<\/strong>, and it is possible, but not straightforward. The code that should be implemented is the same as the one already present in FreeRTOS<\/strong>:<\/p>\n For this reason, I preferred to have the original bootloader that implements FreeRTOS and already has all the exception handlers implemented.<\/p>\n To generate the exception, we have different methods, the simplest one being to perform a write to a non writable area:<\/p>\n This way, when necessary, with just one instruction, we will be able to see the complete context. Furthermore, using a unique method for all types of faults will allow us to perform a unified parsing in all situations and quickly identify if the injected glitch has allowed the instructions to continue until the end of the code.<\/strong><\/p>\n The standard fault injection example uses loops or similar methods that do not allow us to understand in detail what is happening, thus it’s not an optimal approach<\/strong>. Instead, repeated instructions are arguably the best choice. However, in this case, we also want to understand precisely which ones we are affecting<\/strong>. By using a different increment value each time, we can understand which instruction we are influencing and what happens.<\/p>\n To determine which instruction we are affecting, we add a number that is equivalent to a single bit representation. This will speed up certain types of analysis:<\/p>\n The result of the operations will be as follows:<\/p>\n As a safety measure, we also check with IDA Pro that the code generated by the compiler is what we intended it to be:<\/p>\n As we can see, probably due to some assembler optimizations, the code has been partially changed<\/strong>. In fact, the first instructions have been translated as “addi.n,” which are 16-bit instructions, instead of “addi,” which are 24-bit instructions. In terms of code functionality, the result remains unchanged, as the two instructions are equivalent.<\/p>\n By researching details in the “Xtensa Instruction Set Architecture (ISA) – Reference Manual,” we can find the following:<\/p>\n By modifying the assembly code as described at this point (replacing ADDI with _ADDI), we would get the “clean” code, which is also confirmed by the disassembling:<\/p>\n By conducting some tests, we found that approximately 12 instructions are executed in about 162ns. Considering that the compilation options set the frequency to 80Mhz and assuming that each instruction requires approximately 2 clock cycles, the timing looks reasonable:<\/p>\n Using a frequency of 160Mhz, we have approximately 62 nanoseconds for the execution of 12 instructions:<\/p>\n For convenience, let’s start working at 80Mhz to be more precise.<\/p>\n To have a completely controlled environment, we need to perform the following steps:<\/p>\n By running the entire code, we can observe that execution takes around a total of 25,200 nanoseconds:<\/p>\n On the datasheet of the ESP32 processor, further details can be found on how the different VDD pins that provide power to the chip are used:<\/p>\n For this initial analysis, I decided to keep all VDD pins connected together<\/strong>, removing the capacitors connected to the VDD3P3_RTC and VDD3P3_CPU power lines.<\/p>\n The hardware on which the tests were performed has the following configuration, and the circled capacitors have been removed:<\/p>\n Source: https:\/\/github.com\/raelize\/TAoFI-Target\/blob\/main\/files\/schematic.png<\/a><\/p>\n Now that we have a “clean” environment just the way I like it, let’s look at the main features of the glitching script<\/strong>.<\/p>\n For convenience, we use the setup provided during the course, which includes:<\/p>\n After some initial tests, I have determined that the probable values for obtaining a good sample are as follows:<\/p>\n To begin, we will use a “standard” configuration of the Husky:<\/p>\n In the following articles of this series<\/a>, we will also explore how we can make the most of the Husky.<\/p>\n However, the most important part is the initial classification<\/strong> that is performed before saving the result.<\/p>\n As we described earlier, we know that all the results should be “identical” because we use CPU exceptions that are all handled in the same way, whether our glitch is too long, causing an illegal instruction, or our glitch is too short and therefore does not affect code execution.<\/p>\n A specific routine is responsible for analyzing the result, comparing it with the expected result, and saving only the values that are “different” from the standard ones, in order to have a cleaner output during subsequent analysis.<\/strong><\/p>\n With the “Glitch and pray” approach, we can start to see the first results and try to understand how to interpret them better. We have two varying values: the distance of the glitch from the trigger (delay) and the length of the performed glitch (length).<\/p>\n Some important assumptions<\/strong>:<\/p>\n All the results have been classified<\/strong> in this way:<\/p>\n After 36K attempts, here are the first results:<\/p>\n The ones of interest to us are the red dots, where we have the correct PC but A6 doesn’t have the value we expected.<\/p>\n By cleaning up the results a little bit, we can see how the areas are quite concentrated:<\/p>\n We can find in blue some points of particular interest to us. For example, the “illegal instruction” in the first add operation. We can associate this behavior with “we have zeroed too many bits” of a specific instruction.<\/p>\n Searching for results Looking for Looking for Looking for Looking for Looking for Looking for Executing some custom query on the data we can also find where we “skipped the instruction” (we will see later that this is not actually the case) by looking for the expected value in A6.<\/p>\n Looking for Looking for Looking for Looking for Looking for Looking for Looking for As we could see from the initial results, we can consider performing a very precise targeting of an instruction based on the time from the trigger.<\/strong><\/p>\n However, the same results tell us that some instructions are more “simple” to target than others. I hypothesize that this is also due to the pipeline and internal caches of the processor.<\/strong><\/p>\n One of the fundamental things taught in the course by @pulsoid<\/a> and @tieknimmers<\/a> is to debunk the myth of “an instruction was skipped”. Many who talk about glitching and fault injection wrongly use this term just to say “I didn’t understand what happened”.<\/p>\n To understand the results we are going to analyze, we need to hypothesize what will happen at the processor level. Since we are using the “crowbar to ground” technique, it is plausible to assume that during certain CPU operations<\/strong> (such as loading instructions, execution, memory copies, etc.), some bits which are 1 may turn into 0<\/strong>. Other techniques could yield different results, but this is the most likely effect in our situation.<\/p>\n To do this, I have developed a small script that, given a specific opcode, sets N bits to 0 and observes what the “corrupted” instruction would be. In an ideal world, fault injection could change a single bit, but currently we do not know if we can be that precise. Therefore, we must assume that we will change N different bits.<\/p>\n The script generates N different possibilities by assuming influence on N different bits. The bits that have changed from 1 to 0 are marked in red, while the bits that are among the selected N bits but have not changed because they were already set to 0 are marked in green. All possible variations that do not alter the instruction are ignored.<\/p>\n Let’s see, for example, what can happen to the instruction Red bits are the ones changed<\/strong>, green bits are the ones that should been changed but already were set to 0<\/strong>.<\/p>\n The bit representation is consistent with that shown in the datasheet:<\/p>\n Alternatively, a “reduced” version that does not include duplicate cases:<\/p>\n The code can be viewed at https:\/\/github.com\/inode-\/fault_injection\/blob\/main\/OpcodeCalculator\/opcode_calculator.py<\/a><\/p>\n Now let’s try to understand what actually happens at the processor level, assuming that “the instruction was skipped” is not a valid answer<\/strong>.<\/p>\n We start with the simplest cases and move towards the more complex and less “explainable” ones.<\/p>\n The results from a normal execution are as follows:<\/p>\n During the next steps, it is necessary to remember what the states of the registers are in a “normal” situation.<\/p>\n Some typical examples are analyzed below. We have arbitrarily decided to consider that the maximum number of bits changed is 6, but the value could also be higher.<\/em><\/p>\n Difference between the normal registers:<\/p>\n Which means:<\/p>\n That will produce:<\/p>\n Difference between the normal registers:<\/p>\n Which meanss:<\/p>\n That will produce:<\/p>\n Which means:<\/p>\n That will produce:<\/p>\n Which means:<\/p>\n That will produce:<\/p>\n Which means:<\/p>\n That will produce:<\/p>\n Which means:<\/p>\n That will produce:<\/p>\n Which means:<\/p>\n That will produce:<\/p>\n Comparing the possible instructions on which we have made a fault is possible in simple cases. However, in more complex scenarios it becomes difficult to manually explain the cases. For this reason, I have decided to also take another path, to emulate the execution of the fault in a virtual environment and subsequently compare the result. My first choice would have been to use Unicorn Engine<\/a>, but unfortunately it does not currently support the XTENSA CPU.<\/p>\n Another feasible approach could have been to use the JTAG port combined with GDB to modify the instructions and the context, to execute the instructions step by step and see what had changed. Technically feasible but probably too slow to perform as many emulations as we need.<\/p>\n We then decided to try the emulation feature of Ghidra, which is poorly documented but should be supported for all CPUs. In fact, unlike for example IDA Pro, practically all processors come with what is defined as “P-Code”, that is, what a certain assembler operation performs. The P-Code abstraction is also what allows Ghidra to perform decompilation on almost all supported processors.<\/p>\n Some examples of using Ghidra for instruction emulation that I’ve used as a starting point:<\/p>\n Reusing part of the Python code presented earlier, I decided to export the possible instructions that could be executed and import them directly into the code of our plugin.<\/p>\n At this point, as a first step, we must modify the binary to reflect the instructions we want to emulate:<\/p>\n Then we set the context exactly as what is expected by the CPU:<\/p>\n Afterwards, we execute the instructions of interest:<\/p>\n At this point, we compare the results and save only those that are different from what we expect:<\/p>\n Full code available at https:\/\/github.com\/inode-\/fault_injection\/blob\/main\/GhidraEmulation\/xtensa_emulator.java<\/a><\/p>\n One of the main pros of this approach is the possibility of having an emulator up and running in a very short time, even though Ghidra’s APIs are poorly documented. However, there are also a number of cons:<\/p>\n One thing we can state with certainty is that instructions are not “skipped”…<\/strong><\/p>\n Sometimes it is not easy to explain what happens in the context of fault injection, but it is possible to try to understand what happened if there is a clear context<\/strong>. Of course, we cannot be certain, but we can come to have a good degree of confidence<\/strong> in understanding what happened in some cases. In the next articles in this series<\/a>, I will try to find other ways to interpret the results.<\/p>\n Another important finding is that somehow it is possible to affect multiple instructions<\/strong>, and the modified bits don’t have to be contiguous.<\/p>\n Certainly, this article does not intend to be exhaustive, and I know there are many opportunities for improvement. For example, in the context we are working on, the floating-point registers are not printed, but as a start, I would dare to say that it is more than enough.<\/p>\n Once again, I’d like to thank @tieknimmers<\/a> and @pulsoid<\/a> for their invaluable support during the writing of this article and for putting up with my endless questions and queries.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Intro This series of articles describes fault injection attack techniques in order to understand their real potential by testing their […]<\/p>\n","protected":false},"author":7,"featured_media":159901,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[91],"tags":[149,217,73,77,87,147],"class_list":["post-4682","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles","tag-iot","tag-fault-injection","tag-research","tag-exploit","tag-reverse-engineering","tag-hardware"],"acf":[],"yoast_head":"\n\n
\n
\n
\n
Let’s start<\/h3>\n
\n
\n
Preparation of the test environment<\/h3>\n
Using as few instructions as possible<\/h4>\n
GPIO_OUTPUT_SET(26,1);\r\n<\/pre>\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231122184428-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231121225520-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231121225803-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231121225741-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231121225917-2-1.png\")
<\/p>\n\/\/ GPIO 26 PING HIGH using GPIO_OUT_W1TS\r\n\"movi a11, 0x4000000;\"\r\n\"movi a12, 0x3ff44008;\"\r\n\"s32i.n a11, a12, 0;\"\r\n\r\n\/\/ GPIO 26 PIN LOW using GPIO_OUT_W1TC\r\n\"movi a12, 0x3ff4400C;\"\r\n\"movi a11, 0x4000000;\"\r\n\"s32i.n a11, a12, 0;\"\r\n<\/pre>\n
Having a clear understanding of the context<\/h4>\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819215208-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231122105303-2-1.png\")
<\/p>\n\n
\"movi a13, 0x93939393;\"\r\n\"s32i.n a2, a13, 0;\"\r\n<\/pre>\n
Instructions to attack<\/h4>\n
\"addi a6, a6, 0x1;\"\r\n\"addi a6, a6, 0x2;\"\r\n\"addi a6, a6, 0x4;\"\r\n\"addi a6, a6, 0x8;\"\r\n\"addi a6, a6, 0x10\"\r\n\"addi a6, a6, 0x20\"\r\n\"addi a6, a6, 0x40;\"\r\n<\/pre>\n
\"addi a6, a6, 0x1;\" -> a6 = 0x01 (0b00000001)\r\n\"addi a6, a6, 0x2;\" -> a6 = 0x03 (0b00000011)\r\n\"addi a6, a6, 0x4;\" -> a6 = 0x07 (0b00000111)\r\n\"addi a6, a6, 0x8;\" -> a6 = 0x0F (0b00001111)\r\n\"addi a6, a6, 0x10\" -> a6 = 0x1F (0b00011111)\r\n\"addi a6, a6, 0x20\" -> a6 = 0x3F (0b00111111)\r\n\"addi a6, a6, 0x40;\" -> a6 = 0x7F (0b01111111)\r\n<\/pre>\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231201124427-2-1.png\")
<\/p>\nAssembler Note\r\nThe assembler may convert ADDI instructions to ADDI.N when the Code Density\r\nOption is enabled and the immediate operand falls within the available range. If the immediate\r\nis too large the assembler may substitute an equivalent sequence. Prefixing the\r\nADDI instruction with an underscore (_ADDI) disables these optimizations and forces\r\nthe assembler to generate the wide form of the instruction or an error instead.\r\n<\/pre>\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231215224519-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240809153534-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20231201130259-2-1.png\")
<\/p>\nPutting everything together<\/h4>\n
\n
\/\/ a0 is return address, but not used anymore\r\n\"movi a0, 0x40404040;\"\r\n\r\n\/\/ a1 is the stack pointer (it's not a typo, I decided to exclude the a1 to have clean info into the stacktraces)\r\n\/\/ \"movi a0, 0x41414141;\"\r\n\r\n\"movi a2, 0x42424242;\"\r\n\"movi a3, 0x43434343;\"\r\n\"movi a4, 0x44444444;\"\r\n\"movi a5, 0x45454545;\"\r\n\"movi a6, 0x46464646;\"\r\n\"movi a7, 0x47474747;\"\r\n\"movi a8, 0x48484848;\"\r\n\"movi a9, 0x49494949;\"\r\n\"movi a10, 0x50505050;\"\r\n\"movi a11, 0x51515151;\"\r\n\"movi a12, 0x52525252;\"\r\n\"movi a13, 0x93939393;\"\r\n\"movi a14, 0x54545454;\"\r\n\"movi a15, 0x55555555;\"\r\n<\/pre>\n
\n
\/\/ GPIO 26 PING HIGH using GPIO_OUT_W1TS\r\n\"movi a11, 0x4000000;\"\r\n\r\n\"movi a12, 0x3ff44024;\"\r\n\"s32i.n a11, a12, 0;\"\r\n\r\n\"movi a12, 0x3ff44008;\"\r\n\"s32i.n a11, a12, 0;\"\r\n<\/pre>\n
\n
\/\/ Set correctly used registers\r\n\"movi a11, 0x51515151;\"\r\n\"movi a12, 0x52525252;\"\r\n<\/pre>\n
\n
\/\/ Execute NOP instructions\r\n\"nop;\"\r\n<\/pre>\n
\n
\"addi a6, a6, 0x1;\"\r\n\"addi a6, a6, 0x2;\"\r\n\"addi a6, a6, 0x4;\"\r\n\"addi a6, a6, 0x8;\"\r\n\"addi a6, a6, 0x10;\"\r\n\"addi a6, a6, 0x20;\"\r\n\"addi a6, a6, 0x40;\"\r\n<\/pre>\n
\n
\/\/ Execute NOP instructions\r\n\"nop;\"\r\n<\/pre>\n
\n
\/\/ GPIO 26 PIN LOW using GPIO_OUT_W1TC\r\n\"movi a12, 0x3ff4400C;\"\r\n\"movi a11, 0x4000000;\"\r\n\"s32i.n a11, a12, 0;\"\r\n<\/pre>\n
\n
\/\/ GENERATE CPU EXCEPTION\r\n\"s32i.n a2, a13, 0;\"\r\n<\/pre>\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240809153608-2-1.png\")
<\/p>\nGlitching<\/h3>\n
Hardware setup<\/h4>\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240809150151-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819213918-2-1.png\")
<\/p>\nGlitching preparation<\/h4>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240129230604-2-1.png\")
<\/p>\nmin_length = 400 \u00a0 \u00a0\r\nmax_length = 3000\r\nmin_delay = 4000\r\nmax_delay = 22000\r\n<\/pre>\n
cw_scope.clock.clkgen_src \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= 'system'\r\ncw_scope.clock.adc_mul \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = 1\r\ncw_scope.clock.clkgen_freq \u00a0 \u00a0 \u00a0 \u00a0 = 200e6\r\n\r\n# Glitching parameters\r\ncw_scope.io.glitch_hp \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= True\r\ncw_scope.io.glitch_lp \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0= False\u00a0 \u00a0 \r\n<\/pre>\n
A first interpretation of the results<\/h3>\n
\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128233433-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128233745-2-1.png\")
<\/p>\nIllegal.*PC: 0x400d70e4<\/code> we can identify parameters which lead us to corrupt our first target instruction which is at 0x400d70e4:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234155-2-1.png\")
<\/p>\nIllegal.*PC: 0x400d70e7<\/code> we can identify parameters which lead to corrupt the second instruction:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234241-2-1.png\")
<\/p>\nIllegal.*PC: 0x400d70ea<\/code> we can identify parameters which lead to corrupt the third instruction:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234302-2-1.png\")
<\/p>\nIllegal.*PC: 0x400d70ed<\/code> we can identify parameters which lead to corrupt the fourth instruction:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234322-2-1.png\")
<\/p>\nIllegal.*PC: 0x400d70f0<\/code> we can identify parameters which lead to corrupt the fourth instruction:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234353-2-1.png\")
<\/p>\nIllegal.*PC: 0x400d70f3<\/code> we can identify parameters which lead to corrupt the fifth instruction:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234407-2-1.png\")
<\/p>\nIllegal.*PC: 0x400d70f6<\/code> we can identify parameters which lead to corrupt the sixth instruction:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234434-2-1.png\")
<\/p>\nStore.* PC: 0x400d713b.*A6 : 0x0000007e<\/code> we can identify parameters which lead to corrupt the first instruction in a way that the additional operation has not been executed:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234752-2-1.png\")
<\/p>\nStore.* PC: 0x400d713b.*A6 : 0x0000007d<\/code> we can identify parameters which lead to corrupt the second instruction in a way that the additional operation has not been executed. In our initial test, no cases have been identified:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234818-2-1.png\")
<\/p>\nStore.* PC: 0x400d713b.*A6 : 0x0000007b<\/code> we can identify parameters which lead to corrupt the third instruction in a way that the additional operation has not been executed:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234841-2-1.png\")
<\/p>\nStore.* PC: 0x400d713b.*A6 : 0x00000077<\/code> we can identify parameters which lead to corrupt the forth instruction in a way that the additional operation has not been executed:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234858-2-1.png\")
<\/p>\nStore.* PC: 0x400d713b.*A6 : 0x0000006f<\/code> we can identify parameters which lead to corrupt the fifth instruction in a way that the additional operation has not been executed:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234918-2-1.png\")
<\/p>\nStore.* PC: 0x400d713b.*A6 : 0x0000005f<\/code> we can identify parameters which lead to corrupt the sixth instruction in a way that the additional operation has not been executed:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128234941-2-1.png\")
<\/p>\nStore.* PC: 0x400d713b.*A6 : 0x0000003f<\/code> we can identify parameters which lead to corrupt the seventh instruction in a way that the additional operation has not been executed:<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240128235000-2-1.png\")
<\/p>\nA script to better understand the cause<\/h3>\n
addi a6, a6, 0x1;<\/code> in different scenarios assuming a variation from 1 to 4 bits.<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240121152043-1-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819215945-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819222851-2-1.png\")
<\/p>\nA better interpretation of the results<\/h3>\n
\"addi a6, a6, 0x1;\" -> a6 = 0x01 \r\n\"addi a6, a6, 0x2;\" -> a6 = 0x03 \r\n\"addi a6, a6, 0x4;\" -> a6 = 0x07 \r\n\"addi a6, a6, 0x8;\" -> a6 = 0x0F \r\n\"addi a6, a6, 0x10\" -> a6 = 0x1F \r\n\"addi a4, a6, 0x20\" -> a6 = 0x3F\r\n\"addi a6, a6, 0x40;\" -> a6 = 0x7F\r\n<\/pre>\n
Core 0 register dump:\r\nPC : 0x400d713b PS : 0x00060430 A0 : 0x40404040 A1 : 0x3ffb4810 \r\nA2 : 0x42424242 A3 : 0x43434343 A4 : 0x44444444 A5 : 0x45454545 \r\nA6 : 0x0000007f A7 : 0x47474747 A8 : 0x48484848 A9 : 0x49494949 \r\nA10 : 0x50505050 A11 : 0x04000000 A12 : 0x3ff4400c A13 : 0x93939393 \r\nA14 : 0x54545454 A15 : 0x55555555 SAR : 0x00000004 EXCCAUSE: 0x0000001d \r\nEXCVADDR: 0x93939393 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xffffffff \r\n<\/pre>\n
Level 1 (simple)<\/h4>\n
StoreProhibited - PC: 0x400d713b - A6 : 0x00000077(0x0000007f) - \r\n<\/pre>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819223606-2-1.png\")
<\/p>\n\"addi a6, a6, 0x1;\" -> a6 = 0x01 \r\n\"addi a6, a6, 0x2;\" -> a6 = 0x03 \r\n\"addi a6, a6, 0x4;\" -> a6 = 0x07 \r\n\"addi a6, a6, 0x0;\" -> a6 = 0x07 | GLITCHED\r\n\"addi a6, a6, 0x10\" -> a6 = 0x17 \r\n\"addi a6, a6, 0x20\" -> a6 = 0x37\r\n\"addi a6, a6, 0x40;\" -> a6 = 0x77\r\n<\/pre>\n
Level 2 (simple)<\/h4>\n
StoreProhibited - PC: 0x400d713b - A4 : 0x0000003f(0x44444444) - A6 : 0x0000005f(0x0000007f) - \r\n<\/pre>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819223825-2-1.png\")
<\/p>\n\"addi a6, a6, 0x1;\" -> a6 = 0x01 \r\n\"addi a6, a6, 0x2;\" -> a6 = 0x03 \r\n\"addi a6, a6, 0x4;\" -> a6 = 0x07 \r\n\"addi a6, a6, 0x8;\" -> a6 = 0x0F \r\n\"addi a6, a6, 0x10\" -> a6 = 0x1F \r\n\"addi a4, a6, 0x20\" -> a6 = 0x1F, a4 = 0x3F | GLITCHED\r\n\"addi a6, a6, 0x40;\" -> a6 = 0x5F, a4 = 0x3F\r\n<\/pre>\n
Level 3 (simple)<\/h4>\n
StoreProhibited - PC: 0x400d713b - A2 : 0x40404041(0x42424242) - A6 : 0x0000007e(0x0000007f) - \r\n<\/pre>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819223946-2-1.png\")
<\/p>\n\"addi a6, a6, 0x1;\" -> a6 = 0x00, a2 = 0x40404041 | GLITCHED\r\n\"addi a6, a6, 0x2;\" -> a6 = 0x02, a2 = 0x40404041\r\n\"addi a4, a6, 0x4;\" -> a6 = 0x06, a2 = 0x40404041\r\n\"addi a6, a6, 0x8;\" -> a6 = 0x0E, a2 = 0x40404041\r\n\"addi a6, a6, 0x10\" -> a6 = 0x1E, a2 = 0x40404041\r\n\"addi a6, a6, 0x20\" -> a6 = 0x3E, a2 = 0x40404041\r\n\"addi a6, a6, 0x40;\" -> a6 = 0x7E, a2 = 0x40404041\r\n<\/pre>\n
Level 4 (simple)<\/h4>\n
StoreProhibited - PC: 0x400d713b - A4 : 0x00000007(0x44444444) - A6 : 0x0000007b(0x0000007f) - \r\n<\/pre>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819224040-2-1.png\")
<\/p>\n\"addi a6, a6, 0x1;\" -> a6 = 0x01 \r\n\"addi a6, a6, 0x2;\" -> a6 = 0x03 \r\n\"addi a4, a6, 0x4;\" -> a6 = 0x03, a4 = 0x7 | GLITCHED\r\n\"addi a6, a6, 0x8;\" -> a6 = 0x0B, a4 = 0x7 \r\n\"addi a6, a6, 0x10\" -> a6 = 0x1B, a4 = 0x7 \r\n\"addi a6, a6, 0x20\" -> a6 = 0x3B, a4 = 0x7 \r\n\"addi a6, a6, 0x40;\" -> a6 = 0x7B, a4 = 0x7 \r\n<\/pre>\n
Level 5 (medium)<\/h4>\n
StoreProhibited - PC: 0x400d713b - A0 : 0x0000001f(0x40404040) - A4 : 0x0000002f(0x44444444) - A6 : 0x0000004f(0x0000007f) - \r\n<\/pre>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819224413-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819224620-2-1.png\")
<\/p>\n\"addi a6, a6, 0x1;\" -> a6 = 0x01 \r\n\"addi a6, a6, 0x2;\" -> a6 = 0x03 \r\n\"addi a6, a6, 0x4;\" -> a6 = 0x07 \r\n\"addi a6, a6, 0x8;\" -> a6 = 0x0F \r\n\"addi a0, a6, 0x10\" -> a6 = 0x0F, a0 = 0x1F | GLITCHED\r\n\"addi a4, a6, 0x20\" -> a6 = 0x0F, a0 = 0x1F, a4 = 0x2F | GLITCHED\r\n\"addi a6, a6, 0x40;\" -> a6 = 0x7F\r\n<\/pre>\n
Level 6 (medium)<\/h4>\n
StoreProhibited - PC: 0x400d713b - A4 : 0x00000005(0x44444444) - A6 : 0x00000079(0x0000007f) - \r\n<\/pre>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819224835-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819224922-2-1.png\")
<\/p>\n\"addi a6, a6, 0x1;\" -> a6 = 0x01 \r\n\"addi a6, a6, 0x0;\" -> a6 = 0x01 | GLITCHED\r\n\"addi a4, a6, 0x4;\" -> a6 = 0x01, a4 = 0x5 | GLITCHED\r\n\"addi a6, a6, 0x8;\" -> a6 = 0x09, a4 = 0x5 \r\n\"addi a6, a6, 0x10\" -> a6 = 0x19, a4 = 0x5 \r\n\"addi a4, a6, 0x20\" -> a6 = 0x39, a4 = 0x5\r\n\"addi a6, a6, 0x40;\" -> a6 = 0x79, a4 = 0x5\r\n<\/pre>\n
Level 7 (medium)<\/h4>\n
StoreProhibited - PC: 0x400d713b - A6 : 0x42424262(0x0000007f) - \r\n<\/pre>\n
\n
![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819225348-2-1.png\")
<\/p>\n![\"Pasted](\"https:\/\/hnsecurity.it\/wp-content\/uploads\/2024\/11\/Pasted-image-20240819225320-2-1.png\")
<\/p>\n\"addi a6, a6, 0x1;\" -> a6 = 0x01 \r\n\"addi a6, a6, 0x2;\" -> a6 = 0x03 \r\n\"addi a6, a6, 0x4;\" -> a6 = 0x07 \r\n\"addi a6, a6, 0x8;\" -> a6 = 0x0F \r\n\"addi a6, a6, 0x10\" -> a6 = 0x1F \r\n\"addi a6, a2, 0x20\" -> a6 = 0x42424262 | GLITCHED\r\n\"addi a6, a6, 0x00\" -> a6 = 0x42424262 | GLITCHED\r\n<\/pre>\n
Interpretation of the results – another approach<\/h3>\n
Ghidra CPU emulation<\/h4>\n
\n
void patch_code(long newcode[]) throws CancelledException, MemoryAccessException\r\n{\r\n\tAddress current_instruction = currentProgram.getAddressFactory().getDefaultAddressSpace().getAddress(init_addr);\r\n\r\n\tfor(int i = 0; i < newcode.length; i++) \r\n\t{\r\n\t\tclearListing(current_instruction);\r\n\r\n\t\tthis.setBytes(current_instruction, longToBytes_24bits(newcode[i]));\t\t\r\n\t\tcurrent_instruction = current_instruction.add(3);\t\t\r\n\t}\r\n\t\r\n\tdisassemble(currentProgram.getAddressFactory().getDefaultAddressSpace().getAddress(init_addr));\t\t\r\n\treturn;\r\n\r\n}\r\n<\/pre>\nemuHelper.writeRegister(\"a0\", 0x40404040);\r\nemuHelper.writeRegister(\"a1\", 0x41414141);\r\nemuHelper.writeRegister(\"a2\", 0x42424242);\r\nemuHelper.writeRegister(\"a3\", 0x43434343);\r\nemuHelper.writeRegister(\"a4\", 0x44444444);\r\nemuHelper.writeRegister(\"a5\", 0x45454545);\r\nemuHelper.writeRegister(\"a6\", 0x46464646);\r\nemuHelper.writeRegister(\"a7\", 0x47474747);\r\nemuHelper.writeRegister(\"a8\", 0x48484848);\r\nemuHelper.writeRegister(\"a9\", 0x49494949);\r\nemuHelper.writeRegister(\"a10\", 0x50505050);\r\nemuHelper.writeRegister(\"a11\", 0x51515151);\r\nemuHelper.writeRegister(\"a12\", 0x52525252);\r\nemuHelper.writeRegister(\"a13\", 0x93939393);\r\nemuHelper.writeRegister(\"a14\", 0x54545454);\r\nemuHelper.writeRegister(\"a15\", 0x55555555);\r\n\r\nemuHelper.writeRegister(\"a6\", 0x0);\r\n<\/pre>\n
\temuHelper.writeRegister(emuHelper.getPCRegister(), initial_instruction);\r\n\t\r\n\tint j = 0;\r\n\t\r\n\tfor(int i = 0; i<=array_size; i++)\r\n\t{\r\n\t\tAddress executionAddress = emuHelper.getExecutionAddress();\r\n\t\t\r\n\t\toutfile.write(executionAddress.toString() + ' ' + getInstructionAt(executionAddress) + \"\\n\");\r\n\t\t\r\n\t\ttry {\r\n\t\t\tboolean success = emuHelper.step(monitor);\r\n\t\t\t\r\n\t\t\tj++;\r\n\t\t\tif( success == false) {\r\n\t\t\t\tString lastError = emuHelper.getLastError();\r\n\t\t\t\toutfile.write(lastError + \" - \" + getInstructionAt(executionAddress) + \"\\n\");\r\n\t\t\t\toutfile.write(HexFormat.of().formatHex(getBytes(executionAddress, 3)));\r\n\t\t\t\treturn -1;\r\n\t\t\t}\r\n\t\t} catch (Exception e) {\r\n\t\t\tprintln(e.toString());\r\n\t\t\treturn -1;\r\n\t\t\t\r\n\t\t}\r\n\t\t\r\n\t}\r\n<\/pre>\n\t\tif(emuHelper.readRegister(\"a0\").longValue() != 0x40404040 )\r\n\t\t\toutfile.write(\"A0 : 0x\" + String.format(\"%08x\", emuHelper.readRegister(\"a0\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a1\").longValue() != 0x41414141 )\r\n\t\t\toutfile.write(\"A1 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a1\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a2\").longValue() != 0x42424242 )\r\n\t\t\toutfile.write(\"A2 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a2\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a3\").longValue() != 0x43434343 )\r\n\t\t\toutfile.write(\"A3 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a3\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a4\").longValue() != 0x44444444 )\r\n\t\t\toutfile.write(\"A4 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a4\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a5\").longValue() != 0x45454545 )\r\n\t\t\toutfile.write(\"A5 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a5\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a6\").longValue() != 0x7f )\r\n\t\t\toutfile.write(\"A6 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a6\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a7\").longValue() != 0x47474747 )\r\n\t\t\toutfile.write(\"A7 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a7\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a8\").longValue() != 0x48484848 )\r\n\t\t\toutfile.write(\"A8 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a8\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a9\").longValue() != 0x49494949 )\r\n\t\t\toutfile.write(\"A9 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a9\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a10\").longValue() != 0x50505050 )\r\n\t\t\toutfile.write(\"A10 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a10\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a11\").longValue() != 0x51515151 )\r\n\t\t\toutfile.write(\"A11 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a11\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a12\").longValue() != 0x52525252 )\r\n\t\t\toutfile.write(\"A12 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a12\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a13\").longValue() != 0x93939393L )\r\n\t\t\toutfile.write(\"A13 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a13\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a14\").longValue() != 0x54545454 )\r\n\t\t\toutfile.write(\"A14 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a14\").longValue()) + \" \");\r\n\t\tif(emuHelper.readRegister(\"a15\").longValue() != 0x55555555 )\r\n\t\t\toutfile.write(\"A15 : 0x\" + String.format(\"%08x\",emuHelper.readRegister(\"a15\").longValue()) + \" \");\r\n\t\toutfile.write(HexFormat.of().formatHex(getBytes(currentProgram.getAddressFactory().getDefaultAddressSpace().getAddress(init_addr), 3*7)));\r\n\t\toutfile.write(\"\\n\");\r\n\t\t\r\n<\/pre>\n
Pros and cons<\/h4>\n
\n
Conclusions<\/h3>\n