landr0id

I still don't think that does anything regarding use-after-frees, only double-frees.

Here's the code: https://codeberg.org/ziglang/zig/src/commit/e44e927d33d37c44...

The closest callout in the doc comment is:

Never reuses memory addresses, making it easier for Zig to detect branch on undefined values in case of dangling pointers. This relies on the backing allocator to also not reuse addresses.

But it's not really clear what this means. "branch on undefined values" would I think indicate that maybe they're doing a fill pattern that the compiler can detect at runtime when dereferenced? But I don't see it in the `free` path. It's not clear if this is deterministic or not either.

The DebugAllocator catches use-after-free (at least on page-level)

To clarify, is that to say that you have to use the `std.heap.page_allocator` as its backing allocator?

ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory.

I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free?

While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "use-after-free" or "UaF" never occurs on that documentation page. Searching for "safety-checked" doesn't yield any related hits either.

Unless maybe they're using the DebugAllocator in release builds? Even that does not reliably surface UaF.

https://landaire.net/memory-safety-by-default-is-non-negotia...

For the Nomad: The caps slightly rotate. If you look at them from the side profile, they are also all varying heights. I found enough variance in the physical layout of keys that I was constantly making mistakes and pressing multiple keys simultaneously. It has this gimmicky magnetic riser on the back which the magnets fell out of. The display is just a gimmick but has a fun Tamagotchi-type thing that analyzes WPM, so that's cool at least.

The company itself had crazy production delays on both the Nomad and the Knob1, and seem to depend on hypebeast marketing. For $400 you would expect a very premium product and it's easy to argue that they missed the mark pretty hard.

Oh I also placed a pre-order and they refused to cancel after many delays. Unfortunately after that point it was too late for a chargeback.

*just found a random review if you want to see other opinions. The comments discuss some of the weird company shenanigans: https://old.reddit.com/r/MechanicalKeyboards/comments/1ngka3...

If anyone is looking at this thinking it looks pretty and wants to check out Work Louder's keyboards, let me save you the time. Their keyboards must be made by designers who do not type much because they are both not pleasant to type on and not very high-quality.

The Nomad [E] might be one of the worst keyboards I've ever purchased, and I owned one of the original butterfly switch MacBooks.

Big fan of nextest and this is my first time seeing this site. I'll be real I feel a bit ridiculous commenting this but you might want to consider rephrasing this:

Treat tests as cattle, not pets. Detect and terminate slow tests.

Not sure saying, "hey, treat your tests as an animal you can kill at will" paints the right image.

Yeah my bad for not defining it. "Extra-Sensory Perception", basically as you said I believe is the most common feature -- but in general I think encompasses cheats that generally boost your "senses". So it could use audio to visually draw on your screen/radar where the sound came from.

The screenshot in this repo is kind of similar to wallhacks, but you could imagine this could easily be extended to show dropped items and the 3D audio location: https://github.com/ryanjpwatts/esp-analysis

I wonder how often wall hacks are actually used in high-level competitive play by cheaters vs ESP. ESP seems like the better route to avoid manual review flagging suspicious activity. Audible cues (which this currently does not mitigate, and I'm not sure it can) are things that can genuinely separate players by skill and you'd think someone running such a cheat just has very good hearing.

CS2FOW uses static baked map geometry. Dynamic occluders such as doors, breakables, props, smokes, particles, and projectiles are intentionally out of scope for now.

Market window on Mirage just became more powerful on these servers :)

Very cool project nonetheless.

I suppose they did make their work public after all :)

Thank you for pulling up the references.

Not to take away from the authors' work, but this was actually the approach taken by some engineers while Spectre / Meltdown were still under embargo. Not sure if they ever mentioned their work publicly so I will avoid naming them, but some talented folks from Microsoft who basically came to the same conclusion that a specialized environment free of noise was necessary both to test mitigations and find variants.

I didn't really mind the fn keys being there. I rarely use function keys unless I'm RDP'd to a Windows machine.

What drove me crazy though was the escape key. They later added the physical escape key back but I think at that point it was a bit too late.

GPU memory/shaders/etc. isn't protected by MTE or PAC. They said "data-only", so I guess GPU commands could fit into this description.

Static analysis tools + MCP server + a debugger with an MCP server makes reverse engineering incredibly easy and low-cost.

I wrote a blog post about this recently: https://landaire.net/reverse-engineering-with-ai/

Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.

They exploited a linear stack buffer overflow. Not a write-what-where or arb write. A linear stack buffer overflow in 2026! There are at least two distinct failures there:

1. No strong stack protectors.

2. No kASLR.

That's 20-year-old exploit methodology.

Ask yourself why Mythos was so easily able to develop a remote STACK buffer overflow vulnerability.

Last I read, ASLR is a good thing to have, but overall is usually not difficult to defeat.

For local attackers there may be easier avenues to leak the ASLR slide, but for remote attackers it's almost universally agreed it significantly raises the bar.

I don't think it's reasonable to say that an OS that lacks it isn't "serious" about security.

When they implemented it in 2019 it had been an 18-year-old mitigation. If you are serious about security, you implement everything that raises the bar. The term "defense-in-depth" exists for a reason, and ASLR is probably one of the easiest and most effective defense-in-depth measures you can implement that doesn't necessarily require changes from existing code other than compiling with -pie.

FreeBSD didn’t have user land ASLR until 2019 and, amongst other mitigations, still doesn’t have kASLR. It’s not a serious operating system for people who care about security. If you want FreeBSD and security take Shawn Webb’s HardenedBSD.

Mythos hacked the site, wrote, and published the article

Their GUI system (GPUI) is not very mature for use outside of Zed. GPUI is basically a UI framework in the truest sense: a framework for building UI... frameworks/components. It has core functionality for async execution, an ECS for grabbing shared resources, and a div.

It's basically like building a website with div and basic CSS.

gpui-component exists: https://github.com/longbridge/gpui-component

Up until sometime late 2025 GPUI wasn't even on crates.io, and it seems like the GPUI-component ecosystem still promotes using git deps. It was also in "read the code for docs" state for a very long time

It's been a while since I've used it, but there were weird things missing too like the Scollbar was located in Zed's UI component crates instead of core GPUI. Arbitrary text selection also is not possible, which is something I really value about egui.

https://www.iroh.computer/sendme

Iroh's protocol can figure out if the devices are on the same LAN and avoid going over the internet. It can work without a discovery server too -- i.e. completely LAN.

They wrote something that allowed them to virtualize Git -- can't remember the name of that. But it basically hydrated files on-demand when accessed in the filesystem.

The problem was I think something to do with like the number of git objects that it was scaling to causing crazy server load or something. I don't remember the technical details, but definitely something involving the scale of git objects.

At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases.

Fun story: I don't really know what Microsoft's server-side infra looked like when they migrated the OS repo to git (which, contrary to the name, contains more than just stuff related to the Windows OS), but after a few years they started to hit some object scaling limitations where the easiest solution was to just freeze the "os" repo and roll everyone over to "os2".

Part of the idea behind stacked PRs is to keep your commits focused and with isolated changes that are meaningful.

A stacked PR allows you to construct a sequence of PRs in a way that allows you to iterate on and merge the isolated commits, but blocks merging items higher in the stack until the foundational changes are merged.

I think Pijul has some good ideas, but I’m afraid the network effect of git at this point is too strong.

I think jj’s concept of being a front end for many backends and sharing a common UX over them is a good one, but without a pijul backend for existing tools I have a hard time seeing it catch on.

It's not something to over-index on, but it's not a strong protection measure. It simply raises the overall cost to attack and analyze a system.

Take the PS5 for example. It has execute-only memory. Even if you find a bug, how do you exploit it if you can't read the executable text of your ROP/JOP target?

Hi, quick note on "For modern Xbox platforms, public 2024 work exposed SystemOS kernel exploitation on both Xbox One and Xbox Series"

I'm a former Xbox hacker, then former Microsoft employee, and (long after) leaving Microsoft helped with the Collateral Damage post-exploitation payload.

The design of the Xbox One security predates me, but Microsoft has always known that SystemOS would be a weak link that would almost guaranteed to be compromised and shoved most of their attack surface that can be trivially attacked in there. The system shell, 3rd-party apps, guide, etc. all run in SystemOS.

The key things they focused on though were:

1. Extremely strong defense-in-depth

2. Making full or partial exploitation not economical

3rd party apps and the web browser were seen as being obviously untrusted _and_ needed JIT because they'd mostly be based on .NET or the JS VM. But practically speaking there should be nothing interesting in that VM: its compromise shouldn't enable piracy/cheating and ideally shouldn't leak game plaintext.

What some others found though was that for some reason plaintext was actually visible to SystemOS, but didn't enable piracy on console. You can take those games though and run them on PC using XWine1: https://github.com/xwine1

Technically speaking there's no reason why Collateral Damage couldn't have happened waayyyyy earlier in the Xbox One's lifecycle except for motivation. Even still you could probably take some Hyper-V N-day and compromise HostOS through.

Over there years there have been other "exploits" too: some folks have managed to tamper with gamesaves via cloud connected storage and other shenanigans, XSS in the system shell (some of these apps are JS), etc., but most of this was relatively benign and easily patchable. And there has been a very, very small group of people with similar but less capable exploits to Collat.

Collat allowed compromise of plaintext.

Bliss breaks everything :)

For real. Use https://radicle.xyz/ if you want actual takedown resistance.

Looks like your wish was accidentally granted :)

Relevant: https://www.reddit.com/r/ClaudeAI/comments/1s7zgj0/investiga...

https://www.reddit.com/r/ClaudeAI/comments/1s7mkn3/psa_claud...

I maintain some tools for the videogame World of Warships. The developer has a file called GameParams.bin which is Python-pickled data (their scripting language is Python).

Working with this is pretty painful, so I convert the Pickled structure to other formats including JSON.

The file has always been prettified around ~500MB but as of recently expands to about 3GB I think because they’ve added extra regional parameters.

The file inflates to a large size because Pickle refcounts objects for deduping, whereas obviously that’s lost in JSON.

I care about speed and tools not choking on the large inputs so I use jaq for querying and instruction LLMs operating on the data to do the same.