0xkato

0xkato.xyz · English

A blog about technology and stuff related

atom

Open the feed

https://0xkato.xyz/feed.xml

Last post: Aug 4, 2026
Posts in 24 h · 7 days · 30 days: 0 · 0 · 0
Our last check: Answering
Served from: United States
Site title: Home
Text score: 18,334
Format: atom

Posts

What our queue read from this feed. Open one to read it here, or go to the site that published it.

What Codex Actually Sends to the Model
Aug 4, 2026 · original
I recorded the requests Codex generated for a 16-character prompt, then measured what changed as it loaded instructions, exposed tools, read files, ran commands, received images, and compacted its history. When I typed Reply with pong., the prompt was 16 characters long. The request Codex sent was 42,980 bytes. Encoded locally as JSON with o200k_base, it came to roughly 9,435 tokens. The wrapped prompt accounted for about 25 of them, or 0.3%. The rest came from Codex itself: instructions, tool definitions, permissions, skill metadata, environment context, and request framing. Those token counts are local estimates, not API usage or billing. The captured request body itself is exact. File reads and command output are added later. When the accumulated history gets too large, Codex can send it through another model request, replace it with a summary, and continue. How I recorded the request
How to Research Technical Topics With AI
Jul 28, 2026 · original
I used AI throughout the process of learning how LLMs work. I did not begin with an article in mind, I first learned the topic well enough to explain it then decided to turn that understanding into How LLMs Actually Work . I used it to find the right terminology, locate useful material, question my explanations and expose gaps in what I thought I understood. I still had to understand the transformer stack well enough to explain every important part and defend the simplifications I made. This is how I go from a technical question I cannot answer to an explanation I can reconstruct. Turning that understanding into an article comes later. “How do LLMs work?” was still too broad When I started learning how LLMs work the obvious question was “How do LLMs work?” It was also too broad to research directly. It could lead into training, hardware, tokenization, inference, alignment, scaling laws,
How LLMs Actually Work
Jun 1, 2026 · original
This post is a walkthrough of how LLMs work. Modern LLMs are mostly built by stacking transformer blocks over and over, so understanding the transformer machinery gets you most of the way there. I’ll cover the core mechanisms inside modern transformer-based LLMs, without all that sticky math stuff. Don’t get me wrong, you should learn the math, but this can serve as an introduction. Most modern LLMs share the same transformer-family skeleton. The differences come from what each one was trained on, the scale and configuration choices, and the post-training done on top. By the end, you should be able to read many modern LLM papers or model cards and know which piece of the architecture each section is talking about. Here’s the path: Tokens, how a string of text becomes a sequence of integers Embeddings, how those integers get meaning Positional encoding, how the model knows what order the
The Next Jump
Apr 17, 2026 · original
My approach to security has always been the same: understand something deeply so you can do the best work on it. Smart contracts, blockchain infrastructure, kernels, open source libraries. The target changed but the method never did. Go deep, find what’s broken, explain it. I’m changing the target again. This time the shift is bigger than usual. I’ll always do vulnerability research. It’s just how my brain works when I look at software, so it never really stops. But my focus is moving somewhere else. This post is about why. Something changed I was at Defcon 2025 with a friend, and we started building with Claude Code. Over a few days we were turning feature ideas and product changes into reality as fast as we could think of them. I’d been using various LLM applications before that for small tasks, nothing serious, but this was different. It just made shit that worked. We’d be building on
CVE-2026-1678: DNS Parser Overflow in Zephyr
Mar 24, 2026 · original
CVE-2026-1678 / GHSA-536f-h63g-hj42 is a critical out-of-bounds write in Zephyr’s DNS name parser, dns_unpack_name() , affecting versions = 4.3 with a 9.4 CVSS score. Before I go into the details, I want to shout out the Zephyr security team. They were hands down the best team I have worked with on a vulnerability disclosure. I submitted the report, they confirmed and fixed it within days, and published the advisory after the embargo. The whole process was clean and simple from start to finish. Why I looked at the DNS parsers Anywhere code translates between two different formats is a good place to look for memory safety bugs. DNS parsers are a great example of this. Over the wire a name like www.apple.com is not stored as a dot-separated string. The name is split into chunks, each prefixed with a single byte that tells you how many bytes that chunk is, and the whole thing ends with a ze
How CPU Caches Work
Dec 11, 2025 · original
This post is a tour of how CPU caches actually work, using a simple real‑world picture: a busy office with desks, cabinets, and a big archive room. What we’ll cover Here’s the path we’ll walk: Cache overview Data layout and cache friendliness Locality of reference Cache lines Sets, ways, and tags Replacement policies Cache writes and consistency Write-through vs write-back Write-allocate vs no-write-allocate Cache hierarchy (L1, L2, L3) SRAM vs DRAM Summary Along the way we’ll sprinkle Tiny explainers to keep the tone light. 1. Cache overview Imagine you work in a busy office. There is a huge archive room with shelves of folders. That’s your main memory (RAM). You have a small cabinet next to your desk with the files you use a lot. That’s like your L2 / L3 cache. On your desk, you keep a tiny pile of folders open right in front of you. That’s your L1 cache. The closer something is to you
Is RCE Really Just Low Severity?
Nov 27, 2025 · original
This is a friendly case study, not a callout. Big thanks to the {fmt} maintainers for the quick fix. I am happy with the way it was handled and I wish more teams moved this fast. Even if the final result was different from what I first expected, I think it was fair overall. This is the story of how I reported a command injection in the {fmt} library. I will share what I found, how it was fixed, and what I learned. Advisory link: GHSA-65g5-63wg-xjh4 Maintainer thanks: vitaut Everything was resolved in about eight days. That is very fast. I have reports in other projects that have sat in triage for months. How I found it When I read a new codebase I look for shell boundaries. I search for code that invokes system, popen, or exec style calls and passes in strings. If a user can influence those strings, that is a problem. In {fmt} I noticed a small helper that tries to speak text on macOS. I
The Life of a Packet in the Linux kernel
Nov 14, 2025 · original
A practical tour from write() to recv() You run curl http://example.com and now you have some HTML in your terminal but what actually happened? Linux walks your bytes through a small set of well‑defined steps: pick a path, learn a neighbor’s MAC address, queue the packet, ask the NIC to send it, then reverse that on the other side. This post tries to explain that path as simply as I can. If you’ve used Linux, run curl , or poked at ip addr before, you’re qualified to read this. No deep kernel background needed. Note: When I say “the kernel” in this post, I really mean “the Linux kernel and its networking stack” the part that runs in the kernel and moves packets around. What we’ll cover Here is the simplified path we’ll walk through: your app ↓ write()/send() TCP (segments your bytes) ↓ IP (chooses where to send them) ↓ Neighbor/ARP (find the next-hop MAC) ↓ qdisc (queueing, pacing) ↓ dri
A Friendly Tour of Process Memory on Linux
Nov 1, 2025 · original
You run a program. It reads and writes addresses as if a giant, continuous slab of memory had been waiting there all along. It didn’t. Linux builds that illusion on the fly, one page at a time. This is a walk through what your process actually owns, what happens on the first touch of a byte, how protections and huge pages fit in, how to see the truth from /proc , and why modern kernels do a little extra dance to defend against Meltdown . Note: This tour targets Linux on x86‑64, other architectures differ in details (page sizes, cache rules), but the ideas carry over. Intro The picture below is a quick introduction. It is a simple map you can keep in mind as you read. Physical RAM is the real memory. It is a bunch of frames scattered around. The virtual view is the clean line your program sees. It does not match the real layout. The page table is a list. It tells which spot on the virtual
The Linux Boot Process: From Power Button to Kernel
Oct 25, 2025 · original
Part 1 — From power button to the kernel’s first breath You press the power button. A second later a wall of text scrolls by, or a logo fades in, and eventually Linux appears. What happens in between is not magic. It is a careful handshake between tiny programs and a very literal CPU. This part follows that handshake until the very first line of C code inside the Linux kernel runs. The very first instruction When power stabilizes, the CPU resets itself to a tiny, old‑fashioned mode called real mode. Real mode dates back to the original 8086 chip. The rules are simple on purpose. Memory addresses are built from two values the CPU keeps in special fast storage called registers. You combine a segment and an offset like this: physical_address = (segment 4) + offset If you see numbers like 0xFFFFFFF0 , that is hexadecimal. Hex is base 16. We write 0x in front to make that clear. 0x10 is 16 in

Found by rss-feed-index, which checks each feed once a month at most.

Same record as JSON: https://api.agentalog.com/api/feeds/fd_0xkato_xyz_c000f4688ac851c4. More from this site: 0xkato.xyz in the Feeds tab.