我对自己进行红队测试以学习逆向工程
作者通过对其 TUI、APK 和 WASM 二进制文件运行 REA 来对自己的闭源 P2P 消息应用进行自我红队测试,以评估反编译抵抗力,并分享了反编译后的仓库。
关于这个案例
一份防御性自我评估报告:作者对自家项目的二进制文件(Rust TUI、APK、Web)运行了 REA(github.com/morluto/rea),以评估 AI 辅助逆向工程能够多容易地反编译其闭源 P2P 消息应用,并分享了由此产生的反编译仓库。
安装配置
安装方法请查看原始来源。
原文 / README
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)). https://glitr.io https://app.glitr.io 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) submitted by /u/Accurate-Screen8774 to r/cybersecurityai [link] [comments]
其他同名作品
- 我对自己进行了红队测试以了解逆向工程Accurate-Screen8774 · ★ 0
