martinradev/gdb-pt-dump

gdb-pt-dump's Issues

Print physical addresses in page table list

Can you also print out the physical address each virtual address maps to? Just looking at the code for AArch64_Block, it seems like we can just print self.phys to get this information.

Support a windows vm

• Test pt on a windows vm
• Print kaslr information

broken on 32-bit kernels

broken on 32-bit x86 kernel

pwndbg> pt
Cannot get qemu-system pid Unknown arch. Message: The target architecture is set to "auto" (currently "i386").

Support 39-bit VAs on AArch64

Android uses 39-bit VAs instead of 48-bit (CONFIG_ARM64_VA_BITS=39). pt -info detects this (T0SZ ( 0: 5) = 0x19 | 25 bits are truncated. TTBR0_EL1 addresses 39 bits.), but the AArch64 backend doesn't support it. I patched this locally to get it to work like this:

if granule == PT_AARCH64_4KB_PAGE:
    entries = []
    try:
        entries = split_range_into_int_values(read_page(phys_mem, tbl.pa), 8)
    except:
        pass
    target_address_low = 12
    last_level = 3
    sizes = [PT_SIZE_1GIB, PT_SIZE_2MIB, PT_SIZE_4K]
    index_ranges_per_lvl = [(30, 38), (21, 29), (12, 20)]
    # last_level = 4
    # sizes = [PT_SIZE_512GIB, PT_SIZE_1GIB, PT_SIZE_2MIB, PT_SIZE_4K]
    # index_ranges_per_lvl = [(39, 47), (30, 38), (21, 29), (12, 20)]

If it makes sense to you, I can put up a PR that properly adds a case for this where in addition to checking for PT_AARCH64_4KB_PAGE, we would also check for the 39-bit VAs. But I'm not sure exactly how the page tables will look for other granule sizes, so I'd only be able to fix and test this one configuration.

Use mnemonic values instead of hardcoded ones

It can be a bit hard to go back to the code to figure out what bit in a page table entry is what.
Define mnemonic values and use those.

Fix 'pt -kaslr' for aarch64

Implement tests for gdb-pt-dump

The project has a bunch of features which are not well-tested and protected against regressions. Tests are necessary to continue development.

Python Exception <class 'PermissionError'> [Errno 13] Permission denied

I'm trying to use this tools , but i get a error like this :

Python Exception <class 'PermissionError'> [Errno 13] Permission denied: '/proc/12171/mem':
Error occurred in Python: [Errno 13] Permission denied: '/proc/12171/mem'

How can I deal with it?
Thanks.

Allow filtering addresses while the page table is being parsed instead of after

My understanding of the code is that we first parse the entire page table, and then apply the filters. This makes sense when the purpose of the filters is just to limit the amount of information seen, but I need to filter out page ranges for performance issues.

I'm running a KASAN AArch64 image, which results in the following additional page table entries:

---[ Kasan shadow start ]---
0xffffffc000000000-0xffffffc004000000          64M PTE       RW NX SHD AF            UXN    MEM/NORMAL
0xffffffc004000000-0xffffffc040000000         960M PMD
0xffffffc040000000-0xffffffc400000000          15G PGD
0xffffffc400000000-0xffffffc480800000        2056M PTE       ro NX SHD AF            UXN    MEM/NORMAL
0xffffffc480800000-0xffffffc481000000           8M PMD
0xffffffc481000000-0xffffffc481399000        3684K PTE       RW NX SHD AF            UXN    MEM/NORMAL
0xffffffc481399000-0xffffffc481400000         412K PTE
0xffffffc481400000-0xffffffc482000000          12M PMD
0xffffffc482000000-0xffffffc483001000       16388K PTE       RW NX SHD AF            UXN    MEM/NORMAL
0xffffffc483001000-0xffffffc483200000        2044K PTE
0xffffffc483200000-0xffffffc4c0000000         974M PMD
0xffffffc4c0000000-0xffffffc7c0000000          12G PGD
0xffffffc7c0000000-0xffffffc7ebe00000         702M PMD
0xffffffc7ebe00000-0xffffffc7ebfee000        1976K PTE
0xffffffc7ebfee000-0xffffffc7ebfff000          68K PTE       RW NX SHD AF            UXN    MEM/NORMAL
0xffffffc7ebfff000-0xffffffc800000000      327684K PTE       ro NX SHD AF            UXN    MEM/NORMAL
---[ Kasan shadow end ]---

I don't really care about these, but gdb-pt-dump still tries to parse them, which ends up taking forever. I'm wondering if instead of filtering addresses after we've parsed the page table, we can skip addresses while the page table is being parsed, so I could specify a range that would completely skip this KASAN memory.

Rewrite gdb-pt-dump backend in Rust

Python language ergonomics are great for getting a prototype done but Python lacks in the following:

• performance: parsing page tables can involves going through hundreds of thousands of objects, which is slow in Python
• memory usage: memory consumption is too high when there are too many objects
• correctness: being a dynamically typed language, it requires a lot more testing to actually ensure that the code makes sense in all paths and states.

With Rust bindings for Python available through Pyo3, I don't see a reason that we don't have the backend be written in Rust. The only downside I see is that the installation model may need to change. Just copying over the scripts doesn't work since the Rust backend needs to be built.

Optimize page parsing when KASAN is used

With KASAN enabled, the address space is huge which leads to a significant slow down when parsing page tables. A similar issue is observed with the QEMU monitor.

Add 5-Level Paging Support

We need to implement 5-level paging support because the corresponding tests in pwndbg are failing.

pwndbg/pwndbg#2097 (comment)

Add option to find page aliases

A physical page can be mapped to many virtual pages. It would be nice to visualize aliases which may be helpful in determining weak points of randomization-based defenses.

Does pt support qemu user mode? -- Cannot get qemu-system pid

$ qemu-aarch64 -g 1234 -L /usr/aarch64-linux-gnu ./chall

$ gdb-multiarch -ex 'target remote 127.0.0.1:1234' ./chall

> pt -save -filter
Cannot get qemu-system pid

Can't save specific address with pt-dump

I'm trying to use pt-dump on a regular x64 environment,
I would like to save a specific address, however whenever I try to save one address I get the following error:

pt -save -addr 0xffff88813805f440

or

pt -addr 0xffff88813189e000

fail :/

Could you assist in solving this issue?
It sounds like there some weird parsing error there while parsing the address itself,
maybe I'm not using the tool correctly?

Thanks,
Guy

Support `-addr` for AArch64

It seems like only x86 supports the -addr argument at the moment. It would be useful to have this in other architectures, like AArch64, so I can print out page tables that aren't stored in TTBR0_EL1 or TTBR1_EL1 (like TTBR0_EL2 for example).

Prepare tutorial

Prepare a tutorial for how to use the commands and how they come useful.

Exception: Invalid cast. (pt -ss "...")

First off - thank you for making this tool. Seriously.

The issue on CTF challenge brohammer for Midnightsun 2021. I can provide kernel and initrd if you need it:

user:~/ws/midnightsun_2021$ qemu-x86_64 -version
qemu-x86_64 version 4.2.1 (Debian 1:4.2-3ubuntu6.12)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
user:~/ws/midnightsun_2021$ uname -a
Linux void 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux 
user:~/ws/midnightsun_2021$ python3 -V
Python 3.8.5
user:~/ws/midnightsun_2021$ gdb -v
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
user:~/ws/midnightsun_2021$ 


-------

gef➤  pt -ss "this is where the flag will be on the remote host.."
Exception: Invalid cast.
gef➤  pt -ss 'this is where the flag will be on the remote host..'
Exception: Invalid cast.

Any ideas?

Same name of package and its file may lead to NAMESPACE COLLISION

This issue occurred when I was using pwndbg on archlinux, when it calls "import pt".
And the package is installed by "pacman -S python-pt"

And sometimes，it works with import "pt.pt"(only when i rename the "pt" site-package and rename it back without closing the terminal thus the environment could not detect the pt.py in directory temporarily).
But this is not a very good solution.

Thank you for your attention to this issue.

Fix 64K granularity path for aarch64

PT_SIZE_512MIB happens to be undefined for aarch64 with 64K granularity.
This bug is just to track fixing this.

Pgrep qemu-system is not robust

Currently, gdb-pt-dump parses the output of pgrep qemu-system which is not robust if there are multiple PIDs returned.

Is there any better we can do here?

Relevant issue: pwndbg/pwndbg#1587 (comment)