能力值：
( LV2，RANK：10 )
|
-
-
2 楼
目前我表面的能看到的逻辑如下。
fake netapi32.dll的dllmain里面，新建一个mutex，之后对GetEnvironmentVariableW和RegOpenKeyExW下hook。
hook的新的fakeGetEnvironmentVariableW和fakeRegOpenKeyExW函数里面，分别会判断 lpName参数和lpSubKey参数。
如果这个参数是LM_LICENSE_FILE 或 SOFTWARE\\FLEXlm License Manager，说明调用来自flexlm的dll，这个时候通过getModuleHandleExA获得flexlm函数所在的模块handle。对这个flexlm模块进行patch。
这里的flexlm模块patch的逻辑，没看明白，里面壳和混淆什么的太多，晕了。
希望清楚的大侠帮忙解释解释。
感谢。
|
能力值：
( LV2，RANK：10 )
|
-
-
3 楼
自己补充下内容：
由于netapi32.dll loader本身 ollvm的很严重，静态分析比较困难。所以换了个思路，比较了下经过内存patch之后的调用flexlm的dll/exe与patch前的dll/exe，发现ssq的方法是patch了 l_pubkey_verify 函数的头部，修改为了
xor eax, eax
retn。
但是netapi32.dll里面怎么定位到每个调用flexlm的dll/exe的l_pubkey_verify函数的具体位置的，目前还没搞明白逻辑。
有明白的大侠可以指点一二。
|
能力值：
( LV2，RANK：10 )
|
-
-
4 楼
当时我也想看是怎么patch的，发现混淆了，就没搞了
|
能力值：
( LV2，RANK：10 )
|
-
-
5 楼
记录一下最新进展。 大体上理清了SSQ是怎么定位l_pubkey_verify函数并patch的。 hook后，当被hook的函数开始被调用的时候，就回去检查是否是flexlm target，如果是再去检查是否已经patch过。没patch的话就会从PE header之后开始搜索16进制 0x2655.
SSQ认为若一个函数同时满足如下条件，那他就认为这个函数是l_pubkey_verify
1. 能搜索到16进制0x2655 2. 在出现0X2655之后，0xFA的字节范围内接着出现了0xffffff8c 3. 0xffffff8c出现之后，后续很快出现0xb8并且0xb8之后紧跟着就是0xffffffd3，或者很快出现0xc7，并且0xc7之后第六个字节开始是0xffffffd6。
当定位到l_pubkey_verify之后，就开始向前回溯，找到l_pubkey_verify函数头，并patch掉。
|
能力值：
( LV2，RANK：10 )
|
-
-
6 楼
coolspace
记录一下最新进展。大体上理清了SSQ是怎么定位l_pubkey_verify函数并patch的。hook后，当被hook的函数开始被调用的时候，就回去检查是否是flexlm target，如果是再去检 ...
他是采用什么方法回溯到函数头的呢
|
能力值：
( LV2，RANK：10 )
|
-
-
7 楼
为什么x64dbg里直接没有netapi32的加载痕迹呢,这都是我这个菜鸟不明白的地方
|
能力值：
( LV2，RANK：10 )
|
-
-
8 楼
先往前回溯足够的长度，之后开始进行汇编指令识别，一直找到最后的retn，再跳过函数间的无效指令填充，就到了
|
能力值：
( LV2，RANK：10 )
|
-
-
9 楼
x64dbg里看不到加载痕迹，可能和篡改了teb里的数据有关
LIST_ENTRY* head = &NtCurrentTeb()->ProcessEnvironmentBlock->Ldr->InMemoryOrderModuleList;
LIST_ENTRY* next;
for (next = head->Flink; next != head; next=next->Flink)
{
LDR_DATA_TABLE_ENTRY* pEntry = (LDR_DATA_TABLE_ENTRY*)CONTAINING_RECORD(next, LDR_DATA_TABLE_ENTRY, InMemoryOrderLinks);
if (pEntry->DllBase == hModule)
{
pEntry->FullDllName.Buffer[0] = '0';
}
}
return 0;
|
|
|
|
