|
[原创]把mbedtls移植进内核!
记得当初我移植的时候,遇到一个问题是mbedtls使用的内存分配函数是POSIX那套,得自己重写一下内存分配函数的宏,大概看了一下你的头文件,没看到处理这个问题的地方? |
|
|
|
|
|
[求助] x64下SSDT Hook *检测* 的一个问题
はつゆき KiServiceTable在内核加载以后数据会被修改,当然算法和纯映射的不一样,我告诉你的是把内核文件映射到内存中以后的算法。你自己用我给你的算法去算重载以后的内核,然后又来说我的算法不对。我是没有 ...说你的算法不对主要原因是: 没有考虑到参数的运算。 我想再次强调一下, “第二点, 并不是什么太大问题”, 不要过于纠结文件映射到内存的事情。 如果你一定要纠结,那我想按照你的逻辑反驳一下: 我问的是把内核文件重载后如何计算正确地址的问题, 你自己用IDA的数据描述了一遍静态环境下的计算方式, 我是没有在一楼强调用_petl_LdrReloadPE 重载了内核吗? |
|
[求助] x64下SSDT Hook *检测* 的一个问题
はつゆき 为什么要重载内核?直接映射有问题吗?而且你是不是对IDA的数据有一些误解?为什么IDA还会帮你重定位?单就计算SSDT原始值这块, 没有必要重载内核,可以直接映射。 不过我一楼一开始说了, 这是个产品, 同样要兼容x86, 要保证重载的内核可用(老技术了, 例如重载内核过TP……),所以我上面说“不是什么太大的问题” 对于IDA帮你重定位, 只是一种逻辑上的理解, 你可以不认同。 我的证据是,如果你edit->segments->rebase, 然后随便输入个地址(当然要勾选对应选项), 那么IDA的KiServiceTable处的值依然是正确指向对应函数的。那如果你是IDA的作者,在默认载入的情况下,是不是应该用OptionalHeader.ImageBase处取出默认值作为基址,然后发现KiServiceTable“不需要重定位”…… |
|
[求助] x64下SSDT Hook *检测* 的一个问题
はつゆき 低版本KernelBase + (KiServiceTable[Index](0x140080C50) - ImageBase(0x140000000))高版本KernelBase + KiServi ... 先简单说一下吧, 后面会水文章详细解释。 你要的答案, 全部都在 nt!KeCompactServiceTable 里, 所以强烈建议你看一下这个函数, 简单一点说就是如下逻辑: TableSize = ServiceDescriptorTable->ntoskrnl.TableSize; ServiceTableBase = ServiceDescriptorTable->ntoskrnl.ServiceTableBase; ArgumentTable = ServiceDescriptorTable->ntoskrnl.ArgumentTable; for (Index = 0; Index < TableSize; ++Index) { UHALF_PTR FunctionCookie = 0; PUHALF_PTR Pointer = ServiceTableBase + Index * 4; UINT8 ArgumentCookie = *(PUCHAR)(ArgumentTable + Index); switch (OSVersion.dwMajorVersion) { case NT_MAJOR_VERSION_6: FunctionCookie = (UHALF_PTR)*(PUHALF_PTR)(ServiceTableBase + Index * 8) \ - (UHALF_PTR)ServiceTableBase; *Pointer = (16 * FunctionCookie) | (ArgumentCookie >> 2); break; case NT_MAJOR_VERSION_10: FunctionCookie = (UHALF_PTR)*(PUHALF_PTR)(ServiceTableBase + Index * 4) \ - (UHALF_PTR)ServiceTableBase + (UHALF_PTR)NewImageBase; *Pointer = (16 * FunctionCookie) | (ArgumentCookie >> 2); break; } } Win7-Win8.1的内核, 是把8个字节压缩到4个字节。 Win10开始本身就是4个字节。 第一点, 计算过程需要各个函数参数数据参与 (也就是 | (ArtumentCookie >>1)这个操作), 你的代码中没有考虑到参数的问题,这可能导致你最终计算函数地址最后一个字节会出现偏差。 第二点, 不是什么大问题只是一个实现的时候会遇到的细节, 实操中重载的内核大概率会经过重定位, 重定位后的代码本身就已经减过默认地址 ImageBase(0x140000000) 了, 所以你的公式并不通用, 只能在IDA这个数据下(实际上IDA也给你重定位过了)成立。 任意版本的公式是(X64下): PUCHAR KiServiceTable = xxxxxx; // xxxxxx为KiServiceTable基址 PVOID FunctionAddr = KiServiceTable + (HALF_PTR)(*(PHALF_PTR)(KiServiceTable + Index * 4)) >> 4; 而上面的*(PHALF_PTR)(KiServiceTable + Index * 4), 即为 *Pointer 的值, 也就是经过 nt!KeCompactServiceTable的值。 |
|
[求助] x64下SSDT Hook *检测* 的一个问题
はつゆき 抛开_petl_LdrReloadPE和_utl_KeFixServiceDescriptorTable,直接从KiServiceTable下手 第一步,映射ntoskrnl.exe进内核,以下称为 ...感谢你的回复哈~ 我先说一下简短的结论: 你这个算法不对 目前问题我已经解决了, 有点复杂, 正好水一篇文章回回血~ |
|
[原创]一文读懂PE文件签名并手工验证签名有效性
mb_zlxyahlt 大佬 牛的 tinyans.1 编译成windows端 的方法有吗 cmake构建vs项目报错并没有什么特别需要注意的地方, 我是拿来直接用了, 似乎注意一下数据类型, windows的类型名称好像不太一样。 |
|
IDA Hexray反汇编后的代码, 标准数据结构的负值索引问题
cooolie .text:00000001C000BD90 loc_1C000BD90: & ...我曹 所以杨大侠是下内存写断点找到这个地方的? |
|
[求助]IDA Hex-rays F5后面的自动注释是什么意思,求教
@的意思是猜得,不一定准确:第几个参数? <eax>的意思是FPO,表明程序采用了FPO技术,部分参数通过寄存器传值(<eax>标识该参数通过eax传递). |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
能力排名:
No.{{ rank_num }}
等 级:
LV{{ rank_lv-100 }}
活跃值:
在线值:
浏览人数:{{ visits }}
最近活跃:{{ last_active_time }}
注册时间:{{ user_info.create_date_jsonfmt }}
勋章
兑换勋章
证书
证书查询 >
能力值