meltdown - This repository contains several applications, dem

项目说明

Meltdown Proof-of-Concept

This repository contains several applications, demonstrating the Meltdown bug. For technical information about the bug, refer to the paper:

* Meltdown by Lipp, Schwarz, Gruss, Prescher, Haas, Mangard, Kocher, Genkin, Yarom, and Hamburg

The applications in this repository are built with libkdump, a library we de for the paper. This library simplifies exploitation of the bug by automatically adapting to certain properties of the en.

This repository contains several demonstrating Meltdown

* Video #1 shows how Meltdown can be used to spy in realtime on a password input.
* Video #2 shows how Meltdown leaks physical memory content.
* Video #3 shows how Meltdown reconstructs a photo from memory.
* Video #4 shows how Meltdown reconstructs a photo from memory which is encoded with the FLIF file format.
* Video #5 shows how Meltdown leaks uncached memory.

Demos

This repository contains fi to demonstrate different use cases. All demos are tested on Ubuntu 16.04 with an Intel Core i7-6700K, but they should work on any Linux system with any modern Intel CPU since 2010.

For best results, we recommend a fast CPU that supports Intel TSX (e.g. any Intel Core i7-5xxx, i7-6xxx, or i7-7xxx).
Furthermore, every demo should be pinned to one CPU core, e.g. with taskset.

Build dependency for demos

As a pre-requisite, you need to install glibc-static on your machine.

For RPM-based systems:

Demo #1: A first test (test)

This is the most basic demo. It uses Meltdown to read accessible addresses from the own address space, not breaking any isolation mechanisms.

If this demo does not work for you, the remaining demos most likely won't work either. The reasons are manifold, e.g., the CPU could be too slow, not support out-of-order execution, the high-resolution timer is not precise enough (especially in VMs), the operating system does not support custom signal handlers, etc.

#### Build and Run

If you see an output similar to this

then the basic demo works.

Demo #2: Breaking KASLR (kaslr)

Starting with Linux kernel 4.12, KASLR (Kernel Address Space Layout Randomizaton) is active by default. This means, that the location of the kernel (and also the direct physical map which maps the entire physical memory) changes with each reboot.

This demo uses Meltdown to leak the (secret) randomization of the direct physical map. This demo requires root pri to speed up the process. The paper describes a which does not require root pri.

#### Build and Run

After a few seconds, you should see something similar to this

Demo #3: Reliability test (reliability)

This demo tests how reliable physical memory can be read. For this demo, you either need the direct physical map offset (e.g. from demo #2) or you have to disable KASLR by specifying nokaslr in your kernel command line.

#### Build and Run

Build and start reliability. If you ha enabled, the first parameter is the offset of the direct physical map. Otherwise, the program does not require a parameter.

After a few seconds, you should get an output similar to this:

Demo #4: Read physical memory (physical_reader)

This demo reads memory from a different process by directly reading physical memory. For this demo, you either need the direct physical map offset (e.g. from demo #2) or you have to disable KASLR by specifying nokaslr in your kernel command line.

In principal, this program can read arbitrary physical addresses. However, as the physical memory contains a lot of non-human-readable data, we provide a test 工具 (secret), which puts a human-readable string into memory and directly provides the physical address of this string.

#### Build and Run

For the demo, first run secret (as root) to get the physical address of a human-readable string:

It should output something like this:

While the secret program is running, start physical_reader. The first parameter is the physical address printed by secret. If you do not ha disabled, the second parameter is the offset of the direct physical map.

After a few seconds, you should get an output similar to this:

Demo #5: Dump the memory (memdump)

This demo dumps the content of the memory. As demo #3 and #4, it uses the direct physical map, to dump the contents of the physical memory in a hexdump-like format.

Again, as the physical memory contains a lot of non-human-readable content, we provide a test 工具 to fill large amounts of the physical memory with human-readable strings.

#### Build and Run

For the demo, first run memory_filler to fill the memory with human-readable strings. The first argument is the amount of memory (in gigabytes) to fill.

Then, run the memdump 工具 to dump memory contents. If you executed memory_filler before, you should see some string fragments.
If you ha or Chrome with multiple tabs running, you might also see parts of the websites which are open or were recently closed.

The first parameter is the physical address at which the dump should begin (lea to start at the first gigabyte). The second parameter is the amount of bytes you want to be read, to read it all give -1. If you do not ha disabled, the third parameter is the offset of the direct physical map.

You should get a hexdump of parts of the memory (potentially e secrets such as passwords, see example in the paper), e.g.:

Frequently Asked Questions

* Does it work on Windows / Ubuntu on Windows (WSL) / Mac OS?

No. This PoC only works on Linux, as it uses properties specific to the Linux kernel, such as the direct physical map.

* Can I run the PoC in a machine?

Yes, the PoC also works on machines. However, due to the additional layer introduced by a machine, it might not work as good as on nati.

* The KASLR program (kaslr) does not find the offset!

The kaslr 工具 only does very few measurements to be fast. If it does not find the offset, there are two possibilities:

* change the number of retries in kaslr.c: config.retries = 1000;
* use the kernel module in kaslr_offset to directly read the offset from the kernel. Install the kernel headers for your kernel () and run sudo ./direct_physical_map.sh

* You said it works on uncached memory, but all your demos ensure that the memory is cached!

Making it work on uncached memory is trickier, and often requires a bit of tweaking of the parameters. Thus, we ensure that the memory is cached in the PoC to make it easier to reproduce. However, you can simply remove the 代码 that caches the and replace it by a clflush to test the exploit on uncached memory (see Video #5 for an example).
Although not in the original blog post by Google, this was also confirmed by independent researchers (e.g. Alex Ionescu, Raphael Carvalho, Pa).

* It just does not work on my computer, what can I do?

There can be a lot of different reasons for that. We collected a few things you can try:

* Ensure that your CPU frequency is at the maximum, and frequency scaling is disabled.
* If you run it on a mobile device (e.g., a laptop), ensure that it is plugged in to get the best performance.
* Try to pin the tools to a specific CPU core (e.g. with taskset). Also try different cores and core combinations.
* Vary the load on your computer. On some machines it works better if the load is higher, on others it works better if the load is lower.
* Try to disable hyperthreading in the BIOS. On some computers it works a lot better if hyperthreading is disabled.
* Use a different of Meltdown. This can be changed in libkdump/libkdump.c in the line #define MELTDOWN meltdown_nonull. Try for example meltdown instead of meltdown_nonull, which works a lot better on some machines (but not at all on others).
* Try to create many interrupts, e.g. by running the 工具 stress with stress -i 2 (or other for the i parameter, depending on the number of cores).
* Try to restart the demos and also your computer. Especially after a standby, the timing are broken on some computers.
* Play around with the parameters of libkdump, e.g. increase the number of retries and/or measurements.

Warnings

Warning #1: We are pro this 代码 as-is. You are responsible for protecting yourself, your property and data, and others from any risks caused by this 代码. This 代码 may cause unexpected and undesirable behavior to occur on your machine. This 代码 may not detect the on your machine.

Warning #2: If you find that a computer is susceptible to the Meltdown bug, you may want to avoid using it as a multi-user system. Meltdown breaches the CPU's memory protection. On a machine that is susceptible to the Meltdown bug, one process can read all pages used by other processes or by the kernel.

Warning #3: This 代码 is only for testing purposes. Do not run it on any producti. Do not run it on any system that might be used by another person or entity.

项目信息

开发语言：C

Star 数：4169

技术要点

该项目属于黑客技术方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕This repository contains several applications, demonstrating the Meltdown bug.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。