I usually post weekly learning and development updates on Dev.to📝
This time, however, I decided to write a standalone article about something a little different — my first attempt at reverse engineering🦾
What started as simple curiosity quickly turned into an exciting journey of uncovering how a modern AI-generated Python application was actually structured internally🔎
.exe
.exe
.pyc
files using tools like strings
, pycdc
, and pycdas
As someone who works in IT administration and internal tooling, I often become curious about how applications are actually built under the hood.
This time, a coworker showed me a PDF-processing desktop application that had been created with the help of generative AI.
The overall architecture had already been explained to me verbally beforehand.
However, that led me to a simple but exciting question:
How much of an application's internal structure can actually be reconstructed just by reverse engineering the final
.exe
file?
That curiosity became the starting point of this exploration.
The application itself was a harmless internal utility designed for local use, and this investigation was performed purely within an authorized and educational context.
Rather than trying to analyze malware or bypass protections, I wanted to understand:
What made the process especially exciting was slowly piecing together the architecture from small clues hidden inside the executable.
Since I was using Kali Linux on WSL for this experiment, I first prepared a small reverse engineering workspace.
mkdir -p ~/reverse
cd ~/reverse
python3 -m venv venv
source venv/bin/activate
At first, the virtual environment failed because python3-venv
was missing:
sudo apt install python3.13-venv
After that, I recreated the environment successfully.
I installed a few basic tools for inspecting the executable and analyzing Python bytecode.
pip install pyinstaller
I also installed binutils
so I could use strings
:
sudo apt install binutils
pycdc
To inspect .pyc
files more deeply, I built pycdc
from source:
sudo apt install -y cmake g++ git
mkdir -p ~/reverse/tools
cd ~/reverse/tools
git clone https://github.com/zrax/pycdc.git
cd pycdc
mkdir build
cd build
cmake ..
make -j4
This generated:
pycdc
pycdas
which I later used to inspect Python bytecode files.
After confirming the executable was likely packaged with PyInstaller, I used pyinstxtractor
to extract its contents:
git clone https://github.com/extremecoders-re/pyinstxtractor.git
Then:
cd ~/reverse/pdf_exe
python ~/reverse/pyinstxtractor/pyinstxtractor.py PDF.exe
This generated a directory like:
PDF.exe_extracted/
Inside the extracted directory, I was finally able to inspect files such as:
app.pyc
pdf_stamp_processor.pyc
pdf-stamp-frontend/dist
This was the point where the application's overall structure started becoming much clearer.
strings
I first started with:
strings PDF.exe
Very quickly, I noticed Python-related strings:
python313.dll
pyi-python-flag
...
This strongly suggested that the application had been packaged using PyInstaller.
Next, I used:
pyi-archive_viewer PDF.exe
This helped confirm that the executable had been packaged using PyInstaller and allowed me to inspect the internal archive structure.
.pyc
Files I then used:
pycdc
pycdas
to inspect the extracted Python bytecode files.
However, when running pycdc
, I noticed that some parts of the bytecode could not be fully reconstructed.
In many cases, the output stopped after displaying messages like:
Unsupported opcode: CALL_KW (247)
from fastapi import FastAPI, File, UploadFile, Form, HTTPException
...
Instead of fully recovering the original source code, I had to combine multiple fragmented clues together:
I also used generative AI to help interpret and organize those fragmented technical details while reconstructing the application's architecture.
Even with incomplete reconstruction, I was still able to identify:
/api/scan
/api/stamp_and_merge
/api/shutdown
The frontend bundle was much harder to understand.
The built JavaScript looked like this:
var e=Object.create,t=Object.defineProperty,...
At first, it felt almost impossible to read.
The extracted JavaScript was difficult to understand, and I could not initially tell what kind of frontend structure had originally existed before packaging.
By combining:
I gradually started to understand how the frontend had likely been packaged and bundled, and that the application was probably using a modern frontend workflow similar to React/Vite.
At the same time, I also realized that the original frontend source structure itself was no longer included inside the executable.
By combining clues from strings, embedded .pyc
files, frontend assets, and API routes, I was eventually able to reconstruct a rough picture of the application's architecture:
PDF.exe
↓
Launch FastAPI server
↓
Open browser automatically
↓
Serve React frontend
↓
React sends API requests
↓
Python processes PDFs locally
The application was not rendering a desktop GUI directly.
Instead:
What fascinated me most was not simply discovering the architecture itself, but realizing how much of it could still be reconstructed purely from packaged artifacts.
Before starting this experiment, I assumed that most of an application's architecture would disappear once everything had been packaged into a standalone .exe
.
However, I was surprised by how many clues still remained inside the executable:
.pyc
filesBy connecting those small clues together step by step, I was able to reconstruct a surprisingly large portion of the application's overall architecture.
That process itself was one of the most exciting parts of the experience.
This experience also made me think deeply about AI-generated applications and software maintainability.
Generative AI can absolutely help create working applications quickly.
However, once only compiled artifacts remain, reconstructing the original design and development intent becomes much harder.
Even after reverse engineering the executable, I still could not fully reconstruct the original frontend source code or understand every implementation detail.
That limitation itself became an important lesson for me.
It reminded me that understanding software architecture and preserving maintainable source structures are just as important as making software work.
Especially in the age of AI-assisted development.
This reverse engineering journey was honestly a lot of fun.
What made the experience especially enjoyable was gradually reconstructing the application's architecture from small technical clues hidden inside the executable.
At the same time, the experience gave me a deeper appreciation for software architecture, maintainability, and the importance of preserving understandable source code alongside AI-generated applications.