{"slug": "a-curious-journey-into-reverse-engineering-an-ai-generated-python-exe", "title": "A Curious Journey Into Reverse Engineering an AI-Generated Python .exe", "summary": "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.", "body_md": "I usually post weekly learning and development updates on Dev.to📝\n\nThis time, however, I decided to write a standalone article about something a little different — my first attempt at reverse engineering🦾\n\nWhat started as simple curiosity quickly turned into an exciting journey of uncovering how a modern AI-generated Python application was actually structured internally🔎\n\n`.exe`\n\n`.exe`\n\n`.pyc`\n\nfiles using tools like `strings`\n\n, `pycdc`\n\n, and `pycdas`\n\nAs someone who works in IT administration and internal tooling, I often become curious about how applications are actually built under the hood.\n\nThis time, a coworker showed me a PDF-processing desktop application that had been created with the help of generative AI.\n\nThe overall architecture had already been explained to me verbally beforehand.\n\nHowever, that led me to a simple but exciting question:\n\nHow much of an application's internal structure can actually be reconstructed just by reverse engineering the final\n\n`.exe`\n\nfile?\n\nThat curiosity became the starting point of this exploration.\n\nThe application itself was a harmless internal utility designed for local use, and this investigation was performed purely within an authorized and educational context.\n\nRather than trying to analyze malware or bypass protections, I wanted to understand:\n\nWhat made the process especially exciting was slowly piecing together the architecture from small clues hidden inside the executable.\n\nSince I was using Kali Linux on WSL for this experiment, I first prepared a small reverse engineering workspace.\n\n```\nmkdir -p ~/reverse\ncd ~/reverse\n\npython3 -m venv venv\nsource venv/bin/activate\n```\n\nAt first, the virtual environment failed because `python3-venv`\n\nwas missing:\n\n```\nsudo apt install python3.13-venv\n```\n\nAfter that, I recreated the environment successfully.\n\nI installed a few basic tools for inspecting the executable and analyzing Python bytecode.\n\n```\npip install pyinstaller\n```\n\nI also installed `binutils`\n\nso I could use `strings`\n\n:\n\n```\nsudo apt install binutils\n```\n\n`pycdc`\n\nTo inspect `.pyc`\n\nfiles more deeply, I built `pycdc`\n\nfrom source:\n\n```\nsudo apt install -y cmake g++ git\n\nmkdir -p ~/reverse/tools\ncd ~/reverse/tools\n\ngit clone https://github.com/zrax/pycdc.git\n\ncd pycdc\nmkdir build\ncd build\n\ncmake ..\nmake -j4\n```\n\nThis generated:\n\n```\npycdc\npycdas\n```\n\nwhich I later used to inspect Python bytecode files.\n\nAfter confirming the executable was likely packaged with PyInstaller, I used `pyinstxtractor`\n\nto extract its contents:\n\n```\ngit clone https://github.com/extremecoders-re/pyinstxtractor.git\n```\n\nThen:\n\n```\ncd ~/reverse/pdf_exe\n\npython ~/reverse/pyinstxtractor/pyinstxtractor.py PDF.exe\n```\n\nThis generated a directory like:\n\n```\nPDF.exe_extracted/\n```\n\nInside the extracted directory, I was finally able to inspect files such as:\n\n```\napp.pyc\npdf_stamp_processor.pyc\npdf-stamp-frontend/dist\n```\n\nThis was the point where the application's overall structure started becoming much clearer.\n\n`strings`\n\nI first started with:\n\n```\nstrings PDF.exe\n```\n\nVery quickly, I noticed Python-related strings:\n\n```\npython313.dll\npyi-python-flag\n...\n```\n\nThis strongly suggested that the application had been packaged using PyInstaller.\n\nNext, I used:\n\n```\npyi-archive_viewer PDF.exe\n```\n\nThis helped confirm that the executable had been packaged using PyInstaller and allowed me to inspect the internal archive structure.\n\n`.pyc`\n\nFiles\nI then used:\n\n```\npycdc\npycdas\n```\n\nto inspect the extracted Python bytecode files.\n\nHowever, when running `pycdc`\n\n, I noticed that some parts of the bytecode could not be fully reconstructed.\n\nIn many cases, the output stopped after displaying messages like:\n\n``` python\nUnsupported opcode: CALL_KW (247)\nfrom fastapi import FastAPI, File, UploadFile, Form, HTTPException\n...\n# WARNING: Decompyle incomplete\n```\n\nInstead of fully recovering the original source code, I had to combine multiple fragmented clues together:\n\nI also used generative AI to help interpret and organize those fragmented technical details while reconstructing the application's architecture.\n\nEven with incomplete reconstruction, I was still able to identify:\n\n```\n/api/scan\n/api/stamp_and_merge\n/api/shutdown\n```\n\nThe frontend bundle was much harder to understand.\n\nThe built JavaScript looked like this:\n\n``` js\nvar e=Object.create,t=Object.defineProperty,...\n```\n\nAt first, it felt almost impossible to read.\n\nThe extracted JavaScript was difficult to understand, and I could not initially tell what kind of frontend structure had originally existed before packaging.\n\nBy combining:\n\nI 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.\n\nAt the same time, I also realized that the original frontend source structure itself was no longer included inside the executable.\n\nBy combining clues from strings, embedded `.pyc`\n\nfiles, frontend assets, and API routes, I was eventually able to reconstruct a rough picture of the application's architecture:\n\n```\nPDF.exe\n    ↓\nLaunch FastAPI server\n    ↓\nOpen browser automatically\n    ↓\nServe React frontend\n    ↓\nReact sends API requests\n    ↓\nPython processes PDFs locally\n```\n\nThe application was not rendering a desktop GUI directly.\n\nInstead:\n\nWhat fascinated me most was not simply discovering the architecture itself, but realizing how much of it could still be reconstructed purely from packaged artifacts.\n\nBefore starting this experiment, I assumed that most of an application's architecture would disappear once everything had been packaged into a standalone `.exe`\n\n.\n\nHowever, I was surprised by how many clues still remained inside the executable:\n\n`.pyc`\n\nfilesBy connecting those small clues together step by step, I was able to reconstruct a surprisingly large portion of the application's overall architecture.\n\nThat process itself was one of the most exciting parts of the experience.\n\nThis experience also made me think deeply about AI-generated applications and software maintainability.\n\nGenerative AI can absolutely help create working applications quickly.\n\nHowever, once only compiled artifacts remain, reconstructing the original design and development intent becomes much harder.\n\nEven after reverse engineering the executable, I still could not fully reconstruct the original frontend source code or understand every implementation detail.\n\nThat limitation itself became an important lesson for me.\n\nIt reminded me that understanding software architecture and preserving maintainable source structures are just as important as making software work.\n\nEspecially in the age of AI-assisted development.\n\nThis reverse engineering journey was honestly a lot of fun.\n\nWhat made the experience especially enjoyable was gradually reconstructing the application's architecture from small technical clues hidden inside the executable.\n\nAt 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.", "url": "https://wpnews.pro/news/a-curious-journey-into-reverse-engineering-an-ai-generated-python-exe", "canonical_source": "https://dev.to/umitomo-lab/a-curious-journey-into-reverse-engineering-an-ai-generated-python-exe-1n0b", "published_at": "2026-05-26 05:02:08+00:00", "updated_at": "2026-05-26 05:03:21.694160+00:00", "lang": "en", "topics": ["generative-ai", "ai-tools"], "entities": ["Dev.to", "Kali Linux", "WSL"], "alternates": {"html": "https://wpnews.pro/news/a-curious-journey-into-reverse-engineering-an-ai-generated-python-exe", "markdown": "https://wpnews.pro/news/a-curious-journey-into-reverse-engineering-an-ai-generated-python-exe.md", "text": "https://wpnews.pro/news/a-curious-journey-into-reverse-engineering-an-ai-generated-python-exe.txt", "jsonld": "https://wpnews.pro/news/a-curious-journey-into-reverse-engineering-an-ai-generated-python-exe.jsonld"}}