DEV Community: Axo

Learning How AI Can Reverse Engineer Software

Axo — Thu, 15 Oct 2026 06:59:37 +0000

Reverse engineering has always looked intimidating from the outside. It usually means reading assembly, learning heavy tools like Ghidra or IDA, and spending hours tracing code by hand. Recently I came across an open source project called REA that connects AI agents to those same tools, so you can ask questions about a program in plain English and get answers back with evidence attached.

In this post I break down what REA is, how it works under the hood, what it can analyze, how to set it up, and what every beginner should know before trying it, including how to stay on the right side of the law.

🧩 The Idea: Reverse Engineer Anything

Reverse engineering is figuring out how software works when you do not have its source code. Security teams use it to pick apart malware, researchers use it to find vulnerabilities, and developers use it to make old software talk to new systems. As a networking and server admin student leaning toward cybersecurity, it is a skill I kept seeing on job postings and kept avoiding because the learning curve looked like a cliff.

Then I found REA (Reverse Engineer Anything), an open source, MIT licensed project that connects AI agents like Claude Code, Codex, Cursor and Gemini CLI to real reverse engineering tools. Instead of memorizing every menu in Ghidra, you ask your agent a question in plain English. The agent calls REA, REA runs the heavy tools on your own machine, and you get findings back along with the evidence and limitations behind each conclusion.

What surprised me most is how much it covers. Here are the targets that stood out to me:

Target	What REA gives back	What you need
Native binaries	Pseudocode, assembly, strings, symbols, calls and references	Ghidra (free), Hopper or IDA
JavaScript and Electron apps	Modules, imports, routes and IPC between processes	Just Node.js and npm
.NET assemblies	Metadata and CIL instructions	Nothing extra, static analysis only
Android APKs	Manifest, classes and decompiled methods	JADX and a full JDK
Packet summaries	Endpoints, DNS, TLS SNI and protocol breakdown	tshark and capinfos

That last row is the one that got me as a networking student. The same agent that reads a binary can also summarize a packet capture.

Source: REA README

🔑 The Part That Broke My Brain: MCP

The concept that took me the longest to understand was how an AI chatbot could suddenly "use" a program like Ghidra.

Here is the short version of what I learned. MCP stands for Model Context Protocol, and it is a standard way for an AI agent to call outside tools. On its own, an AI model can only read and write text, so if you paste in some assembly it is basically guessing. REA runs as a local MCP server that offers the agent a set of tools, things like "decompile this function" or "list the strings in this file." The loop looks like this:

You ask your agent a question about a program.
The agent picks a REA tool and calls it through MCP.
REA runs Ghidra (or another engine) locally against the file.
REA sends back pseudocode, assembly and references, plus what it could not confirm.
The agent reads the evidence, asks follow up questions, and explains it to you.

The moment it clicked for me: the AI is not making up what the program does. It is reading the same evidence a human reverse engineer would read, just a lot faster.

That "what it could not confirm" part matters more than I expected. AI models can sound confident while being wrong, so a tool that reports its own unknowns keeps both you and the agent honest.

⚙️ Getting It Running

REA needs Node.js and npm. The supported versions are Node 22 (22.19 or newer), Node 24 (24.11 or newer), or Node 26 and up. For native binaries you also need an analysis engine such as Ghidra, Hopper or IDA. Ghidra is the easiest place for a beginner to start because it is free. Setup is one command:

npx rea-agents setup

It asks which agents you use, shows you the changes it wants to make, and backs up your existing config before adding the REA MCP server. After that you restart your agent and it can use the new tools.

If you want the rea command in your terminal for regular use, you can install it globally:

npm install --global rea-agents
rea --help
rea update

One gotcha to watch for on Linux: Ghidra and the JavaScript analysis need a procps compatible ps command on your PATH, so if things fail on a minimal VM, check that first.

One more thing I did not expect to learn from a README: the project warns that copycat repos with similar names exist, and you should only install from the official GitHub repo, rea.tools, or the rea-agents npm package. That is a real supply chain attack lesson hiding inside an install guide.

🔍 How You Actually Use It

There are two ways to work with REA. The first is through your AI agent. After setup, you describe what you want to understand in plain English, and the agent decides which REA tools to call. A prompt might look like this:

Explain how the clipboard feature in this app works, show me the evidence,
and list anything you could not confirm.

The second way is the terminal, which runs the same workflows without an agent. For example, this command inspects an extracted JavaScript or Electron app and needs no native analysis engine at all:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

According to the docs, the output lists the app's modules, imports and Electron boundaries, along with the evidence for each one.

🧪 A Core Skill: Spotting Known Algorithms

Whether a person or an AI is doing the analysis, one of the most useful reverse engineering tricks is recognizing well known algorithms by their fingerprints. Compiling throws away comments, and stripping a binary removes function names, but neither can hide the math. Here is a classic example, a string hash called djb2, written in C:

unsigned int djb2(const char *s) {
    unsigned int h = 5381;
    while (*s) {
        h = ((h << 5) + h) + *s++;
    }
    return h;
}

Once this is compiled and stripped, the name djb2 is gone. What survives in the pseudocode or assembly are two clues: the starting value 5381, and a shift left by 5 followed by an add, which is just a fast way to multiply by 33. Someone who knows those clues can name the function in seconds, and an agent reading evidence from REA can match them the same way. Other famous constants work like this too, such as 0x67452301 at the start of MD5 and SHA-1, or 0xEDB88320 in CRC32.

Compilers erase names, but they cannot erase math. That is why constants are one of the first things reverse engineers look for.

Identifying an algorithm is only half the job. The other half is proving it, by running the original program and a rewritten version on the same inputs and checking that the outputs match.

🧠 What I Learned (Including Staying Legal)

The biggest takeaway is that AI does not replace understanding, it speeds it up. An agent can find an answer fast, but testing that answer against the original program is what proves it. Skip that step and you are just trusting a confident sounding paragraph.

The second lesson is about responsibility, because reverse engineering tools can be misused:

Only analyze what you own or are authorized to examine. The REA project says it is meant for lawful research, education, interoperability, software preservation, and software you own or have permission to analyze. Software license agreements and laws can restrict reverse engineering, so practicing on your own programs or on CTF challenges is the safe move.
Use legit tools. REA does not come with licenses for paid tools like IDA, Hopper or JEB, and the project is clear that cracked copies and stolen keys are not okay. Ghidra is free, which makes it perfect for students.
Think about your data. REA runs the analysis locally, but the results still go to your agent, and the AI provider behind it has its own data policy. I would not feed it anything from work or school that I am not allowed to share.

🚀 What's Coming Next

Next, I want to dig into the packet capture side of REA, since that ties straight into my networking classes. I also want to work through beginner reverse engineering challenges on picoCTF, where breaking things is the whole point and completely allowed.

If you want to see what this looks like on real software, the REA showcases are worth reading. In one, someone traced a sound calculation in the old game DX Ball and rebuilt it in C so accurately that it passes 3,205 test cases against the original x86 code. Another follows how the Notion desktop app moves clipboard data between its processes. They are a great example of the verify step done at scale.

The core idea is simple: ask a question, let the agent gather evidence with REA, then verify the answer yourself. That loop makes a field that once felt out of reach a lot more approachable for beginners.

Thanks for reading. More updates coming as I keep digging in.

Links: REA on GitHub · rea.tools · Ghidra

I am Building a Fitness Dashboard

Axo — Sun, 03 May 2026 06:57:30 +0000

A few weeks ago I had no idea what Gunicorn was, had never touched PostgreSQL, and had never written a single line of Django. This week I connected a live fitness API to a web app I built from scratch and generated a downloadable shareable card with real data on it. That feels pretty wild to say out loud.

Let me back up and explain what I have been building, because I think the concept is actually kind of interesting.

🏋️ The Idea: A Fitness Identity Card

While researching project ideas, I kept coming back to apps like Spotify Wrapped, that end of year card everyone shares on social media. I wanted to make something like that but for fitness. Something where you connect your Strava or Fitbit account, pick which stats matter to you (total distance, longest run, active days, elevation gained, etc.), arrange them however you want, and then share a link or download a card image. I am calling it FitCard.

The gap I noticed is that nothing like this really exists in a clean, social friendly way. There are stat trackers out there, but none of them give you a fully personalized shareable card you could post on Instagram or hand to a recruiter as proof you actually follow through on things.

🔑 The Part That Broke My Brain: OAuth

Getting Strava connected was honestly the hardest part of the whole week. Not because the code was complicated, but because I did not fully understand what OAuth actually was before I started.

Here is the short version of what I learned: OAuth is a system where instead of giving your password to a third party app, you get redirected to the original service (Strava, in this case), you approve access there, and then Strava hands back a token to my app. That token is what I use to make API calls on your behalf. No passwords stored, no security nightmare.

The first time the redirect worked and I saw "Strava Connected" show up on my dashboard, I genuinely did not believe it worked on the first try.

Once I had the token I could call Strava's API and pull back real stats. Here is basically what that looks like:

headers = {'Authorization': f'Bearer {access_token}'}
stats = requests.get(
    f'https://www.strava.com/api/v3/athletes/{athlete_id}/stats',
    headers=headers
).json()

The fact that a few lines of Python can reach out to Strava's servers, grab someone's running history, and display it on a page I built still kind of amazes me.

🎛️ Making It Feel Like a Real Product: Drag and Drop

One of the features I really wanted was the ability to customize which widgets show on your card and arrange them however you want, kind of like how you can move apps around on an iPhone home screen. I used a JavaScript library called SortableJS for this, which handles all the drag logic. I just had to wire it up to save the new positions back to the database whenever you drop a widget in a new spot.

Sortable.create(grid, {
    animation: 150,
    ghostClass: 'sortable-ghost',
    onEnd: function() {
        // save new positions to the database
    }
});

What I did not expect was how satisfying that would feel to use. Dragging a widget, watching it snap into place, refreshing the page and seeing it stay. That is when it started feeling like a real app rather than a class project.

🖼️ The Downloadable Card

The last piece this week was generating an actual downloadable image of your FitCard using a Python library called Pillow. This was different from everything else I had done because instead of building a web page, I was drawing pixels. Laying out text, colors, and shapes programmatically onto a canvas and then saving it as a PNG file.

img = Image.new('RGB', (800, 500), (26, 26, 26))
draw = ImageDraw.Draw(img)
draw.text((40, 40), "FitCard", fill=(0, 229, 160), font=font_large)

My first version had a thick black border around the card that looked terrible. Fixing it was a two line change, but it is the kind of thing you only notice when you actually look at the output. That is a lesson I keep relearning: you have to test your own work with fresh eyes.

🚀 What's Coming Next

The app works but there is still a lot left to do. The VM's IP address keeps changing every time I restart it, which is annoying and something I need to fix with a static IP. I also want to add support for a second fitness platform and make sure the public profile page shows real data instead of placeholder values.

But the core loop works: connect an account, pick your widgets, arrange them, view your public card, download the image. For three weeks of work starting from zero Django knowledge, I am pretty happy with where this is.

Thanks for reading. More updates coming as the project continues.

I am Building a Fitness Dashboard

Axo — Sun, 03 May 2026 06:57:30 +0000

Let me back up and explain what I have been building, because I think the concept is actually kind of interesting.

🏋️ The Idea: A Fitness Identity Card

🔑 The Part That Broke My Brain: OAuth

Getting Strava connected was honestly the hardest part of the whole week. Not because the code was complicated, but because I did not fully understand what OAuth actually was before I started.

The first time the redirect worked and I saw "Strava Connected" show up on my dashboard, I genuinely did not believe it worked on the first try.

Once I had the token I could call Strava's API and pull back real stats. Here is basically what that looks like:

headers = {'Authorization': f'Bearer {access_token}'}
stats = requests.get(
    f'https://www.strava.com/api/v3/athletes/{athlete_id}/stats',
    headers=headers
).json()

The fact that a few lines of Python can reach out to Strava's servers, grab someone's running history, and display it on a page I built still kind of amazes me.

🎛️ Making It Feel Like a Real Product: Drag and Drop

Sortable.create(grid, {
    animation: 150,
    ghostClass: 'sortable-ghost',
    onEnd: function() {
        // save new positions to the database
    }
});

🖼️ The Downloadable Card

img = Image.new('RGB', (800, 500), (26, 26, 26))
draw = ImageDraw.Draw(img)
draw.text((40, 40), "FitCard", fill=(0, 229, 160), font=font_large)

🚀 What's Coming Next

Thanks for reading. More updates coming as the project continues.

sudo - Power Tool, Not a Magic Fix

Axo — Sun, 12 Apr 2026 04:45:10 +0000

If you've spent any time in a Linux terminal, you've typed sudo in front of a command. Maybe it was because something was blocked, maybe someone told you to, or maybe you just picked up the habit. Either way, most beginners use it constantly without really thinking about what it's doing.

So let's talk about it. What sudo actually is, when you should reach for it, and where it can genuinely get you into trouble.

🔑 What You're Actually Doing When You Type `sudo`

sudo stands for "superuser do." When you put it in front of a command, you're telling Linux to run that command as the root user, the most powerful account on the Root can read, modify, or delete anything. No file is off limits, no permission can stop it, and nothing it does is automatically undoable.

That's a lot of power to invoke casually.

✅ When `sudo` Makes Sense

There are plenty of situations where sudo is exactly the right tool. Installing software, editing system configuration files, managing users, restarting services. These all genuinely require elevated privileges and sudo is the correct way to get them.

sudo apt install nginx
sudo nano /etc/hosts
sudo systemctl restart ssh

The common thread is that these are all tasks that affect the system beyond your own user space. That's the right mental bar to clear before reaching for sudo.

⚠️ When People Misuse It

The most common mistake beginners make is using sudo as a shortcut whenever they hit a Permission Denied error. That error exists for a reason. The system is telling you that your current user isn't supposed to be doing that thing, and the correct response is to ask why, not to bulldoze through it with root privileges.

The second big mistake is running commands you don't fully understand and adding sudo to make them work. That's genuinely risky. If you copied a command from the internet and can't explain what every part of it does, adding sudo to it is not the move.

💀 The Commands Worth Being Careful With

A few combinations are worth knowing about specifically because they go from useful to catastrophic very quickly with root access.

sudo rm -rf /

This deletes everything on the system. No confirmation prompt, no warning, no recovery.

sudo chmod -R 777 /

This strips all permission restrictions from the entire filesystem, leaving your system wide open.

sudo dd if=/dev/zero of=/dev/sda

This wipes your hard drive completely by overwriting it with zeros.

None of these commands will ask if you're sure. Linux assumes you know what you're doing.

🧠 The Simple Rule

If something works fine without sudo, don't add it. Reach for it only when the system genuinely requires elevated privileges, and when you do, read the full command twice before you hit Enter. Root doesn't do second chances.

DEV Community: Axo

Learning How AI Can Reverse Engineer Software

🧩 The Idea: Reverse Engineer Anything

🔑 The Part That Broke My Brain: MCP

⚙️ Getting It Running

🔍 How You Actually Use It

🧪 A Core Skill: Spotting Known Algorithms

🧠 What I Learned (Including Staying Legal)

🚀 What's Coming Next

I am Building a Fitness Dashboard

🏋️ The Idea: A Fitness Identity Card

🔑 The Part That Broke My Brain: OAuth

🎛️ Making It Feel Like a Real Product: Drag and Drop

🖼️ The Downloadable Card

🚀 What's Coming Next

I am Building a Fitness Dashboard

🏋️ The Idea: A Fitness Identity Card

🔑 The Part That Broke My Brain: OAuth

🎛️ Making It Feel Like a Real Product: Drag and Drop

🖼️ The Downloadable Card

🚀 What's Coming Next

sudo - Power Tool, Not a Magic Fix

🔑 What You're Actually Doing When You Type sudo

✅ When sudo Makes Sense

⚠️ When People Misuse It

💀 The Commands Worth Being Careful With

🧠 The Simple Rule

🔑 What You're Actually Doing When You Type `sudo`

✅ When `sudo` Makes Sense