jprx

6 ms·

1.
Show HN: Darwin-VM – run the latest iOS and macOS in QEMU(github.com)
2 points by jprx 1mo ago|0 comments
2.
by jprx 4mo ago
Haven't gotten around to it yet haha
3.
by jprx 4mo ago
Hi everyone, Joseph (paper author) here. You can find Fractal on Github: https://github.com/jprx/fractal The full paper, slides from my S&P talk, and all our experiment data can be found at the Fractal project webs
4.
by jprx 1y ago
You can find PDFs of the lectures as well as the reading list here: https://shd.mit.edu/2025/calendar.html https://shd.mit.edu/2025/lectureReadings.html
5.
by jprx 1y ago
Personally, I learned programming when I was a kid by watching YouTube tutorials + reading random Internet sources. When helping build SHD, it was important to me that we "paid it forward" & made all our lab materials open for
6.
by jprx 1y ago
We teach using Intel X86_64 CPUs for a variety of reasons - Most academic research has been done on Intel systems, so it's easier for students reading papers to relate to their experiences in the labs - X86_64 provides convenient cache
7.
by jprx 2y ago
Yes! Our labs include building your own real spectre attack against the kernel, bypassing ASLR and building ROP chains with various side channels, finding and exploiting backdoors in a RISC-V CPU by building a hardware fuzzer, and more. (so
8.
A wild race condition in the macOS kernel (CVE-2025-24118)(jprx.io)
4 points by jprx 2y ago|0 comments
9.
Susctl CVE-2024-54507: A particularly 'sus' sysctl in the XNU kernel(jprx.io)
148 points by jprx 2y ago|41 comments
10.
by jprx 2y ago
You get it!!
11.
A buffer overflow in the XNU kernel(jprx.io)
146 points by jprx 2y ago|35 comments
12.
by jprx 4y ago
Unwinding changes to the TLB on every mispredict would have a significant overhead and hurt overall performance. Removing valid data you just cached (speculatively or otherwise) is generally a bad idea. User mode software requires a TLB (un
13.
by jprx 4y ago
Additionally, if can find a way to trick a user into installing a malicious kext, why even bother with PACMAN? You already have arbitrary kernel code execution!
14.
by jprx 4y ago
You could maybe do it with lots of fences or just a ridiculous chain of NOPs after each branch such that the ROB is cleared before you have time to try to load a pointer speculatively. In practice, both of these would probably kill performa
15.
by jprx 4y ago
Pretty much! (There are a few aspects that make this challenging in practice, but that's the idea).
16.
by jprx 4y ago
ILL-INI!!! 1) Our attack does apply a brute force technique with the twist that crashes are suppressed via speculative execution. If you tried to brute force a PAC against the kernel, you'd instantly panic your device and have to reboo
17.
by jprx 4y ago
This is a great question! What this means is that a software patch cannot fix the speculative execution behavior that causes the PACMAN issue since it is built directly into how the hardware operates.
18.
by jprx 4y ago
You can think of it a lot like that! PAC is more advanced as you can describe what a pointer "should" do on access (aka is this a data or code pointer?).
19.
by jprx 4y ago
Hi! This is an interesting idea. However, there is a problem that arises- if you rotate the key, then old pointers now become invalid. And since the kernel is always alive and servicing requests (and contains structures with very long lifet
20.
by jprx 4y ago
Hi! I think I can clear a few things up here. Our goal is to demonstrate that we can learn the PAC for a kernel pointer from userspace. Just demonstrating that this is even possible is a big step in understanding of how mitigations like poi
21.
by jprx 4y ago
You hit the nail right on the head! That's exactly what we did :)
22.
by jprx 4y ago
Hi! Joseph (one of the authors) here. You can read more about our attack here: https://pacmanattack.com
23.
by jprx 4y ago
Hi! Joseph (one of the authors) here. The PDF is available here: https://pacmanattack.com/paper.pdf
24.
Pacman: Hardware Bypass for Pointer Authentication on M1(pacmanattack.com)
3 points by jprx 4y ago|0 comments