Elvis Wiki - User contributions [en]

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T21:44:04Z

TNicholson:

= Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs =

== Introduction ==

The rapid increase in memory density over the last few decades has led to the discovery of the Rowhammer vulnerability in 2014 and the RowPress vulnerability in 2023. These vulnerabilities arise from insufficient electrical isolation between DRAM memory cells, potentially causing bit flip errors when DRAM rows are accessed in specific patterns.

While much research has focused on x86 architectures, this bachelor thesis explores the feasibility and impact of implementing Rowhammer attacks on ARM-based systems, specifically the AMD Zynq SoCs. The thesis examines the architecture, memory management, and caching policies of ARM systems to evaluate their resilience or susceptibility to Rowhammer. Although the Rowhammer attack is already well-documented and extensively researched, there is limited literature available on RowPress.

=== Research Objectives ===
The primary objective of this research is to evaluate the viability of Rowhammer and RowPress vulnerabilities on AMD Zynq SoCs. Key objectives include:
* Understanding the architectural differences between x86 and ARM in the context of DRAM vulnerabilities.
* Implementing Rowhammer on ARM-based SoCs and evaluating its effectiveness.
* Investigating the viability of RowPress on the Zynq SoC platform.
* Comparing the ARM-based findings with existing x86-based research.

=== DRAM Architecture ===
A typical DRAM module is hierarchically organized and consists of multiple banks, each containing rows and columns of memory cells. A memory cell is made up of a capacitor and a transistor. Each cell is at the intersection of two perpendicular wires, the horizontal wordline and the vertical bitline. The voltage in the wordlines can be used to read data from any given row. For example, when the voltage of a wordline for a specific row is raised, all access-transistors of the corresponding cells are activated, connecting the capacitors storing the bit to the vertical bitlines. This allows the cell charge representing the stored data to flow into the row buffer. The row buffer acts similar to a cache, accelerating repeated access to a given memory row. The image below visualizes the DRAM architecture.
[[File:dram_architecture.png]]

DRAM memory is accessed in the following steps:
# '''Translate physical address to memory location:''' This is done by the memory controller using translation functions.
# '''Activate/Open row:''' Increasing the voltage of the calculated row connects the capacitors to their connected bitlines, causing the binary data stored in the capacitors to move to the row buffer, of which each bank has one.
# '''Read or modify data:''' Once in the row buffer, the data can be read or modified as needed.
# '''Close row:''' By lowering the voltage of the wordline, the row is closed. Once the row buffer has been cleared, another row can be opened after the memory controller issues the PRECHARGE command.

DRAM cell capacitors lose their charge over time. For this reason, DRAM cell charge needs to be refreshed at regular intervals. This is done by reading row data to the buffer and writing the same data back to the row. The interval at which DRAM must be refreshed depends on several factors, including the specific standard of DRAM used and operating temperature. The most recent DRAM standards, DDR5 and LPDDR5, implement a refresh interval of 32 ms, while the previous standards, DDR3 and DDR4, had standard refresh intervals of 64 ms.

=== Rowhammer Attack ===
Rowhammer is a vulnerability that exploits the electrical interference between DRAM cells. By rapidly and repeatedly activating specific rows (aggressor rows), nearby rows (victim rows) encounter electrical interference, potentially causing bit flips.

For a conventional Rowhammer attack to succeed, three main requirements must be satisfied:
# '''Memory accesses must not be served by the cache:''' If repeated memory accesses required for Rowhammer are handled by either the CPU cache or the row buffer, the DRAM hardware is never reached, making it impossible to cause bit flips. This requirement can generally be satisfied by evicting data from the cache or not putting data into the cache in the first place.
# '''Memory access must be fast:''' Depending on the refresh rate of the used memory controller, there is a very limited timeframe during which bit flips can be caused before the charge of the DRAM cells is refreshed.
# '''Memory access must be highly targeted:''' Rowhammer usually relies on being able to access very specific DRAM rows located in close proximity to each other. Therefore, it is important to understand the memory mapping functions involved in translating physical addresses into the actual location on the memory module.

Rowhammer attacks can be classified into different patterns:
* '''Single-sided Rowhammer:''' Repeated access to one row adjacent to the target row.
* '''Double-sided Rowhammer:''' Accessing two rows on either side of the target row, increasing the likelihood of bit flips.

Double-sided Rowhammer is the most common variant.

Rowhammer has been widely studied on x86 systems, and advanced exploits have been developed.

=== RowPress Attack ===
RowPress is a more recent attack method discovered in 2023. Unlike Rowhammer, which relies on high-frequency row activations, RowPress induces bit flips by keeping a memory row open for extended periods (referred to as tAggON). The prolonged activation of an aggressor row can destabilize adjacent rows and cause data corruption. There is currently very little research on RowPress, and existing studies have only been done on highly specialized testing hardware.

=== ARM Architecture and Memory Access ===
ARM architectures, such as those used in the Zynq SoCs, differ from x86 in several key areas, particularly in memory access and cache management. ARM processors typically use a different set of instructions for cache maintenance, and direct memory access is handled differently. Furthermore, ARM-based systems often have more constrained memory controllers and may employ different policies for handling row activations, which affects the feasibility of attacks like Rowhammer and RowPress.

== Methodology ==

=== AMD Zynq SoC Overview ===
The AMD Zynq-7000 SoC is an embedded development platform with a dual-core ARM Cortex-A9 processor and programmable logic (FPGA). The specific model used in this thesis, the Digilent Zybo Z7-20, includes 1 GB of DDR3L DRAM.

[[File:zybo-z7.png|300px]]

=== Development Environment ===
The development environment used for this research consists of AMD’s Vivado for hardware design and Vitis for program development. The hardware design created using Vivado includes the Zynq Processing System (Zynq PS) and the default DRAM memory configuration. Altering the DRAM parameters would not have aided in the experiments. The program, written in C, controls the memory access patterns and performs the Rowhammer tests.

=== DRAM Address Mapping ===
Understanding the specific DRAM address mapping functions is important for successfully targeting specific rows in a Rowhammer or RowPress attack. The address mapping functions translate a physical address to the exact location of the associated data on the DRAM module. By analyzing the Technical Reference Manual and configuration files, the exact address bits used for row, bank, and column mapping were identified.

The following addressing information was obtained from the documentation:
* Bank: 3 address bits required to address the 8 banks, these bits are 12,13, and 14.
* Row: 15 address bits required to address the rows, 15-29.
* Column: 10 address bits required to address the columns, 2-11.

Based on this information, a function was implemented that receives bank, row, and column as int parameters, and returns a pointer to the address corresponding to the DRAM location. See the code snippet below:

<syntaxhighlight lang="C">
void* getAddress(int bank, int row, int column) {
bank &= 0x7;
row &= ((1 << (ROW_BITS - 1)) - 1) | (1 << (ROW_BITS - 1));
column &= 0x3FF;
uint32_t address = (bank << 12) | (row << ROW_START) | (column << COLUMN_START);
return ((uintptr_t)address >= (uintptr_t)(&__rowhammer_space_start) && (uintptr_t)address <= (uintptr_t)(&__rowhammer_space_end)) ? (void*)address : NULL;
}
</syntaxhighlight>

=== Cache Management ===
One of the primary challenges in implementing Rowhammer on ARM systems is ensuring that memory accesses bypass the CPU caches and directly reach DRAM. Unlike x86 systems, ARM does not have a universal instruction like `clflush` for cache flushing. In this study, cache flushing was achieved using the Xilinx SDK's cache maintenance functions, and in some of the experiments, the data cache was completely disabled to ensure uncached memory access during the attacks. In the below code, the aggressor rows are hammered, and the caches are flushed after each access. This low-level access to the cache management functions was very helpful, as it relieved the need for complex cache eviction strategies.

<syntaxhighlight lang="C">
void performRowhammer(void* neighborRow1, void* neighborRow2, int iterations) {
for (int i = 0; i < iterations; i++) {
readAddress(neighborRow1);
Xil_DCacheFlushLine(neighborRow1);
readAddress(neighborRow2);
Xil_DCacheFlushLine(neighborRow2);
}
}
</syntaxhighlight>

=== Test Setup for Rowhammer ===
The Rowhammer test on the Zynq-7000 was designed to simulate a double-sided hammering pattern. First, specific memory locations were initialized with a known data pattern. Then, the aggressor rows surrounding a target row were repeatedly accessed for a large number of iterations, while cache flushes ensured that accesses were handled by DRAM, not the CPU cache. After hammering, the target and adjacent rows were checked for bit flips by comparing their data to the original pattern.

The Rowhammer program contains the following steps:

# '''Iterate over and initialize memory columns:''' For each row of a bank, all columns are initialized with a 32-bit data pattern of alternating bit values.
# '''Flush and invalidate caches:''' The L1 and L2 caches are flushed, invalidated, and disabled to prevent the CPU cache from serving subsequent memory requests.
# '''Iterate over rows and calculate aggressor row addresses:''' A for-loop is used to iterate over the number of rows, with the current row being the victim row. As this is supposed to be a double-sided Rowhammer pattern, addresses to two neighboring aggressor rows are calculated.
# '''Repeatedly activate aggressor rows:''' The calculated addresses are accessed repeatedly for a specified number of iterations, thus essentially performing the Rowhammer attack.
# '''Check surrounding rows for bit flips:''' After a pair of aggressor rows has been hammered, the contents of the surrounding rows is checked for bit flips by comparing the actual value read from memory to the expected data pattern used for initialization.

Below is a pseudocode representation of the actual source code:

<syntaxhighlight lang="pseudo">
for each bank
for each row
for each column
address = calculate_address(bank, row, column)
if address is not NULL
initialize column = init_pattern
end if
end for
end for
disable_caches()
for each row
address1 = calculate_address(bank, row - 1, 0)
address2 = calculate_address(bank, row + 1, 0)
for rowhammer_iterations
activate row of address1
activate row at address2
end for
for each check_row from row - 2 to row + 2
for each column
check_address = get_address(bank, check_row, column)
if read from address does not equal init_pattern
print "Bit flip found"
end if
end for
end for
end for
end for
</syntaxhighlight>

=== Test Setup for RowPress ===
As discussed in the theory section, the RowPress mechanism is fundamentally different from Rowhammer. Instead of inducing data errors by rapidly activating aggressor rows, RowPress works by keeping a single row open for an extended period, leading to bit flips.

== Implementation Challenges ==
RowPress relies on specialized FPGA hardware, which poses challenges when implementing it on platforms like the Zynq-7000. The following issues arise when applying RowPress to such platforms:

* '''Aggressor Row-On Time (tAggON):''' RowPress requires a DRAM row to remain open for a longer time, disturbing nearby rows and causing bit flips.
* '''Memory Controller Behaviour:''' The memory controller is responsible for controlling how long a row stays open, which is more critical in RowPress compared to Rowhammer.
* '''Timing Constraints:''' Lower clock speeds make precise timing difficult, affecting the effectiveness of RowPress.
* '''Limited Control over Memory Controller Settings:''' The Zynq-7000 platform offers limited flexibility to adjust critical DRAM timing parameters, unlike more advanced FPGA hardware.

== RowPress on the Zynq-7000 Platform ==
While it is difficult to create an ideal RowPress testing environment on the Zynq-7000, specific access patterns may be used to prolong row-open times. For example, accessing a row and then switching to a different cache block within the same row may cause the memory controller to keep the row open longer.

Building on the existing Rowhammer code, addresses mapped to the same row can be generated. Memory requests to different cache blocks within the same row may prompt the memory controller to keep the row open for subsequent accesses. To verify this, the following steps can be taken:

# Flush all cache blocks of a DRAM row from the CPU caches using appropriate instructions.
# Access a different row so the memory controller closes the previous row.
# Measure the CPU cycles needed to access each cache block of the row being tested.

A noticeable latency difference between the first and subsequent accesses indicates that the row remains open longer, effectively increasing tAggON.

The success of this approach depends on the row buffer management policy used by the memory controller. The main policies include:

* '''Closed-Page Policy:''' Closes a DRAM row immediately after a read or write operation.
* '''Fixed Open-Page Policy:''' Keeps a row open for a fixed duration after an operation.
* '''Adaptive Open-Page Policy:''' Dynamically adjusts how long a row remains open based on the system's activity.

To increase row-open time, the memory controller must use an adaptive open-page policy. On the Zybo Z7-20, it is possible to verify that the controller follows this policy, as indicated by certain control bits in the configuration files.

Profiling the system to synchronize RowPress patterns with DRAM refresh cycles can help maintain longer row activation times. Similar to Rowhammer, understanding DRAM address translation is crucial to targeting specific memory locations.

== Results ==

=== Rowhammer Results ===
Despite implementing double-sided hammering and flushing the CPU caches, no bit flips were observed during the Rowhammer tests on the Zynq-7000 platform. The potential reasons are manifold, and they are outlined in the thesis.

=== RowPress Results ===
The RowPress implementation faced even more significant challenges. The limited configurability of the memory controller on the Zynq-7000 meant that row-open time could not be extended as needed for RowPress. Further testing with hardware that provides more control over memory timing is required to evaluate RowPress effectively.

== Conclusion ==
Rowhammer and RowPress are critical vulnerabilities in DRAM that have been primarily explored on x86 systems. This research aimed to implement these vulnerabilities on ARM-based systems using the AMD Zynq SoC platform. While the Rowhammer and RowPress implementations on the Zynq-7000 did not result in observable bit flips, the research highlights the difficulty of replicating these attacks on ARM architectures. The findings suggest that further research is needed, particularly with more flexible hardware setups that allow better control over memory access patterns and timing.

== Future Work ==
Future research should focus on testing Rowhammer and RowPress on a wider variety of ARM-based platforms and exploring more sophisticated methods for managing memory access and timing. Additionally, hardware that allows for finer control over memory controllers, such as FPGAs with more advanced DRAM interfaces, would be beneficial for testing these vulnerabilities.

== References ==

* H. Luo, A. Olgun et al., "RowPress: Amplifying Read Disturbance in Modern DRAM Chips," in ''Proceedings of the 50th Annual International Symposium on Computer Architecture (ISCA)'', 2023.
* Y. Kim, R. Daly et al., "Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors," in ''Proc. 41st Int. Symp. Comput. Archit. (ISCA)'', 2014, pp. 361–372, doi: 10.1109/ISCA.2014.6853210.
* D. Gruss and C. Maurice, "Rowhammer Attacks: A Walkthrough Guide," in ''Proc. RuhrSec 2017'', Graz University of Technology, 2017. [Online]. Available: https://www.tugraz.at. [Accessed: Sept. 16, 2024].
* Z. Zhang, Z. Zhan, D. Balasubramanian, X. Koutsoukos, and G. Karsai, "Triggering Rowhammer Hardware Faults on ARM: A Revisit," in ''Proceedings of the 2018 Workshop on Attacks and Solutions in Hardware Security (ASHES '18)'', Toronto, Canada, 2018, pp. 24-33. doi: 10.1145/3266444.3266454.

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T19:29:23Z

TNicholson:

= Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs =

== Introduction ==

The rapid increase in memory density over the last few decades has led to the discovery of the Rowhammer vulnerability in 2014 and the RowPress vulnerability in 2023. These vulnerabilities arise from insufficient electrical isolation between DRAM memory cells, potentially causing bit flip errors when DRAM rows are accessed in specific patterns.

While much research has focused on x86 architectures, this bachelor thesis explores the feasibility and impact of implementing Rowhammer attacks on ARM-based systems, specifically the AMD Zynq SoCs. The thesis examines the architecture, memory management, and caching policies of ARM systems to evaluate their resilience or susceptibility to Rowhammer. Although the Rowhammer attack is already well-documented and extensively researched, there is limited literature available on RowPress.

=== Research Objectives ===
The primary objective of this research is to evaluate the viability of Rowhammer and RowPress vulnerabilities on AMD Zynq SoCs. Key objectives include:
* Understanding the architectural differences between x86 and ARM in the context of DRAM vulnerabilities.
* Implementing Rowhammer on ARM-based SoCs and evaluating its effectiveness.
* Investigating the viability of RowPress on the Zynq SoC platform.
* Comparing the ARM-based findings with existing x86-based research.

=== DRAM Architecture ===
A typical DRAM module is hierarchically organized and consists of multiple banks, each containing rows and columns of memory cells. A memory cell is made up of a capacitor and a transistor. Each cell is at the intersection of two perpendicular wires, the horizontal wordline and the vertical bitline. The voltage in the wordlines can be used to read data from any given row. For example, when the voltage of a wordline for a specific row is raised, all access-transistors of the corresponding cells are activated, connecting the capacitors storing the bit to the vertical bitlines. This allows the cell charge representing the stored data to flow into the row buffer. The row buffer acts similar to a cache, accelerating repeated access to a given memory row. The image below visualizes the DRAM architecture.
[[File:dram_architecture.png]]
DRAM memory is accessed in the following steps:
# '''Translate physical address to memory location:''' This is done by the memory controller using translation functions.
# '''Activate/Open row:''' Increasing the voltage of the calculated row connects the capacitors to their connected bitlines, causing the binary data stored in the capacitors to move to the row buffer, of which each bank has one.
# '''Read or modify data:''' Once in the row buffer, the data can be read or modified as needed.
# '''Close row:''' By lowering the voltage of the wordline, the row is closed. Once the row buffer has been cleared, another row can be opened after the memory controller issues the PRECHARGE command.
DRAM cell capacitors lose their charge over time. For this reason, DRAM cell charge needs to be refreshed at regular intervals. This is done by reading row data to the buffer and writing the same data back to the row. The interval at which DRAM must be refresh depends on several factors, including the specific standard of DRAM used and operating temperature. The most recent DRAM standards, DDR5 and LPDDR5, implement a refresh interval of 32 ms, while the previous standards, DDR3 and DDR4, had standard refresh intervals of 64 ms.

=== Rowhammer Attack ===
Rowhammer is a vulnerability that exploits the electrical interference between DRAM cells. By rapidly and repeatedly activating specific rows (aggressor rows), nearby rows (victim rows) encounter electrical interference, potentially causing bit flips.
For a conventional Rowhammer attack to succeed, three main requirements must be satisfied:
#'''Memory accesses must not be served by the cache: ''' If repeated memory accesses required for Rowhammer are handled by either the CPU cache or the row buffer, the DRAM hardware is never reached, making it impossible to cause bit flips. This requirement can generally be satisfied by evicting data from the cache or not putting data into the cache in the first place
#'''Memory access must be fast: ''' Depending on the refresh rate of the used memory con troller, there is a very limited timeframe during which bit flips can be caused before the charge of the DRAM cells is refreshed
#'''Memory access must be highly targeted:''' Rowhammer usually relies on being able to access very specific DRAM rows located in close proximity to each other. Therefore, it is important to understand the memory mapping functions involved in translating physical addresses into the actual location on the memory module.
Rowhammer attacks can be classified into different patterns:
* '''Single-sided Rowhammer:''' Repeated access to one row adjacent to the target row.
* '''Double-sided Rowhammer:''' Accessing two rows on either side of the target row, increasing the likelihood of bit flips.

Double-sided Rowhammer is the most common variant.

Rowhammer has been widely studied on x86 systems, and advanced exploits have been developed.

=== RowPress Attack ===
RowPress is a more recent attack method discovered in 2023. Unlike Rowhammer, which relies on high-frequency row activations, RowPress induces bit flips by keeping a memory row open for extended periods (referred to as tAggON). The prolonged activation of an aggressor row can destabilize adjacent rows and cause data corruption. There is currently very little research on RowPress, and existing studies have only been done on highly specialized testing hardware.

=== ARM Architecture and Memory Access ===
ARM architectures, such as those used in the Zynq SoCs, differ from x86 in several key areas, particularly in memory access and cache management. ARM processors typically use a different set of instructions for cache maintenance, and direct memory access is handled differently. Furthermore, ARM-based systems often have more constrained memory controllers and may employ different policies for handling row activations, which affects the feasibility of attacks like Rowhammer and RowPress.

== Methodology ==

=== AMD Zynq SoC Overview ===
The AMD Zynq-7000 SoC is an embedded development platform with a dual-core ARM Cortex-A9 processor and programmable logic (FPGA). The specific model used in this thesis, the Digilent Zybo Z7-20, includes 1 GB of DDR3L DRAM.

[[File:zybo-z7.png|300px]]

=== Development Environment ===
The development environment used for this research consists of AMD’s Vivado for hardware design and Vitis for program development. The hardware design created using Vivado includes the Zynq Processing System (Zynq PS) and the default DRAM memory configuration. Altering the DRAM parameters would not have aided in the experiments. The program, written in C, controls the memory access patterns and performs the Rowhammer tests.

=== DRAM Address Mapping ===
Understanding the specific DRAM address mapping functions is important for successfully targeting specific rows in a Rowhammer or RowPress attack. The address mapping functions translate a physical address to the exact location of the associated data on the DRAM module. By analyzing the Technical Reference Manual and configuration files, the exact address bits used for row, bank, and column mapping were identified.
The following addressing information was obtained from the documentation:
Bank: 3 address bits required to address the 8 banks, these bits are 12,13 and 14
Row: 15 address bits required to address the rows, 15-29
Column: 10 address bits required to address the columns, 2-11
Based on this information, a function was implemented that receives bank, row and column as int parameters, and returns a pointer to the address corresponding to the DRAM location. See the code snippet below:

<syntaxhighlight lang="C">

void* getAddress(int bank, int row, int column) {
bank &= 0x7;
row &= ((1 << (ROW_BITS- 1))- 1) | (1 << (ROW_BITS- 1));
column &= 0x3FF;
uint32_t address = (bank << 12) | (row << ROW_START) | (column << COLUMN_START);
return ((uintptr_t)address >= (uintptr_t)(&__rowhammer_space_start) && (uintptr_t)address <= (uintptr_t)(&__rowhammer_space_end)) ? (void*)address : NULL;
}
</syntaxhighlight>

=== Cache Management ===
One of the primary challenges in implementing Rowhammer on ARM systems is ensuring that memory accesses bypass the CPU caches and directly reach DRAM. Unlike x86 systems, ARM does not have a universal instruction like `clflush` for cache flushing. In this study, cache flushing was achieved using the Xilinx SDK's cache maintenance functions, and in some of the experiments, the data cache was completely disabled to ensure uncached memory access during the attacks. In the below code, the aggressor rows are hammered, and the caches are flushed after each access. This low-level access to the cache management functions was very helpful, as it relieved the need for complex cache eviction strategies.

<syntaxhighlight lang="C">
void performRowhammer(void* neighborRow1, void* neighborRow2, int iterations) {
for (int i = 0; i < iterations; i++) {
readAddress(neighborRow1);
Xil_DCacheFlushLine(neighborRow1);
readAddress(neighborRow2);
Xil_DCacheFlushLine(neighborRow2);
}
}
</syntaxhighlight>

=== Test Setup for Rowhammer ===
The Rowhammer test on the Zynq-7000 was designed to simulate a double-sided hammering pattern. First, specific memory locations were initialized with a known data pattern. Then, the aggressor rows surrounding a target row were repeatedly accessed for a large number of iterations, while cache flushes ensured that accesses were handled by DRAM, not the CPU cache. After hammering, the target and adjacent rows were checked for bit flips by comparing their data to the original pattern.

The Rowhammer program contains the following steps:

# '''Iterate over and initialize memory columns:''' For each row of a bank, all columns are initialized with a 32-bit data pattern of alternating bit values. This initialization pattern is used in a later step to check whether bits were actually flipped. The memory region check of the address calculation functions ensures we only write to memory that lies within the defined boundary.
# '''Flush and invalidate caches:''' The L1 and L2 caches are flushed, invalidated, and disabled to prevent the CPU cache from serving subsequent memory requests.
# '''Iterate over rows and calculate aggressor row addresses:''' A for-loop is used to iterate over the number of rows, with the current row being the victim row. As this is supposed to be a double-sided Rowhammer pattern, addresses to two neighboring aggressor rows are calculated.
# '''Repeatedly activate aggressor rows:''' The calculated addresses are accessed repeatedly for a specified number of iterations, thus essentially performing the Rowhammer attack.
# '''Check surrounding rows for bit flips:''' After a pair of aggressor rows has been hammered, the contents of the surrounding rows is checked for bit flips by comparing the actual value read from memory to the expected data pattern used for initialization.

Below is a pseudocode representation of the actual source code.

<syntaxhighlight>
for each bank
for each row
for each column
address = calculate_address(bank, row, column)
if address is not NULL
initialize column = init_pattern
end if
end for
end for
disable_caches()
for each row
address1 = calculate_address(bank, row- 1, 0)
address2 = calculate_address(bank, row + 1, 0)
for rowhammer_iterations
activate row of address1
activate row at address2
end for
for each check_row from row- 2 to row + 2
for each column
check_address = get_address(bank, check_row, column)
if read from address does not equal init_pattern
print "Bit flip found"
end if
end for
end for
end for
</syntaxhighlight>

=== Test Setup for RowPress ===
As discussed in the theory section, the RowPress mechanism is fundamentally different from Rowhammer. Instead of inducing data errors by rapidly activating aggressor rows, RowPress works by keeping a single row open for an extended period, leading to bit flips.

== Implementation Challenges ==
RowPress relies on specialized FPGA hardware, which poses challenges when implementing it on platforms like the Zynq-7000. The following issues arise when applying RowPress to such platforms:

* '''Aggressor Row-On Time (tAggON):''' RowPress requires a DRAM row to remain open for a longer time, disturbing nearby rows and causing bit flips.
* '''Memory Controller Behaviour:''' The memory controller is responsible for controlling how long a row stays open, which is more critical in RowPress compared to Rowhammer.
* '''Timing Constraints:''' Lower clock speeds make precise timing difficult, affecting the effectiveness of RowPress.
* '''Limited Control over Memory Controller Settings:''' The Zynq-7000 platform offers limited flexibility to adjust critical DRAM timing parameters, unlike more advanced FPGA hardware.

== RowPress on the Zynq-7000 Platform ==
While it is difficult to create an ideal RowPress testing environment on the Zynq-7000, specific access patterns may be used to prolong row-open times. For example, accessing a row and then switching to a different cache block within the same row may cause the memory controller to keep the row open longer.

Building on the existing Rowhammer code, addresses mapped to the same row can be generated. Memory requests to different cache blocks within the same row may prompt the memory controller to keep the row open for subsequent accesses. To verify this, the following steps can be taken:

# Flush all cache blocks of a DRAM row from the CPU caches using appropriate instructions.
# Access a different row so the memory controller closes the previous row.
# Measure the CPU cycles needed to access each cache block of the row being tested.

A noticeable latency difference between the first and subsequent accesses indicates that the row remains open longer, effectively increasing tAggON.

The success of this approach depends on the row buffer management policy used by the memory controller. The main policies include:

* '''Closed-Page Policy:''' Closes a DRAM row immediately after a read or write operation.
* '''Fixed Open-Page Policy:''' Keeps a row open for a fixed duration after an operation.
* '''Adaptive Open-Page Policy:''' Dynamically adjusts how long a row remains open based on the system's activity.

To increase row-open time, the memory controller must use an adaptive open-page policy. On the Zybo Z7-20, it is possible to verify that the controller follows this policy, as indicated by certain control bits in the configuration files.

Profiling the system to synchronize RowPress patterns with DRAM refresh cycles can help maintain longer row activation times. Similar to Rowhammer, understanding DRAM address translation is crucial to targeting specific memory locations.

== Results ==

=== Rowhammer Results ===
Despite implementing double-sided hammering and flushing the CPU caches, no bit flips were observed during the Rowhammer tests on the Zynq-7000 platform. The potential reasons are manifold, and they are outlined in the thesis.

=== RowPress Results ===
The RowPress implementation faced even more significant challenges. The limited configurability of the memory controller on the Zynq-7000 meant that row-open time could not be extended as needed for RowPress. Further testing with hardware that provides more control over memory timing is required to evaluate RowPress effectively.

== Conclusion ==
Rowhammer and RowPress are critical vulnerabilities in DRAM that have been primarily explored on x86 systems. This research aimed to implement these vulnerabilities on ARM-based systems using the AMD Zynq SoC platform. While the Rowhammer and RowPress implementations on the Zynq-7000 did not result in observable bit flips, the research highlights the difficulty of replicating these attacks on ARM architectures. The findings suggest that further research is needed, particularly with more flexible hardware setups that allow better control over memory access patterns and timing.

== Future Work ==
Future research should focus on testing Rowhammer and RowPress on a wider variety of ARM-based platforms and exploring more sophisticated methods for managing memory access and timing. Additionally, hardware that allows for finer control over memory controllers, such as FPGAs with more advanced DRAM interfaces, would be beneficial for testing these vulnerabilities.

== References ==

H. Luo, A. Olgun et al., "RowPress: Amplifying Read Disturbance in Modern DRAM Chips," in ''Proceedings of the 50th Annual International Symposium on Computer Architecture (ISCA)'', 2023.

Y. Kim, R. Daly et al., "Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors," in ''Proc. 41st Int. Symp. Comput. Archit. (ISCA)'', 2014, pp. 361–372, doi: 10.1109/ISCA.2014.6853210.

D. Gruss and C. Maurice, "Rowhammer Attacks: A Walkthrough Guide," in ''Proc. RuhrSec 2017'', Graz University of Technology, 2017. [Online]. Available: https://www.tugraz.at. [Accessed: Sept. 16, 2024].

Z. Zhang, Z. Zhan, D. Balasubramanian, X. Koutsoukos, and G. Karsai, "Triggering Rowhammer Hardware Faults on ARM: A Revisit," in ''Proceedings of the 2018 Workshop on Attacks and Solutions in Hardware Security (ASHES '18)'', Toronto, Canada, 2018, pp. 24-33. doi: 10.1145/3266444.3266454.

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T19:25:51Z

TNicholson:

= Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs =

== Introduction ==

The rapid increase in memory density over the last few decades has led to the discovery of the Rowhammer vulnerability in 2014 and the RowPress vulnerability in 2023. These vulnerabilities arise from insufficient electrical isolation between DRAM memory cells, potentially causing bit flip errors when DRAM rows are accessed in specific patterns.

While much research has focused on x86 architectures, this bachelor thesis explores the feasibility and impact of implementing Rowhammer attacks on ARM-based systems, specifically the AMD Zynq SoCs. The thesis examines the architecture, memory management, and caching policies of ARM systems to evaluate their resilience or susceptibility to Rowhammer. Although the Rowhammer attack is already well-documented and extensively researched, there is limited literature available on RowPress.

=== Research Objectives ===
The primary objective of this research is to evaluate the viability of Rowhammer and RowPress vulnerabilities on AMD Zynq SoCs. Key objectives include:
* Understanding the architectural differences between x86 and ARM in the context of DRAM vulnerabilities.
* Implementing Rowhammer on ARM-based SoCs and evaluating its effectiveness.
* Investigating the viability of RowPress on the Zynq SoC platform.
* Comparing the ARM-based findings with existing x86-based research.

=== DRAM Architecture ===
A typical DRAM module is hierarchically organized and consists of multiple banks, each containing rows and columns of memory cells. A memory cell is made up of a capacitor and a transistor. Each cell is at the intersection of two perpendicular wires, the horizontal wordline and the vertical bitline. The voltage in the wordlines can be used to read data from any given row. For example, when the voltage of a wordline for a specific row is raised, all access-transistors of the corresponding cells are activated, connecting the capacitors storing the bit to the vertical bitlines. This allows the cell charge representing the stored data to flow into the row buffer. The row buffer acts similar to a cache, accelerating repeated access to a given memory row. The image below visualizes the DRAM architecture.
[[File:dram_architecture.png]]
DRAM memory is accessed in the following steps:
# '''Translate physical address to memory location:''' This is done by the memory controller using translation functions.
# '''Activate/Open row:''' Increasing the voltage of the calculated row connects the capacitors to their connected bitlines, causing the binary data stored in the capacitors to move to the row buffer, of which each bank has one.
# '''Read or modify data:''' Once in the row buffer, the data can be read or modified as needed.
# '''Close row:''' By lowering the voltage of the wordline, the row is closed. Once the row buffer has been cleared, another row can be opened after the memory controller issues the PRECHARGE command.
DRAM cell capacitors lose their charge over time. For this reason, DRAM cell charge needs to be refreshed at regular intervals. This is done by reading row data to the buffer and writing the same data back to the row. The interval at which DRAM must be refresh depends on several factors, including the specific standard of DRAM used and operating temperature. The most recent DRAM standards, DDR5 and LPDDR5, implement a refresh interval of 32 ms, while the previous standards, DDR3 and DDR4, had standard refresh intervals of 64 ms.

=== Rowhammer Attack ===
Rowhammer is a vulnerability that exploits the electrical interference between DRAM cells. By rapidly and repeatedly activating specific rows (aggressor rows), nearby rows (victim rows) encounter electrical interference, potentially causing bit flips.
For a conventional Rowhammer attack to succeed, three main requirements must be satisfied:
#'''Memory accesses must not be served by the cache: ''' If repeated memory accesses required for Rowhammer are handled by either the CPU cache or the row buffer, the DRAM hardware is never reached, making it impossible to cause bit flips. This requirement can generally be satisfied by evicting data from the cache or not putting data into the cache in the first place
#'''Memory access must be fast: ''' Depending on the refresh rate of the used memory con troller, there is a very limited timeframe during which bit flips can be caused before the charge of the DRAM cells is refreshed
#'''Memory access must be highly targeted:''' Rowhammer usually relies on being able to access very specific DRAM rows located in close proximity to each other. Therefore, it is important to understand the memory mapping functions involved in translating physical addresses into the actual location on the memory module.
Rowhammer attacks can be classified into different patterns:
* '''Single-sided Rowhammer:''' Repeated access to one row adjacent to the target row.
* '''Double-sided Rowhammer:''' Accessing two rows on either side of the target row, increasing the likelihood of bit flips.

Double-sided Rowhammer is the most common variant.

Rowhammer has been widely studied on x86 systems, and advanced exploits have been developed.

=== RowPress Attack ===
RowPress is a more recent attack method discovered in 2023. Unlike Rowhammer, which relies on high-frequency row activations, RowPress induces bit flips by keeping a memory row open for extended periods (referred to as tAggON). The prolonged activation of an aggressor row can destabilize adjacent rows and cause data corruption. There is currently very little research on RowPress, and existing studies have only been done on highly specialized testing hardware.

=== ARM Architecture and Memory Access ===
ARM architectures, such as those used in the Zynq SoCs, differ from x86 in several key areas, particularly in memory access and cache management. ARM processors typically use a different set of instructions for cache maintenance, and direct memory access is handled differently. Furthermore, ARM-based systems often have more constrained memory controllers and may employ different policies for handling row activations, which affects the feasibility of attacks like Rowhammer and RowPress.

== Methodology ==

=== AMD Zynq SoC Overview ===
The AMD Zynq-7000 SoC is an embedded development platform with a dual-core ARM Cortex-A9 processor and programmable logic (FPGA). The specific model used in this thesis, the Digilent Zybo Z7-20, includes 1 GB of DDR3L DRAM.

[[File:zybo-z7.png|300px]]

=== Development Environment ===
The development environment used for this research consists of AMD’s Vivado for hardware design and Vitis for program development. The hardware design created using Vivado includes the Zynq Processing System (Zynq PS) and the default DRAM memory configuration. Altering the DRAM parameters would not have aided in the experiments. The program, written in C, controls the memory access patterns and performs the Rowhammer tests.

=== DRAM Address Mapping ===
Understanding the specific DRAM address mapping functions is important for successfully targeting specific rows in a Rowhammer or RowPress attack. The address mapping functions translate a physical address to the exact location of the associated data on the DRAM module. By analyzing the Technical Reference Manual and configuration files, the exact address bits used for row, bank, and column mapping were identified.
The following addressing information was obtained from the documentation:
Bank: 3 address bits required to address the 8 banks, these bits are 12,13 and 14
Row: 15 address bits required to address the rows, 15-29
Column: 10 address bits required to address the columns, 2-11
Based on this information, a function was implemented that receives bank, row and column as int parameters, and returns a pointer to the address corresponding to the DRAM location. See the code snippet below:

<syntaxhighlight lang="C">

void* getAddress(int bank, int row, int column) {
bank &= 0x7;
row &= ((1 << (ROW_BITS- 1))- 1) | (1 << (ROW_BITS- 1));
column &= 0x3FF;
uint32_t address = (bank << 12) | (row << ROW_START) | (column << COLUMN_START);
return ((uintptr_t)address >= (uintptr_t)(&__rowhammer_space_start) && (uintptr_t)address <= (uintptr_t)(&__rowhammer_space_end)) ? (void*)address : NULL;
}
</syntaxhighlight>

=== Cache Management ===
One of the primary challenges in implementing Rowhammer on ARM systems is ensuring that memory accesses bypass the CPU caches and directly reach DRAM. Unlike x86 systems, ARM does not have a universal instruction like `clflush` for cache flushing. In this study, cache flushing was achieved using the Xilinx SDK's cache maintenance functions, and in some of the experiments, the data cache was completely disabled to ensure uncached memory access during the attacks. In the below code, the aggressor rows are hammered, and the caches are flushed after each access. This low-level access to the cache management functions was very helpful, as it relieved the need for complex cache eviction strategies.

<syntaxhighlight lang="C">
void performRowhammer(void* neighborRow1, void* neighborRow2, int iterations) {
for (int i = 0; i < iterations; i++) {
readAddress(neighborRow1);
Xil_DCacheFlushLine(neighborRow1);
readAddress(neighborRow2);
Xil_DCacheFlushLine(neighborRow2);
}
}
</syntaxhighlight>

=== Test Setup for Rowhammer ===
The Rowhammer test on the Zynq-7000 was designed to simulate a double-sided hammering pattern. First, specific memory locations were initialized with a known data pattern. Then, the aggressor rows surrounding a target row were repeatedly accessed for a large number of iterations, while cache flushes ensured that accesses were handled by DRAM, not the CPU cache. After hammering, the target and adjacent rows were checked for bit flips by comparing their data to the original pattern.

The Rowhammer program contains the following steps:

# '''Iterate over and initialize memory columns:''' For each row of a bank, all columns are initialized with a 32-bit data pattern of alternating bit values. This initialization pattern is used in a later step to check whether bits were actually flipped. The memory region check of the address calculation functions ensures we only write to memory that lies within the defined boundary.
# '''Flush and invalidate caches:''' The L1 and L2 caches are flushed, invalidated, and disabled to prevent the CPU cache from serving subsequent memory requests.
# '''Iterate over rows and calculate aggressor row addresses:''' A for-loop is used to iterate over the number of rows, with the current row being the victim row. As this is supposed to be a double-sided Rowhammer pattern, addresses to two neighboring aggressor rows are calculated.
# '''Repeatedly activate aggressor rows:''' The calculated addresses are accessed repeatedly for a specified number of iterations, thus essentially performing the Rowhammer attack.
# '''Check surrounding rows for bit flips:''' After a pair of aggressor rows has been hammered, the contents of the surrounding rows is checked for bit flips by comparing the actual value read from memory to the expected data pattern used for initialization.

Below is a pseudocode representation of the actual source code.

<syntaxhighlight>
for each bank
for each row
for each column
address = calculate_address(bank, row, column)
if address is not NULL
initialize column = init_pattern
end if
end for
end for
disable_caches()
for each row
address1 = calculate_address(bank, row- 1, 0)
address2 = calculate_address(bank, row + 1, 0)
for rowhammer_iterations
activate row of address1
activate row at address2
end for
for each check_row from row- 2 to row + 2
for each column
check_address = get_address(bank, check_row, column)
if read from address does not equal init_pattern
print "Bit flip found"
end if
end for
end for
end for
</syntaxhighlight>

=== Test Setup for RowPress ===
Implementing RowPress on the Zynq-7000 presented significant challenges due to the limitations of the memory controller, which does not allow fine-grained control over row-open time (tAggON). The thesis highlights the possibility of using specific memory access patterns to cause the memory controller to prolong the row-open time without explicitly changing the timing configuration parameters. However, the viability of this approach depends on the row buffer management policy of the memory controller. It was concluded that RowPress is not viable on the selected hardware. Precise configurability of the memory controller is of utmost importance for RowPress.

== Results ==

=== Rowhammer Results ===
Despite implementing double-sided hammering and flushing the CPU caches, no bit flips were observed during the Rowhammer tests on the Zynq-7000 platform. The potential reasons are manifold, and they are outlined in the thesis.

=== RowPress Results ===
The RowPress implementation faced even more significant challenges. The limited configurability of the memory controller on the Zynq-7000 meant that row-open time could not be extended as needed for RowPress. Further testing with hardware that provides more control over memory timing is required to evaluate RowPress effectively.

== Conclusion ==
Rowhammer and RowPress are critical vulnerabilities in DRAM that have been primarily explored on x86 systems. This research aimed to implement these vulnerabilities on ARM-based systems using the AMD Zynq SoC platform. While the Rowhammer and RowPress implementations on the Zynq-7000 did not result in observable bit flips, the research highlights the difficulty of replicating these attacks on ARM architectures. The findings suggest that further research is needed, particularly with more flexible hardware setups that allow better control over memory access patterns and timing.

== Future Work ==
Future research should focus on testing Rowhammer and RowPress on a wider variety of ARM-based platforms and exploring more sophisticated methods for managing memory access and timing. Additionally, hardware that allows for finer control over memory controllers, such as FPGAs with more advanced DRAM interfaces, would be beneficial for testing these vulnerabilities.

== References ==

H. Luo, A. Olgun et al., "RowPress: Amplifying Read Disturbance in Modern DRAM Chips," in ''Proceedings of the 50th Annual International Symposium on Computer Architecture (ISCA)'', 2023.

Y. Kim, R. Daly et al., "Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors," in ''Proc. 41st Int. Symp. Comput. Archit. (ISCA)'', 2014, pp. 361–372, doi: 10.1109/ISCA.2014.6853210.

D. Gruss and C. Maurice, "Rowhammer Attacks: A Walkthrough Guide," in ''Proc. RuhrSec 2017'', Graz University of Technology, 2017. [Online]. Available: https://www.tugraz.at. [Accessed: Sept. 16, 2024].

Z. Zhang, Z. Zhan, D. Balasubramanian, X. Koutsoukos, and G. Karsai, "Triggering Rowhammer Hardware Faults on ARM: A Revisit," in ''Proceedings of the 2018 Workshop on Attacks and Solutions in Hardware Security (ASHES '18)'', Toronto, Canada, 2018, pp. 24-33. doi: 10.1145/3266444.3266454.

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T19:21:52Z

TNicholson:

= Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs =

== Introduction ==

The rapid increase in memory density over the last few decades has led to the discovery of the Rowhammer vulnerability in 2014 and the RowPress vulnerability in 2023. These vulnerabilities arise from insufficient electrical isolation between DRAM memory cells, potentially causing bit flip errors when DRAM rows are accessed in specific patterns.

While much research has focused on x86 architectures, this bachelor thesis explores the feasibility and impact of implementing Rowhammer attacks on ARM-based systems, specifically the AMD Zynq SoCs. The thesis examines the architecture, memory management, and caching policies of ARM systems to evaluate their resilience or susceptibility to Rowhammer. Although the Rowhammer attack is already well-documented and extensively researched, there is limited literature available on RowPress.

=== Research Objectives ===
The primary objective of this research is to evaluate the viability of Rowhammer and RowPress vulnerabilities on AMD Zynq SoCs. Key objectives include:
* Understanding the architectural differences between x86 and ARM in the context of DRAM vulnerabilities.
* Implementing Rowhammer on ARM-based SoCs and evaluating its effectiveness.
* Investigating the viability of RowPress on the Zynq SoC platform.
* Comparing the ARM-based findings with existing x86-based research.

=== DRAM Architecture ===
A typical DRAM module is hierarchically organized and consists of multiple banks, each containing rows and columns of memory cells. A memory cell is made up of a capacitor and a transistor. Each cell is at the intersection of two perpendicular wires, the horizontal wordline and the vertical bitline. The voltage in the wordlines can be used to read data from any given row. For example, when the voltage of a wordline for a specific row is raised, all access-transistors of the corresponding cells are activated, connecting the capacitors storing the bit to the vertical bitlines. This allows the cell charge representing the stored data to flow into the row buffer. The row buffer acts similar to a cache, accelerating repeated access to a given memory row. The image below visualizes the DRAM architecture.
[[File:dram_architecture.png]]
DRAM memory is accessed in the following steps:
# '''Translate physical address to memory location:''' This is done by the memory controller using translation functions.
# '''Activate/Open row:''' Increasing the voltage of the calculated row connects the capacitors to their connected bitlines, causing the binary data stored in the capacitors to move to the row buffer, of which each bank has one.
# '''Read or modify data:''' Once in the row buffer, the data can be read or modified as needed.
# '''Close row:''' By lowering the voltage of the wordline, the row is closed. Once the row buffer has been cleared, another row can be opened after the memory controller issues the PRECHARGE command.
DRAM cell capacitors lose their charge over time. For this reason, DRAM cell charge needs to be refreshed at regular intervals. This is done by reading row data to the buffer and writing the same data back to the row. The interval at which DRAM must be refresh depends on several factors, including the specific standard of DRAM used and operating temperature. The most recent DRAM standards, DDR5 and LPDDR5, implement a refresh interval of 32 ms, while the previous standards, DDR3 and DDR4, had standard refresh intervals of 64 ms.

=== Rowhammer Attack ===
Rowhammer is a vulnerability that exploits the electrical interference between DRAM cells. By rapidly and repeatedly activating specific rows (aggressor rows), nearby rows (victim rows) encounter electrical interference, potentially causing bit flips.
For a conventional Rowhammer attack to succeed, three main requirements must be satisfied:
#'''Memory accesses must not be served by the cache: ''' If repeated memory accesses required for Rowhammer are handled by either the CPU cache or the row buffer, the DRAM hardware is never reached, making it impossible to cause bit flips. This requirement can generally be satisfied by evicting data from the cache or not putting data into the cache in the first place
#'''Memory access must be fast: ''' Depending on the refresh rate of the used memory con troller, there is a very limited timeframe during which bit flips can be caused before the charge of the DRAM cells is refreshed
#'''Memory access must be highly targeted:''' Rowhammer usually relies on being able to access very specific DRAM rows located in close proximity to each other. Therefore, it is important to understand the memory mapping functions involved in translating physical addresses into the actual location on the memory module.
Rowhammer attacks can be classified into different patterns:
* '''Single-sided Rowhammer:''' Repeated access to one row adjacent to the target row.
* '''Double-sided Rowhammer:''' Accessing two rows on either side of the target row, increasing the likelihood of bit flips.

Double-sided Rowhammer is the most common variant.

Rowhammer has been widely studied on x86 systems, and advanced exploits have been developed.

=== RowPress Attack ===
RowPress is a more recent attack method discovered in 2023. Unlike Rowhammer, which relies on high-frequency row activations, RowPress induces bit flips by keeping a memory row open for extended periods (referred to as tAggON). The prolonged activation of an aggressor row can destabilize adjacent rows and cause data corruption. There is currently very little research on RowPress, and existing studies have only been done on highly specialized testing hardware.

=== ARM Architecture and Memory Access ===
ARM architectures, such as those used in the Zynq SoCs, differ from x86 in several key areas, particularly in memory access and cache management. ARM processors typically use a different set of instructions for cache maintenance, and direct memory access is handled differently. Furthermore, ARM-based systems often have more constrained memory controllers and may employ different policies for handling row activations, which affects the feasibility of attacks like Rowhammer and RowPress.

== Methodology ==

=== AMD Zynq SoC Overview ===
The AMD Zynq-7000 SoC is an embedded development platform with a dual-core ARM Cortex-A9 processor and programmable logic (FPGA). The specific model used in this thesis, the Digilent Zybo Z7-20, includes 1 GB of DDR3L DRAM.

[[File:zybo-z7.png|300px]]

=== Development Environment ===
The development environment used for this research consists of AMD’s Vivado for hardware design and Vitis for program development. The hardware design created using Vivado includes the Zynq Processing System (Zynq PS) and the default DRAM memory configuration. Altering the DRAM parameters would not have aided in the experiments. The program, written in C, controls the memory access patterns and performs the Rowhammer tests.

=== DRAM Address Mapping ===
Understanding the specific DRAM address mapping functions is important for successfully targeting specific rows in a Rowhammer or RowPress attack. The address mapping functions translate a physical address to the exact location of the associated data on the DRAM module. By analyzing the Technical Reference Manual and configuration files, the exact address bits used for row, bank, and column mapping were identified.
The following addressing information was obtained from the documentation:
Bank: 3 address bits required to address the 8 banks, these bits are 12,13 and 14
Row: 15 address bits required to address the rows, 15-29
Column: 10 address bits required to address the columns, 2-11
Based on this information, a function was implemented that receives bank, row and column as int parameters, and returns a pointer to the address corresponding to the DRAM location. See the code snippet below:

<syntaxhighlight lang="C">

void* getAddress(int bank, int row, int column) {
bank &= 0x7;
row &= ((1 << (ROW_BITS- 1))- 1) | (1 << (ROW_BITS- 1));
column &= 0x3FF;
uint32_t address = (bank << 12) | (row << ROW_START) | (column << COLUMN_START);
return ((uintptr_t)address >= (uintptr_t)(&__rowhammer_space_start) && (uintptr_t)address <= (uintptr_t)(&__rowhammer_space_end)) ? (void*)address : NULL;
}
</syntaxhighlight>

=== Cache Management ===
One of the primary challenges in implementing Rowhammer on ARM systems is ensuring that memory accesses bypass the CPU caches and directly reach DRAM. Unlike x86 systems, ARM does not have a universal instruction like `clflush` for cache flushing. In this study, cache flushing was achieved using the Xilinx SDK's cache maintenance functions, and in some of the experiments, the data cache was completely disabled to ensure uncached memory access during the attacks. In the below code, the aggressor rows are hammered, and the caches are flushed after each access. This low-level access to the cache management functions was very helpful, as it relieved the need for complex cache eviction strategies.

<syntaxhighlight lang="C">
void performRowhammer(void* neighborRow1, void* neighborRow2, int iterations) {
for (int i = 0; i < iterations; i++) {
readAddress(neighborRow1);
Xil_DCacheFlushLine(neighborRow1);
readAddress(neighborRow2);
Xil_DCacheFlushLine(neighborRow2);
}
}
</syntaxhighlight>

=== Test Setup for Rowhammer ===
The Rowhammer test on the Zynq-7000 was designed to simulate a double-sided hammering pattern. First, specific memory locations were initialized with a known data pattern. Then, the aggressor rows surrounding a target row were repeatedly accessed for a large number of iterations, while cache flushes ensured that accesses were handled by DRAM, not the CPU cache. After hammering, the target and adjacent rows were checked for bit flips by comparing their data to the original pattern. Below is a pseudocode representation of the program:

<syntaxhighlight>
for each bank
for each row
for each column
address = calculate_address(bank, row, column)
if address is not NULL
initialize column = init_pattern
end if
end for
end for
disable_caches()
for each row
address1 = calculate_address(bank, row- 1, 0)
address2 = calculate_address(bank, row + 1, 0)
for rowhammer_iterations
activate row of address1
activate row at address2
end for
for each check_row from row- 2 to row + 2
for each column
check_address = get_address(bank, check_row, column)
if read from address does not equal init_pattern
print "Bit flip found"
end if
end for
end for
end for
</syntaxhighlight>

=== Test Setup for RowPress ===
Implementing RowPress on the Zynq-7000 presented significant challenges due to the limitations of the memory controller, which does not allow fine-grained control over row-open time (tAggON). The thesis highlights the possibility of using specific memory access patterns to cause the memory controller to prolong the row-open time without explicitly changing the timing configuration parameters. However, the viability of this approach depends on the row buffer management policy of the memory controller. It was concluded that RowPress is not viable on the selected hardware. Precise configurability of the memory controller is of utmost importance for RowPress.

== Results ==

=== Rowhammer Results ===
Despite implementing double-sided hammering and flushing the CPU caches, no bit flips were observed during the Rowhammer tests on the Zynq-7000 platform. The potential reasons are manifold, and they are outlined in the thesis.

=== RowPress Results ===
The RowPress implementation faced even more significant challenges. The limited configurability of the memory controller on the Zynq-7000 meant that row-open time could not be extended as needed for RowPress. Further testing with hardware that provides more control over memory timing is required to evaluate RowPress effectively.

== Conclusion ==
Rowhammer and RowPress are critical vulnerabilities in DRAM that have been primarily explored on x86 systems. This research aimed to implement these vulnerabilities on ARM-based systems using the AMD Zynq SoC platform. While the Rowhammer and RowPress implementations on the Zynq-7000 did not result in observable bit flips, the research highlights the difficulty of replicating these attacks on ARM architectures. The findings suggest that further research is needed, particularly with more flexible hardware setups that allow better control over memory access patterns and timing.

== Future Work ==
Future research should focus on testing Rowhammer and RowPress on a wider variety of ARM-based platforms and exploring more sophisticated methods for managing memory access and timing. Additionally, hardware that allows for finer control over memory controllers, such as FPGAs with more advanced DRAM interfaces, would be beneficial for testing these vulnerabilities.

== References ==

H. Luo, A. Olgun et al., "RowPress: Amplifying Read Disturbance in Modern DRAM Chips," in ''Proceedings of the 50th Annual International Symposium on Computer Architecture (ISCA)'', 2023.

Y. Kim, R. Daly et al., "Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors," in ''Proc. 41st Int. Symp. Comput. Archit. (ISCA)'', 2014, pp. 361–372, doi: 10.1109/ISCA.2014.6853210.

D. Gruss and C. Maurice, "Rowhammer Attacks: A Walkthrough Guide," in ''Proc. RuhrSec 2017'', Graz University of Technology, 2017. [Online]. Available: https://www.tugraz.at. [Accessed: Sept. 16, 2024].

Z. Zhang, Z. Zhan, D. Balasubramanian, X. Koutsoukos, and G. Karsai, "Triggering Rowhammer Hardware Faults on ARM: A Revisit," in ''Proceedings of the 2018 Workshop on Attacks and Solutions in Hardware Security (ASHES '18)'', Toronto, Canada, 2018, pp. 24-33. doi: 10.1145/3266444.3266454.

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T14:00:44Z

TNicholson:

File:Zybo-z7.png

2024-09-16T13:59:25Z

TNicholson:

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T13:48:45Z

TNicholson:

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T13:11:55Z

TNicholson:

File:Dram architecture.png

2024-09-16T11:01:33Z

TNicholson: This image shows the hierarchical structure of DRAM modules.

== Summary ==
This image shows the hierarchical structure of DRAM modules.

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T09:47:53Z

TNicholson:

Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs

2024-09-16T09:40:42Z

TNicholson: Created page with "= Rowhammer and RowPress: Implementation and Evaluation on AMD Zynq SoCs = == Introduction == The rapid increase in memory density over the last few decades has led to the discovery of the Rowhammer vulnerability in 2014 and the RowPress vulnerability in 2023. These vulnerabilities arise from insufficient electrical isolation between DRAM memory cells, potentially causing bit flip errors when DRAM rows are accessed in specific patterns. While much research has focused..."

Malware Lab: VM Setup and AWS EC2

2024-02-29T11:36:32Z

TNicholson:

The prerequisites for this guide are that you should have two virtual machine instances running on your hypervisor:

* Flare VM (Setup instructions: [[Flare VM Installation]])
* Remnux

The idea of this lab setup is to be able to detonate live malware on the Flare VM, while using the Remnux VM to observe network traffic. It is also important that we make sure the network is isolated from our host system. The ways of accomplishing this vary depending on which virtualization software you are using. But you must definitely create a new virtual internal network, and then place both virtual machines inside this network. Make sure it is a Host-Only network (VirtualBox). Note that you will not have internet access within that network - so if you need to download any tools, you may need to temporarily move the VMs to a NAT network, download the tools, and then move them back to the Host-Only network.

In the Remnux VM, we will run inetsim to simulate network services such as DNS. Inetsim can generally impersonate any kind of network service, but we will be using it for DNS.


== Configure Inetsim to impersonate DNS ==

To configure Inetsim to impersonate DNS, follow these steps:

<ol style="list-style-type: decimal;">
<li>Open a terminal in the Remnux VM.</li>
<li>Install Inetsim using the following command in case it is not already installed:
<pre>sudo apt-get install inetsim</pre></li>
<li>Open the Inetsim configuration file using the following command:
<pre> sudo nano /etc/inetsim/inetsim.conf</pre></li>
<li>Find the following line in the configuration file: <code>#start_service dns</code> and remove the comment (#) from the beginning of the line.</li>
<li>Find the following line in the configuration file: <code>service_bind_address</code> and set the IP address to <code>0.0.0.0</code>.</li>
<li>Find the <code>#dns_default_ip</code> line, remove the comment (#) from the beginning of the line, and set the IP address to the IP address of the Remnux VM.</li>
<li>Save the configuration file and exit the text editor.</li>
<li>Start the Inetsim service using the following command:
<pre>sudo systemctl restart inetsim</pre></li></ol>


== Prepare the Flare VM instance ==

In the Flare VM, we will detonate the malware samples and observe the network traffic using Wireshark.


=== Configure Flare VM to use the Remnux VM as the DNS server ===

To configure Flare VM to use the Remnux VM as the DNS server, follow these steps:

# Search for Ethernet settings in the Windows search bar and click on “Change adapter options”.
# Click on the network connection and then click on “Properties”.
# Select “Internet Protocol Version 4 (TCP/IPv4)” and click on “Properties”.
# Set the DNS server to the IP address of the Remnux VM.
# Click “OK” to save the settings.


== Testing the lab environment ==

To test the lab environment, follow these steps:

<ol style="list-style-type: decimal;">
<li>Test ping connectivity between the two VMs.</li>
<li>Run the following command to check if the DNS server is set correctly:
<pre>nslookup google.com</pre>
The output should show the IP address of the Remnux VM as the DNS server.</li>
<li>Run the following command to check if the network traffic is being captured by the Remnux VM:
<pre> ping google.com</pre>
Open Wireshark in the Remnux VM and check if the network traffic is being captured.</li>
<li>Download a malware sample to the Flare VM and detonate it.</li>
<li>Observe the network traffic in Wireshark in the Remnux VM to see if the malware is making any network connections.</li></ol>

IMPORTANT: Once you have it all set up, take a snapshot of the VMs. This way, you can restore the VMs to their original state after running malware samples. This can save you a lot of time and effort in the long run, as you won’t have to reinstall the VMs every time you run a malware sample.


== Automated Deployment of the Lab Environment in the Cloud ==

If you don’t want to host the lab on your own machine, you can choose to deploy the malware lab on Amazon Web Services (AWS) - as shown later on in this article, the deployment process can also be automated using an IaC (Infrastructure-as-Code) approach with Terraform.


=== Prerequisites ===

Before you begin, you will need to have the following:

* An AWS account
* Terraform installed on your local machine (or use Windows Subsystem for Linux (WSL) if you are using Windows)

First, we need to manually recreate the Flare VM on AWS. In the case of AWS, FlareVM is best installed on a base Windows Server image. Be sure to allocate enough storage space for the VMs, especially for the Flare VM. For external access, you will need to use RDP to connect to the Flare VM. You might need to explicitly allow RDP access from any IP. AWS allows you to download the RDP file to connect to the Flare VM. AWS automatically puts a password on the Windows Server, which you can get by decrypting the password using the key pair you created when you launched the instance. Once you have the password, you can connect to the Flare VM using the RDP file.

Once connected to the Flare VM remote desktop, you need to go through the same steps as you would on a local machine to set up the Flare VM. Just use the provided scripts to install the tools and set up the environment.

After setting up Flare VM, you can use AWS to create an AMI (Amazon Machine Image) of the Flare VM. This will allow you to launch new instances of the Flare VM without having to go through the setup process again:

* Select the AWS instance of the Flare VM in the AWS Management Console.
* Click on “Actions” and then “Image and templates” and then “Create image”.
* Give the image a name and description and click “Create image”.

To later be able to launch instances of the AMI using Terraform, you will need to create a new role in AWS:

* Go to the AWS Management Console and search for “IAM”.
* Click on “Users” and then “Add user”.
* Groups: Create a new group and give it a name (e.g. EC-full-access). Under Permissions Policies, select “AmazonEC2FullAccess”.
* Add the user to the group and continue
* Create a Command-Line-Interface (CLI) access key and secret key for the user.

Now, you can continue with the Terraform deployment. For this, switch over to WSL or a Linux machine, as Terraform is not officially supported on Windows.

Update the repository and install Terraform, JQ and AWS-CLI using the following commands:

<pre>sudo apt-get update

sudo apt install jq

# Installation instructions for Terraform can be found here: https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli

sudo apt install awscli</pre>
Configure the AWS IAM user using the following command:

<code>aws configure</code>

Enter the access key, secret key, region (use the specific AWS region your node is deployed in) and output format when prompted.

Create a new directory for the Terraform configuration files and navigate to it:

<pre>mkdir malware-lab
cd malware-lab</pre>
For the Terraform configuration, there is a very useful Git repository that contains a Terraform template for deploying a malware lab on AWS. You can clone the repository using the following command:

<pre>git clone https://github.com/adanalvarez/AWS-malware-lab.git</pre>
It contains a base version of the Terraform configuration for deploying the malware lab on AWS. To specify further details for your deployment, you need to create a new file called “terraform.tfvars” in the malware-lab directory and specify the following variables:

<pre class="hcl">{
"environment": "malware-lab",
"ami": "ami-xxxxxxxxxxxxxxxxx",
"account" : "222222222222",
"region": "eu-west-1",
"enable_guacamole": false,
"enable_inetsim": true
}</pre>
In this case, Guacamole is used to provide remote access to the Flare VM, and Inetsim is used to simulate network services. If you want to enable these features, you can set the “enable_guacamole” and “enable_inetsim” variables to “true”.

Now, you must check which version of Terraform is installed on your machine. You can do this using the following command:

<code>terraform -v</code>

Then, open the main.tf file in the malware-lab directory and change the Terraform version to the version installed on your machine.

In the instances.tf file, you need to change the following:

* In the Linux instance for Inetsim, change the AMI id to a corresponding AMI id for Ubuntu Server 20.04 LTS.

Under <code>network.tf</code>, you also need to change the availability zone to the availability zone of your AWS instance.

Now, you can initialize the Terraform configuration using the following command:

<code>terraform init</code>

Then, you can deploy the malware lab using the following command:

<code>terraform apply</code>

This will deploy the malware lab on AWS. Once the deployment is complete, you can access the Flare VM using the RDP file provided by AWS. You can also access the Remnux VM using SSH.

The Terraform output will provide you with the public IP addresses of the Flare VM. Just like before, you can connect to the EC2 instance via RDP.

To destroy the malware lab, you can use the following command:

<code>terraform destroy</code>

This will destroy all the resources created by Terraform.


== Conclusion ==

In this guide, we have set up a malware lab environment using two virtual machines: Flare VM and Remnux. We have configured Inetsim to impersonate DNS on the Remnux VM and set up the Flare VM to use the Remnux VM as the DNS server. We have also tested the lab environment by observing network traffic using Wireshark. Finally, we have automated the deployment of the lab environment on AWS using Terraform. This lab environment can be used to safely detonate live malware samples and observe their network behavior.

Introduction to Malware Analysis

2024-02-29T11:35:05Z

TNicholson: /* Analysis Enviroments */

If you want to get started learning about malware analysis, this guide is for you. We will first start by setting up suitable environments in which malware can safely be analyzed.

It is very important that when dealing with malware samples, you only download them from trusted sources and only ever unpack them within your VM setup.


== Analysis Enviroments ==

Of course, there are very many different malware analysis environments you can choose from. But for the sake of simplicity, this guide will focus on two fairly well-known software systems: Flare VM and Remnux. The main difference between these two operating systems is that Flare VM runs on Windows and Remnux runs on Ubuntu (Linux). What they have in common is that they offer a wide range of tools that should easily be enough to get you started!

Installing and setting up Remnux is simplified by only having to download the pre-built .ova virtual machine file (https://docs.remnux.org/install-distro/get-virtual-appliance).

There is already a different article about setting up a Windows malware analysis environment. However, I found it way easier to just use the Flare VM scripts to automate the process. Setting up FlareVM is somewhat time-intensive, but I have written a step-by-step guide to help get you started: [[Flare VM Installation]]. If you prefer using a video as guidance, I can recommend this video: https://www.youtube.com/watch?v=BiSdnusy2AQ&ab_channel=LetsDefend

In a different article, ([[Malware Lab: VM Setup and AWS EC2]]) it will be described how we can combine FlareVM and Remnux within a single malware lab environment, in which malware can be detonated on the FlareVM and the Remnux machine acts as a fake DNS server using inetsim.

In the end, the type of malware you want to analyze influences which operating system you will use for analysis. Later on throughout this guide, we will also analyze IoT malware, this is practially always malware in an ELF Linux executable format.



== General knowledge about Malware Analysis ==

Before you start setting up your malware analysis lab, make sure you understand the following basic concepts.


=== Static vs. Dynamic Analysis ===

Static analysis deals with extracting data about a malware sample without actually executing it. The main objective is to extract features from the malware that could help us understand what a certain malware does upon execution.

The following steps are important when approaching a malware sample:

* Identifying the file type (Target OS, architecture and format)
* Trying to identify the malware: Hashing the malware file gives it a unique identifier. The hash can be entered into various malware search engines, which attempt to find malware that has an identical hash.
* String extraction: Strings extracted from the binary file can give the malware analyst an idea of what the malware can do.
* (Un)packing and (De)obfuscation: These are techniques used to prevent detection and make it harder to find readable strings. Unpacking and deobfuscating reveals more information about the sample.
* PE headers: Reveal a lot about the functionality of the malware

Dynamic analysis involves executing the malware sample in a controlled environment to observe its behaviour. This type of analysis provides insights into the runtime behavior of the malware, such as network communication, file system modifications, and process interactions. From observing this behaviour, important conclusions can be drawn.

To perform dynamic analysis, follow these steps:

# Set up a suitable sandbox environment: Create a virtual machine to isolate the malware from your host system. Using LXC containers is generally not advisable.
# Execute the malware: Run the malware sample in the sandbox environment, monitoring its behavior and capturing any relevant data.
# Monitor network activity: Use tools like Wireshark or tcpdump to capture network traffic generated by the malware. Analyze the captured data to understand the communication patterns and potential malicious activities.
# Monitor file system changes: Use file monitoring tools like inotify or Sysmon to track file system modifications made by the malware. This can help identify any files created, modified, or deleted during the execution.
# Analyze process interactions: Use process monitoring tools like Process Monitor or Procmon to monitor the malware’s interactions with other processes on the system. This can provide insights into any suspicious or malicious behavior.
# Capture system calls: Use tools like strace or API monitoring tools to capture system calls made by the malware. This can reveal the underlying functionality and interactions with the operating system.
# The last step should be to aggregate and analyze all captured activity.

Dynamic analysis is very useful when the full behaviour and intent of the malware cannot be inferred from static analysis alone.

Remember to always perform dynamic analysis in a controlled and isolated environment to prevent any unintended consequences or damage to your system.


=== Safely sourcing malware samples ===

It is very important to be careful where you get your malware samples from. To begin with, I can recommend the GitHub repository https://github.com/ytisf/theZoo. It contains a wide selection of live malware samples that can be used for static and dynamic analysis.

It is common practice to download the samples as .zip files. The folders should always be encrypted, usually using the password “infected”.

== References ==

https://www.sans.org/blog/how-you-can-start-learning-malware-analysis/

https://www.bitdefender.com/blog/businessinsights/the-differences-between-static-malware-analysis-and-dynamic-malware-analysis/

[[Category:Documentation]]

Introduction to Malware Analysis

2024-02-29T11:34:34Z

TNicholson: /* Analysis Enviroments */

If you want to get started learning about malware analysis, this guide is for you. We will first start by setting up suitable environments in which malware can safely be analyzed.

It is very important that when dealing with malware samples, you only download them from trusted sources and only ever unpack them within your VM setup.


== Analysis Enviroments ==

Of course, there are very many different malware analysis environments you can choose from. But for the sake of simplicity, this guide will focus on two fairly well-known software systems: Flare VM and Remnux. The main difference between these two operating systems is that Flare VM runs on Windows and Remnux runs on Ubuntu (Linux). What they have in common is that they offer a wide range of tools that should easily be enough to get you started!

Installing and setting up Remnux is simplified by only having to download the pre-built .ova virtual machine file (https://docs.remnux.org/install-distro/get-virtual-appliance).

There is already a different article about setting up a Windows malware analysis environment. However, I found it way easier to just use the Flare VM scripts to automate the process. Setting up FlareVM is somewhat time-intensive, but I have written a step-by-step guide to help get you started: https://wiki.elvis.science/index.php?title=Flare_VM_Installation. If you prefer using a video as guidance, I can recommend this video: https://www.youtube.com/watch?v=BiSdnusy2AQ&ab_channel=LetsDefend

In a different article, ([[Malware Lab: VM Setup and AWS EC2]]) it will be described how we can combine FlareVM and Remnux within a single malware lab environment, in which malware can be detonated on the FlareVM and the Remnux machine acts as a fake DNS server using inetsim.

In the end, the type of malware you want to analyze influences which operating system you will use for analysis. Later on throughout this guide, we will also analyze IoT malware, this is practially always malware in an ELF Linux executable format.



== General knowledge about Malware Analysis ==

Before you start setting up your malware analysis lab, make sure you understand the following basic concepts.


=== Static vs. Dynamic Analysis ===

Static analysis deals with extracting data about a malware sample without actually executing it. The main objective is to extract features from the malware that could help us understand what a certain malware does upon execution.

The following steps are important when approaching a malware sample:

* Identifying the file type (Target OS, architecture and format)
* Trying to identify the malware: Hashing the malware file gives it a unique identifier. The hash can be entered into various malware search engines, which attempt to find malware that has an identical hash.
* String extraction: Strings extracted from the binary file can give the malware analyst an idea of what the malware can do.
* (Un)packing and (De)obfuscation: These are techniques used to prevent detection and make it harder to find readable strings. Unpacking and deobfuscating reveals more information about the sample.
* PE headers: Reveal a lot about the functionality of the malware

Dynamic analysis involves executing the malware sample in a controlled environment to observe its behaviour. This type of analysis provides insights into the runtime behavior of the malware, such as network communication, file system modifications, and process interactions. From observing this behaviour, important conclusions can be drawn.

To perform dynamic analysis, follow these steps:

# Set up a suitable sandbox environment: Create a virtual machine to isolate the malware from your host system. Using LXC containers is generally not advisable.
# Execute the malware: Run the malware sample in the sandbox environment, monitoring its behavior and capturing any relevant data.
# Monitor network activity: Use tools like Wireshark or tcpdump to capture network traffic generated by the malware. Analyze the captured data to understand the communication patterns and potential malicious activities.
# Monitor file system changes: Use file monitoring tools like inotify or Sysmon to track file system modifications made by the malware. This can help identify any files created, modified, or deleted during the execution.
# Analyze process interactions: Use process monitoring tools like Process Monitor or Procmon to monitor the malware’s interactions with other processes on the system. This can provide insights into any suspicious or malicious behavior.
# Capture system calls: Use tools like strace or API monitoring tools to capture system calls made by the malware. This can reveal the underlying functionality and interactions with the operating system.
# The last step should be to aggregate and analyze all captured activity.

Dynamic analysis is very useful when the full behaviour and intent of the malware cannot be inferred from static analysis alone.

Remember to always perform dynamic analysis in a controlled and isolated environment to prevent any unintended consequences or damage to your system.


=== Safely sourcing malware samples ===

It is very important to be careful where you get your malware samples from. To begin with, I can recommend the GitHub repository https://github.com/ytisf/theZoo. It contains a wide selection of live malware samples that can be used for static and dynamic analysis.

It is common practice to download the samples as .zip files. The folders should always be encrypted, usually using the password “infected”.

== References ==

https://www.sans.org/blog/how-you-can-start-learning-malware-analysis/

https://www.bitdefender.com/blog/businessinsights/the-differences-between-static-malware-analysis-and-dynamic-malware-analysis/

[[Category:Documentation]]

Malware Lab: VM Setup and AWS EC2

2024-02-29T11:31:50Z

TNicholson: Created page with "The prerequisites for this guide are that you should have two virtual machine instances running on your hypervisor: * Flare VM (Follow this link for setup instructions:https://wiki.elvis.science/index.php?title=Flare_VM_Installation) * Remnux The idea of this lab setup is to be able to detonate live malware on the Flare VM, while using the Remnux VM to observe network traffic. It is also important that we make sure the network is isolated from our host system. The ways..."

The prerequisites for this guide are that you should have two virtual machine instances running on your hypervisor:

* Flare VM (Follow this link for setup instructions:https://wiki.elvis.science/index.php?title=Flare_VM_Installation)
* Remnux

The idea of this lab setup is to be able to detonate live malware on the Flare VM, while using the Remnux VM to observe network traffic. It is also important that we make sure the network is isolated from our host system. The ways of accomplishing this vary depending on which virtualization software you are using. But you must definitely create a new virtual internal network, and then place both virtual machines inside this network. Make sure it is a Host-Only network (VirtualBox). Note that you will not have internet access within that network - so if you need to download any tools, you may need to temporarily move the VMs to a NAT network, download the tools, and then move them back to the Host-Only network.

In the Remnux VM, we will run inetsim to simulate network services such as DNS. Inetsim can generally impersonate any kind of network service, but we will be using it for DNS.


== Configure Inetsim to impersonate DNS ==

To configure Inetsim to impersonate DNS, follow these steps:

<ol style="list-style-type: decimal;">
<li>Open a terminal in the Remnux VM.</li>
<li>Install Inetsim using the following command in case it is not already installed:
<pre>sudo apt-get install inetsim</pre></li>
<li>Open the Inetsim configuration file using the following command:
<pre> sudo nano /etc/inetsim/inetsim.conf</pre></li>
<li>Find the following line in the configuration file: <code>#start_service dns</code> and remove the comment (#) from the beginning of the line.</li>
<li>Find the following line in the configuration file: <code>service_bind_address</code> and set the IP address to <code>0.0.0.0</code>.</li>
<li>Find the <code>#dns_default_ip</code> line, remove the comment (#) from the beginning of the line, and set the IP address to the IP address of the Remnux VM.</li>
<li>Save the configuration file and exit the text editor.</li>
<li>Start the Inetsim service using the following command:
<pre>sudo systemctl restart inetsim</pre></li></ol>


== Prepare the Flare VM instance ==

In the Flare VM, we will detonate the malware samples and observe the network traffic using Wireshark.


=== Configure Flare VM to use the Remnux VM as the DNS server ===

To configure Flare VM to use the Remnux VM as the DNS server, follow these steps:

# Search for Ethernet settings in the Windows search bar and click on “Change adapter options”.
# Click on the network connection and then click on “Properties”.
# Select “Internet Protocol Version 4 (TCP/IPv4)” and click on “Properties”.
# Set the DNS server to the IP address of the Remnux VM.
# Click “OK” to save the settings.


== Testing the lab environment ==

To test the lab environment, follow these steps:

<ol style="list-style-type: decimal;">
<li>Test ping connectivity between the two VMs.</li>
<li>Run the following command to check if the DNS server is set correctly:
<pre>nslookup google.com</pre>
The output should show the IP address of the Remnux VM as the DNS server.</li>
<li>Run the following command to check if the network traffic is being captured by the Remnux VM:
<pre> ping google.com</pre>
Open Wireshark in the Remnux VM and check if the network traffic is being captured.</li>
<li>Download a malware sample to the Flare VM and detonate it.</li>
<li>Observe the network traffic in Wireshark in the Remnux VM to see if the malware is making any network connections.</li></ol>

IMPORTANT: Once you have it all set up, take a snapshot of the VMs. This way, you can restore the VMs to their original state after running malware samples. This can save you a lot of time and effort in the long run, as you won’t have to reinstall the VMs every time you run a malware sample.


== Automated Deployment of the Lab Environment in the Cloud ==

If you don’t want to host the lab on your own machine, you can choose to deploy the malware lab on Amazon Web Services (AWS) - as shown later on in this article, the deployment process can also be automated using an IaC (Infrastructure-as-Code) approach with Terraform.


=== Prerequisites ===

Before you begin, you will need to have the following:

* An AWS account
* Terraform installed on your local machine (or use Windows Subsystem for Linux (WSL) if you are using Windows)

First, we need to manually recreate the Flare VM on AWS. In the case of AWS, FlareVM is best installed on a base Windows Server image. Be sure to allocate enough storage space for the VMs, especially for the Flare VM. For external access, you will need to use RDP to connect to the Flare VM. You might need to explicitly allow RDP access from any IP. AWS allows you to download the RDP file to connect to the Flare VM. AWS automatically puts a password on the Windows Server, which you can get by decrypting the password using the key pair you created when you launched the instance. Once you have the password, you can connect to the Flare VM using the RDP file.

Once connected to the Flare VM remote desktop, you need to go through the same steps as you would on a local machine to set up the Flare VM. Just use the provided scripts to install the tools and set up the environment.

After setting up Flare VM, you can use AWS to create an AMI (Amazon Machine Image) of the Flare VM. This will allow you to launch new instances of the Flare VM without having to go through the setup process again:

* Select the AWS instance of the Flare VM in the AWS Management Console.
* Click on “Actions” and then “Image and templates” and then “Create image”.
* Give the image a name and description and click “Create image”.

To later be able to launch instances of the AMI using Terraform, you will need to create a new role in AWS:

* Go to the AWS Management Console and search for “IAM”.
* Click on “Users” and then “Add user”.
* Groups: Create a new group and give it a name (e.g. EC-full-access). Under Permissions Policies, select “AmazonEC2FullAccess”.
* Add the user to the group and continue
* Create a Command-Line-Interface (CLI) access key and secret key for the user.

Now, you can continue with the Terraform deployment. For this, switch over to WSL or a Linux machine, as Terraform is not officially supported on Windows.

Update the repository and install Terraform, JQ and AWS-CLI using the following commands:

<pre>sudo apt-get update

sudo apt install jq

# Installation instructions for Terraform can be found here: https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli

sudo apt install awscli</pre>
Configure the AWS IAM user using the following command:

<code>aws configure</code>

Enter the access key, secret key, region (use the specific AWS region your node is deployed in) and output format when prompted.

Create a new directory for the Terraform configuration files and navigate to it:

<pre>mkdir malware-lab
cd malware-lab</pre>
For the Terraform configuration, there is a very useful Git repository that contains a Terraform template for deploying a malware lab on AWS. You can clone the repository using the following command:

<pre>git clone https://github.com/adanalvarez/AWS-malware-lab.git</pre>
It contains a base version of the Terraform configuration for deploying the malware lab on AWS. To specify further details for your deployment, you need to create a new file called “terraform.tfvars” in the malware-lab directory and specify the following variables:

<pre class="hcl">{
"environment": "malware-lab",
"ami": "ami-xxxxxxxxxxxxxxxxx",
"account" : "222222222222",
"region": "eu-west-1",
"enable_guacamole": false,
"enable_inetsim": true
}</pre>
In this case, Guacamole is used to provide remote access to the Flare VM, and Inetsim is used to simulate network services. If you want to enable these features, you can set the “enable_guacamole” and “enable_inetsim” variables to “true”.

Now, you must check which version of Terraform is installed on your machine. You can do this using the following command:

<code>terraform -v</code>

Then, open the main.tf file in the malware-lab directory and change the Terraform version to the version installed on your machine.

In the instances.tf file, you need to change the following:

* In the Linux instance for Inetsim, change the AMI id to a corresponding AMI id for Ubuntu Server 20.04 LTS.

Under <code>network.tf</code>, you also need to change the availability zone to the availability zone of your AWS instance.

Now, you can initialize the Terraform configuration using the following command:

<code>terraform init</code>

Then, you can deploy the malware lab using the following command:

<code>terraform apply</code>

This will deploy the malware lab on AWS. Once the deployment is complete, you can access the Flare VM using the RDP file provided by AWS. You can also access the Remnux VM using SSH.

The Terraform output will provide you with the public IP addresses of the Flare VM. Just like before, you can connect to the EC2 instance via RDP.

To destroy the malware lab, you can use the following command:

<code>terraform destroy</code>

This will destroy all the resources created by Terraform.


== Conclusion ==

In this guide, we have set up a malware lab environment using two virtual machines: Flare VM and Remnux. We have configured Inetsim to impersonate DNS on the Remnux VM and set up the Flare VM to use the Remnux VM as the DNS server. We have also tested the lab environment by observing network traffic using Wireshark. Finally, we have automated the deployment of the lab environment on AWS using Terraform. This lab environment can be used to safely detonate live malware samples and observe their network behavior.

Introduction to Malware Analysis

2024-02-28T13:10:45Z

TNicholson:

If you want to get started learning about malware analysis, this guide is for you. We will first start by setting up suitable environments in which malware can safely be analyzed.

It is very important that when dealing with malware samples, you only download them from trusted sources and only ever unpack them within your VM setup.


== Analysis Enviroments ==

Of course, there are very many different malware analysis environments you can choose from. But for the sake of simplicity, this guide will focus on two fairly well-known software systems: Flare VM and Remnux. The main difference between these two operating systems is that Flare VM runs on Windows and Remnux runs on Ubuntu (Linux). What they have in common is that they offer a wide range of tools that should easily be enough to get you started!

Installing and setting up Remnux is simplified by only having to download the pre-built .ova virtual machine file (https://docs.remnux.org/install-distro/get-virtual-appliance).

There is already a different article about setting up a Windows malware analysis environment. However, I found it way easier to just use the Flare VM scripts to automate the process. Setting up FlareVM is somewhat time-intensive, but I have written a step-by-step guide to help get you started: https://wiki.elvis.science/index.php?title=Flare_VM_Installation. If you prefer using a video as guidance, I can recommend this video: https://www.youtube.com/watch?v=BiSdnusy2AQ&ab_channel=LetsDefend

In a different article it will be described how we can combine FlareVM and Remnux within a single malware lab environment, in which malware can be detonated on the FlareVM and the Remnux machine acts as a fake DNS server using inetsim.

In the end, the type of malware you want to analyze influences which operating system you will use for analysis. Later on throughout this guide, we will also analyze IoT malware, this is practially always malware in an ELF Linux executable format.


== General knowledge about Malware Analysis ==

Before you start setting up your malware analysis lab, make sure you understand the following basic concepts.


=== Static vs. Dynamic Analysis ===

Static analysis deals with extracting data about a malware sample without actually executing it. The main objective is to extract features from the malware that could help us understand what a certain malware does upon execution.

The following steps are important when approaching a malware sample:

* Identifying the file type (Target OS, architecture and format)
* Trying to identify the malware: Hashing the malware file gives it a unique identifier. The hash can be entered into various malware search engines, which attempt to find malware that has an identical hash.
* String extraction: Strings extracted from the binary file can give the malware analyst an idea of what the malware can do.
* (Un)packing and (De)obfuscation: These are techniques used to prevent detection and make it harder to find readable strings. Unpacking and deobfuscating reveals more information about the sample.
* PE headers: Reveal a lot about the functionality of the malware

Dynamic analysis involves executing the malware sample in a controlled environment to observe its behaviour. This type of analysis provides insights into the runtime behavior of the malware, such as network communication, file system modifications, and process interactions. From observing this behaviour, important conclusions can be drawn.

To perform dynamic analysis, follow these steps:

# Set up a suitable sandbox environment: Create a virtual machine to isolate the malware from your host system. Using LXC containers is generally not advisable.
# Execute the malware: Run the malware sample in the sandbox environment, monitoring its behavior and capturing any relevant data.
# Monitor network activity: Use tools like Wireshark or tcpdump to capture network traffic generated by the malware. Analyze the captured data to understand the communication patterns and potential malicious activities.
# Monitor file system changes: Use file monitoring tools like inotify or Sysmon to track file system modifications made by the malware. This can help identify any files created, modified, or deleted during the execution.
# Analyze process interactions: Use process monitoring tools like Process Monitor or Procmon to monitor the malware’s interactions with other processes on the system. This can provide insights into any suspicious or malicious behavior.
# Capture system calls: Use tools like strace or API monitoring tools to capture system calls made by the malware. This can reveal the underlying functionality and interactions with the operating system.
# The last step should be to aggregate and analyze all captured activity.

Dynamic analysis is very useful when the full behaviour and intent of the malware cannot be inferred from static analysis alone.

Remember to always perform dynamic analysis in a controlled and isolated environment to prevent any unintended consequences or damage to your system.


=== Safely sourcing malware samples ===

It is very important to be careful where you get your malware samples from. To begin with, I can recommend the GitHub repository https://github.com/ytisf/theZoo. It contains a wide selection of live malware samples that can be used for static and dynamic analysis.

It is common practice to download the samples as .zip files. The folders should always be encrypted, usually using the password “infected”.

== References ==

https://www.sans.org/blog/how-you-can-start-learning-malware-analysis/

https://www.bitdefender.com/blog/businessinsights/the-differences-between-static-malware-analysis-and-dynamic-malware-analysis/

[[Category:Documentation]]

Introduction to Malware Analysis

2024-02-28T13:06:36Z

TNicholson:

If you want to get started learning about malware analysis, this guide is for you. We will first start by setting up suitable environments in which malware can safely be analyzed.

It is very important that when dealing with malware samples, you only download them from trusted sources and only ever unpack them within your VM setup.


== Analysis Enviroments ==

Of course, there are very many different malware analysis environments you can choose from. But for the sake of simplicity, this guide will focus on two fairly well-known software systems: Flare VM and Remnux. The main difference between these two operating systems is that Flare VM runs on Windows and Remnux runs on Ubuntu (Linux). What they have in common is that they offer a wide range of tools that should easily be enough to get you started!

Installing and setting up Remnux is simplified by only having to download the pre-built .ova virtual machine file (https://docs.remnux.org/install-distro/get-virtual-appliance).

There is already a different article about setting up a Windows malware analysis environment. However, I found it way easier to just use the Flare VM scripts to automate the process. Setting up FlareVM is somewhat time-intensive, but I have written a step-by-step guide to help get you started: https://wiki.elvis.science/index.php?title=Flare_VM_Installation. If you prefer using a video as guidance, I can recommend this video: https://www.youtube.com/watch?v=BiSdnusy2AQ&ab_channel=LetsDefend

In the end, the type of malware you want to analyze influences which operating system you will use for analysis. Later on throughout this guide, we will also analyze IoT malware, this is practially always malware in an ELF Linux executable format.


== General knowledge about Malware Analysis ==

Before you start setting up your malware analysis lab, make sure you understand the following basic concepts.


=== Static vs. Dynamic Analysis ===

Static analysis deals with extracting data about a malware sample without actually executing it. The main objective is to extract features from the malware that could help us understand what a certain malware does upon execution.

The following steps are important when approaching a malware sample:

* Identifying the file type (Target OS, architecture and format)
* Trying to identify the malware: Hashing the malware file gives it a unique identifier. The hash can be entered into various malware search engines, which attempt to find malware that has an identical hash.
* String extraction: Strings extracted from the binary file can give the malware analyst an idea of what the malware can do.
* (Un)packing and (De)obfuscation: These are techniques used to prevent detection and make it harder to find readable strings. Unpacking and deobfuscating reveals more information about the sample.
* PE headers: Reveal a lot about the functionality of the malware

Dynamic analysis involves executing the malware sample in a controlled environment to observe its behaviour. This type of analysis provides insights into the runtime behavior of the malware, such as network communication, file system modifications, and process interactions. From observing this behaviour, important conclusions can be drawn.

To perform dynamic analysis, follow these steps:

# Set up a suitable sandbox environment: Create a virtual machine to isolate the malware from your host system. Using LXC containers is generally not advisable.
# Execute the malware: Run the malware sample in the sandbox environment, monitoring its behavior and capturing any relevant data.
# Monitor network activity: Use tools like Wireshark or tcpdump to capture network traffic generated by the malware. Analyze the captured data to understand the communication patterns and potential malicious activities.
# Monitor file system changes: Use file monitoring tools like inotify or Sysmon to track file system modifications made by the malware. This can help identify any files created, modified, or deleted during the execution.
# Analyze process interactions: Use process monitoring tools like Process Monitor or Procmon to monitor the malware’s interactions with other processes on the system. This can provide insights into any suspicious or malicious behavior.
# Capture system calls: Use tools like strace or API monitoring tools to capture system calls made by the malware. This can reveal the underlying functionality and interactions with the operating system.
# The last step should be to aggregate and analyze all captured activity.

Dynamic analysis is very useful when the full behaviour and intent of the malware cannot be inferred from static analysis alone.

Remember to always perform dynamic analysis in a controlled and isolated environment to prevent any unintended consequences or damage to your system.


=== Safely sourcing malware samples ===

It is very important to be careful where you get your malware samples from. To begin with, I can recommend the GitHub repository https://github.com/ytisf/theZoo. It contains a wide selection of live malware samples that can be used for static and dynamic analysis.

It is common practice to download the samples as .zip files. The folders should always be encrypted, usually using the password “infected”.

== References ==

https://www.sans.org/blog/how-you-can-start-learning-malware-analysis/

https://www.bitdefender.com/blog/businessinsights/the-differences-between-static-malware-analysis-and-dynamic-malware-analysis/

[[Category:Documentation]]

Introduction to Malware Analysis

2024-02-28T13:05:45Z

TNicholson:

If you want to get started learning about malware analysis, this guide is for you. We will first start by setting up suitable environments in which malware can safely be analyzed.

It is very important that when dealing with malware samples, you only download them from trusted sources and only ever unpack them within your VM setup.


== Analysis Enviroments ==

Of course, there are very many different malware analysis environments you can choose from. But for the sake of simplicity, this guide will focus on two fairly well-known software systems: Flare VM and Remnux. The main difference between these two operating systems is that Flare VM runs on Windows and Remnux runs on Ubuntu (Linux). What they have in common is that they offer a wide range of tools that should easily be enough to get you started!

Installing and setting up Remnux is simplified by only having to download the pre-built .ova virtual machine file (https://docs.remnux.org/install-distro/get-virtual-appliance).

There is already a different article about setting up a Windows malware analysis environment. However, I found it way easier to just use the Flare VM scripts to automate the process. Setting up FlareVM is somewhat time-intensive, but I have written a step-by-step guide to help get you started: https://wiki.elvis.science/index.php?title=Flare_VM_Installation. If you prefer using a video as guidance, I can recommend this video: https://www.youtube.com/watch?v=BiSdnusy2AQ&ab_channel=LetsDefend

In the end, the type of malware you want to analyze influences which operating system you will use for analysis. Later on throughout this guide, we will also analyze IoT malware, this is practially always malware in an ELF Linux executable format.


== General knowledge about Malware Analysis ==

Before you start setting up your malware analysis lab, make sure you understand the following basic concepts.


=== Static vs. Dynamic and Hybrid Analysis ===

Static analysis deals with extracting data about a malware sample without actually executing it. The main objective is to extract features from the malware that could help us understand what a certain malware does upon execution.

The following steps are important when approaching a malware sample:

* Identifying the file type (Target OS, architecture and format)
* Trying to identify the malware: Hashing the malware file gives it a unique identifier. The hash can be entered into various malware search engines, which attempt to find malware that has an identical hash.
* String extraction: Strings extracted from the binary file can give the malware analyst an idea of what the malware can do.
* (Un)packing and (De)obfuscation: These are techniques used to prevent detection and make it harder to find readable strings. Unpacking and deobfuscating reveals more information about the sample.
* PE headers: Reveal a lot about the functionality of the malware

Dynamic analysis involves executing the malware sample in a controlled environment to observe its behaviour. This type of analysis provides insights into the runtime behavior of the malware, such as network communication, file system modifications, and process interactions. From observing this behaviour, important conclusions can be drawn.

To perform dynamic analysis, follow these steps:

# Set up a suitable sandbox environment: Create a virtual machine to isolate the malware from your host system. Using LXC containers is generally not advisable.
# Execute the malware: Run the malware sample in the sandbox environment, monitoring its behavior and capturing any relevant data.
# Monitor network activity: Use tools like Wireshark or tcpdump to capture network traffic generated by the malware. Analyze the captured data to understand the communication patterns and potential malicious activities.
# Monitor file system changes: Use file monitoring tools like inotify or Sysmon to track file system modifications made by the malware. This can help identify any files created, modified, or deleted during the execution.
# Analyze process interactions: Use process monitoring tools like Process Monitor or Procmon to monitor the malware’s interactions with other processes on the system. This can provide insights into any suspicious or malicious behavior.
# Capture system calls: Use tools like strace or API monitoring tools to capture system calls made by the malware. This can reveal the underlying functionality and interactions with the operating system.
# The last step should be to aggregate and analyze all captured activity.

Dynamic analysis is very useful when the full behaviour and intent of the malware cannot be inferred from static analysis alone.

Remember to always perform dynamic analysis in a controlled and isolated environment to prevent any unintended consequences or damage to your system.


=== Safely sourcing malware samples ===

It is very important to be careful where you get your malware samples from. To begin with, I can recommend the GitHub repository https://github.com/ytisf/theZoo. It contains a wide selection of live malware samples that can be used for static and dynamic analysis.

It is common practice to download the samples as .zip files. The folders should always be encrypted, usually using the password “infected”.

== References ==

https://www.sans.org/blog/how-you-can-start-learning-malware-analysis/

https://www.bitdefender.com/blog/businessinsights/the-differences-between-static-malware-analysis-and-dynamic-malware-analysis/

[[Category:Documentation]]

Malware Analysis Beginner Guide

2024-02-28T13:05:23Z

TNicholson: TNicholson moved page Malware Analysis Beginner Guide to Introduction to Malware Analysis

#REDIRECT [[Introduction to Malware Analysis]]

Introduction to Malware Analysis

2024-02-28T13:05:23Z

TNicholson: TNicholson moved page Malware Analysis Beginner Guide to Introduction to Malware Analysis

= Introduction to Malware Analysis =

If you want to get started learning about malware analysis, this guide is for you. We will first start by setting up suitable environments in which malware can safely be analyzed.

It is very important that when dealing with malware samples, you only download them from trusted sources and only ever unpack them within your VM setup.


== Analysis Enviroments ==

Of course, there are very many different malware analysis environments you can choose from. But for the sake of simplicity, this guide will focus on two fairly well-known software systems: Flare VM and Remnux. The main difference between these two operating systems is that Flare VM runs on Windows and Remnux runs on Ubuntu (Linux). What they have in common is that they offer a wide range of tools that should easily be enough to get you started!

Installing and setting up Remnux is simplified by only having to download the pre-built .ova virtual machine file (https://docs.remnux.org/install-distro/get-virtual-appliance).

There is already a different article about setting up a Windows malware analysis environment. However, I found it way easier to just use the Flare VM scripts to automate the process. Setting up FlareVM is somewhat time-intensive, but I have written a step-by-step guide to help get you started: https://wiki.elvis.science/index.php?title=Flare_VM_Installation. If you prefer using a video as guidance, I can recommend this video: https://www.youtube.com/watch?v=BiSdnusy2AQ&ab_channel=LetsDefend

In the end, the type of malware you want to analyze influences which operating system you will use for analysis. Later on throughout this guide, we will also analyze IoT malware, this is practially always malware in an ELF Linux executable format.


== General knowledge about Malware Analysis ==

Before you start setting up your malware analysis lab, make sure you understand the following basic concepts.


=== Static vs. Dynamic and Hybrid Analysis ===

Static analysis deals with extracting data about a malware sample without actually executing it. The main objective is to extract features from the malware that could help us understand what a certain malware does upon execution.

The following steps are important when approaching a malware sample:

* Identifying the file type (Target OS, architecture and format)
* Trying to identify the malware: Hashing the malware file gives it a unique identifier. The hash can be entered into various malware search engines, which attempt to find malware that has an identical hash.
* String extraction: Strings extracted from the binary file can give the malware analyst an idea of what the malware can do.
* (Un)packing and (De)obfuscation: These are techniques used to prevent detection and make it harder to find readable strings. Unpacking and deobfuscating reveals more information about the sample.
* PE headers: Reveal a lot about the functionality of the malware

Dynamic analysis involves executing the malware sample in a controlled environment to observe its behaviour. This type of analysis provides insights into the runtime behavior of the malware, such as network communication, file system modifications, and process interactions. From observing this behaviour, important conclusions can be drawn.

To perform dynamic analysis, follow these steps:

# Set up a suitable sandbox environment: Create a virtual machine to isolate the malware from your host system. Using LXC containers is generally not advisable.
# Execute the malware: Run the malware sample in the sandbox environment, monitoring its behavior and capturing any relevant data.
# Monitor network activity: Use tools like Wireshark or tcpdump to capture network traffic generated by the malware. Analyze the captured data to understand the communication patterns and potential malicious activities.
# Monitor file system changes: Use file monitoring tools like inotify or Sysmon to track file system modifications made by the malware. This can help identify any files created, modified, or deleted during the execution.
# Analyze process interactions: Use process monitoring tools like Process Monitor or Procmon to monitor the malware’s interactions with other processes on the system. This can provide insights into any suspicious or malicious behavior.
# Capture system calls: Use tools like strace or API monitoring tools to capture system calls made by the malware. This can reveal the underlying functionality and interactions with the operating system.
# The last step should be to aggregate and analyze all captured activity.

Dynamic analysis is very useful when the full behaviour and intent of the malware cannot be inferred from static analysis alone.

Remember to always perform dynamic analysis in a controlled and isolated environment to prevent any unintended consequences or damage to your system.


=== Safely sourcing malware samples ===

It is very important to be careful where you get your malware samples from. To begin with, I can recommend the GitHub repository https://github.com/ytisf/theZoo. It contains a wide selection of live malware samples that can be used for static and dynamic analysis.

It is common practice to download the samples as .zip files. The folders should always be encrypted, usually using the password “infected”.

== References ==

https://www.sans.org/blog/how-you-can-start-learning-malware-analysis/

https://www.bitdefender.com/blog/businessinsights/the-differences-between-static-malware-analysis-and-dynamic-malware-analysis/

[[Category:Documentation]]

Introduction to Malware Analysis

2024-02-28T13:04:42Z

TNicholson:

Introduction to Malware Analysis

2024-02-28T13:02:35Z

TNicholson: Created page with " = Introduction to Malware Analysis = If you want to get started learning about malware analysis, this guide is for you. We will first start by setting up suitable environments in which malware can safely be analyzed. It is very important that when dealing with malware samples, you only download them from trusted sources and only ever unpack them within your VM setup. == Analysi..."

RowHammer, ThrowHammer and NetHammer attacks

2024-01-08T09:43:10Z

TNicholson:

== Summary ==

In this paper, I presented and compared the different attacks about RowHammer, ThrowHammer and NetHammer but the special focus was lying on the RowHammer attack because this attack is the basis of the other attacks. Firstly, I gave an overview about the Internet, personal computers on households and how the technology developed year by year in order to bring a better feeling of understanding about todays capabilities and possibilities. Subsequently I demonstrated some details about the RAM, DRAM and also explained for what they will be used because these components are very important components of machines like computer. They are very affected by those attacks. Furthermore I described the attacks beginning by the RowHammer attack and how it works and what it uses in order to make the attack happen.
== Dynamic Random Access Memory - DRAM ==

The DRAM is the easiest, slowest and cheapest memory type. Those kind of chips will be used in the todays RAM. Mostly the SDRAM type will be used. To stick on the facts from above, we will now look at how a DRAM look like. The figure shows the main structure of a DRAM memory cell component. It consist of a transistor, which works as a switch and a capacitor, which is the actual memory component. The capacitor is a component which can save an electric charge for a certain amount of time, it depends on the capacitor how long it can hold an electric charge. To fully charge or uncharge a capacitor it needs 5 * T (Tau) to either charge or uncharge it.
 
 
'''t = 5 ∗ T = 5 ∗ R ∗ C (2.1)'''
 
 
The formula to calculate the time when a capacitor will be fully charged or uncharged is showed on 2.1 where R is the resistor and C is the capacitor. In the DRAM memory cell a bit will be saved by charging the capacitor. Reading and writing happens through the transistor which functions as a switch. The transistor decides when to close the connection between capacitor and bitline and when to open it, so no information can flow to the bitline. Through the wordline the transistor can be controlled. Every gate of the transistor is connected to a wordline and each of this wordlines controls the access to the whole row. The cells of a DRAM are organized in arrays as described before. Each of those arrays are also called bank. A DRAM chip usually has 8 banks. Over time the charge will get lost and the data in the cell will also be lost. When a cell starts losing its data until it loses it completely the time in between is also called the data retention time. In order to not lose data fast and keep the data for a longer time each wordline of each row has to be accessed periodically, so in a specific interval of time, to charge the capacitors of that row through the bitlines. This process is called the "DRAM refresh". Every DRAM row needs to be refreshed within a certain frequency, which is usually 32 to 64 ms (Milliseconds) in the current DRAMs in order to ensure data integrity.

[[File:dram.png|thumb|none|300px|Source: Author]]
== Requirements for RowHammer attack ==

* Have access to local computer
* Access to memory must not be cached - otherwise, the DRAM is never reached
* Memory access must be very fast (race against the refresh time)
* Memory access must be performed in a very targeted way - only specific combinations of proximate row access may cause bit flips
* This cause bit flips on adjacent rows

== Requirements for ThrowHammer attack ==

* This is a remote attack
* Both attacker and victim computers have to enable RDMA on the NIC
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim
* RDMA does write the data directly on the victim application instead on a buffer in-between
* This causes bit flips on DRAM cell rows

== Requirements for NetHammer attack ==

* This is a remote attack
* This attack does neither need an executable code or RDMA enabled NICs
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim, for example UDP packets with minimum packet size of 64 bytes
* It does not directly cause bit flips on the cells but instead it keeps reopening rows permanently which can cause bit flips

== Description ==

=== RowHammer ===

The memory isolation is in general a key property of a reliable and secure computer or computing system. In normal circumstances an access to a memory address should not be that hard and it should definitely not have any side effects on data that is stored in other adjacent addresses. However, year for year the manufacturers tries to place more chips on the computer in order to gain more computing power and introduce new performance statistics to the end customer. In order to place more chips they have to make the chips smaller year for year. That means, those memory chips become much more vulnerable to disturbance. A disturbance is a phenomenon in which different memory cells interfere with each others operation. The whole problem and in the same time the key attack about this RowHammer topic is that repeatedly reading from the same memory address in DRAM could change data in adjacent memory addresses. In this addresses we talk about bits, so it could be for example that if a process A wants to access the memory address 2 several times in a row that some bits from the memory address 1 and 3 could change from one to zero or from zero to one, so it could flip. One bit change could manipulate the data that a memory address holds completely, so the data would be corrupt or would mean something completely different which is obviously not the sense of what DRAM should do or in general what the user of the computer at least expects. In specific, when a DRAM row is opened, so it is activated, and closed rapidly and repeatedly enough times within a DRAM refresh interval, one or more bits in physically adjacent DRAM rows can be flipped to the wrong value as described before. The repeating activating and closing a DRAM row is called hammering and this process as a whole is called RowHammer.

=== Possible Solutions against RowHammer attacks ===

Manufacturing better DRAM chips
* That means it is a must requirement for the major manufacturers to create and develop much better and secure DRAM chips then before. This includes that those chips should not be vulnerable to those easy attacks anymore.

Error correction codes
* Using strong error correction codes (ECC) would improve and help to correct errors that are coming from RowHammer attacks.

Refresh rate
* The increasing of the refresh rate for all of the memory would increase the milliseconds of the refresh time so it would be faster. The cell would get refreshed much faster. So the bits will be refreshed again and the cell has again the correct data instead of the manipulated ones.

Remapping/Retiring statically
* A statically remapping or retiring of RowHammer affected cells via a one time post-manufacturing analysis would decrease the probability of an upcoming RowHammer attack.

Remapping/Retiring dynamically
* A dynamically remapping or retiring of RowHammer affected cells during the system opera- tion would decrease the probability of an upcoming RowHammer attacks much more.

Identifying hammered rows
* Exactly identifying hammered rows during runtime and refreshing their adjacent rows. But all of those solutions are coming with performance, power or cost overheads.

=== Remote Direct Memory Access - RDMA ===

RDMA is technology that allows computers in a network to exchange data directly from the RAM without involving the CPU or the operating system of both communication partner computers. With this, it is possible to move data from and into a server by implementing a transport protocol into the hardware of the network interface card. This technology provides a function called "Zero-Copy-Networking" which enables to read data directly from a RAM of a computer and write the fetched data to the RAM of another computer in another network. RDMA provides a much faster data transferring time and a network with less latency. When both sender computer and receiver computer supports RDMA then the conversation will be executed faster than transferring the data when one of them does not support RDMA. Figure shows a conversation with an RDMA connection.

[[File:rdma.png|thumb|none|600px|Source: Author]]

=== ThrowHammer ===

So the ThrowHammer attack is nothing else then a remotely used RowHammer attack where the attacker focuses on systems that are using RDMA. When the system wants to send a packet to another network then usually the CPU has to do some work. The CPU has to take the data from the client application and saves it to a direct memory access (DMA) buffer in the kernel space. Then the network interface card (NIC) takes this saved data from the DMA and sends it to the other network, to be more precise it will be send to the NIC of the other network. The target network then continues to copy the data to the DMA buffer and subsequently the CPU takes the data and provides it to the target client application. This is the general process of a non-RDMA system. With RDMA the CPU is not involved in this process, there is no need for it. So the client application sends directly the data to its own NIC and the NIC sends it further to the target NIC of the target network. When the target NIC gets the data it will be directly provided for the client application like showed in the figure.

[[File:non-rdma.png|thumb|none|600px|Source: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf]]

In order to transfer packets efficiently ThrowHammer makes use of RDMA capabilities. Sending packets rapidly and frequently over a high speed network may cause bit flips on the target system because of RDMA.

=== NetHammer ===

The NetHammer attack is actually a RowHammer attack which is neither relying on any attacker controlled code on the victim computer or RDMA enabled network cards. So it does not require local code execution. It only needs a fast network connection between the attacker and the victim. This attack sends a crafted stream of small network packets to the target computer a one-location or single-sided RowHammer attack. Single-sided hammering is when accessing 8 randomly chosen memory locations simultaneously and there the probability is high that at least 2 out of 8 random memory locations will be mapped into the same out of 32 DRAM banks on DDR3. DDR3 is Double Data Rates 3 which is a SDRAM type. One-location hammering is when only accessing one single location at a high frequency. In this access pattern the attacker does not directly cause row conflicts but instead it keeps re-opening one row permanently. Each packet that is received on the target device, a set of addresses is accessed for example in a user-space application processing the contents, in the kernel driver, somewhere in between or a combination of all. So when sending packets rapidly and repeatedly, those set of addresses are hammered and therefore bit flips can occur. So to make remotely bit flips happen it is needed to send as many packets as possible, as fast as possible and in a short time frame over a the network. For example, UDP (User Datagram Protocol) packets without any specific content can be used for this attack. On those UDP packets it should be allowed to have an overall packet size of 64 B (Byte) which is the minimum packet size for an Ethernet packet. Ethernet has also a maximum frame size of 1518 B. With this it is possible to send up to 1 024 000 packets per second over a 500 Mbit per second connection.

=== Flip Feng Shui ===

Flip Feng Shui is a highly advanced implementation of Rowhammer capable of flipping bits in a controlled way anywhere in the software. Memory deduplication allows attackers to map a physical page onto a virtual page they own, as long as the page content is known. Rowhammer is then used to flip bits in locations of the target page. The developers of this technique managed to compromise the public RSA keys in the OpenSSH authorized_keys file, making them easier to factorize. They were then able to generate a private key and logged into the server.

Using the same techniques, they also flipped bits in the sources.list file, changing ubuntu.com to e.g. ubunvu.com (one bit flip away from the legitimate domain). The researchers registered these domains and served a malicious package update from it. By additionally manipulating the trusted.gpg file, they tricked the victim VM into verifying and installing a malicious update.

=== DRAMA and Rowhammer.js ===

Researchers from the TU Graz have published two very helpful tools which anyone can use to check if their computer is vulnerable to Rowhammer - more specifically, Rowhammer based on the cache eviction technique. The tools run on Linux Intel Ivybridge, Haswell or Skylake systems. It will only work against DDR3 DRAM.

Here is a demo of both tools provided by the authors: https://www.youtube.com/watch?v=X8-X_52rg80&ab_channel=DanielGruss

* DRAMA (https://github.com/IAIK/drama)
This tool is used to reverse-engineer the DRAM mappings - this is required so that specific rows can be targeted easily.

* git clone https://github.com/IAIK/drama
* cd drama/re
* make
* taskset 0x4 sudo ./measure -p 0.75 -s 16 (allocate 75% of DRAM for measurement, expect 16 sets) - After some time - this will output the most likely DRAM mappings

* Rowhammer.js (https://github.com/IAIK/rowhammerjs)
The "native" folder of this repository contains the source code for a simple Rowhammer attack. The code can be compiled for Haswell, Skylake and Ivybridge architectures. But first, the DRAM mappings from the DRAMA tool need to written into the source code. This way, the correct rows are hammered. If any bit flips are found, they will be output in the console.

* git clone https://github.com/IAIK/rowhammerjs
* cd rowhammerjs/native
* nano rowhammer.cc and insert the DRAM mappings for your specific architecture (see image)
* make rowhammer-ivy (for Ivybridge systems, adapt this command to your own architecture)
* ./rowhammer-ivy -d 2 -f 0 (two dimms, hammer only offset zero to increase attack speed)

== Used Hardware ==

[[HP Pavilion Desktop PC with DDR3 RAM and Ivy-Bridge architecture]]

== References ==

* T. Alsop, “How many people have access to a computer 2019,” Feb 2021. [Online]. Available: https://www.statista.com/statistics/748551/ worldwide-households-with-computer/
* W. b. C. Stouffer, “115 cybersecurity statistics and trends you need to know in 2021.” [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-cyberthreat-trends-cybersecurity-threat-review.html
* A. Schaller, W. Xiong, N. A. Anagnostopoulos, M. U. Saleem, S. Gabmeyer, S. Katzen- beisser, and J. Szefer, “Intrinsic rowhammer pufs: Leveraging the rowhammer effect for improved security,” 2017 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2017.
* O. Mutlu and J. S. Kim, “Rowhammer: A retrospective,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 8, p. 1555–1571, 2020.
* M. C.-T. Chao, H.-Y. Yang, R.-F. Huang, S.-C. Lin, and C.-Y. Chin, “Fault models for embedded-dram macros,” Proceedings of the 46th Annual Design Automation Conference on ZZZ - DAC 09, 2009.
* R.-F. Huang, H.-Y. Yang, M. C.-T. Chao, and S.-C. Lin, “Alternate hammering test for application-specific drams and an industrial case study,” Proceedings of the 49th Annual Design Automation Conference on - DAC 12, 2012.
* P. C.-F. Chia, S.-J. Wen, and S. H. Baeg, “New dram hci qualification method em- phasizing on repeated memory access,” 2010 IEEE International Integrated Reliability Workshop Final Report, 2010.
* M. Seaborn and T. Dullien., Jan 1970. [Online]. Available: https://googleprojectzero. blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
* “throwhammer: rowhammer attacks over the network and defenses.” [Online]. Available: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf
* M. Lipp, M. Schwarz, L. Raab, L. Lamster, M. T. Aga, C. Maurice, and D. Gruss, “Nethammer: Inducing rowhammer faults through network requests,” 2020 IEEE Eu- ropean Symposium on Security and Privacy Workshops, 2020.

[[Category:Basic]]

RowHammer, ThrowHammer and NetHammer attacks

2024-01-08T09:37:32Z

TNicholson:

== Summary ==

In this paper, I presented and compared the different attacks about RowHammer, ThrowHammer and NetHammer but the special focus was lying on the RowHammer attack because this attack is the basis of the other attacks. Firstly, I gave an overview about the Internet, personal computers on households and how the technology developed year by year in order to bring a better feeling of understanding about todays capabilities and possibilities. Subsequently I demonstrated some details about the RAM, DRAM and also explained for what they will be used because these components are very important components of machines like computer. They are very affected by those attacks. Furthermore I described the attacks beginning by the RowHammer attack and how it works and what it uses in order to make the attack happen.

== Requirements for RowHammer attack ==

* Have access to local computer
* Access to memory must not be cached - otherwise, the DRAM is never reached
* Memory access must be very fast (race against the refresh time)
* Memory access must be performed in a very targeted way - only specific combinations of proximate row access may cause bit flips
* This cause bit flips on adjacent rows

== Requirements for ThrowHammer attack ==

* This is a remote attack
* Both attacker and victim computers have to enable RDMA on the NIC
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim
* RDMA does write the data directly on the victim application instead on a buffer in-between
* This causes bit flips on DRAM cell rows

== Requirements for NetHammer attack ==

* This is a remote attack
* This attack does neither need an executable code or RDMA enabled NICs
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim, for example UDP packets with minimum packet size of 64 bytes
* It does not directly cause bit flips on the cells but instead it keeps reopening rows permanently which can cause bit flips

== Description ==

=== Dynamic Random Access Memory - DRAM ===

The DRAM is the easiest, slowest and cheapest memory type. Those kind of chips will be used in the todays RAM. Mostly the SDRAM type will be used. To stick on the facts from above, we will now look at how a DRAM look like. The figure shows the main structure of a DRAM memory cell component. It consist of a transistor, which works as a switch and a capacitor, which is the actual memory component. The capacitor is a component which can save an electric charge for a certain amount of time, it depends on the capacitor how long it can hold an electric charge. To fully charge or uncharge a capacitor it needs 5 * T (Tau) to either charge or uncharge it.
 
 
'''t = 5 ∗ T = 5 ∗ R ∗ C (2.1)'''
 
 
The formula to calculate the time when a capacitor will be fully charged or uncharged is showed on 2.1 where R is the resistor and C is the capacitor. In the DRAM memory cell a bit will be saved by charging the capacitor. Reading and writing happens through the transistor which functions as a switch. The transistor decides when to close the connection between capacitor and bitline and when to open it, so no information can flow to the bitline. Through the wordline the transistor can be controlled. Every gate of the transistor is connected to a wordline and each of this wordlines controls the access to the whole row. The cells of a DRAM are organized in arrays as described before. Each of those arrays are also called bank. A DRAM chip usually has 8 banks. Over time the charge will get lost and the data in the cell will also be lost. When a cell starts losing its data until it loses it completely the time in between is also called the data retention time. In order to not lose data fast and keep the data for a longer time each wordline of each row has to be accessed periodically, so in a specific interval of time, to charge the capacitors of that row through the bitlines. This process is called the "DRAM refresh". Every DRAM row needs to be refreshed within a certain frequency, which is usually 32 to 64 ms (Milliseconds) in the current DRAMs in order to ensure data integrity.

[[File:dram.png|thumb|none|300px|Source: Author]]

=== RowHammer ===

The memory isolation is in general a key property of a reliable and secure computer or computing system. In normal circumstances an access to a memory address should not be that hard and it should definitely not have any side effects on data that is stored in other adjacent addresses. However, year for year the manufacturers tries to place more chips on the computer in order to gain more computing power and introduce new performance statistics to the end customer. In order to place more chips they have to make the chips smaller year for year. That means, those memory chips become much more vulnerable to disturbance. A disturbance is a phenomenon in which different memory cells interfere with each others operation. The whole problem and in the same time the key attack about this RowHammer topic is that repeatedly reading from the same memory address in DRAM could change data in adjacent memory addresses. In this addresses we talk about bits, so it could be for example that if a process A wants to access the memory address 2 several times in a row that some bits from the memory address 1 and 3 could change from one to zero or from zero to one, so it could flip. One bit change could manipulate the data that a memory address holds completely, so the data would be corrupt or would mean something completely different which is obviously not the sense of what DRAM should do or in general what the user of the computer at least expects. In specific, when a DRAM row is opened, so it is activated, and closed rapidly and repeatedly enough times within a DRAM refresh interval, one or more bits in physically adjacent DRAM rows can be flipped to the wrong value as described before. The repeating activating and closing a DRAM row is called hammering and this process as a whole is called RowHammer.

=== Possible Solutions against RowHammer attacks ===

Manufacturing better DRAM chips
* That means it is a must requirement for the major manufacturers to create and develop much better and secure DRAM chips then before. This includes that those chips should not be vulnerable to those easy attacks anymore.

Error correction codes
* Using strong error correction codes (ECC) would improve and help to correct errors that are coming from RowHammer attacks.

Refresh rate
* The increasing of the refresh rate for all of the memory would increase the milliseconds of the refresh time so it would be faster. The cell would get refreshed much faster. So the bits will be refreshed again and the cell has again the correct data instead of the manipulated ones.

Remapping/Retiring statically
* A statically remapping or retiring of RowHammer affected cells via a one time post-manufacturing analysis would decrease the probability of an upcoming RowHammer attack.

Remapping/Retiring dynamically
* A dynamically remapping or retiring of RowHammer affected cells during the system opera- tion would decrease the probability of an upcoming RowHammer attacks much more.

Identifying hammered rows
* Exactly identifying hammered rows during runtime and refreshing their adjacent rows. But all of those solutions are coming with performance, power or cost overheads.

=== Remote Direct Memory Access - RDMA ===

RDMA is technology that allows computers in a network to exchange data directly from the RAM without involving the CPU or the operating system of both communication partner computers. With this, it is possible to move data from and into a server by implementing a transport protocol into the hardware of the network interface card. This technology provides a function called "Zero-Copy-Networking" which enables to read data directly from a RAM of a computer and write the fetched data to the RAM of another computer in another network. RDMA provides a much faster data transferring time and a network with less latency. When both sender computer and receiver computer supports RDMA then the conversation will be executed faster than transferring the data when one of them does not support RDMA. Figure shows a conversation with an RDMA connection.

[[File:rdma.png|thumb|none|600px|Source: Author]]

=== ThrowHammer ===

So the ThrowHammer attack is nothing else then a remotely used RowHammer attack where the attacker focuses on systems that are using RDMA. When the system wants to send a packet to another network then usually the CPU has to do some work. The CPU has to take the data from the client application and saves it to a direct memory access (DMA) buffer in the kernel space. Then the network interface card (NIC) takes this saved data from the DMA and sends it to the other network, to be more precise it will be send to the NIC of the other network. The target network then continues to copy the data to the DMA buffer and subsequently the CPU takes the data and provides it to the target client application. This is the general process of a non-RDMA system. With RDMA the CPU is not involved in this process, there is no need for it. So the client application sends directly the data to its own NIC and the NIC sends it further to the target NIC of the target network. When the target NIC gets the data it will be directly provided for the client application like showed in the figure.

[[File:non-rdma.png|thumb|none|600px|Source: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf]]

In order to transfer packets efficiently ThrowHammer makes use of RDMA capabilities. Sending packets rapidly and frequently over a high speed network may cause bit flips on the target system because of RDMA.

=== NetHammer ===

The NetHammer attack is actually a RowHammer attack which is neither relying on any attacker controlled code on the victim computer or RDMA enabled network cards. So it does not require local code execution. It only needs a fast network connection between the attacker and the victim. This attack sends a crafted stream of small network packets to the target computer a one-location or single-sided RowHammer attack. Single-sided hammering is when accessing 8 randomly chosen memory locations simultaneously and there the probability is high that at least 2 out of 8 random memory locations will be mapped into the same out of 32 DRAM banks on DDR3. DDR3 is Double Data Rates 3 which is a SDRAM type. One-location hammering is when only accessing one single location at a high frequency. In this access pattern the attacker does not directly cause row conflicts but instead it keeps re-opening one row permanently. Each packet that is received on the target device, a set of addresses is accessed for example in a user-space application processing the contents, in the kernel driver, somewhere in between or a combination of all. So when sending packets rapidly and repeatedly, those set of addresses are hammered and therefore bit flips can occur. So to make remotely bit flips happen it is needed to send as many packets as possible, as fast as possible and in a short time frame over a the network. For example, UDP (User Datagram Protocol) packets without any specific content can be used for this attack. On those UDP packets it should be allowed to have an overall packet size of 64 B (Byte) which is the minimum packet size for an Ethernet packet. Ethernet has also a maximum frame size of 1518 B. With this it is possible to send up to 1 024 000 packets per second over a 500 Mbit per second connection.

=== Flip Feng Shui ===

Flip Feng Shui is a highly advanced implementation of Rowhammer capable of flipping bits in a controlled way anywhere in the software. Memory deduplication allows attackers to map a physical page onto a virtual page they own, as long as the page content is known. Rowhammer is then used to flip bits in locations of the target page. The developers of this technique managed to compromise the public RSA keys in the OpenSSH authorized_keys file, making them easier to factorize. They were then able to generate a private key and logged into the server.

Using the same techniques, they also flipped bits in the sources.list file, changing ubuntu.com to e.g. ubunvu.com (one bit flip away from the legitimate domain). The researchers registered these domains and served a malicious package update from it. By additionally manipulating the trusted.gpg file, they tricked the victim VM into verifying and installing a malicious update.

=== DRAMA and Rowhammer.js ===

Researchers from the TU Graz have published two very helpful tools which anyone can use to check if their computer is vulnerable to Rowhammer - more specifically, Rowhammer based on the cache eviction technique. The tools run on Linux Intel Ivybridge, Haswell or Skylake systems. It will only work against DDR3 DRAM.

Here is a demo of both tools provided by the authors: https://www.youtube.com/watch?v=X8-X_52rg80&ab_channel=DanielGruss

* DRAMA (https://github.com/IAIK/drama)
This tool is used to reverse-engineer the DRAM mappings - this is required so that specific rows can be targeted easily.

* git clone https://github.com/IAIK/drama
* cd drama/re
* make
* taskset 0x4 sudo ./measure -p 0.75 -s 16 (allocate 75% of DRAM for measurement, expect 16 sets) - After some time - this will output the most likely DRAM mappings

* Rowhammer.js (https://github.com/IAIK/rowhammerjs)
The "native" folder of this repository contains the source code for a simple Rowhammer attack. The code can be compiled for Haswell, Skylake and Ivybridge architectures. But first, the DRAM mappings from the DRAMA tool need to written into the source code. This way, the correct rows are hammered. If any bit flips are found, they will be output in the console.

* git clone https://github.com/IAIK/rowhammerjs
* cd rowhammerjs/native
* nano rowhammer.cc and insert the DRAM mappings for your specific architecture (see image)
* make rowhammer-ivy (for Ivybridge systems, adapt this command to your own architecture)
* ./rowhammer-ivy -d 2 -f 0 (two dimms, hammer only offset zero to increase attack speed)

== Used Hardware ==

[[HP Pavilion Desktop PC with DDR3 RAM and Ivy-Bridge architecture]]

== References ==

* T. Alsop, “How many people have access to a computer 2019,” Feb 2021. [Online]. Available: https://www.statista.com/statistics/748551/ worldwide-households-with-computer/
* W. b. C. Stouffer, “115 cybersecurity statistics and trends you need to know in 2021.” [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-cyberthreat-trends-cybersecurity-threat-review.html
* A. Schaller, W. Xiong, N. A. Anagnostopoulos, M. U. Saleem, S. Gabmeyer, S. Katzen- beisser, and J. Szefer, “Intrinsic rowhammer pufs: Leveraging the rowhammer effect for improved security,” 2017 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2017.
* O. Mutlu and J. S. Kim, “Rowhammer: A retrospective,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 8, p. 1555–1571, 2020.
* M. C.-T. Chao, H.-Y. Yang, R.-F. Huang, S.-C. Lin, and C.-Y. Chin, “Fault models for embedded-dram macros,” Proceedings of the 46th Annual Design Automation Conference on ZZZ - DAC 09, 2009.
* R.-F. Huang, H.-Y. Yang, M. C.-T. Chao, and S.-C. Lin, “Alternate hammering test for application-specific drams and an industrial case study,” Proceedings of the 49th Annual Design Automation Conference on - DAC 12, 2012.
* P. C.-F. Chia, S.-J. Wen, and S. H. Baeg, “New dram hci qualification method em- phasizing on repeated memory access,” 2010 IEEE International Integrated Reliability Workshop Final Report, 2010.
* M. Seaborn and T. Dullien., Jan 1970. [Online]. Available: https://googleprojectzero. blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
* “throwhammer: rowhammer attacks over the network and defenses.” [Online]. Available: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf
* M. Lipp, M. Schwarz, L. Raab, L. Lamster, M. T. Aga, C. Maurice, and D. Gruss, “Nethammer: Inducing rowhammer faults through network requests,” 2020 IEEE Eu- ropean Symposium on Security and Privacy Workshops, 2020.

[[Category:Basic]]

RowHammer, ThrowHammer and NetHammer attacks

2024-01-08T09:34:59Z

TNicholson:

== Summary ==

In this paper, I presented and compared the different attacks about RowHammer, ThrowHammer and NetHammer but the special focus was lying on the RowHammer attack because this attack is the basis of the other attacks. Firstly, I gave an overview about the Internet, personal computers on households and how the technology developed year by year in order to bring a better feeling of understanding about todays capabilities and possibilities. Subsequently I demonstrated some details about the RAM, DRAM and also explained for what they will be used because these components are very important components of machines like computer. They are very affected by those attacks. Furthermore I described the attacks beginning by the RowHammer attack and how it works and what it uses in order to make the attack happen.

== Requirements for RowHammer attack ==

* Have access to local computer
* Access to memory must not be cached - otherwise, the DRAM is never reached
* Memory access must be very fast (race against the refresh time)
* Memory access must be performed in a very targeted way - only specific combinations of proximate row access may cause bit flips
* This cause bit flips on adjacent rows

== Requirements for ThrowHammer attack ==

* This is a remote attack
* Both attacker and victim computers have to enable RDMA on the NIC
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim
* RDMA does write the data directly on the victim application instead on a buffer in-between
* This causes bit flips on DRAM cell rows

== Requirements for NetHammer attack ==

* This is a remote attack
* This attack does neither need an executable code or RDMA enabled NICs
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim, for example UDP packets with minimum packet size of 64 bytes
* It does not directly cause bit flips on the cells but instead it keeps reopening rows permanently which can cause bit flips

== Description ==

=== Dynamic Random Access Memory - DRAM ===

The DRAM is the easiest, slowest and cheapest memory type. Those kind of chips will be used in the todays RAM. Mostly the SDRAM type will be used. To stick on the facts from above, we will now look at how a DRAM look like. The figure shows the main structure of a DRAM memory cell component. It consist of a transistor, which works as a switch and a capacitor, which is the actual memory component. The capacitor is a component which can save an electric charge for a certain amount of time, it depends on the capacitor how long it can hold an electric charge. To fully charge or uncharge a capacitor it needs 5 * T (Tau) to either charge or uncharge it.
 
 
'''t = 5 ∗ T = 5 ∗ R ∗ C (2.1)'''
 
 
The formula to calculate the time when a capacitor will be fully charged or uncharged is showed on 2.1 where R is the resistor and C is the capacitor. In the DRAM memory cell a bit will be saved by charging the capacitor. Reading and writing happens through the transistor which functions as a switch. The transistor decides when to close the connection between capacitor and bitline and when to open it, so no information can flow to the bitline. Through the wordline the transistor can be controlled. Every gate of the transistor is connected to a wordline and each of this wordlines controls the access to the whole row. The cells of a DRAM are organized in arrays as described before. Each of those arrays are also called bank. A DRAM chip usually has 8 banks. Over time the charge will get lost and the data in the cell will also be lost. When a cell starts losing its data until it loses it completely the time in between is also called the data retention time. In order to not lose data fast and keep the data for a longer time each wordline of each row has to be accessed periodically, so in a specific interval of time, to charge the capacitors of that row through the bitlines. This process is called the "DRAM refresh". Every DRAM row needs to be refreshed within a certain frequency, which is usually 32 to 64 ms (Milliseconds) in the current DRAMs in order to ensure data integrity.

[[File:dram.png|thumb|none|300px|Source: Author]]

=== RowHammer ===

The memory isolation is in general a key property of a reliable and secure computer or computing system. In normal circumstances an access to a memory address should not be that hard and it should definitely not have any side effects on data that is stored in other adjacent addresses. However, year for year the manufacturers tries to place more chips on the computer in order to gain more computing power and introduce new performance statistics to the end customer. In order to place more chips they have to make the chips smaller year for year. That means, those memory chips become much more vulnerable to disturbance. A disturbance is a phenomenon in which different memory cells interfere with each others operation. The whole problem and in the same time the key attack about this RowHammer topic is that repeatedly reading from the same memory address in DRAM could change data in adjacent memory addresses. In this addresses we talk about bits, so it could be for example that if a process A wants to access the memory address 2 several times in a row that some bits from the memory address 1 and 3 could change from one to zero or from zero to one, so it could flip. One bit change could manipulate the data that a memory address holds completely, so the data would be corrupt or would mean something completely different which is obviously not the sense of what DRAM should do or in general what the user of the computer at least expects. In specific, when a DRAM row is opened, so it is activated, and closed rapidly and repeatedly enough times within a DRAM refresh interval, one or more bits in physically adjacent DRAM rows can be flipped to the wrong value as described before. The repeating activating and closing a DRAM row is called hammering and this process as a whole is called RowHammer.

=== Possible Solutions against RowHammer attacks ===

Manufacturing better DRAM chips
* That means it is a must requirement for the major manufacturers to create and develop much better and secure DRAM chips then before. This includes that those chips should not be vulnerable to those easy attacks anymore.

Error correction codes
* Using strong error correction codes (ECC) would improve and help to correct errors that are coming from RowHammer attacks.

Refresh rate
* The increasing of the refresh rate for all of the memory would increase the milliseconds of the refresh time so it would be faster. The cell would get refreshed much faster. So the bits will be refreshed again and the cell has again the correct data instead of the manipulated ones.

Remapping/Retiring statically
* A statically remapping or retiring of RowHammer affected cells via a one time post-manufacturing analysis would decrease the probability of an upcoming RowHammer attack.

Remapping/Retiring dynamically
* A dynamically remapping or retiring of RowHammer affected cells during the system opera- tion would decrease the probability of an upcoming RowHammer attacks much more.

Identifying hammered rows
* Exactly identifying hammered rows during runtime and refreshing their adjacent rows. But all of those solutions are coming with performance, power or cost overheads.

=== Remote Direct Memory Access - RDMA ===

RDMA is technology that allows computers in a network to exchange data directly from the RAM without involving the CPU or the operating system of both communication partner computers. With this, it is possible to move data from and into a server by implementing a transport protocol into the hardware of the network interface card. This technology provides a function called "Zero-Copy-Networking" which enables to read data directly from a RAM of a computer and write the fetched data to the RAM of another computer in another network. RDMA provides a much faster data transferring time and a network with less latency. When both sender computer and receiver computer supports RDMA then the conversation will be executed faster than transferring the data when one of them does not support RDMA. Figure shows a conversation with an RDMA connection.

[[File:rdma.png|thumb|none|600px|Source: Author]]

=== ThrowHammer ===

So the ThrowHammer attack is nothing else then a remotely used RowHammer attack where the attacker focuses on systems that are using RDMA. When the system wants to send a packet to another network then usually the CPU has to do some work. The CPU has to take the data from the client application and saves it to a direct memory access (DMA) buffer in the kernel space. Then the network interface card (NIC) takes this saved data from the DMA and sends it to the other network, to be more precise it will be send to the NIC of the other network. The target network then continues to copy the data to the DMA buffer and subsequently the CPU takes the data and provides it to the target client application. This is the general process of a non-RDMA system. With RDMA the CPU is not involved in this process, there is no need for it. So the client application sends directly the data to its own NIC and the NIC sends it further to the target NIC of the target network. When the target NIC gets the data it will be directly provided for the client application like showed in the figure.

[[File:non-rdma.png|thumb|none|600px|Source: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf]]

In order to transfer packets efficiently ThrowHammer makes use of RDMA capabilities. Sending packets rapidly and frequently over a high speed network may cause bit flips on the target system because of RDMA.

=== NetHammer ===

The NetHammer attack is actually a RowHammer attack which is neither relying on any attacker controlled code on the victim computer or RDMA enabled network cards. So it does not require local code execution. It only needs a fast network connection between the attacker and the victim. This attack sends a crafted stream of small network packets to the target computer a one-location or single-sided RowHammer attack. Single-sided hammering is when accessing 8 randomly chosen memory locations simultaneously and there the probability is high that at least 2 out of 8 random memory locations will be mapped into the same out of 32 DRAM banks on DDR3. DDR3 is Double Data Rates 3 which is a SDRAM type. One-location hammering is when only accessing one single location at a high frequency. In this access pattern the attacker does not directly cause row conflicts but instead it keeps re-opening one row permanently. Each packet that is received on the target device, a set of addresses is accessed for example in a user-space application processing the contents, in the kernel driver, somewhere in between or a combination of all. So when sending packets rapidly and repeatedly, those set of addresses are hammered and therefore bit flips can occur. So to make remotely bit flips happen it is needed to send as many packets as possible, as fast as possible and in a short time frame over a the network. For example, UDP (User Datagram Protocol) packets without any specific content can be used for this attack. On those UDP packets it should be allowed to have an overall packet size of 64 B (Byte) which is the minimum packet size for an Ethernet packet. Ethernet has also a maximum frame size of 1518 B. With this it is possible to send up to 1 024 000 packets per second over a 500 Mbit per second connection.

=== Flip Feng Shui ===

Flip Feng Shui is a highly advanced implementation of Rowhammer capable of flipping bits in a controlled way anywhere in the software. Memory deduplication allows attackers to map a physical page onto a virtual page they own, as long as the page content is known. Rowhammer is then used to flip bits in locations of the target page. The developers of this technique managed to compromise the public RSA keys in the OpenSSH authorized_keys file, making them easier to factorize. They were then able to generate a private key and logged into the server.

Using the same techniques, they also flipped bits in the sources.list file, changing ubuntu.com to e.g. ubunvu.com (one bit flip away from the legitimate domain). The researchers registered these domains and served a malicious package update from it. By additionally manipulating the trusted.gpg file, they tricked the victim VM into verifying and installing a malicious update.

=== DRAMA and Rowhammer.js ===

Researchers from the TU Graz have published two very helpful tools which anyone can use to check if their computer is vulnerable to Rowhammer - more specifically, Rowhammer based on the cache eviction technique. The tools run on Linux Intel Ivybridge, Haswell or Skylake systems. It will only work against DDR3 DRAM.

Here is a demo of both tools provided by the authors: https://www.youtube.com/watch?v=X8-X_52rg80&ab_channel=DanielGruss

* DRAMA (https://github.com/IAIK/drama)
This tool is used to reverse-engineer the DRAM mappings - this is required so that specific rows can be targeted easily.

* git clone https://github.com/IAIK/drama
* cd drama/re
* make
* taskset 0x4 sudo ./measure -p 0.75 -s 16 (allocate 75% of DRAM for measurement, expect 16 sets) - After some time - this will output the most likely DRAM mappings

* Rowhammer.js (https://github.com/IAIK/rowhammerjs)
The "native" folder of this repository contains the source code for a simple Rowhammer attack. The code can be compiled for Haswell, Skylake and Ivybridge architectures. But first, the DRAM mappings from the DRAMA tool need to written into the source code. This way, the correct rows are hammered. If any bit flips are found, they will be output in the console.

* git clone https://github.com/IAIK/rowhammerjs
* cd rowhammerjs/native
* nano rowhammer.cc and insert the DRAM mappings for your specific architecture (see image)
* make rowhammer-ivy (for Ivybridge systems, adapt this command to your own architecture)
* ./rowhammer-ivy -d 2 -f 0 (two dimms, hammer only offset zero to increase attack speed)

== Used Hardware ==

[[MacBook Pro 2019, macOS Big Sur, Version 11.6]]

== References ==

* T. Alsop, “How many people have access to a computer 2019,” Feb 2021. [Online]. Available: https://www.statista.com/statistics/748551/ worldwide-households-with-computer/
* W. b. C. Stouffer, “115 cybersecurity statistics and trends you need to know in 2021.” [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-cyberthreat-trends-cybersecurity-threat-review.html
* A. Schaller, W. Xiong, N. A. Anagnostopoulos, M. U. Saleem, S. Gabmeyer, S. Katzen- beisser, and J. Szefer, “Intrinsic rowhammer pufs: Leveraging the rowhammer effect for improved security,” 2017 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2017.
* O. Mutlu and J. S. Kim, “Rowhammer: A retrospective,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 8, p. 1555–1571, 2020.
* M. C.-T. Chao, H.-Y. Yang, R.-F. Huang, S.-C. Lin, and C.-Y. Chin, “Fault models for embedded-dram macros,” Proceedings of the 46th Annual Design Automation Conference on ZZZ - DAC 09, 2009.
* R.-F. Huang, H.-Y. Yang, M. C.-T. Chao, and S.-C. Lin, “Alternate hammering test for application-specific drams and an industrial case study,” Proceedings of the 49th Annual Design Automation Conference on - DAC 12, 2012.
* P. C.-F. Chia, S.-J. Wen, and S. H. Baeg, “New dram hci qualification method em- phasizing on repeated memory access,” 2010 IEEE International Integrated Reliability Workshop Final Report, 2010.
* M. Seaborn and T. Dullien., Jan 1970. [Online]. Available: https://googleprojectzero. blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
* “throwhammer: rowhammer attacks over the network and defenses.” [Online]. Available: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf
* M. Lipp, M. Schwarz, L. Raab, L. Lamster, M. T. Aga, C. Maurice, and D. Gruss, “Nethammer: Inducing rowhammer faults through network requests,” 2020 IEEE Eu- ropean Symposium on Security and Privacy Workshops, 2020.

[[Category:Basic]]

RowHammer, ThrowHammer and NetHammer attacks

2024-01-08T09:26:13Z

TNicholson:

== Summary ==

In this paper, I presented and compared the different attacks about RowHammer, ThrowHammer and NetHammer but the special focus was lying on the RowHammer attack because this attack is the basis of the other attacks. Firstly, I gave an overview about the Internet, personal computers on households and how the technology developed year by year in order to bring a better feeling of understanding about todays capabilities and possibilities. Subsequently I demonstrated some details about the RAM, DRAM and also explained for what they will be used because these components are very important components of machines like computer. They are very affected by those attacks. Furthermore I described the attacks beginning by the RowHammer attack and how it works and what it uses in order to make the attack happen.

== Requirements for RowHammer attack ==

* Have access to local computer
* Access to memory must not be cached - otherwise, the DRAM is never reached
* Memory access must be very fast (race against the refresh time)
* Memory access must be performed in a very targeted way - only specific combinations of proximate row access may cause bit flips
* This cause bit flips on adjacent rows

== Requirements for ThrowHammer attack ==

* This is a remote attack
* Both attacker and victim computers have to enable RDMA on the NIC
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim
* RDMA does write the data directly on the victim application instead on a buffer in-between
* This causes bit flips on DRAM cell rows

== Requirements for NetHammer attack ==

* This is a remote attack
* This attack does neither need an executable code or RDMA enabled NICs
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim, for example UDP packets with minimum packet size of 64 bytes
* It does not directly cause bit flips on the cells but instead it keeps reopening rows permanently which can cause bit flips

== Description ==

=== Dynamic Random Access Memory - DRAM ===

The DRAM is the easiest, slowest and cheapest memory type. Those kind of chips will be used in the todays RAM. Mostly the SDRAM type will be used. To stick on the facts from above, we will now look at how a DRAM look like. The figure shows the main structure of a DRAM memory cell component. It consist of a transistor, which works as a switch and a capacitor, which is the actual memory component. The capacitor is a component which can save an electric charge for a certain amount of time, it depends on the capacitor how long it can hold an electric charge. To fully charge or uncharge a capacitor it needs 5 * T (Tau) to either charge or uncharge it.
 
 
'''t = 5 ∗ T = 5 ∗ R ∗ C (2.1)'''
 
 
The formula to calculate the time when a capacitor will be fully charged or uncharged is showed on 2.1 where R is the resistor and C is the capacitor. In the DRAM memory cell a bit will be saved by charging the capacitor. Reading and writing happens through the transistor which functions as a switch. The transistor decides when to close the connection between capacitor and bitline and when to open it, so no information can flow to the bitline. Through the wordline the transistor can be controlled. Every gate of the transistor is connected to a wordline and each of this wordlines controls the access to the whole row. The cells of a DRAM are organized in arrays as described before. Each of those arrays are also called bank. A DRAM chip usually has 8 banks. Over time the charge will get lost and the data in the cell will also be lost. When a cell starts losing its data until it loses it completely the time in between is also called the data retention time. In order to not lose data fast and keep the data for a longer time each wordline of each row has to be accessed periodically, so in a specific interval of time, to charge the capacitors of that row through the bitlines. This process is called the "DRAM refresh". Every DRAM row needs to be refreshed within a certain frequency, which is usually 32 to 64 ms (Milliseconds) in the current DRAMs in order to ensure data integrity.

[[File:dram.png|thumb|none|300px|Source: Author]]

=== RowHammer ===

The memory isolation is in general a key property of a reliable and secure computer or computing system. In normal circumstances an access to a memory address should not be that hard and it should definitely not have any side effects on data that is stored in other adjacent addresses. However, year for year the manufacturers tries to place more chips on the computer in order to gain more computing power and introduce new performance statistics to the end customer. In order to place more chips they have to make the chips smaller year for year. That means, those memory chips become much more vulnerable to disturbance. A disturbance is a phenomenon in which different memory cells interfere with each others operation. The whole problem and in the same time the key attack about this RowHammer topic is that repeatedly reading from the same memory address in DRAM could change data in adjacent memory addresses. In this addresses we talk about bits, so it could be for example that if a process A wants to access the memory address 2 several times in a row that some bits from the memory address 1 and 3 could change from one to zero or from zero to one, so it could flip. One bit change could manipulate the data that a memory address holds completely, so the data would be corrupt or would mean something completely different which is obviously not the sense of what DRAM should do or in general what the user of the computer at least expects. In specific, when a DRAM row is opened, so it is activated, and closed rapidly and repeatedly enough times within a DRAM refresh interval, one or more bits in physically adjacent DRAM rows can be flipped to the wrong value as described before. The repeating activating and closing a DRAM row is called hammering and this process as a whole is called RowHammer.

=== Possible Solutions against RowHammer attacks ===

Manufacturing better DRAM chips
* That means it is a must requirement for the major manufacturers to create and develop much better and secure DRAM chips then before. This includes that those chips should not be vulnerable to those easy attacks anymore.

Error correction codes
* Using strong error correction codes (ECC) would improve and help to correct errors that are coming from RowHammer attacks.

Refresh rate
* The increasing of the refresh rate for all of the memory would increase the milliseconds of the refresh time so it would be faster. The cell would get refreshed much faster. So the bits will be refreshed again and the cell has again the correct data instead of the manipulated ones.

Remapping/Retiring statically
* A statically remapping or retiring of RowHammer affected cells via a one time post-manufacturing analysis would decrease the probability of an upcoming RowHammer attack.

Remapping/Retiring dynamically
* A dynamically remapping or retiring of RowHammer affected cells during the system opera- tion would decrease the probability of an upcoming RowHammer attacks much more.

Identifying hammered rows
* Exactly identifying hammered rows during runtime and refreshing their adjacent rows. But all of those solutions are coming with performance, power or cost overheads.

=== Remote Direct Memory Access - RDMA ===

RDMA is technology that allows computers in a network to exchange data directly from the RAM without involving the CPU or the operating system of both communication partner computers. With this, it is possible to move data from and into a server by implementing a transport protocol into the hardware of the network interface card. This technology provides a function called "Zero-Copy-Networking" which enables to read data directly from a RAM of a computer and write the fetched data to the RAM of another computer in another network. RDMA provides a much faster data transferring time and a network with less latency. When both sender computer and receiver computer supports RDMA then the conversation will be executed faster than transferring the data when one of them does not support RDMA. Figure shows a conversation with an RDMA connection.

[[File:rdma.png|thumb|none|600px|Source: Author]]

=== ThrowHammer ===

So the ThrowHammer attack is nothing else then a remotely used RowHammer attack where the attacker focuses on systems that are using RDMA. When the system wants to send a packet to another network then usually the CPU has to do some work. The CPU has to take the data from the client application and saves it to a direct memory access (DMA) buffer in the kernel space. Then the network interface card (NIC) takes this saved data from the DMA and sends it to the other network, to be more precise it will be send to the NIC of the other network. The target network then continues to copy the data to the DMA buffer and subsequently the CPU takes the data and provides it to the target client application. This is the general process of a non-RDMA system. With RDMA the CPU is not involved in this process, there is no need for it. So the client application sends directly the data to its own NIC and the NIC sends it further to the target NIC of the target network. When the target NIC gets the data it will be directly provided for the client application like showed in the figure.

[[File:non-rdma.png|thumb|none|600px|Source: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf]]

In order to transfer packets efficiently ThrowHammer makes use of RDMA capabilities. Sending packets rapidly and frequently over a high speed network may cause bit flips on the target system because of RDMA.

=== NetHammer ===

The NetHammer attack is actually a RowHammer attack which is neither relying on any attacker controlled code on the victim computer or RDMA enabled network cards. So it does not require local code execution. It only needs a fast network connection between the attacker and the victim. This attack sends a crafted stream of small network packets to the target computer a one-location or single-sided RowHammer attack. Single-sided hammering is when accessing 8 randomly chosen memory locations simultaneously and there the probability is high that at least 2 out of 8 random memory locations will be mapped into the same out of 32 DRAM banks on DDR3. DDR3 is Double Data Rates 3 which is a SDRAM type. One-location hammering is when only accessing one single location at a high frequency. In this access pattern the attacker does not directly cause row conflicts but instead it keeps re-opening one row permanently. Each packet that is received on the target device, a set of addresses is accessed for example in a user-space application processing the contents, in the kernel driver, somewhere in between or a combination of all. So when sending packets rapidly and repeatedly, those set of addresses are hammered and therefore bit flips can occur. So to make remotely bit flips happen it is needed to send as many packets as possible, as fast as possible and in a short time frame over a the network. For example, UDP (User Datagram Protocol) packets without any specific content can be used for this attack. On those UDP packets it should be allowed to have an overall packet size of 64 B (Byte) which is the minimum packet size for an Ethernet packet. Ethernet has also a maximum frame size of 1518 B. With this it is possible to send up to 1 024 000 packets per second over a 500 Mbit per second connection.

=== Flip Feng Shui ===

Flip Feng Shui is a highly advanced implementation of Rowhammer capable of flipping bits in a controlled way anywhere in the software. Memory deduplication allows attackers to map a physical page onto a virtual page they own, as long as the page content is known. Rowhammer is then used to flip bits in locations of the target page. The developers of this technique managed to compromise the public RSA keys in the OpenSSH authorized_keys file, making them easier to factorize. They were then able to generate a private key and logged into the server.

Using the same techniques, they also flipped bits in the sources.list file, changing ubuntu.com to e.g. ubunvu.com (one bit flip away from the legitimate domain). The researchers registered these domains and served a malicious package update from it. By additionally manipulating the trusted.gpg file, they tricked the victim VM into verifying and installing a malicious update.

=== DRAMA and Rowhammer.js ===

Researchers from the TU Graz have published two very helpful tools which anyone can use to check if their computer is vulnerable to Rowhammer - more specifically, Rowhammer based on the cache eviction technique. The tools run on Linux Intel Ivybridge, Haswell or Skylake systems. It will only work against DDR3 DRAM.

Here is a demo of both tools provided by the authors: https://www.youtube.com/watch?v=X8-X_52rg80&ab_channel=DanielGruss

* DRAMA (https://github.com/IAIK/drama)
This tool is used to reverse-engineer the DRAM mappings - this is required so that specific rows can be targeted easily.

* Rowhammer.js (https://github.com/IAIK/rowhammerjs)
The "native" folder of this repository contains the source code for a simple Rowhammer attack. The code can be compiled for Haswell, Skylake and Ivybridge architectures. But first, the DRAM mappings from the DRAMA tool need to written into the source code. This way, the correct rows are hammered. If any bit flips are found, they will be output in the console.

== Used Hardware ==

[[MacBook Pro 2019, macOS Big Sur, Version 11.6]]

== References ==

* T. Alsop, “How many people have access to a computer 2019,” Feb 2021. [Online]. Available: https://www.statista.com/statistics/748551/ worldwide-households-with-computer/
* W. b. C. Stouffer, “115 cybersecurity statistics and trends you need to know in 2021.” [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-cyberthreat-trends-cybersecurity-threat-review.html
* A. Schaller, W. Xiong, N. A. Anagnostopoulos, M. U. Saleem, S. Gabmeyer, S. Katzen- beisser, and J. Szefer, “Intrinsic rowhammer pufs: Leveraging the rowhammer effect for improved security,” 2017 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2017.
* O. Mutlu and J. S. Kim, “Rowhammer: A retrospective,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 8, p. 1555–1571, 2020.
* M. C.-T. Chao, H.-Y. Yang, R.-F. Huang, S.-C. Lin, and C.-Y. Chin, “Fault models for embedded-dram macros,” Proceedings of the 46th Annual Design Automation Conference on ZZZ - DAC 09, 2009.
* R.-F. Huang, H.-Y. Yang, M. C.-T. Chao, and S.-C. Lin, “Alternate hammering test for application-specific drams and an industrial case study,” Proceedings of the 49th Annual Design Automation Conference on - DAC 12, 2012.
* P. C.-F. Chia, S.-J. Wen, and S. H. Baeg, “New dram hci qualification method em- phasizing on repeated memory access,” 2010 IEEE International Integrated Reliability Workshop Final Report, 2010.
* M. Seaborn and T. Dullien., Jan 1970. [Online]. Available: https://googleprojectzero. blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
* “throwhammer: rowhammer attacks over the network and defenses.” [Online]. Available: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf
* M. Lipp, M. Schwarz, L. Raab, L. Lamster, M. T. Aga, C. Maurice, and D. Gruss, “Nethammer: Inducing rowhammer faults through network requests,” 2020 IEEE Eu- ropean Symposium on Security and Privacy Workshops, 2020.

[[Category:Basic]]

RowHammer, ThrowHammer and NetHammer attacks

2024-01-08T09:21:02Z

TNicholson:

== Summary ==

In this paper, I presented and compared the different attacks about RowHammer, ThrowHammer and NetHammer but the special focus was lying on the RowHammer attack because this attack is the basis of the other attacks. Firstly, I gave an overview about the Internet, personal computers on households and how the technology developed year by year in order to bring a better feeling of understanding about todays capabilities and possibilities. Subsequently I demonstrated some details about the RAM, DRAM and also explained for what they will be used because these components are very important components of machines like computer. They are very affected by those attacks. Furthermore I described the attacks beginning by the RowHammer attack and how it works and what it uses in order to make the attack happen.

== Requirements for RowHammer attack ==

* Have access to local computer
* Access to memory must not be cached - otherwise, the DRAM is never reached
* Memory access must be very fast (race against the refresh time)
* Memory access must be performed in a very targeted way - only specific combinations of proximate row access may cause bit flips
* This cause bit flips on adjacent rows

== Requirements for ThrowHammer attack ==

* This is a remote attack
* Both attacker and victim computers have to enable RDMA on the NIC
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim
* RDMA does write the data directly on the victim application instead on a buffer in-between
* This causes bit flips on DRAM cell rows

== Requirements for NetHammer attack ==

* This is a remote attack
* This attack does neither need an executable code or RDMA enabled NICs
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim, for example UDP packets with minimum packet size of 64 bytes
* It does not directly cause bit flips on the cells but instead it keeps reopening rows permanently which can cause bit flips

== Description ==

=== Dynamic Random Access Memory - DRAM ===

The DRAM is the easiest, slowest and cheapest memory type. Those kind of chips will be used in the todays RAM. Mostly the SDRAM type will be used. To stick on the facts from above, we will now look at how a DRAM look like. The figure shows the main structure of a DRAM memory cell component. It consist of a transistor, which works as a switch and a capacitor, which is the actual memory component. The capacitor is a component which can save an electric charge for a certain amount of time, it depends on the capacitor how long it can hold an electric charge. To fully charge or uncharge a capacitor it needs 5 * T (Tau) to either charge or uncharge it.
 
 
'''t = 5 ∗ T = 5 ∗ R ∗ C (2.1)'''
 
 
The formula to calculate the time when a capacitor will be fully charged or uncharged is showed on 2.1 where R is the resistor and C is the capacitor. In the DRAM memory cell a bit will be saved by charging the capacitor. Reading and writing happens through the transistor which functions as a switch. The transistor decides when to close the connection between capacitor and bitline and when to open it, so no information can flow to the bitline. Through the wordline the transistor can be controlled. Every gate of the transistor is connected to a wordline and each of this wordlines controls the access to the whole row. The cells of a DRAM are organized in arrays as described before. Each of those arrays are also called bank. A DRAM chip usually has 8 banks. Over time the charge will get lost and the data in the cell will also be lost. When a cell starts losing its data until it loses it completely the time in between is also called the data retention time. In order to not lose data fast and keep the data for a longer time each wordline of each row has to be accessed periodically, so in a specific interval of time, to charge the capacitors of that row through the bitlines. This process is called the "DRAM refresh". Every DRAM row needs to be refreshed within a certain frequency, which is usually 32 to 64 ms (Milliseconds) in the current DRAMs in order to ensure data integrity.

[[File:dram.png|thumb|none|300px|Source: Author]]

=== RowHammer ===

The memory isolation is in general a key property of a reliable and secure computer or computing system. In normal circumstances an access to a memory address should not be that hard and it should definitely not have any side effects on data that is stored in other adjacent addresses. However, year for year the manufacturers tries to place more chips on the computer in order to gain more computing power and introduce new performance statistics to the end customer. In order to place more chips they have to make the chips smaller year for year. That means, those memory chips become much more vulnerable to disturbance. A disturbance is a phenomenon in which different memory cells interfere with each others operation. The whole problem and in the same time the key attack about this RowHammer topic is that repeatedly reading from the same memory address in DRAM could change data in adjacent memory addresses. In this addresses we talk about bits, so it could be for example that if a process A wants to access the memory address 2 several times in a row that some bits from the memory address 1 and 3 could change from one to zero or from zero to one, so it could flip. One bit change could manipulate the data that a memory address holds completely, so the data would be corrupt or would mean something completely different which is obviously not the sense of what DRAM should do or in general what the user of the computer at least expects. In specific, when a DRAM row is opened, so it is activated, and closed rapidly and repeatedly enough times within a DRAM refresh interval, one or more bits in physically adjacent DRAM rows can be flipped to the wrong value as described before. The repeating activating and closing a DRAM row is called hammering and this process as a whole is called RowHammer.

=== Possible Solutions against RowHammer attacks ===

Manufacturing better DRAM chips
* That means it is a must requirement for the major manufacturers to create and develop much better and secure DRAM chips then before. This includes that those chips should not be vulnerable to those easy attacks anymore.

Error correction codes
* Using strong error correction codes (ECC) would improve and help to correct errors that are coming from RowHammer attacks.

Refresh rate
* The increasing of the refresh rate for all of the memory would increase the milliseconds of the refresh time so it would be faster. The cell would get refreshed much faster. So the bits will be refreshed again and the cell has again the correct data instead of the manipulated ones.

Remapping/Retiring statically
* A statically remapping or retiring of RowHammer affected cells via a one time post-manufacturing analysis would decrease the probability of an upcoming RowHammer attack.

Remapping/Retiring dynamically
* A dynamically remapping or retiring of RowHammer affected cells during the system opera- tion would decrease the probability of an upcoming RowHammer attacks much more.

Identifying hammered rows
* Exactly identifying hammered rows during runtime and refreshing their adjacent rows. But all of those solutions are coming with performance, power or cost overheads.

=== Remote Direct Memory Access - RDMA ===

RDMA is technology that allows computers in a network to exchange data directly from the RAM without involving the CPU or the operating system of both communication partner computers. With this, it is possible to move data from and into a server by implementing a transport protocol into the hardware of the network interface card. This technology provides a function called "Zero-Copy-Networking" which enables to read data directly from a RAM of a computer and write the fetched data to the RAM of another computer in another network. RDMA provides a much faster data transferring time and a network with less latency. When both sender computer and receiver computer supports RDMA then the conversation will be executed faster than transferring the data when one of them does not support RDMA. Figure shows a conversation with an RDMA connection.

[[File:rdma.png|thumb|none|600px|Source: Author]]

=== ThrowHammer ===

So the ThrowHammer attack is nothing else then a remotely used RowHammer attack where the attacker focuses on systems that are using RDMA. When the system wants to send a packet to another network then usually the CPU has to do some work. The CPU has to take the data from the client application and saves it to a direct memory access (DMA) buffer in the kernel space. Then the network interface card (NIC) takes this saved data from the DMA and sends it to the other network, to be more precise it will be send to the NIC of the other network. The target network then continues to copy the data to the DMA buffer and subsequently the CPU takes the data and provides it to the target client application. This is the general process of a non-RDMA system. With RDMA the CPU is not involved in this process, there is no need for it. So the client application sends directly the data to its own NIC and the NIC sends it further to the target NIC of the target network. When the target NIC gets the data it will be directly provided for the client application like showed in the figure.

[[File:non-rdma.png|thumb|none|600px|Source: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf]]

In order to transfer packets efficiently ThrowHammer makes use of RDMA capabilities. Sending packets rapidly and frequently over a high speed network may cause bit flips on the target system because of RDMA.

=== NetHammer ===

The NetHammer attack is actually a RowHammer attack which is neither relying on any attacker controlled code on the victim computer or RDMA enabled network cards. So it does not require local code execution. It only needs a fast network connection between the attacker and the victim. This attack sends a crafted stream of small network packets to the target computer a one-location or single-sided RowHammer attack. Single-sided hammering is when accessing 8 randomly chosen memory locations simultaneously and there the probability is high that at least 2 out of 8 random memory locations will be mapped into the same out of 32 DRAM banks on DDR3. DDR3 is Double Data Rates 3 which is a SDRAM type. One-location hammering is when only accessing one single location at a high frequency. In this access pattern the attacker does not directly cause row conflicts but instead it keeps re-opening one row permanently. Each packet that is received on the target device, a set of addresses is accessed for example in a user-space application processing the contents, in the kernel driver, somewhere in between or a combination of all. So when sending packets rapidly and repeatedly, those set of addresses are hammered and therefore bit flips can occur. So to make remotely bit flips happen it is needed to send as many packets as possible, as fast as possible and in a short time frame over a the network. For example, UDP (User Datagram Protocol) packets without any specific content can be used for this attack. On those UDP packets it should be allowed to have an overall packet size of 64 B (Byte) which is the minimum packet size for an Ethernet packet. Ethernet has also a maximum frame size of 1518 B. With this it is possible to send up to 1 024 000 packets per second over a 500 Mbit per second connection.

=== DRAMA and Rowhammer.js ===

Researchers from the TU Graz have published two very helpful tools which anyone can use to check if their computer is vulnerable to Rowhammer - more specifically, Rowhammer based on the cache eviction technique. The tools run on Linux Intel Ivybridge, Haswell or Skylake systems. It will only work against DDR3 DRAM.

Here is a demo of both tools provided by the authors: https://www.youtube.com/watch?v=X8-X_52rg80&ab_channel=DanielGruss

* DRAMA (https://github.com/IAIK/drama)
This tool is used to reverse-engineer the DRAM mappings - this is required so that specific rows can be targeted easily.

* Rowhammer.js (https://github.com/IAIK/rowhammerjs)
The "native" folder of this repository contains the source code for a simple Rowhammer attack. The code can be compiled for Haswell, Skylake and Ivybridge architectures. But first, the DRAM mappings from the DRAMA tool need to written into the source code. This way, the correct rows are hammered. If any bit flips are found, they will be output in the console.

== Used Hardware ==

[[MacBook Pro 2019, macOS Big Sur, Version 11.6]]

== References ==

* T. Alsop, “How many people have access to a computer 2019,” Feb 2021. [Online]. Available: https://www.statista.com/statistics/748551/ worldwide-households-with-computer/
* W. b. C. Stouffer, “115 cybersecurity statistics and trends you need to know in 2021.” [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-cyberthreat-trends-cybersecurity-threat-review.html
* A. Schaller, W. Xiong, N. A. Anagnostopoulos, M. U. Saleem, S. Gabmeyer, S. Katzen- beisser, and J. Szefer, “Intrinsic rowhammer pufs: Leveraging the rowhammer effect for improved security,” 2017 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2017.
* O. Mutlu and J. S. Kim, “Rowhammer: A retrospective,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 8, p. 1555–1571, 2020.
* M. C.-T. Chao, H.-Y. Yang, R.-F. Huang, S.-C. Lin, and C.-Y. Chin, “Fault models for embedded-dram macros,” Proceedings of the 46th Annual Design Automation Conference on ZZZ - DAC 09, 2009.
* R.-F. Huang, H.-Y. Yang, M. C.-T. Chao, and S.-C. Lin, “Alternate hammering test for application-specific drams and an industrial case study,” Proceedings of the 49th Annual Design Automation Conference on - DAC 12, 2012.
* P. C.-F. Chia, S.-J. Wen, and S. H. Baeg, “New dram hci qualification method em- phasizing on repeated memory access,” 2010 IEEE International Integrated Reliability Workshop Final Report, 2010.
* M. Seaborn and T. Dullien., Jan 1970. [Online]. Available: https://googleprojectzero. blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
* “throwhammer: rowhammer attacks over the network and defenses.” [Online]. Available: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf
* M. Lipp, M. Schwarz, L. Raab, L. Lamster, M. T. Aga, C. Maurice, and D. Gruss, “Nethammer: Inducing rowhammer faults through network requests,” 2020 IEEE Eu- ropean Symposium on Security and Privacy Workshops, 2020.

[[Category:Basic]]

RowHammer, ThrowHammer and NetHammer attacks

2024-01-08T09:18:10Z

TNicholson:

== Summary ==

In this paper, I presented and compared the different attacks about RowHammer, ThrowHammer and NetHammer but the special focus was lying on the RowHammer attack because this attack is the basis of the other attacks. Firstly, I gave an overview about the Internet, personal computers on households and how the technology developed year by year in order to bring a better feeling of understanding about todays capabilities and possibilities. Subsequently I demonstrated some details about the RAM, DRAM and also explained for what they will be used because these components are very important components of machines like computer. They are very affected by those attacks. Furthermore I described the attacks beginning by the RowHammer attack and how it works and what it uses in order to make the attack happen.

== Requirements for RowHammer attack ==

* Have access to local computer
* Execute local code which rapidly and repeatedly reopens rows on DRAM cells
* This cause bit flips on adjacent rows

== Requirements for ThrowHammer attack ==

* This is a remote attack
* Both attacker and victim computers have to enable RDMA on the NIC
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim
* RDMA does write the data directly on the victim application instead on a buffer in-between
* This causes bit flips on DRAM cell rows

== Requirements for NetHammer attack ==

* This is a remote attack
* This attack does neither need an executable code or RDMA enabled NICs
* Attacker needs a fast network connection to victim computer
* Attacker sends packets as many as possible and as fast as possible to victim, for example UDP packets with minimum packet size of 64 bytes
* It does not directly cause bit flips on the cells but instead it keeps reopening rows permanently which can cause bit flips

== Description ==

=== Dynamic Random Access Memory - DRAM ===

The DRAM is the easiest, slowest and cheapest memory type. Those kind of chips will be used in the todays RAM. Mostly the SDRAM type will be used. To stick on the facts from above, we will now look at how a DRAM look like. The figure shows the main structure of a DRAM memory cell component. It consist of a transistor, which works as a switch and a capacitor, which is the actual memory component. The capacitor is a component which can save an electric charge for a certain amount of time, it depends on the capacitor how long it can hold an electric charge. To fully charge or uncharge a capacitor it needs 5 * T (Tau) to either charge or uncharge it.
 
 
'''t = 5 ∗ T = 5 ∗ R ∗ C (2.1)'''
 
 
The formula to calculate the time when a capacitor will be fully charged or uncharged is showed on 2.1 where R is the resistor and C is the capacitor. In the DRAM memory cell a bit will be saved by charging the capacitor. Reading and writing happens through the transistor which functions as a switch. The transistor decides when to close the connection between capacitor and bitline and when to open it, so no information can flow to the bitline. Through the wordline the transistor can be controlled. Every gate of the transistor is connected to a wordline and each of this wordlines controls the access to the whole row. The cells of a DRAM are organized in arrays as described before. Each of those arrays are also called bank. A DRAM chip usually has 8 banks. Over time the charge will get lost and the data in the cell will also be lost. When a cell starts losing its data until it loses it completely the time in between is also called the data retention time. In order to not lose data fast and keep the data for a longer time each wordline of each row has to be accessed periodically, so in a specific interval of time, to charge the capacitors of that row through the bitlines. This process is called the "DRAM refresh". Every DRAM row needs to be refreshed within a certain frequency, which is usually 32 to 64 ms (Milliseconds) in the current DRAMs in order to ensure data integrity.

[[File:dram.png|thumb|none|300px|Source: Author]]

=== RowHammer ===

The memory isolation is in general a key property of a reliable and secure computer or computing system. In normal circumstances an access to a memory address should not be that hard and it should definitely not have any side effects on data that is stored in other adjacent addresses. However, year for year the manufacturers tries to place more chips on the computer in order to gain more computing power and introduce new performance statistics to the end customer. In order to place more chips they have to make the chips smaller year for year. That means, those memory chips become much more vulnerable to disturbance. A disturbance is a phenomenon in which different memory cells interfere with each others operation. The whole problem and in the same time the key attack about this RowHammer topic is that repeatedly reading from the same memory address in DRAM could change data in adjacent memory addresses. In this addresses we talk about bits, so it could be for example that if a process A wants to access the memory address 2 several times in a row that some bits from the memory address 1 and 3 could change from one to zero or from zero to one, so it could flip. One bit change could manipulate the data that a memory address holds completely, so the data would be corrupt or would mean something completely different which is obviously not the sense of what DRAM should do or in general what the user of the computer at least expects. In specific, when a DRAM row is opened, so it is activated, and closed rapidly and repeatedly enough times within a DRAM refresh interval, one or more bits in physically adjacent DRAM rows can be flipped to the wrong value as described before. The repeating activating and closing a DRAM row is called hammering and this process as a whole is called RowHammer.

=== Possible Solutions against RowHammer attacks ===

Manufacturing better DRAM chips
* That means it is a must requirement for the major manufacturers to create and develop much better and secure DRAM chips then before. This includes that those chips should not be vulnerable to those easy attacks anymore.

Error correction codes
* Using strong error correction codes (ECC) would improve and help to correct errors that are coming from RowHammer attacks.

Refresh rate
* The increasing of the refresh rate for all of the memory would increase the milliseconds of the refresh time so it would be faster. The cell would get refreshed much faster. So the bits will be refreshed again and the cell has again the correct data instead of the manipulated ones.

Remapping/Retiring statically
* A statically remapping or retiring of RowHammer affected cells via a one time post-manufacturing analysis would decrease the probability of an upcoming RowHammer attack.

Remapping/Retiring dynamically
* A dynamically remapping or retiring of RowHammer affected cells during the system opera- tion would decrease the probability of an upcoming RowHammer attacks much more.

Identifying hammered rows
* Exactly identifying hammered rows during runtime and refreshing their adjacent rows. But all of those solutions are coming with performance, power or cost overheads.

=== Remote Direct Memory Access - RDMA ===

RDMA is technology that allows computers in a network to exchange data directly from the RAM without involving the CPU or the operating system of both communication partner computers. With this, it is possible to move data from and into a server by implementing a transport protocol into the hardware of the network interface card. This technology provides a function called "Zero-Copy-Networking" which enables to read data directly from a RAM of a computer and write the fetched data to the RAM of another computer in another network. RDMA provides a much faster data transferring time and a network with less latency. When both sender computer and receiver computer supports RDMA then the conversation will be executed faster than transferring the data when one of them does not support RDMA. Figure shows a conversation with an RDMA connection.

[[File:rdma.png|thumb|none|600px|Source: Author]]

=== ThrowHammer ===

So the ThrowHammer attack is nothing else then a remotely used RowHammer attack where the attacker focuses on systems that are using RDMA. When the system wants to send a packet to another network then usually the CPU has to do some work. The CPU has to take the data from the client application and saves it to a direct memory access (DMA) buffer in the kernel space. Then the network interface card (NIC) takes this saved data from the DMA and sends it to the other network, to be more precise it will be send to the NIC of the other network. The target network then continues to copy the data to the DMA buffer and subsequently the CPU takes the data and provides it to the target client application. This is the general process of a non-RDMA system. With RDMA the CPU is not involved in this process, there is no need for it. So the client application sends directly the data to its own NIC and the NIC sends it further to the target NIC of the target network. When the target NIC gets the data it will be directly provided for the client application like showed in the figure.

[[File:non-rdma.png|thumb|none|600px|Source: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf]]

In order to transfer packets efficiently ThrowHammer makes use of RDMA capabilities. Sending packets rapidly and frequently over a high speed network may cause bit flips on the target system because of RDMA.

=== NetHammer ===

The NetHammer attack is actually a RowHammer attack which is neither relying on any attacker controlled code on the victim computer or RDMA enabled network cards. So it does not require local code execution. It only needs a fast network connection between the attacker and the victim. This attack sends a crafted stream of small network packets to the target computer a one-location or single-sided RowHammer attack. Single-sided hammering is when accessing 8 randomly chosen memory locations simultaneously and there the probability is high that at least 2 out of 8 random memory locations will be mapped into the same out of 32 DRAM banks on DDR3. DDR3 is Double Data Rates 3 which is a SDRAM type. One-location hammering is when only accessing one single location at a high frequency. In this access pattern the attacker does not directly cause row conflicts but instead it keeps re-opening one row permanently. Each packet that is received on the target device, a set of addresses is accessed for example in a user-space application processing the contents, in the kernel driver, somewhere in between or a combination of all. So when sending packets rapidly and repeatedly, those set of addresses are hammered and therefore bit flips can occur. So to make remotely bit flips happen it is needed to send as many packets as possible, as fast as possible and in a short time frame over a the network. For example, UDP (User Datagram Protocol) packets without any specific content can be used for this attack. On those UDP packets it should be allowed to have an overall packet size of 64 B (Byte) which is the minimum packet size for an Ethernet packet. Ethernet has also a maximum frame size of 1518 B. With this it is possible to send up to 1 024 000 packets per second over a 500 Mbit per second connection.

=== DRAMA and Rowhammer.js ===

Researchers from the TU Graz have published two very helpful tools which anyone can use to check if their computer is vulnerable to Rowhammer - more specifically, Rowhammer based on the cache eviction technique. The tools run on Linux Intel Ivybridge, Haswell or Skylake systems. It will only work against DDR3 DRAM.

Here is a demo of both tools provided by the authors: https://www.youtube.com/watch?v=X8-X_52rg80&ab_channel=DanielGruss

* DRAMA (https://github.com/IAIK/drama)
This tool is used to reverse-engineer the DRAM mappings - this is required so that specific rows can be targeted easily.

* Rowhammer.js (https://github.com/IAIK/rowhammerjs)
The "native" folder of this repository contains the source code for a simple Rowhammer attack. The code can be compiled for Haswell, Skylake and Ivybridge architectures. But first, the DRAM mappings from the DRAMA tool need to written into the source code. This way, the correct rows are hammered. If any bit flips are found, they will be output in the console.

== Used Hardware ==

[[MacBook Pro 2019, macOS Big Sur, Version 11.6]]

== References ==

* T. Alsop, “How many people have access to a computer 2019,” Feb 2021. [Online]. Available: https://www.statista.com/statistics/748551/ worldwide-households-with-computer/
* W. b. C. Stouffer, “115 cybersecurity statistics and trends you need to know in 2021.” [Online]. Available: https://us.norton.com/ internetsecurity-emerging-threats-cyberthreat-trends-cybersecurity-threat-review.html
* A. Schaller, W. Xiong, N. A. Anagnostopoulos, M. U. Saleem, S. Gabmeyer, S. Katzen- beisser, and J. Szefer, “Intrinsic rowhammer pufs: Leveraging the rowhammer effect for improved security,” 2017 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2017.
* O. Mutlu and J. S. Kim, “Rowhammer: A retrospective,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 8, p. 1555–1571, 2020.
* M. C.-T. Chao, H.-Y. Yang, R.-F. Huang, S.-C. Lin, and C.-Y. Chin, “Fault models for embedded-dram macros,” Proceedings of the 46th Annual Design Automation Conference on ZZZ - DAC 09, 2009.
* R.-F. Huang, H.-Y. Yang, M. C.-T. Chao, and S.-C. Lin, “Alternate hammering test for application-specific drams and an industrial case study,” Proceedings of the 49th Annual Design Automation Conference on - DAC 12, 2012.
* P. C.-F. Chia, S.-J. Wen, and S. H. Baeg, “New dram hci qualification method em- phasizing on repeated memory access,” 2010 IEEE International Integrated Reliability Workshop Final Report, 2010.
* M. Seaborn and T. Dullien., Jan 1970. [Online]. Available: https://googleprojectzero. blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
* “throwhammer: rowhammer attacks over the network and defenses.” [Online]. Available: https://www.usenix.org/system/files/conference/atc18/atc18-tatar.pdf
* M. Lipp, M. Schwarz, L. Raab, L. Lamster, M. T. Aga, C. Maurice, and D. Gruss, “Nethammer: Inducing rowhammer faults through network requests,” 2020 IEEE Eu- ropean Symposium on Security and Privacy Workshops, 2020.

[[Category:Basic]]

Dragino LoRa Hat Single-Channel-Gateway

2023-12-08T14:43:23Z

TNicholson:

== Used Hardware: ==

* Raspberry Pi 4
* Dragino Raspberry Pi LoRa/GPS HAT
* SD Card sufficient for Raspberry Pi OS Installation


== Hardware Assembly ==

Carefully place the HAT onto the Raspberry Pi’s GPIO pins and gently push down. Always remember never to power on the HAT without a mounted antenna, as doing so could result in hardware damage.


== System setup ==

For this hardware, a clean install of Raspberry Pi OS is recommended. I recommend using the Raspberry Pi Imager, as it allows you to pre-set ssh settings before flashing the OS.

* Connect to the Raspberry Pi via ssh
* Enable SPI interface: ''sudo raspi-config''
** Select Interface Options -> Select Yes when asked if you want to enable the SPI interface
* Reboot the Raspberry Pi: ''sudo shutdown -r now''

'''Note''': On the Raspberry Pi 4, there can be problems with installing the WiringPi package. If you encounter the same issue with an error message appearing when trying to install it, use the following commands to install a compatible version of WiringPi:

* <code>cd /tmp</code>
* <code>wget https://project-downloads.drogon.net/wiringpi-latest.deb</code>
* <code>sudo dpkg -i wiringpi-latest.deb</code>
* Check if the correct version was installed: <code>gpio -v</code>
** This should output version 2.52.

Once WiringPi is installed and configured correctly, the Dragino LoRa/GPS Hat can be set up to act as a few different things.


=== LoRa Single Channel Gateway ===

The Dragino LoRa Hat can be setup as an 868 MHz single-channel LoRa gateway. To do this, we can leverage existing software. - ''sudo apt install git'' - ''git clone https://github.com/tftelkamp/single_chan_pkt_fwd'' - ''cd ~/single_chan_pkt_fwd'' - ''nano main.cpp''

In the main.cpp file, you can define variables necessary for registering the gateway (e.g. longitude and latitude) - You must also change the server IP to the IP of eu1.cloud.thethings.network (52.212.223.226).

[[File:Server_IP.png]]

* <code>make</code>
* <code>sudo ./single_chan_pkt_fwd</code>

You can hit Ctrl+Z to exit the program and close down the gateway - this means the gateway is only running when the command is executed.


=== Registering the Gateway in The Things Network ===

After starting the gateway program as stated before, the Gateway ID will be displayed (see image below).

[[File:GatewayID.png]]

You can now register a new gateway in the TTN console with this ID. If everything is configured correctly, you should see some activity coming from the gateway.

'''Note:''' By default, the Things Network will not display single-channel gateways on the map of gateways, as they are considered less reliable. However, for most experimental purposes, they suffice.

File:Server IP.png

2023-12-08T14:42:16Z

TNicholson:

Dragino LoRa Hat Single-Channel-Gateway

2023-12-08T14:41:03Z

TNicholson:

== Used Hardware: ==

* Raspberry Pi 4
* Dragino Raspberry Pi LoRa/GPS HAT
* SD Card sufficient for Raspberry Pi OS Installation


== Hardware Assembly ==

Carefully place the HAT onto the Raspberry Pi’s GPIO pins and gently push down. Always remember never to power on the HAT without a mounted antenna, as doing so could result in hardware damage.


== System setup ==

For this hardware, a clean install of Raspberry Pi OS is recommended. I recommend using the Raspberry Pi Imager, as it allows you to pre-set ssh settings before flashing the OS.

* Connect to the Raspberry Pi via ssh
* Enable SPI interface: ''sudo raspi-config''
** Select Interface Options -> Select Yes when asked if you want to enable the SPI interface
* Reboot the Raspberry Pi: ''sudo shutdown -r now''

'''Note''': On the Raspberry Pi 4, there can be problems with installing the WiringPi package. If you encounter the same issue with an error message appearing when trying to install it, use the following commands to install a compatible version of WiringPi:

* <code>cd /tmp</code>
* <code>wget https://project-downloads.drogon.net/wiringpi-latest.deb</code>
* <code>sudo dpkg -i wiringpi-latest.deb</code>
* Check if the correct version was installed: <code>gpio -v</code>
** This should output version 2.52.

Once WiringPi is installed and configured correctly, the Dragino LoRa/GPS Hat can be set up to act as a few different things.


=== LoRa Single Channel Gateway ===

The Dragino LoRa Hat can be setup as an 868 MHz single-channel LoRa gateway. To do this, we can leverage existing software. - ''sudo apt install git'' - ''git clone https://github.com/tftelkamp/single_chan_pkt_fwd'' - ''cd ~/single_chan_pkt_fwd'' - ''nano main.cpp''

In the main.cpp file, you can define variables necessary for registering the gateway (e.g. longitude and latitude) - You must also change the server IP to the IP of eu1.cloud.thethings.network (52.212.223.226).

* <code>make</code>
* <code>sudo ./single_chan_pkt_fwd</code>

You can hit Ctrl+Z to exit the program and close down the gateway - this means the gateway is only running when the command is executed.


=== Registering the Gateway in The Things Network ===

After starting the gateway program as stated before, the Gateway ID will be displayed (see image below).

[[File:GatewayID.png]]

You can now register a new gateway in the TTN console with this ID. If everything is configured correctly, you should see some activity coming from the gateway.

'''Note:''' By default, the Things Network will not display single-channel gateways on the map of gateways, as they are considered less reliable. However, for most experimental purposes, they suffice.

File:GatewayID.png

2023-12-08T14:38:14Z

TNicholson:

Dragino LoRa Hat Single-Channel-Gateway

2023-12-08T14:37:33Z

TNicholson: Created page with " == Used Hardware: == * Raspberry Pi 4 * Dragino Raspberry Pi LoRa/GPS HAT * SD Card sufficient for Raspberry Pi OS Installation == Hardware Assembly == Carefully place the HAT onto the Raspberry Pi’s GPIO pins and gently push down. Always remember never to power on the HAT without a mounted antenna, as doing so could result in hardware damage. == System setup == F..."

== Used Hardware: ==

* Raspberry Pi 4
* Dragino Raspberry Pi LoRa/GPS HAT
* SD Card sufficient for Raspberry Pi OS Installation


== Hardware Assembly ==

Carefully place the HAT onto the Raspberry Pi’s GPIO pins and gently push down. Always remember never to power on the HAT without a mounted antenna, as doing so could result in hardware damage.


== System setup ==

For this hardware, a clean install of Raspberry Pi OS is recommended. I recommend using the Raspberry Pi Imager, as it allows you to pre-set ssh settings before flashing the OS.

* Connect to the Raspberry Pi via ssh
* Enable SPI interface: ''sudo raspi-config''
** Select Interface Options -> Select Yes when asked if you want to enable the SPI interface
* Reboot the Raspberry Pi: ''sudo shutdown -r now''

'''Note''': On the Raspberry Pi 4, there can be problems with installing the WiringPi package. If you encounter the same issue with an error message appearing when trying to install it, use the following commands to install a compatible version of WiringPi:

* <code>cd /tmp</code>
* <code>wget https://project-downloads.drogon.net/wiringpi-latest.deb</code>
* <code>sudo dpkg -i wiringpi-latest.deb</code>
* Check if the correct version was installed: <code>gpio -v</code>
** This should output version 2.52.

Once WiringPi is installed and configured correctly, the Dragino LoRa/GPS Hat can be set up to act as a few different things.


=== LoRa Single Channel Gateway ===

The Dragino LoRa Hat can be setup as an 868 MHz single-channel LoRa gateway. To do this, we can leverage existing software. - ''sudo apt install git'' - ''git clone https://github.com/tftelkamp/single_chan_pkt_fwd'' - ''cd ~/single_chan_pkt_fwd'' - ''nano main.cpp''

In the main.cpp file, you can define variables necessary for registering the gateway (e.g. longitude and latitude) - You must also change the server IP to the IP of eu1.cloud.thethings.network (52.212.223.226).

* <code>make</code>
* <code>sudo ./single_chan_pkt_fwd</code>

You can hit Ctrl+Z to exit the program and close down the gateway - this means the gateway is only running when the command is executed.


=== Registering the Gateway in The Things Network ===

After starting the gateway program as stated before, the Gateway ID will be displayed.

You can now register a new gateway in the TTN console with this ID. If everything is configured correctly, you should see some activity coming from the gateway.

'''Note:''' By default, the Things Network will not display single-channel gateways on the map of gateways, as they are considered less reliable. However, for most experimental purposes, they suffice.

LoRaWAN / Riot-OS Setup

2023-11-30T10:59:03Z

TNicholson:

== Summary ==

Setting up a LoRaWAN application with Riot-OS on a STM32 LoRa and Sigfox Discovery Kit

== Requirements ==

* Operating system: Ubuntu
* Packages: git

== Description ==

=== Step 1 ===

Install the following packages

sudo apt-get update
sudo apt-get install git
openocd
gcc-multilib
build-essential
python-serial
libudev-dev
moserial

=== Step 2 ===

Install the toolchain

Goto https://developer.arm.com/downloads/-/gnu-rm and download
gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2
Move it to your home directory.

Uninstall old packages
sudo apt remove binutils-arm-none-eabi gcc-arm-none-eabi libnewlib-arm-none-eabi

Unzip the downloaded file
tar -xjvf gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2

Add the toolchain to your path
export PATH=$PATH:/home/(your user)/gcc-arm-none-eabi-7-2018-q2-update/bin/

=== Step 3 ===

Download Riot-OS

git clone https://github.com/RIOT-OS/RIOT.git myRIOT

=== Step 4 ===

Build and run "Hello World" on the STM32 LoRa and Sigfox kit.

Set the rights for your username to be able to flash the application on the board.

sudo usermod -a -G dialout <username>

Then reboot your computer.

Attach the antenna to the board - never use it without the antenna!
Connect the board to your computer via micro USB cable.

[[File:stm32loraBoardUSBconn.jpg]]

Start up moSerial and connect it with the board. Make sure to adjust the parameters as specified in the screenshot.

[[File:moSerial.jpg]]

Build and flash the application.

cd myRIOT/examples/hello-world
make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash

If you do not use a serial terminal like moserial or terraterm use term

make BOARD=b-l072z-lrwan1 term

You may also set the BOARD in the Makefile of the application.

=== Step 5 ===

Create an application at the TTN (The Things Network).

Register at https://www.thethingsnetwork.org/ and login. Click on your user name and select "Console", and then click on "Applications" and then on "Create Application".

[[File:Register_TTN_Application.png]]

After filling in the name and description for your application click on "Create Application" at the bottom.

Register the board for your application by clicking on "Register end device".

Choose the option "Enter device specifics manually" and select the options as shown in the image below. Most LoRaWAN versions will work fine for this example. The JoinEUI field can be filled with all zeros.

[[File:Register Device.png]]

Then click "Confirm" button next to the JoinEUI to continue.

Click the "Generate" button for both the DevEUI and the AppKey as shown in the image below.
When completed, click "Register end device".

[[File:Register Device 2.png]]

You will now be redirected to the end device page. In the device overview, you can see all the parameters you need for the Makefile.

[[File:Copy from here.png]]

Now you can copy each key and paste it in your Makefile (cf. Step 6).

=== Step 6 ===

Build and run LoRaWAN Riot application.

cd myRIOT/examples/lorawan

Now edit the Makefile: insert device EUI, application EUI, and application key.

[[File:makefile.jpg]]

Build the application and flash it to the board.

make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash term

Goto to your TTN account and click on "Data" - there you can see the incoming data.

If you get "Join procedure failed" output and all your EUIs in the makefile are correct, then press the RESET button (black) on your board.

== Used Hardware ==

[[STM32 LoRa and Sigfox Discovery kit]]

== Courses ==

* [[Internet- & Netzwerktechnologien]] (2019)

== References ==

* https://www.thethingsnetwork.org/
* https://developer.arm.com/

[[Category:Documentation]]

LoRaWAN / Riot-OS Setup

2023-11-30T10:47:21Z

TNicholson: Updated images and instructions to new TTN version

== Summary ==

Setting up a LoRaWAN application with Riot-OS on a STM32 LoRa and Sigfox Discovery Kit

== Requirements ==

* Operating system: Ubuntu 18.04 bionic amd64
* Packages: git

== Description ==

=== Step 1 ===

Install the following packages

sudo apt-get update
sudo apt-get install git
openocd
gcc-multilib
build-essential
python-serial
libudev-dev
moserial

=== Step 2 ===

Install the toolchain

Goto https://developer.arm.com/downloads/-/gnu-rm and download
gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2
Move it to your home directory.

Uninstall old packages
sudo apt remove binutils-arm-none-eabi gcc-arm-none-eabi libnewlib-arm-none-eabi

Unzip the downloaded file
tar -xjvf gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2

Add the toolchain to your path
export PATH=$PATH:/home/(your user)/gcc-arm-none-eabi-7-2018-q2-update/bin/

=== Step 3 ===

Download Riot-OS

git clone https://github.com/RIOT-OS/RIOT.git myRIOT

=== Step 4 ===

Build and run "Hello World" on the STM32 LoRa and Sigfox kit.

Set the rights for your username to be able to flash the application on the board.

sudo usermod -a -G dialout <username>

Then reboot your computer.

Attach the antenna to the board - never use it without the antenna!
Connect the board to your computer via micro USB cable.

[[File:stm32loraBoardUSBconn.jpg]]

Start up moSerial and connect it with the board. Make sure to adjust the parameters as specified in the screenshot.

[[File:moSerial.jpg]]

Build and flash the application.

cd myRIOT/examples/hello-world
make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash

If you do not use a serial terminal like moserial or terraterm use term

make BOARD=b-l072z-lrwan1 term

You may also set the BOARD in the Makefile of the application.

=== Step 5 ===

Create an application at the TTN (The Things Network).

Register at https://www.thethingsnetwork.org/ and login. Click on your user name and select "Console", and then click on "Applications" and then on "Create Application".

[[File:Register_TTN_Application.png]]

After filling in the name and description for your application click on "Create Application" at the bottom.

Register the board for your application by clicking on "Register end device".

Choose the option "Enter device specifics manually" and select the options as shown in the image below. Most LoRaWAN versions will work fine for this example. The JoinEUI field can be filled with all zeros.

[[File:Register Device.png]]

Then click "Confirm" button next to the JoinEUI to continue.

Click the "Generate" button for both the DevEUI and the AppKey as shown in the image below.
When completed, click "Register end device".

[[File:Register Device 2.png]]

You will now be redirected to the end device page. In the device overview, you can see all the parameters you need for the Makefile.

[[File:Copy from here.png]]

Now you can copy each key and paste it in your Makefile (cf. Step 6).

=== Step 6 ===

Build and run LoRaWAN Riot application.

cd myRIOT/examples/lorawan

Now edit the Makefile: insert device EUI, application EUI, and application key.

[[File:makefile.jpg]]

Build the application and flash it to the board.

make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash term

Goto to your TTN account and click on "Data" - there you can see the incoming data.

If you get "Join procedure failed" output and all your EUIs in the makefile are correct, then press the RESET button (black) on your board.

== Used Hardware ==

[[STM32 LoRa and Sigfox Discovery kit]]

== Courses ==

* [[Internet- & Netzwerktechnologien]] (2019)

== References ==

* https://www.thethingsnetwork.org/
* https://developer.arm.com/

[[Category:Documentation]]

File:Edit makefile.png

2023-11-30T10:44:38Z

TNicholson:

File:Copy from here.png

2023-11-30T10:43:39Z

TNicholson:

File:Register Device 2.png

2023-11-30T10:30:50Z

TNicholson:

File:Register Device.png

2023-11-30T10:29:50Z

TNicholson:

LoRaWAN / Riot-OS Setup

2023-11-30T10:28:55Z

TNicholson:

== Summary ==

Setting up a LoRaWAN application with Riot-OS on a STM32 LoRa and Sigfox Discovery Kit

== Requirements ==

* Operating system: Ubuntu 18.04 bionic amd64
* Packages: git

== Description ==

=== Step 1 ===

Install the following packages

sudo apt-get update
sudo apt-get install git
openocd
gcc-multilib
build-essential
python-serial
libudev-dev
moserial

=== Step 2 ===

Install the toolchain

Goto https://developer.arm.com/downloads/-/gnu-rm and download
gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2
Move it to your home directory.

Uninstall old packages
sudo apt remove binutils-arm-none-eabi gcc-arm-none-eabi libnewlib-arm-none-eabi

Unzip the downloaded file
tar -xjvf gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2

Add the toolchain to your path
export PATH=$PATH:/home/(your user)/gcc-arm-none-eabi-7-2018-q2-update/bin/

=== Step 3 ===

Download Riot-OS

git clone https://github.com/RIOT-OS/RIOT.git myRIOT

=== Step 4 ===

Build and run "Hello World" on the STM32 LoRa and Sigfox kit.

Set the rights for your username to be able to flash the application on the board.

sudo usermod -a -G dialout <username>

Then reboot your computer.

Attach the antenna to the board - never use it without the antenna!
Connect the board to your computer via micro USB cable.

[[File:stm32loraBoardUSBconn.jpg]]

Start up moSerial and connect it with the board. Make sure to adjust the parameters as specified in the screenshot.

[[File:moSerial.jpg]]

Build and flash the application.

cd myRIOT/examples/hello-world
make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash

If you do not use a serial terminal like moserial or terraterm use term

make BOARD=b-l072z-lrwan1 term

You may also set the BOARD in the Makefile of the application.

=== Step 5 ===

Create an application at the TTN (The Things Network).

Register at https://www.thethingsnetwork.org/ and login. Click on your user name and select "Console", and then click on "Applications" and then on "Create Application".

[[File:Register_TTN_Application.png]]

After filling in the name and description for your application click on "Create Application" at the bottom.

Register the board for your application by clicking on "Register device".

[[File:regDevice.jpg]]

Enter a unique ID for your device and generate a device EUI. Then click on "Register".

The Device Overview shows all keys you need for your code.

[[File:devOverview.jpg]]

Now you can copy each key and paste it in your Makefile (cf. Step 6).

=== Step 6 ===

Build and run LoRaWAN Riot application.

cd myRIOT/examples/lorawan

Now edit the Makefile: insert device EUI, application EUI, and application key.

[[File:makefile.jpg]]

Build the applictation and flash it to the board.

make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash term

Goto to your TTN account and click on "Data" - there you can see the incoming data.

If you get "Join procedure failed" output and all your EUIs in the makefile are correct, then press the RESET button (black) on your board.

== Used Hardware ==

[[STM32 LoRa and Sigfox Discovery kit]]

== Courses ==

* [[Internet- & Netzwerktechnologien]] (2019)

== References ==

* https://www.thethingsnetwork.org/
* https://developer.arm.com/

[[Category:Documentation]]

File:Register TTN Application.png

2023-11-30T10:27:18Z

TNicholson: UI for registering an Application on TTN with the new Things Stack V3

== Summary ==
UI for registering an Application on TTN with the new Things Stack V3

LoRaWAN / Riot-OS Setup

2023-11-30T08:44:40Z

TNicholson:

== Summary ==

Setting up a LoRaWAN application with Riot-OS on a STM32 LoRa and Sigfox Discovery Kit

== Requirements ==

* Operating system: Ubuntu 18.04 bionic amd64
* Packages: git

== Description ==

=== Step 1 ===

Install the following packages

sudo apt-get update
sudo apt-get install git
openocd
gcc-multilib
build-essential
python-serial
libudev-dev
moserial

=== Step 2 ===

Install the toolchain

Goto https://developer.arm.com/downloads/-/gnu-rm and download
gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2
Move it to your home directory.

Uninstall old packages
sudo apt remove binutils-arm-none-eabi gcc-arm-none-eabi libnewlib-arm-none-eabi

Unzip the downloaded file
tar -xjvf gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2

Add the toolchain to your path
export PATH=$PATH:/home/(your user)/gcc-arm-none-eabi-7-2018-q2-update/bin/

=== Step 3 ===

Download Riot-OS

git clone https://github.com/RIOT-OS/RIOT.git myRIOT

=== Step 4 ===

Build and run "Hello World" on the STM32 LoRa and Sigfox kit.

Set the rights for your username to be able to flash the application on the board.

sudo usermod -a -G dialout <username>

Then reboot your computer.

Attach the antenna to the board - never use it without the antenna!
Connect the board to your computer via micro USB cable.

[[File:stm32loraBoardUSBconn.jpg]]

Start up moSerial and connect it with the board. Make sure to adjust the parameters as specified in the screenshot.

[[File:moSerial.jpg]]

Build and flash the application.

cd myRIOT/examples/hello-world
make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash

If you do not use a serial terminal like moserial or terraterm use term

make BOARD=b-l072z-lrwan1 term

You may also set the BOARD in the Makefile of the application.

=== Step 5 ===

Create an application at the TTN (The Things Network).

Register at https://www.thethingsnetwork.org/ and login. Click on your user name and select "Console", and then click on "Applications" and then on "add application".

[[File:TTNaddApp.jpg]]

After filling in the name and description for your application click on "Add Application" (bottom right).

Register the board for your application by clicking on "Register device".

[[File:regDevice.jpg]]

Enter a unique ID for your device and generate a device EUI. Then click on "Register".

The Device Overview shows all keys you need for your code.

[[File:devOverview.jpg]]

Now you can copy each key and paste it in your Makefile (cf. Step 6).

=== Step 6 ===

Build and run LoRaWAN Riot application.

cd myRIOT/examples/lorawan

Now edit the Makefile: insert device EUI, application EUI, and application key.

[[File:makefile.jpg]]

Build the applictation and flash it to the board.

make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash term

Goto to your TTN account and click on "Data" - there you can see the incoming data.

If you get "Join procedure failed" output and all your EUIs in the makefile are correct, then press the RESET button (black) on your board.

== Used Hardware ==

[[STM32 LoRa and Sigfox Discovery kit]]

== Courses ==

* [[Internet- & Netzwerktechnologien]] (2019)

== References ==

* https://www.thethingsnetwork.org/
* https://developer.arm.com/

[[Category:Documentation]]

LoRaWAN / Riot-OS Setup

2023-11-30T08:22:02Z

TNicholson:

== Summary ==

Setting up a LoRaWAN application with Riot-OS on a STM32 LoRa and Sigfox Discovery Kit

== Requirements ==

* Operating system: Ubuntu 18.04 bionic amd64
* Packages: git

== Description ==

=== Step 1 ===

Install the following packages

sudo apt-get update
sudo apt-get install git
openocd
gcc-multilib
build-essential
python-serial
libudev-dev
moserial

=== Step 2 ===

Install the toolchain

Goto https://developer.arm.com/downloads/-/gnu-rm and download
gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2
Move it to your home directory.

Uninstall old packages
sudo apt remove binutils-arm-none-eabi gcc-arm-none-eabi libnewlib-arm-none-eabi

Unzip the downloaded file
tar -xjvf gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2

Add the toolchain to your path
export PATH=$PATH:/home/(your user)/gcc-arm-none-eabi-7-2018-q2-update/bin/

=== Step 3 ===

Download Riot-OS

git clone https://github.com/RIOT-OS/RIOT.git myRIOT

=== Step 4 ===

Build and run "Hello World" on the STM32 LoRa and Sigfox kit.

Set the rights for your username to be able to flash the application on the board.

sudo usermod -a -G dialout <username>

Then reboot your computer.

Attach the antenna to the board - never use it without the antenna!
Connect the board to your computer via micro USB cable.

[[File:stm32loraBoardUSBconn.jpg]]

Start up moSerial and connect it with the board.

[[File:moSerial.jpg]]

Build and flash the application.

cd myRIOT/examples/hello-world
make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash

If you do not use a serial terminal like moserial or terraterm use term

make BOARD=b-l072z-lrwan1 term

You may also set the BOARD in the Makefile of the application.

=== Step 5 ===

Create an application at the TTN (The Things Network).

Register at https://www.thethingsnetwork.org/ and login. Click on your user name and select "Console", and then click on "Applications" and then on "add application".

[[File:TTNaddApp.jpg]]

After filling in the name and description for your application click on "Add Application" (bottom right).

Register the board for your application by clicking on "Register device".

[[File:regDevice.jpg]]

Enter a unique ID for your device and generate a device EUI. Then click on "Register".

The Device Overview shows all keys you need for your code.

[[File:devOverview.jpg]]

Now you can copy each key and paste it in your Makefile (cf. Step 6).

=== Step 6 ===

Build and run LoRaWAN Riot application.

cd myRIOT/examples/lorawan

Now edit the Makefile: insert device EUI, application EUI, and application key.

[[File:makefile.jpg]]

Build the applictation and flash it to the board.

make BOARD=b-l072z-lrwan1
make BOARD=b-l072z-lrwan1 flash term

Goto to your TTN account and click on "Data" - there you can see the incoming data.

If you get "Join procedure failed" output and all your EUIs in the makefile are correct, then press the RESET button (black) on your board.

== Used Hardware ==

[[STM32 LoRa and Sigfox Discovery kit]]

== Courses ==

* [[Internet- & Netzwerktechnologien]] (2019)

== References ==

* https://www.thethingsnetwork.org/
* https://developer.arm.com/

[[Category:Documentation]]

Flare VM Installation

2023-11-06T14:39:10Z

TNicholson:

Flare VM is a Windows distribution specifically designed for Malware Analysis. It includes all the relevant tools to get started in this field.


== Step 1: Setup Virtual Machine ==

First, you need to setup a Windows 10 virtual machine. This can be done by downloading the ISO from Microsoft and installing it inside your preferred hypervisor, such as VirtualBox or VMware Workstation. The VM must satisfy the following requirements:

* IMPORTANT: The network adapter of the virtual machine must be set to the Host-only settings. This is extremely important to prevent potential spreading of malware onto the host system or network.
* The hard drive of the VM must be at least 60 GB large, RAM should be at least 2 GB (more is recommended)
* Your Windows Username should not include any spaces or special characters
* Tamper Protection and any Antivirus program must be disabled.
* Windows Updates should also be disabled.

[[File:FlareVM-Configuration.png|thumb|none|alt=VM configuration (VMWare Workstation)|VM configuration (VMware Workstation)]]


== Step 2: Install Flare VM ==

Go to the official FlareVM Github repository (https://github.com/mandiant/flare-vm)

# Download the install.ps1 script
# Open Powershell as Administrator
# Go to the directory the script is located in and run: Unblock-File ..ps1
# Enable script execution: Set-ExecutionPolicy Unrestricted
# Type Y to accept
# Finally, exeute the script: .\install.ps1 and enter your Windows password when prompted

This installation can take some time (up to 3 hours). Your machine will reboot a few times during the installation.

Once you see “Type ENTER to exit:”, type Enter to Exit the script - then, the installation is complete.

Now, you should definitely save a snapshot of the VM so you can always revert back to this state if needed. In case of any failed package installations, the install script should also generate a failed_packages.txt file, in which the tools that failed to install correctly are listed. In case you need one of those tools, you can then install it manually. Now, you can get started with analyzing some malware samples!

== References ==
https://github.com/mandiant/flare-vm

https://www.mandiant.com/resources/blog/flare-vm-the-windows-malware

[[Category:Documentation]]

File:FlareVM-Configuration.png

2023-11-06T14:35:22Z

TNicholson:

Flare VM Installation

2023-11-06T13:57:37Z

TNicholson:

Flare VM is a Windows distribution specifically designed for Malware Analysis. It includes all the relevant tools to get started in this field.


== Step 1: Setup Virtual Machine ==

First, you need to setup a Windows 10 virtual machine. This can be done by downloading the ISO from Microsoft and installing it inside your preferred hypervisor, such as VirtualBox or VMware Workstation. The VM must satisfy the following requirements:

* IMPORTANT: The network adapter of the virtual machine must be set to the Host-only settings. This is extremely important to prevent potential spreading of malware onto the host system or network.
* The hard drive of the VM must be at least 60 GB large, RAM should be at least 2 GB (more is recommended)
* Your Windows Username should not include any spaces or special characters
* Tamper Protection and any Antivirus program must be disabled.
* Windows Updates should also be disabled.


== Step 2: Install Flare VM ==

Go to the official FlareVM Github repository (https://github.com/mandiant/flare-vm)

# Download the install.ps1 script
# Open Powershell as Administrator
# Go to the directory the script is located in and run: Unblock-File ..ps1
# Enable script execution: Set-ExecutionPolicy Unrestricted
# Type Y to accept
# Finally, exeute the script: .\install.ps1 and enter your Windows password when prompted

This installation can take some time (up to 3 hours). Your machine will reboot a few times during the installation.

Once you see “Type ENTER to exit:”, type Enter to Exit the script - then, the installation is complete.

Now, you should definitely save a snapshot of the VM so you can always revert back to this state if needed. In case of any failed package installations, the install script should also generate a failed_packages.txt file, in which the tools that failed to install correctly are listed. In case you need one of those tools, you can then install it manually. Now, you can get started with analyzing some malware samples!

== References ==
https://github.com/mandiant/flare-vm

https://www.mandiant.com/resources/blog/flare-vm-the-windows-malware

[[Category:Documentation]]

Flare VM Installation

2023-11-06T13:52:07Z

TNicholson:

Flare VM is a Windows distribution specifically designed for Malware Analysis. It includes all the relevant tools to get started in this field.


== Step 1: Setup Virtual Machine ==

First, you need to setup a Windows 10 virtual machine. This can be done by downloading the ISO from Microsoft and installing it inside your preferred hypervisor, such as VirtualBox or VMware Workstation. The VM must satisfy the following requirements:

* IMPORTANT: The network adapter of the virtual machine must be set to the Host-only settings. This is extremely important to prevent potential spreading of malware onto the host system or network.
* The hard drive of the VM must be at least 60 GB large, RAM should be at least 2 GB (more is recommended)
* Your Windows Username should not include any spaces or special characters
* Tamper Protection and any Antivirus program must be disabled.
* Windows Updates should also be disabled.


== Step 2: Install Flare VM ==

Go to the official FlareVM Github repository (https://github.com/mandiant/flare-vm)

# Download the install.ps1 script
# Open Powershell as Administrator
# Go to the directory the script is located in and run: Unblock-File ..ps1
# Enable script execution: Set-ExecutionPolicy Unrestricted
# Type Y to accept
# Finally, exeute the script: .\install.ps1 and enter your Windows password when prompted

This installation can take some time (up to 3 hours). Your machine will reboot a few times during the installation.

Once you see “Type ENTER to exit:”, type Enter to Exit the script - then, the installation is complete.

Now, you should definitely save a snapshot of the VM so you can always revert back to this state if needed. In case of any failed package installations, the install script should also generate a failed_packages.txt file, in which the tools that failed to install correctly are listed. In case you need one of those tools, you can then install it manually. Now, you can get started with analyzing some malware samples!
[[Category:Documentation]]

Flare VM Installation

2023-11-06T13:46:30Z

TNicholson:

Flare VM is a Windows distribution specifically designed for Malware Analysis. It includes all the relevant tools to get started in this field.


== Step 1: Setup Virtual Machine ==

First, you need to setup a Windows 10 virtual machine. This can be done by downloading the ISO from Microsoft and installing it inside your preferred hypervisor, such as VirtualBox or VMware Workstation. The VM must satisfy the following requirements:

* IMPORTANT: The network adapter of the virtual machine must be set to the Host-only settings. This is extremely important to prevent potential spreading of malware onto the host system or network.
* The hard drive of the VM must be at least 60 GB large, RAM should be at least 2 GB (more is recommended)
* Your Windows Username should not include any spaces or special characters
* Tamper Protection and any Antivirus program must be disabled.
* Windows Updates should also be disabled.


== Step 2: Install Flare VM ==

Go to the official FlareVM Github repository (https://github.com/mandiant/flare-vm)

# Download the install.ps1 script
# Open Powershell as Administrator
# Go to the directory the script is located in and run: Unblock-File ..ps1
# Enable script execution: Set-ExecutionPolicy Unrestricted
# Type Y to accept
# Finally, exeute the script: .\install.ps1 and enter your Windows password when prompted

This installation can take some time (up to 3 hours). Your machine will reboot a few times during the installation.

Once you see “Type ENTER to exit:”, type Enter to Exit the script - then, the installation is complete.

Now, you should definitely save a snapshot of the VM so you can always revert back to this state if needed. In case of any failed package installations, the install script should also generate a failed_packages.txt file, in which the tools that failed to install correctly are listed. In case you need one of those tools, you can then install it manually. Now, you can get started with analyzing some malware samples!

Flare VM Installation

2023-10-28T13:56:32Z

TNicholson:

OWASP Zed Attack Proxy

2023-10-28T13:56:19Z

TNicholson: TNicholson moved page (Article title) to Flare VM Installation

#REDIRECT [[Flare VM Installation]]