r/Pentesting • u/Accurate-Screen8774 • 9h ago
I Red-Teamed Myself to Learn About Reverse Engineering
https://glitr.io/blog/reverse-engineering-my-own-project
i wanted to red-team myself on my project and id like to know how to reverse engineer so i can see what can be done to defend against it.
my app is aiming to be fully client-side. things like javascript seem like it would relatively easy for an AI to chew-up, my latest project is in rust, which would make it harder for a person, but AI can digest binaries.
i created a fairly unique p2p messaging app. a Rust-based frontend with a Git-server backend, which can be used to establish a P2P connection. while this version remains close-source, i have aimed to create the most comprehensive documentation (formal-verification and security audits too (all ai generated under my guidance)).
a core detail to my project is the focus on local-first and client-side cryptography and storage. id wanted to learn how vulnerable this project is to decompilation. i think my older iteration as a javascript webapp would be relatively easy for AI, so i thought id put a spin-on-things by having a rust wasm frontend... i dont think it even slowed it down.
i dont know much about decompiling, but i think the TUI would be the easiest for it to decompile and given its largly one codebase, it can be used to trace and see whats going on the build for the other platforms.
it might be that all close source is obselete. i tried asking here, and the responses there are polar opposites, so i decided to get some first-hand experience.
im using using cursor composer 2.5 (far from the frontier models available). i used https://github.com/morluto/rea and gave it a few binaries of my project (tui, apk, web) and pointed it to the documentation on the website.
after a few prompts, it seems to have done a decent job decompiling the project here: https://github.com/positive-intentions/glitr-decompiled (note: this is basically AI-slop). like with many projects, i see AI lacks taste in architecture. it consolidates a lot of complexity into one repo, when in my project it's split into multiple repos. it also seems to lack a bunch of bells and whistles i added for my own benefit like formal verification and rigorous unit-tests (having done it myself before, i dont think that is a large gap to fill for somone who knows what they are doing). i think the overhead to keep up with new changes may become trivial if you can automate the process. i kinda offer the base in the repo above (maybe it saves you a few tokens?), but its for my own research and i dont plan to maintain it given it undermines the actual project.
in general, im impressed. it seems this may push forward my timeline for when i open source my project, i wasnt expecting close-source being so easy to undemine. while the project can be decompiled, in a project like this, its important to consider the countless nuances there are in cybersecurity. the code is only a part of the project.
(note: feel free to try decompile this yourself or offer tips on how i can improve. id be keen to see what can be done. feel free to reach out for clarity about how it works within the limitation of the original source code not being used)