逆向工程应成为威胁模型的一部分

https://glitr.io/blog/reverse-engineering-my-own-project TLDR; i thought my project would have been harder to chew up. it was surprisingly low-effort. I don't think it completely undermines my project being close source, but it does seem trivial enough for it to be a factor in the threat model. i wanted to learn more about this reverse engineering trend myself on my project, so i can see what can be done to defend against it. my app is aiming to be fully client-side. An implementation in javascript seems like it would relatively easy for an AI to swallow. my latest project is in rust, which would make it harder for a person, but AI can now 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 aimed to create comprehensive technical documentation (formal-verification and security audits too). https://glitr.io https://app.glitr.io a core detail to my project is the focus on client-side cryptography and storage. 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. In practice, i dont think AI broke a sweat. i know nothing about decompiling, but i think the TUI would be the easiest for it to decompile... and given its largly one codebase for all the platforms, it can be used to trace and see what is going on in the builds 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. i used cursor's "auto" agent (in contrast to the frontier models available). i used https://github.com/morluto/rea and tried to make it easier by proving it with a few binaries of my project (tui, apk, web, desktop) and pointed it to the documentation as a 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 output of the deco pilation process ) 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 it's a large gap to close for somone who knows what they're doing. i think the overhead to keep up with new changes may become trivial if you can automate the process of ingesting new binaries. 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 considering how fast and low effort this was. it seems this may push forward my timeline for when i open source my project, i wasnt expecting client-side 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 software development and cybersecurity. the code is only a fraction of the project. i think people should try this in their own code. while the decompiled output is not the same codebase, it seems trivial for me to take some unfamiliar app and rebuild a protocol-compatible version with some new button, feature... or auto-installing malware. (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 if the docs are not clear) submitted by /u/Accurate-Screen8774 to r/Infosec [link] [comments]