In this article I will dissect what CPU Cache and TLB are. It can help understand how Meltdown and Specter work.
I’ve had a lot of time to dive into certain pecularities of how programs are outlined both in RAM and on disk when working as a malware analyst. One part of my job was to treat infected files. For that purpose I wrote remedy scripts. For them to work I had to have a solid underatanding where to perform the amputation. Since the topic might be a little confusing, I’ve published it here. Originally it was hand-written in my 💎 notebook 📓.
At the very beginning of my career I found it hard to grasp the notion of memory layout and stack. Even when I read about it several times, it didn’t feel solid. That’s why I drew drew and drew. Because my mind prefers pictures, analogies, metaphors and examples! So, I’ve made that. May be someone finds it useful.

I was thinking about a good metaphor, but that was the extent of my imagination… Let’s say some weirdo (let’s call him Gargaralian) is piling up all the boring books he has 📚 under the table because the appartment is too small and the luxury of having a bookcase is not an option available for him. Besides, the table is a little loose, so that pile of books could be like the fifth leg. Something like that:
During forensics investigation it’s sometimes needed to reverse engineer some suspicious piece of code. This section is a reverse engineering dive-in section.
In this article I am trying to reasearch compilation and linking process.
.cpp - is a human-readable file written in any programming language. In this example it’s a file written in C++. An example of this file (meaningless for simplicity sake):
#include <iostream>
using namespace std;
int main()
{
int a, b, c;
return 0;
}
.obj, .coff - binary file with its own structure. 1 file of source code (*.cpp) is compiled into 1 .obj or .coff file. Consists of sections, symbol table (name and current location of variable or function that can be referenced by other object files), relocation table (addresses referenced in this file that the linker must adjust when it knows the final memory layout) and debug info. A header that says where in the files the sections below are located A (concatenated) text segment, which contains all the source code (with some missing addresses) A (concatenated) data segment (which combines all data and the bss segments)
Is used to safe memory. For example, number 5 only occupies 1 byte, but 1032 will need two bytes to live. They are also little-endian values. But how to tell when the number ends? Easy, the most significant bit of every byte (byte being the smallest space occupied) tells the PC whether there are more bytes to come. So, for example, the following is the number 5, just five, no caveats:

⚠️ Note that x64 does not use this mechanism for exception handling.
Consider the following code:
int main()
{
__try
{
TestExceptions();
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
printf("Executing SEH __except block\r\n");
}
return 0;
}
How is that code handled in memory?
This is usually how the SEH is registered (Assembly view):
PUSH 0040184B
XOR EAX, EAX
PUSH DWORD PTR FS:[EAX]
MOV DWORD PTR FS:[EAX], ESP
NtGlobalFlag FLG_HEAP_ENABLE_TAIL_CHECK (0x10), FLG_HEAP_ENABLE_FREE_CHECK (0x20), and FLG_HEAP_VALIDATE_PARAMETERS (0x40)
One of the examples of a special files are:
/dev/stdin/dev/stdout/dev/random (PRNG which may delay returning a value to acquire additional entropy.) That is why when I cat /dev/random and do nothing else, it just prints the values, but when I start moving the mouse or turning on a movie - it’s hanging for a while./dev/urandom (PRNG which always returns a value immediately, regardless of required entropy.)https://www.computerhope.com/jargon/s/special-file.htm#character-special
[1] Manual unpacking (rus 🇷🇺)
[2] Unpacking FSG 2.0 (rus 🇷🇺)
[3] Introduction to unpacking (rus 🇷🇺)
[4] Unpacking Thunderbolt (rus 🇷🇺)
[5] Unpacking Beria (rus 🇷🇺)
[6] Unpacking PECompact 2.xx without using ImportRec (rus 🇷🇺)