如何保护非托管应用程序中的字符串不受进程转储的影响

How to protect strings in a unmanaged application from process dump

本文关键字：字符串 影响 转储 进程 应用程序 何保护 保护      更新时间：2023-10-16

首先，这不是一个重复的帖子

请读到最后，你明白了！

我正在开发一些应用程序，安全性对我来说非常重要…

我搜索了很多，我做了很多方法，我测试了我找到的每一种方法，但没有太大区别！

◾️我需要保护应用程序中一些非常重要的字符串，如AES256或Base64加密的密钥和IV密钥。

我们都面临的两个事实：

  1. 我们都知道.NET的安全性很低！事实上，一个孩子可以通过手机破解它！！！

  2. 没有什么比100%安全性更好的了，我们只是通过使访问资源变得越来越困难来降低访问速度。。。

但我现在面临的确实是一个严重的安全问题，它可能会伤害很多客户。

好的，是时候提问了

我需要知道如何保护我的AES密钥和AESIV免受转储程序和内存提取器的攻击，即使我无法创建非常高的安全性，我也需要保护它不被一键打开

My application is a Unmanaged C++

我所做和尝试的事情：

A)使用XOR方法：

我使用xor方法创建字符串，但它可以通过string2 dumper一键提取

阅读更多：https://github.com/Jyang772/XOR_Crypter

B)使用分离字符串：

这里有一个例子：

char Departed_String1[4];
int nmbr1 = 0;
char Departed_String1_dep[4];
int nmbr1_dep = 0;
Departed_String1[nmbr1++] = 'T';
Departed_String1_dep[nmbr1_dep++] = 'U';
Departed_String1[nmbr1++] = 'E';
Departed_String1_dep[nmbr1_dep++] = 'C';
Departed_String1[nmbr1++] = 'S';
Departed_String1_dep[nmbr1_dep++] = 'h';
Departed_String1_dep[nmbr1_dep++] = 'U';
Departed_String1[nmbr1++] = 'T';
Departed_String1_dep[nmbr1_dep++] = 'y';
Departed_String1_dep[nmbr1_dep++] = '8';

这个也可以很容易地用调试器打开！

C)我自己的方法：LostChars

const char* teststring_src = "HeVthsNiNVrtTuODkhPgDkmCxQApD:feSCiQDDWePakOTtFcLzTSbKTaZwsUnpeYMlndoYXJyXBpSSSNGsWblpQhUKKCzWUfHnNxQtNsXXnFzXtSGzIBYjCIlSMbEoqwJfArwrqfeLRANEYgjdknHuzSIzgiglRBFEDmFqDBBbgUQD VvDjnQPdFKDYTSxnDXTqKdHtOCayMbACkmQLJqgHtBtTj CoiXxETJwiIkgMgaVaskZtLiWDotsTldTHdBiJiGIfCmjjjBdAbIFiJFFhXPeAjiKbPuktOmiIuhqDkIhMxFBGZevIIjoOuKfddWgUmdFbNfShAIhphPYKhpxtimPhmDatYlOWCXBXQbkFDY QaKyRMhHznNJClQjDmevKUSnfoCXfWplSDzVWxMOkGkntVMmijf QzbalAbRokBAXXfDvevyHbOmAaUIKMBivJVrTxALngQjGShZdzTsZJwIooYLIuqxcTjELFPRFAAzqE fnIznpwtUzEXFBm"; 
std::string teststring = (std::string(1,teststring_src[468])+std::string(1,teststring_src[4])+std::string(1,teststring_src[230])+std::string(1,teststring_src[249])+std::string(1,teststring_src[174])+std::string(1,teststring_src[343])+std::string(1,teststring_src[239])+std::string(1,teststring_src[365])+std::string(1,teststring_src[41])+std::string(1,teststring_src[417])+std::string(1,teststring_src[227])+std::string(1,teststring_src[62])+std::string(1,teststring_src[469])+std::string(1,teststring_src[248])+std::string(1,teststring_src[220])+std::string(1,teststring_src[329])+std::string(1,teststring_src[504])+std::string(1,teststring_src[453])+std::string(1,teststring_src[223])+std::string(1,teststring_src[66])+std::string(1,teststring_src[156])+std::string(1,teststring_src[496])+std::string(1,teststring_src[29])+std::string(1,teststring_src[20]));

不完美的工作仍然转储！

D)使用十六进制而不是字符串：

wchar_t string[7] = { 0x0118, 0x0154, 0x010C, 0x012C, 0x0154, 0x0084, 0x0000 };
for (unsigned int GUEvK = 0, GNsdj = 0; GUEvK < 7; GUEvK++)
{
GNsdj = string[GUEvK];
GNsdj = ((GNsdj << 14) | ( (GNsdj & 0xFFFF) >> 2)) & 0xFFFF;
string[GUEvK] = GNsdj;
}
wprintf(string);

好吧：)这家伙做了一个软件来严重保护字符串哇，太棒了50欧元的优惠！但是这里有一个小问题！

只需2次点击和1秒即可通过Process Explorer进行转储

这是一个例子：

unsigned char myKey[48] = { 0xCF, 0x34, 0xF8, 0x5F, 0x5C, 0x3D, 0x22, 0x13, 0xB4, 0xF3, 0x63, 0x7E, 0x6B, 0x34, 0x01, 0xB7, 0xDB, 0x89, 0x9A, 0xB5, 0x1B, 0x22, 0xD4, 0x29, 0xE6, 0x7C, 0x43, 0x0B, 0x27, 0x00, 0x91, 0x5F, 0x14, 0x39, 0xED, 0x74, 0x7D, 0x4B, 0x22, 0x04, 0x48, 0x49, 0xF1, 0x88, 0xBE, 0x29, 0x1F, 0x27 };
myKey[30] -= 0x18;
myKey[39] -= 0x8E;
myKey[3] += 0x16;
myKey[1] += 0x45;
myKey[0] ^= 0xA2;
myKey[24] += 0x8C;
myKey[44] ^= 0xDB;
myKey[15] ^= 0xC5;
myKey[7] += 0x60;
myKey[27] ^= 0x63;
myKey[37] += 0x23;
myKey[2] ^= 0x8B;
myKey[25] ^= 0x18;
myKey[12] ^= 0x18;
myKey[14] ^= 0x62;
myKey[11] ^= 0x0C;
myKey[13] += 0x31;
myKey[6] -= 0xB0;
myKey[22] ^= 0xA3;
myKey[43] += 0xED;
myKey[29] -= 0x8C;
myKey[38] ^= 0x47;
myKey[19] -= 0x54;
myKey[33] -= 0xC2;
myKey[40] += 0x1D;
myKey[20] -= 0xA8;
myKey[34] ^= 0x84;
myKey[8] += 0xC1;
myKey[28] -= 0xC6;
myKey[18] -= 0x2A;
myKey[17] -= 0x15;
myKey[4] ^= 0x2C;
myKey[9] -= 0x83;
myKey[26] += 0x31;
myKey[10] ^= 0x06;
myKey[16] += 0x8A;
myKey[42] += 0x76;
myKey[5] ^= 0x58;
myKey[23] ^= 0x46;
myKey[32] += 0x61;
myKey[41] ^= 0x3B;
myKey[31] ^= 0x30;
myKey[46] ^= 0x6C;
myKey[35] -= 0x08;
myKey[36] ^= 0x11;
myKey[45] -= 0xB6;
myKey[21] += 0x51;
myKey[47] += 0xD9;

您只需要运行您的应用程序，右键单击Process Explorer中的应用程序并单击Full Dump

繁荣所有字符串都在那里！

**我尝试了很多其他方法，但仍然一切都在Full Dump中…**

真的没有办法防止这种安全漏洞吗？我感谢任何帮助！

首先，请记住，如果攻击者可以将调试器附加到您的进程，而您的进程必须负责解密，那么根据定义，您已经失败了；你能得到的最好的东西就是"默默无闻的安全感"。更安全的方法通常需要将部分工作卸载给攻击者无法访问的参与者，无论是外部防篡改加密设备还是远程服务。

但最重要的是，任何方法都容易被转储，因为你迟早需要访问明文，而且它会在内存中为任何有调试器的人准备好被读取。

话虽如此，您可以通过仅在需要时解密字符串并在之后立即将其擦除来缓解最后一个问题；这缩小了攻击者的机会之窗。因此，您不需要一个解密静态缓冲区的函数，而是需要一个用所需机密填充客户端提供的缓冲区的功能(并确保客户端在释放缓冲区之前将其内容清零-使用memset-类似于volatile指针，以确保擦除未被优化)。

至于实际将密钥存储到可执行文件中，可以使用各种方法来制造混乱。使用普通初始化器初始化全局变量会将相关数据放在可执行文件的.rodata部分，这是我要查找的第一个位置；任何具有足够高熵的字符串都将是进一步研究它在哪里使用的绝对赠品(IDA反汇编程序使这变得特别容易)。脑海中浮现的一种可能性是，从一个函数中一次初始化一个字节的缓冲区(可能将指针指向缓冲区volatile，以确保编译器不会耍奇怪的把戏)；这应该将数据直接放入代码部分，这样就不那么可疑了，而且由于操作码的交织，熵应该保持较低。

这些数据本可以通过使用一些简单的技巧来进一步加密——比如说，将简单的XorShift PRNG的输出进行异或运算；这再次增加了混乱，但XorShift是在少数指令中实现的，因此您没有额外的依赖项或"可疑"代码。

另一个重要的点是，如果你隐藏解密密钥，不要使用操作系统提供的加密原语，而是静态链接你的实现，可能是一个不使用AES-NI或其他明显赠品的实现。如果我首先尝试提取解密密钥，我会将所有相关的CryptoAPI挂接到调试器中，并查看可执行文件中的加密指令，以定位最有趣的区域。

相关文章：