A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

A developer reverse-engineered a PyInstaller-packaged Python .exe file from an AI-generated PDF-processing application, using tools like `strings`, `pycdc`, and `pycdas` on Kali Linux to reconstruct its internal architecture. The investigation revealed the application was built with Python 3.13 and contained `.pyc` files for modules including FastAPI, though decompilation was incomplete due to unsupported opcodes. The developer successfully extracted the executable's structure and identified its components, demonstrating how much of an AI-generated application's internals can be recovered from the final binary.

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: python Unsupported opcode: CALL KW 247 from fastapi import FastAPI, File, UploadFile, Form, HTTPException ... WARNING: Decompyle incomplete 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: js 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.