Timeline for What kinds of steps can I take to make my C++ application harder to reverse engineer?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jun 4, 2023 at 2:35 | history | suggested | Rohit Gupta | CC BY-SA 4.0 |
Corrected typos
|
| May 26, 2023 at 3:49 | review | Suggested edits | |||
| S Jun 4, 2023 at 2:35 | |||||
| Jun 21, 2014 at 15:32 | comment | added | user2005 | I agree - we're just trying to build a better lock. Can you give any links to articles that discuss these things you mention? | |
| Jun 21, 2014 at 10:18 | comment | added | Peter Andersson | @Sosukodo I would put the variables into a local cache, probably on the stack, decrypt them there, use them, then zero out the memory. I would also make sure that the decryption algorithm, usage and key is completely embedded in VM based obfuscation. It's important that there's not an easy way of finding and decrypting all variables by some automated means. Embedding the key into virtualized code and not into data makes this much harder. It's of course very hard to make it impossible but we're trying to make the work of the reverse engineer as tedious and boring as possible. | |
| Jun 20, 2014 at 21:41 | comment | added | user2005 | "So using static variables that decrypt when loaded [..] will lead to a quick find". What is the alternative? | |
| Mar 22, 2013 at 14:29 | vote | accept | WilliamKF | ||
| Mar 21, 2013 at 14:46 | comment | added | Peter Andersson | Haha, yeah you can definitely pick complex heavily templated code in order to get some free obfuscation. Wasn't there an article on /r/re showing the use of templates only in order to create a pure C++ obfuscation framework with opaque predicates and using template meta programming to generate random numbers using a linear congruential generator? I seem to remember one at least. | |
| Mar 21, 2013 at 14:24 | comment | added | Igor Skochinsky♦ | "use inlining very generously and wrap them in a good obfuscation algorithm" <- just add Boost. Boost + inlining + LTCG = hell on wheels. Tens of copies of the same functions with different registers used to pass arguments and differently inlined subfunctions, twenty kinds of smart pointers, argh! | |
| S Mar 21, 2013 at 12:50 | history | edited | Peter Andersson | CC BY-SA 3.0 |
added 1403 characters in body
|
| Mar 21, 2013 at 12:46 | review | Suggested edits | |||
| S Mar 21, 2013 at 12:50 | |||||
| Mar 21, 2013 at 12:40 | history | edited | Peter Andersson | CC BY-SA 3.0 |
added 1403 characters in body
|
| Mar 21, 2013 at 12:24 | history | answered | Peter Andersson | CC BY-SA 3.0 |