In the previous article https://8ksec.io/dissecting-windows-malware-series-understanding-cryptography-and-data-encoding-part-3/, we saw an example of how understanding Data Encoding mechanisms can push us forward in:
Identifying the type of encoding the malware uses
What are the key functions we need to understand to perform the decoding stage accurately
How should we these pieces of information as pivot to understand the bigger picture
Now before heading on to Network Traffic Analysis, we’re going to talk about CPU architectures.
Table of Contents
What's In It For Me
We’ll see the differences between RISC and CISC CPU architectures, and examine how that knowledge might be useful to us as Malware Analysts.
RISC vs CISC
CISC processors, or Complex Instruction Set Computers, aim to perform an action (or a set of actions) with the minimal possible number of assembly code lines.
This is achieved by a processor capable of decoding and executing an ISA (Instruction Set Architecture) characterized by a wide variety of assembly commands.
The ISA is essentially a collection of assembly commands that define the processor’s architecture, featuring specific commands like jmp, mov, add, etc., which the processor “recognizes” and can translate into machine language for execution.
The ISA is also characterized by the registers it “recognizes,” though we won’t delve into that aspect here.
RISC processors, or Reduced Instruction Set Computers, aim to perform an action (or a set of actions) in a single clock cycle—often referred to in professional jargon as “One Clock Cycle.”
This goal is achieved by simplifying the ISA to a more limited set of commands that are designed to complete their tasks within a single clock cycle.
<img alt="" height="800" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/04/RISCvsCISC-img1.webp?fit=800%2C800&ssl=1" width="800" /> Image : RISC vs CISC
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>A Bit of History – The Tale of RISC and CISC</h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Chapter A – Grandpa CISC<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f474.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>In the late ’70s, when CISC processors were just beginning to be developed, memory (RAM) was a very expensive commodity.</p><p>Existing compilers were still in their infancy and didn’t perform as well as they do today, prompting people to write programs in Assembly code themselves.</p><p>Due to the high cost of memory, there was a necessity to find solutions for preserving it and using it in the most efficient way possible.</p><p>It was concluded that creating an ISA (Instruction Set Architecture) composed of CPU instructions with broad functionality could address this need.</p><p>This meant that a single command, represented by a single Assembly command, despite being complex for the processor to execute – could perform many tasks, allowing programmers to utilize it effectively.</p><p>However, this approach soon revealed several problems for a variety of reasons:</p><ol start=""><li><p>The processor uses a Decoder to decode the Assembly command. Due to the wide functionality of the commands, they varied significantly in terms of encoding/presentation in machine language, etc. Creating a Decoder capable of decoding every such Assembly command, or even several Decoders, was, to put it mildly, a significant headache.</p></li><li><p>The temporary solution for the Decoders, which also became the second issue with CISC processors, was to invent something called Microcode.</p></li></ol><p>Similar to how modern programs use subroutines or functions that can be called repeatedly, Microcode was employed in the same way.</p><p>For each command in the ISA, a small program was created and allocated a specific place in the CPU memory, composed of even smaller instructions called Microcode.</p><p>Thus, the CPU would have a small set of Microcode commands that could be expanded with more complex instructions simply by adding a small Microcode program inside the processor.</p><p>Over time, it was realized that the continuous addition of Microcodes began to become a significant headache just as well.</p><p>Fixing any bug in the Microcode was a serious challenge since it wasn’t easy to test the code as before.</p><p><strong>This led to the realization that perhaps there was another way to approach this problem.</strong></p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="800" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/cisc_question_mark.webp?fit=800%2C800&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Chapter B – RISC RISC RISC<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f60e.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Aside from the challenges encountered in implementing CISC processor architecture, a shift occurred due to several factors:</p><ol start=""><li><p>The significant reduction in the cost of RAM.</p></li><li><p>Advances in compiler technology.</p></li><li><p>A move by programmers towards programming in “higher-level” languages rather than assembly code.</p></li></ol><p>These developments facilitated the transition to using RISC processors.</p><p>It was recognized that in terms of performance, the same or even better results could be achieved using simpler commands instead of a few complex commands, where each command is highly complex.</p><p>Additionally, it was discovered that the frequency of using these complex commands in CISC processors was not as high as expected, and the cost outweighed the benefits.</p><p>This led to the conception of the RISC philosophy: Rather than employing a wide ISA composed of many complex instructions, the shift was towards a narrow ISA consisting of a few simple instructions. </p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>These simple instructions could be used to implement the functionality of the complex instructions as needed.</p><p>The focus shifted towards software optimization, leaving the resolution of Microcode-related issues and hardware adjustments to compiler developers.</p><p>This approach also underscored the concept of “Reduced” in RISC, emphasizing the reduction in instruction complexity.</p><p>The simplicity here pertains to the hardware implementation within the processor, which would use fewer resources and thus simplify the compiler’s task, rather than simplifying the programming process for developers.</p><p>Consider the following example that illustrates a code snippet written for MIPS processors (RISC) in Assembly:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="157" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/mips_hand_written_code.png?fit=454%2C157&ssl=1" width="454" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<ol start=""><li><p>Values are loaded from memory using load commands (<em>lw</em> = load word).</p></li><li><p>A multiplication operation is then performed between these values using the <em>mult</em> command, with the product’s value stored in the <em>lo</em> and <em>hi</em> registers (representing the lower 32 bits and the higher 32 bits of the product, respectively).</p></li></ol><ol start="3"><li><p>The value from the <em>lo</em> register is transferred to the <em>t1</em> register.</p></li></ol><p>Finally, the product’s value is stored back into memory using the store command (<em>sw</em> = store word).</p><p>In contrast, when performing a similar multiplication task in 8086 (CISC) Assembly, the operation is considerably more complex, involving memory access, computation, and storing the result in a target register—all within a single command. </p><p>This highlights the complexity inherent in CISC architectures compared to the simpler, more efficient approach favored by RISC architectures.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="39" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/assembly_86_hand_written.png?fit=679%2C39&ssl=1" width="679" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h4>Side Note:</h4> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>The operations in lines 17-18 (in the MIPS Assembly code) could potentially be optimized further.</p><p>However, the primary focus here is on the fundamental differences between the architectures.</p><p>This example illustrates the contrast in approach and underlying philosophy between CISC and RISC architectures, which will be explored further in the next paragraph.</p><div></div><p>The principle we aimed to illustrate is rooted in the differences between the architectures, which is represented in the diagram below:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="291" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/risc_vs_cisc_architecture.png?fit=574%2C291&ssl=1" width="574" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>These differences significantly influence how each architecture operates, reflecting the foundational philosophies or “schools” upon which they are based.</p><p>We will explore these distinctions in more detail in the following paragraph.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>So, What Are the Pain Points and Gains on Each Side<img alt="❓" src="https://s.w.org/images/core/emoji/15.0.3/72x72/2753.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>As mentioned earlier, the motivation behind inventing the RISC architecture stemmed from the simple realization that:</p><p>People, in reality, rarely write in Assembly anymore. So, why not develop a simpler architecture than CISC, one that the processor can translate and execute more easily?</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Therefore, RISC was designed primarily to optimize compilers rather than for direct human use.</p><p>Let’s briefly summarize the nuances between the two architectures:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<table><thead><tr><th>CISC Architecture</th><th>RISC Architecture</th></tr></thead><tbody><tr><td>The ISA includes commands that may span <strong>more than a single clock cycle</strong>.</td><td>All commands in the ISA are designed to be uniform and are guaranteed to <strong>complete within a single clock cycle</strong>.</td></tr><tr><td><strong>Hardware-Centric Design</strong> – Emphasis is placed on the ISA to maximize hardware utilization optimally. This approach is evident in hardware improvements, such as increasing the number of transistors for a more efficient implementation of instructions.</td><td><strong>Software-Centric Design</strong> – Responsibility lies with the programmer to ensure code efficiency and compiler performance, rather than focusing on hardware intricacies.</td></tr><tr><td><strong>Efficient Use of RAM Memory</strong> – Fewer commands need to be loaded into memory since each command is complex and offers extensive functionality.</td><td><strong>Less Efficient Use of RAM Memory</strong> – More commands must be loaded into memory because achieving certain functionalities requires more commands.</td></tr><tr><td>Supports <strong>Microcode</strong>: A single command can function as a small program. At the same time, many <strong>commands differ from each other</strong> in their representation, variable sizes, and command sizes.</td><td>A single layer of commands, each of the same <strong>fixed size</strong>.</td></tr><tr><td><strong>Memory-To-Memory</strong> Operations: Explained in the next paragraph.</td><td><strong>Register-To-Register</strong> Operations: Explained in the next paragraph.</td></tr><tr><td><strong>Diverse Addressing Modes</strong> – The system incorporates a variety of addressing modes.</td><td><strong>Single and Predefined Addressing Modes</strong> – The system employs straightforward and specific addressing modes.</td></tr></tbody></table> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>A Brief Explanation of Addressing Modes<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f520.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Addressing modes describe the various methods used to fetch data.</p><p>For instance:</p><ol start=""><li><p>Using a constant variable to represent the address from which fetching continues.</p></li><li><p>Employing relative addresses, such as the PC-Relative addressing mode found in MIPS processors, which operates in this manner.</p></li><li><p>Utilizing absolute addresses, for example, in MIPS processors, this approach is used to calculate jump addresses.</p></li><li><p>There are several other addressing modes as well.</p></li></ol> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Important Points That Have Received Less Attention So Far<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f51d.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>A central concept that emerged with the advent of RISC processors is pipelining.</p><p>We’ll use an industrial laundry to illustrate this principle:</p><p>Imagine a large industrial laundry where workers process incoming clothes. They face a huge pile of laundry needing washing, involving several steps:</p><ol start=""><li><p>Take a smaller pile from the large pile and place it into an available washing machine.</p></li><li><p>Once the washing cycle is complete, transfer the clean clothes to the dryer.</p></li><li><p>After drying, place the clean clothes on the folding table.</p></li><li><p>Fold the clothes at the table.</p></li><li><p>Sort the clothes according to customers in the organizing closet.</p></li></ol><p> </p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<a href="https://www.amazon.com/Computer-Organization-Design-MIPS-Architecture/dp/0124077269" rel="noreferrer" target="_blank">
<img alt="" height="595" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/pipeline.png?fit=800%2C595&ssl=1" width="800" /> </a>
Image Reference: <a href="https://www.amazon.com/Computer-Organization-Design-MIPS-Architecture/dp/0124077269" rel="noreferrer" target="_blank">https://www.amazon.com/Computer-Organization-Design-MIPS-Architecture/dp/0124077269</a>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Comparing this process to command execution: traditionally, one command would complete in full before the next began.</p><p>For instance, after the washing machine finished its half-hour cycle, only then would we start the next phase, moving the clothes to the dryer, and so forth.</p><p>This method, where the total execution time equals the sum of all individual stages, is highly inefficient.</p><p>However, if we ensure all stages take the same amount (or at least a similar amount) of time, we can leverage the pipelining principle.</p><p>What does this mean?</p><p>If every command takes the same time to execute, as soon as one batch of laundry finishes in the washing machine, it can be moved to the dryer, and a new batch can start washing.</p><p>This way, we don’t need to wait for one batch to complete all five stages before beginning with the next batch, optimizing the entire cleaning process.</p><p>This process is feasible because each stage (or in the context of processors, each command) takes the same time, preventing any “bottlenecks” where commands are delayed due to one taking significantly longer than others.</p><p>RISC architecture designers understood this principle well.</p><p>This explains the features we previously discussed: <strong>one clock cycle per command</strong> and <strong>uniform command sizes</strong> (32-bit) to ensure decoding occurs in roughly the same time frame for each command, among other features.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Load/Store Architecture versus Memory-To-Memory Architecture<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f559.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>RISC architecture, also known as Load-Store architecture, utilizes Load and Store commands to access the main memory (RAM) for reading and writing purposes.</p><p>To leverage the pipelining principle effectively, it’s crucial that all commands are executed within the same order of magnitude regarding execution time.</p><p>Therefore, in RISC architecture, loading and storing to the main memory are allocated a separate stage in the pipeline.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<a href="https://www.amazon.com/Computer-Organization-Design-MIPS-Architecture/dp/0124077269" rel="noreferrer" target="_blank">
<img alt="" height="571" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/store-load-image.png?fit=800%2C571&ssl=1" width="800" /> </a>
Image Reference: <a href="https://www.amazon.com/Computer-Organization-Design-MIPS-Architecture/dp/0124077269" rel="noreferrer" target="_blank">https://www.amazon.com/Computer-Organization-Design-MIPS-Architecture/dp/0124077269</a>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>These commands, due to accessing RAM and not working with values already in the registers, require more time. To maintain uniform command execution times, they are given their own stage in the pipeline.</p><p>In contrast, CISC processors allow certain commands to load data from main memory, perform operations like addition, subtraction, or multiplication, and directly write back to the memory, hence the term Memory-To-Memory or “memory crossing.”</p><p>While this may seem more efficient, such commands significantly extend the execution time within the pipeline compared to other commands.</p><p>The RISC approach, favoring splitting such tasks into multiple separate commands, ensures each command is executed in its stage, allowing subsequent commands to proceed without delay.</p><p>Moreover, the inclusion of compound commands—entailing memory reading, ALU operations, and memory writing—is contrary to RISC processors’ simplicity principle.</p><p>In RISC, all operations are performed on data within the registers—hence the name Register-To-Register. Loading from and storing back to main memory occur in distinct stages, as do ALU operations, with values first saved back in the register before being written to memory in a separate stage.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Multiple Registers<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f516.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Earlier, we discussed how RISC processors are perceived as less efficient in utilizing RAM, requiring more “simple commands” to perform actions that CISC processors might accomplish with far fewer commands.</p><p>Consequently, this necessitates loading more commands into the RAM.</p><p><strong>The solution offered by RISC architecture to this challenge is the increased use of registers.</strong></p><p>The innovators behind RISC architecture realized that most commands involve reading and writing data from memory to perform operations on this data.</p><p>So, why not allocate more registers for the CPU’s use?</p><p>By doing so, more information can be transferred from memory to registers, minimizing the need for memory access.</p><p>A point to contemplate on: If that’s the case, why not add a significantly large number of registers, especially considering RISC processors typically make do with only 31… </p><p>This approach necessitated thorough analysis to determine when information needs to be stored in a register, when it should be written back to memory, and other intricate details—largely demanding substantial advancements in compiler technology.</p><p>Herein lies a benefit of RISC processors: their addressing modes are considerably more restricted, simplifying these modifications.</p><p>This article will not delve into that topic.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>The Response of CISC Processors to the Advantages of RISC Processors<img alt="❗" src="https://s.w.org/images/core/emoji/15.0.3/72x72/2757.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>The developers behind CISC processors did not simply stand by idly in the face of RISC processors’ advancements.</p><p>They began to incorporate principles and characteristics of RISC processors into their designs.</p><p>Realizing the necessity to remain competitive, they sought ways to implement pipelining within their processors, a challenge given the architecture at the time.</p><p>Their solution was to make the inner workings of CISC processors as similar to RISC processors as possible.</p><p>This involved decoding commands in the CISC architecture and then breaking them down into simpler commands known as <em>micro-operations</em>.</p><p>Similar to commands in RISC processors, these micro-operations could then be processed in the pipeline due to their more predictable execution times and comparable durations.</p><p>While the topic of micro-operations is fascinating, we won’t delve into it further here, but feel free to explore more at the following link:</p><p><a href="https://erik-engheim.medium.com/what-the-heck-is-a-micro-operation-e991f76209e" rel="noreferrer" target="_blank">https://erik-engheim.medium.com/what-the-heck-is-a-micro-operation-e991f76209e</a>.”</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>The Emergence of RISC-V Processors<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f4c8.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>In a notable shift, we turn our attention to RISC-V processors.</p><p>You may or may not have encountered this buzzword, but it has been gaining traction in technology circles recently—and for good reason.</p><p>RISC-V processors are often heralded as the “Linux of CPUs.”</p><p>However, their open-source nature is not the only remarkable aspect.</p><p>Much like the open-source principle revolutionized software, we’re beginning to see its influence extend into other realms, including hardware.</p><p>Among the benefits of RISC-V processors:</p><ol start=""><li><p>Their Instruction Set Architecture (ISA) is non-incremental. What does this mean?</p><p> Traditional ISAs like x86, MIPS, and ARM accumulate additional commands over time, leading to bloated and complex ISAs.</p><p> For instance, the x86 ISA includes over 1500 different commands, many of which are rarely, if ever, used.</p><p> RISC-V opts for a modular approach based on extensions.</p><p> Unnecessary commands can be excluded, resulting in a streamlined set of instructions. This modularity affords several advantages:</p></li></ol><ul><li><p>RISC-V processors are simpler to implement, requiring a minimal ISA and fewer transistors.</p></li><li><p>This simplicity can contribute to higher clock frequencies, enhancing processor performance. While it’s somewhat simplistic to attribute performance solely to clock speed—since other factors play a role—it’s undeniably a significant factor.</p></li></ul><ol start="2"><li><p>A Unique Aspect of RISC-V Processors</p></li></ol><p>Interestingly, the RISC-V Foundation doesn’t manufacture RISC-V processors.</p><p>Instead, it produces a <em>specification</em> — a kind of ‘agreement’ among software developers, hardware developers, and others who adopt this specification.</p><p>This agreement ensures that RISC-V processors conform to the provided specifications.</p><p>What compels adherence to this “contract,” especially without legal enforcement or the threat of lawsuits? </p><p>The answer to that might be more nuanced than expected, inviting deeper contemplation.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="492" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/risc_v.png?fit=501%2C492&ssl=1" width="501" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>So Today, Aren't RISC and CISC the Same<img alt="❓" src="https://s.w.org/images/core/emoji/15.0.3/72x72/2753.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>With everything we’ve discussed, the distinction between CISC and RISC architectures seems to be blurring, doesn’t it?</p><p>CISC developers are beginning to incorporate micro-operations to facilitate pipeline processing, while some RISC developers are adopting technologies such as compressed instruction sets and hyper-threading, traditionally associated with CISC processors (these topics, due to their complexity deserve a separate article).</p><p>It appears that the differences, at least those perceptible to the casual observer, are gradually diminishing.</p><p>However, the fundamental essence that characterizes each architecture remains unchanged:</p><ul><li><p>RISC processors are defined by their use of fixed-size commands, in contrast to the variable-sized commands of CISC processors.</p></li><li><p>RISC based systems emphasize the standardization of commands and efficient pipeline utilization, whereas CISC based systems may employ supplementary techniques to address gaps in their custom pipelines.</p></li><li><p>The distinction is clear in the load/store approach of RISC processors, where memory access is executed through specific, dedicated commands, as opposed to the memory-to-memory approach of CISC processors, which allows actions like memory access, address or value computation, and memory write-back within a single command.</p></li><li><p>RISC favors the use of multiple registers to reduce memory access frequency, whereas CISC typically utilizes a more limited number of registers.</p></li></ul><p>In summary: While RISC architectures offload much of the computational heavy lifting to the compiler, enhancing performance, CISC architectures enable more complex operations, such as various memory access modes, offering solutions in many scenarios.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>So Where Are We Actually Going<img alt="❓" src="https://s.w.org/images/core/emoji/15.0.3/72x72/2753.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>It turns out that not all ISAs “are created equal in the image of God” and the ISA of a particular processor can significantly affect the way the CPU itself is designed – in terms of hardware.</p><p>The specific ISA chosen can simplify the design process of creating a high performance processor that consumes as few resources as possible.</p><p>That’s why in recent years Apple wants to create tailor made solutions for their computers/smartphones with specialized hardware capable of providing solutions in areas such as:</p><ul><li><p>Machine Learning</p></li><li><p>Encryption</p></li><li><p>Face Recognition</p></li><li><p>and much more</p></li></ul><p>While the guys at Intel with competing x86 processors are forced to do all this with an external chip – because of the CISC architecture they are based on. </p><p>Apple aims to do everything in a large integrated circuit or in other words – System on a Chip (SoC).</p><p>This shift in approach has long arrived to smartphones since due to their size, they do not have the privilege of another external chip (all components including: CPU, GPU, Memory, Specialized Hardware, and others) everything must be implemented in a single circuit and that’s why ARM is very dominant in the smartphone market (based mainly on RISC processors).</p><p>We are already seeing recently that laptops are starting to rely on <strong>Tight Integration</strong>, all implemented in a single Integrated Circuit – it provides a noticeable improvement in performance, and the next step is that even PC computers will be implemented this way.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="800" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/cpu_race.webp?fit=800%2C800&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>What Have We Talked About<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f4c3.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>We explored the distinctions and implementations, at a high-level overview, of RISC versus CISC architecture.</p><p>We delved into the history of CISC processors and the rationale behind the development of RISC processors.</p><p>With that being said, you sure have noticed that CISC processors still hold a significant market share, despite the advantages of RISC.</p><p>This situation involves intriguing dynamics related to x86 processors – if you’re looking for some intriguing insights, I recommend doing a bit of research.</p><p>We highlighted many benefits of RISC processors in comparison to CISC processors and touched upon several key concepts in architecture, including:</p><ol start=""><li><p>Pipelining</p></li><li><p>Load/Store architecture versus Memory-To-Memory</p></li><li><p>Multiple registers versus a limited number of registers</p></li></ol><p>We briefly discussed the emerging RISC-V architecture, which offers tailor-made chips, allowing you to select which instruction set extensions are included in your ISA – quite a revolutionary concept!</p><p>We also considered the current direction of technology in this dynamically evolving field, hinting that future shifts might lead us toward entirely different technologies and methodologies.</p><p>It’s crucial to acknowledge the topics we didn’t cover in depth, as they represent complex areas that are challenging to explore independently:</p><ol start=""><li><p>Although mentioned briefly, <strong>microcode versus micro-operations</strong> constitute an expansive subject that enthusiasts will find fascinating.</p></li><li><p>The latest <strong>optimization strategies</strong>, particularly those considering security aspects: Hyper-Threading versus Hardware-Threading.</p></li><li><p>We used an industrial laundry as an analogy for the pipeline, yet there are many more technical nuances fundamental to the operation of RISC processors and CPUs in general.</p><p>The <strong>pipeline</strong> is divided into five stages: Fetch, Decode, Execute, Memory, Write-Back.</p><p>There are also <strong>data hazards</strong> and control hazards stemming from the parallelism it facilitates – indeed, a whole other realm of discussion.</p><p>The concepts of <strong>latency</strong> and <strong>throughput</strong> – while not overly complex, these are important to understand.</p><p>The question of where cache memory fits into all of this wasn’t addressed, even though it plays a crucial role in various technologies and, by extension, processor architectures. </p><p>For those wishing to explore further, head to the References section for some resources.</p></li></ol> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>But How Is It Related To Malware Analysis<img alt="❓" src="https://s.w.org/images/core/emoji/15.0.3/72x72/2753.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Following the extensive architectural knowledge we learned in this crash course, you probably already see how it can benefit a Malware Analyst:</p><ol start=""><li><p><strong>Optimization Techniques</strong>:</p><p>Malware often uses various optimization techniques to run efficiently on target systems. RISC architectures, with their simpler and fewer instructions, tend to execute programs faster than CISC architectures in certain contexts. </p><p>Knowing the targeted architecture can help analysts understand the malware’s optimization strategies.</p></li><li><p><strong>Assembly Language Analysis</strong>:</p><p>Malware analysis involves examining the assembly code generated by the malware. Since CISC and RISC architectures have different instruction sets, the assembly code will look different.</p><p>Understanding these differences can help analysts more accurately disassemble and analyze the binary code of malware to understand its functionality and purpose.</p></li><li><p><strong>Payload Design</strong>:</p><p>Some malware payloads are designed specifically for the nuances of a particular architecture.</p><p>For example, a payload exploiting a specific vulnerability in a CISC-based system might not work on a RISC-based system. Knowing the architecture can help analysts determine the intended target of the malware and its potential impact.</p></li><li><p><strong>Obfuscation Techniques</strong>:</p><p>Malware authors often use obfuscation to hide the true intent of their code.</p><p>The complexity of CISC instruction sets can be exploited to create more complex obfuscations compared to RISC. </p><p>Understanding the architectural differences can aid in deobfuscating and understanding the malware’s true behavior.</p></li></ol><p>And those are just the top of the iceberg<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1fab2.png" style="height: 1em;" /></p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>References</h3><p>Well, the article has reached its conclusion.</p><p>The following resources have been a great aid in completing this work:</p><ol start=""><li><p>An insightful blog by Erik Engheim, excellently written and covering a broad range of topics related to processor architecture: “What Does RISC and CISC Mean in 2020?”</p><p><a href="https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020-7b4d42c9a9de" rel="noreferrer" target="_blank">https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020-7b4d42c9a9de</a></p></li><li><p>A concise and accurate webpage on the differences between RISC and CISC by Stanford University: “Stanford University – RISC vs CISC”</p><p><a href="https://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/" rel="noreferrer" target="_blank">https://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/</a></p></li><li><p>Additional informative articles that served as great inspiration:</p><p><a href="https://www.microcontrollertips.com/risc-vs-cisc-architectures-one-better/" rel="noreferrer" target="_blank">https://www.microcontrollertips.com/risc-vs-cisc-architectures-one-better/</a> <a href="https://www.baeldung.com/cs/risc-vs-cisc" rel="noreferrer" target="_blank">https://www.baeldung.com/cs/risc-vs-cisc</a></p></li><li><p>The book <em>Computer Organization and Design by David A. Patterson and John L. Hennessy</em>, which was invaluable for its theoretical insights and explanatory images (including those related to laundry and pipelining <img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f642.png" style="height: 1em;" /></p></li></ol> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>GET IN TOUCH</h3><p>Excited to learn more about Windows Malware Analysis? We just released our latest training on Windows Malware Analysis And Memory Forensics! You can find more information about it <a href="https://8ksec.io/windows-malware-analysis-and-memory-forensics/" rel="noreferrer" target="_blank">here</a>. Please don’t hesitate to reach out to us through our <a href="https://8ksec.io/contact-us/" rel="noreferrer" target="_blank">Contact Us page</a> if you have any questions.</p><p>Visit our <a href="https://8ksec.io/training/" rel="noreferrer" target="_blank">training page</a> if you’re interested in learning more about our other course offerings and want to develop your abilities further. Additionally, you may look through our <a href="https://8ksec.io/event-and-calendar/" rel="noreferrer" target="_blank">Events</a> page and sign up for our upcoming Public trainings.</p> </div>
</div>
</div>
</div>
</div><p>The post <a href="https://8ksec.io/dissecting-windows-malware-series-risc-vs-cisc-architectures-part-4/" rel="noreferrer" target="_blank">Dissecting Windows Malware Series – RISC vs CISC Architectures – Part 4</a> first appeared on <a href="https://8ksec.io" rel="noreferrer" target="_blank">8kSec</a>.</p>
Article Link: https://8ksec.io/dissecting-windows-malware-series-risc-vs-cisc-architectures-part-4/