Working with AI coding agents

The posts on this site say "we". That means me and the AI coding agents I work with. This post is about how that went on the 1.130 work, since there are a lot of "feelings" around agentic coding. I tend to see it as support for experienced developers. But I recognize it lowers the barrier to entry, and a lot of unskilled AI-built work has turned off users and skilled engineers alike.

The timeline

Getting the current 1.130 client to log in against OpenDAoC took about a week. That was evenings, around a day job, and I was working on the Godot client and this site at the same time. Years ago the same work would have taken me months, maybe more.

What reverse engineering takes

Reverse engineering is a nerd skill, and by "nerd" I mean someone with deep expertise in a subject. Being a strong developer or engineer deserves respect. Being as experienced and skilled in the surrounding disciplines is rarer. Reverse engineering (RE) needs that kind of depth: deep skill across a set of fields related to software development and engineering. That's why even other nerds look at RE nerds with awe.

You need to know development, languages, compilers and assembly, and what code looks like once it's binary. You need to know how each operating system lays those binaries out as executables and libraries (Windows PE, Linux shared libraries and the Linux ABI), how they get loaded into memory, code segments versus data, memory analysis, breakpoints, and how to use Ghidra and Frida. Then networking: TCP and UDP, sockets, application protocols, pktmon, tcpdump, Wireshark, pcap, packet analysis. Then crypto: handshakes, public and private keys, RSA, hashes, session keys, shared secrets, RC4, S-boxes, randomness.

With all of that, you still have to follow the process and data flows from start to finish. Think of it like a complex military "kill chain": you have to find the point where you can intervene to change the outcome.

My advantage is that I'm older and have worked in all of those areas for 40-plus years: Z80 assembly, device drivers for AT&T Unix, early SMTP and firewalls, .com startups that decoded network packets and built products, and the last 20 years in deep research, engineering and analysis.

Three agents

Claude Code

Claude has gotten very good over the last year. It worked with me on my fork of the OpenDAoC server running locally, and on analysing the Windows client: protocol analysis, code, tests and documentation.

Its guardrails stop it from reverse engineering the crypto, such as how the client handles its keys, or decrypting captured traffic. As the work gets closer to that, it starts declining. I needed a sniffer that could decrypt, and it refused, so I tried something else.

Grok

I'd heard Grok has fewer guardrails. Maybe so, but it wasn't very clever. It got a lot wrong about the Windows binaries: functions, data, what was what. It didn't follow directions. I'd ask for a .cs file that did X, Y and Z, it would say it was done, and there'd be no file. Three prompts later, after I swore at it, it made the file, and the code was often bad. It couldn't remember details from five prompts back, never mind across sessions.

After three full days and $30 of it acting lazy and stupid, I had very little to show.

Codex

So I moved to Codex on the $20 personal plan. With it I finished the OpenDAoC server changes, and we wrote the packet sniffer, the same idea as CapnBry's DaocSkilla, an open-source Win32 sniffer and radar from the early 2000s. It wraps a packet capture tool in C# on the Windows machine and streams the capture to a listening port on my Mac, where it's logged, decrypted, decoded and analysed.

The sniffer caught a real bug. OpenDAoC has two paths for sending to the client, and we'd missed one. Its packets went out in clear text and crashed the client.

REA

I was tempted to use REA, but didn't.

Agentic coding lowers the barrier to hard technical work, and reverse engineering is about as hard as it gets. Reverse Engineer Anything (REA), an MCP server for reverse engineering, looks like it lowers it further. It got popular fast, and its release is what got me thinking about putting real effort into DAoC.

I don't like connecting a lot of MCP servers, and REA looks heavy, with a lot of functionality, and it burns a lot of tokens. It also wouldn't have helped with what I wanted, which was to use the reverse engineering skills myself and relearn them.

You still need to understand the stack. The tools make you faster if you do, and get you further if you're still learning.

Who did what

The agents did most of the work around the encryption: reading the server source, parsing captures, writing the server changes, the sniffer, and the tests. The crypto analysis, where the key lives, how the client's session key gets to the server, and how the server reads it, was mine. That's the part that leans on the 40 years.

I'm not proficient in C#, dislike C++, can do some Rust and Go, grew up writing C, and love Python. So THANKS, Claude and Codex, for writing the C# I could describe in pseudo-code.

Every finding on this site links to the capture or source code behind it. Agents can be confidently wrong, and so can I, so the tests and the write-ups are how we check each other.

What's next

I've left out a lot of the client-side crypto details. But I'll make the tools available so OpenDAoC users can connect a retail 1.130 client to my fork of OpenDAoC.

Next, I need to work with the OpenDAoC folks to get the changes into their codebase.