Obfuscation and reverse engineering deterrents for C++ Win/OSX app

Obfuscation and reverse engineering deterrents for C++ Win/OSX app

凯凯我们等你回来 发布于 2021-11-25 字数 807 浏览 785 回复 2 原文

I've got a C++ app that ships on Windows and OSX. It communicates with our backend using TCP (encrypted with OpenSSL, natch). I'd like to throw up some speed bumps for folks who are trying to reverse engineer the protocol and/or disassemble the executable.

Skype does an excellent job of this, which is why you won't find a lot of apps that speak skype. Here is a really good read about what it does: http://www.secdev.org/conf/skype_BHEU06.handout.pdf

I'd like some ideas about how to accomplish similar stuff our app. Are there commercial products that make code harder to statically analyze? What is the best way to invest my time to accomplish the goals I've listed?

Thanks,

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

梦在深巷 2022-06-07 2 楼

If I remember correctly Skype is using something similar (maybe they pay them to implement it in Skype, who knows) to "Code Guards" described in:

https://www.cerias.purdue.edu/tools_and_resources/bibtex_archive/archive/2001-49.pdf

情定在深秋 2022-06-07 1 楼

Some simple suggestions for OSX:

  • Prevent gdb from attaching to your program
    http://www.steike.com/code/debugging-itunes-with-gdb/
    (this can be worked around, but will keep some casual explorers away)

  • Have at least some of the code in your product stored outside the text segment of the executable, for example in data, or in an external (encrypted) shared library.

  • Minimally protect any sensitive string data by not storing it in plain text. Run "strings" against your executable, and if you see anything that might be helpful to someone trying to figure out the protocol, encrypt it.

  • GCC's -fomit-frame-pointer option can make debugging more painful (but can interact badly with C++ exceptions).