我一直在思考如何保护我的C/ c++代码不被反汇编和逆向工程破坏。通常情况下，在我的代码中，我绝不会宽恕这种行为;然而，为了各种人的安全，我目前正在研究的协议决不能被检查或理解。
现在这对我来说是一个新的主题，互联网并没有真正的资源来防止逆向工程，而是描述了大量关于如何逆向工程的信息
到目前为止我想到的一些事情是:
Code injection (calling dummy functions before and after actual function calls)
Code obfustication (mangles the disassembly of the binary)
Write my own startup routines (harder for debuggers to bind to)
void startup();
int _start()
{
startup( );
exit (0)
}
void startup()
{
/* code here */
}
Runtime check for debuggers (and force exit if detected)
Function trampolines
void trampoline(void (*fnptr)(), bool ping = false)
{
if(ping)
fnptr();
else
trampoline(fnptr, true);
}
Pointless allocations and deallocations (stack changes a lot)
Pointless dummy calls and trampolines (tons of jumping in disassembly output)
Tons of casting (for obfuscated disassembly)
我的意思是，这些是我想过的一些事情，但它们都可以在适当的时间框架内由代码分析师解决。我还有别的选择吗?
通过不公开来保证安全并不像比他聪明得多的人所证明的那样有效
我们两个。如果你必须保护你的客户的通信协议，那么你是
道德上有义务使用最好的代码，这些代码是公开的，并由专家全面审查。
这适用于人们可以检查代码的情况。如果您的应用程序是在嵌入式微处理器上运行的，那么您可以选择一个具有密封功能的微处理器，这使得在运行时不可能检查代码或观察更多的琐碎参数，例如当前使用情况。(是的，除了硬件入侵技术，你要小心地拆卸芯片，使用先进的设备来检查单个晶体管上的电流。)
我是x86逆向工程汇编程序的作者。如果你准备感冒的话
惊喜，寄给我你竭尽全力的结果。(通过我的网站联系我。)
在我所看到的答案中，很少有人会给我带来实质性的障碍。如果你想看的话
如何复杂的逆向工程代码工作，你真的应该研究网站
逆向工程挑战。
你的问题需要澄清一下。你怎么能保守协议的秘密，如果
计算机代码可以进行逆向工程吗?如果我的协议是发送一个RSA加密消息(甚至是公钥)，通过保持协议的秘密，你能得到什么?
出于所有实际目的，检查器将面对一系列随机比特。
问候阿尔伯特
最好的反反汇编技巧，特别是在可变字长指令集上，是在汇编程序/机器代码中，而不是在c中
CLC
BCC over
.byte 0x09
over:
The disassembler has to resolve the problem that a branch destination is the second byte in a multi byte instruction. An instruction set simulator will have no problem though. Branching to computed addresses, which you can cause from C, also make the disassembly difficult to impossible. Instruction set simulator will have no problem with it. Using a simulator to sort out branch destinations for you can aid the disassembly process. Compiled code is relatively clean and easy for a disassembler. So I think some assembly is required.
I think it was near the beginning of Michael Abrash's Zen of Assembly Language where he showed a simple anti disassembler and anti-debugger trick. The 8088/6 had a prefetch queue what you did was have an instruction that modified the next instruction or a couple ahead. If single stepping then you executed the modified instruction, if your instruction set simulator did not simulate the hardware completely, you executed the modified instruction. On real hardware running normally the real instruction would already be in the queue and the modified memory location wouldnt cause any damage so long as you didnt execute that string of instructions again. You could probably still use a trick like this today as pipelined processors fetch the next instruction. Or if you know that the hardware has a separate instruction and data cache you can modify a number of bytes ahead if you align this code in the cache line properly, the modified byte will not be written through the instruction cache but the data cache, and an instruction set simulator that did not have proper cache simulators would fail to execute properly. I think software only solutions are not going to get you very far.
上面这些都是老的和众所周知的，我对当前的工具了解不够，不知道它们是否已经围绕这些事情工作了。自修改代码可能/将使调试器出错，但是人类可以/将缩小问题范围，然后看到自修改代码并解决它。
It used to be that the hackers would take about 18 months to work something out, dvds for example. Now they are averaging around 2 days to 2 weeks (if motivated) (blue ray, iphones, etc). That means to me if I spend more than a few days on security, I am likely wasting my time. The only real security you will get is through hardware (for example your instructions are encrypted and only the processor core well inside the chip decrypts just before execution, in a way that it cannot expose the decrypted instructions). That might buy you months instead of days.
另外，读读凯文·米特尼克的《欺骗的艺术》。这样的人可以拿起电话，让你或同事把秘密交给系统，以为那是公司其他部门的经理、其他同事或硬件工程师。你的安全系统也被破坏了。安全不仅仅是管理技术，还要管理人。
我不认为任何代码都是牢不可破的，但奖励必须非常棒，才能让人们愿意尝试它。
话虽如此，你还是应该做以下事情:
Use the highest optimization level possible (reverse engineering is not only about getting the assembly sequence, it is also about understanding the code and porting it into a higher-level language such as C). Highly optimized code can be a b---h to follow.
Make structures dense by not having larger data types than necessary. Rearrange structure members between official code releases. Rearranged bit fields in structures are also something you can use.
You can check for the presence of certain values which shouldn't be changed (a copyright message is an example). If a byte vector contains "vwxyz" you can have another byte vector containing "abcde" and compare the differences. The function doing it should not be passed pointers to the vectors but use external pointers defined in other modules as (pseudo-C code) "char *p1=&string1[539];" and "char p2=&string2[-11731];". That way there won't be any pointers pointing exactly at the two strings. In the comparison code you then compare for "(p1-539+i)-*(p2+11731+i)==some value". The cracker will think it is safe to change string1 because no one appears to reference it. Bury the test in some unexpected place.
尝试自己破解汇编代码，看看哪些是容易的，哪些是困难的。您可以尝试一些想法，使代码更难进行反向工程，并使调试更加困难。
