一线开发 [2023]迅速上手meta的llama模型 首先确保自己有足够的资源配置.这边给个资源配置表: ### 硬件要求 7B模型: 1张3090就行,很垃圾,没什么效果 13B模型: 2张3090就行,很垃圾,没什么效果 30B模型: 4张3090是最低要求,推理速度极慢.有条件四张A100 60B模型: 没跑过 这边以30B模型为例: 首先克隆项目: https://github.com/facebookresearch/llama 然后自己网上找个30B的权重 阅读全文 2023-03-13 huoji 2 条评论
一线开发 [2023]LLAMA是否会引发下一代安全领域AI机器学习革命? ###前言 这边不说chatgpt如何智能智能了,都是搞技术的,我们都知道chatgpt是基于transformer的,不是啥闭源技术,主要是数据量的问题. 这边讨论一下一个潜在的可能爆发点,低成本预训练模型的可行性. ###传统模型的不足 在安全领域传统的AI模型据我所知有如下内容 1. 流量检测,如waf等 2. 恶意程序检测 3. DevOps 4. 这个国外比较多,EDR主机日志检测 传统模型其实都面临一个不足,那就是误报大、样本训练开销大,到最后往往都会变成 非白即黑. 对未知样本,一律判黑. 此外困扰传统模型的最大的问题是,AI的理解能力不是那么好,AI的效果直接取决于样本参数的输入 ###LLAMA为什么可能是下一代安全领域的AI机器学习革命 不知道各位注意到了没有,chatgpt也能处理安全相关的事务,是的,这是这些大语言模型的特点-'具有理解能力' 包括你的代码、waf流量日志、主机流量日志,直接脱离传统的需要自定义输入参数的问题,直接问,直接回复.AI就跟理解了一样 这就带来一个非常显而易见的特点,输入参数能泛化,调参成本直线下降,之前各种绞尽**脑汁的想特征提取,现在统统不需要了,AI似乎能理解一下,只要给一段json,就能返回你需要的结果.** 这会大大降低模型的成本,以及大幅度提高模型的效果.试想一下,随便一个人拿llama模型,强化训练一个专用的AI(事实上openAI已经有类似的模型蒸馏接口了) **在原llama模型的理解能力上,分化出专用检出模型,理解能力+检出能力,也许会让目前的AI提高一个等级.** ###缺点 当然我不是专业搞AI的,可能会预测错.这种想法显而易见的也有缺点,那就是llama太占资源了.相比传统的AI,占的资源不是一个量级的.对于现在来说,为了实现一个小功能,去做用尽资源跑一个大模型,可能有点得不偿失. 但是在以后,硬件成本降低后,这一切都有可能 阅读全文 2023-03-12 huoji 1 条评论
APT研究系统安全工具软件二进制安全C/C++一线开发 [2023]Windows X64 Rookit对抗 随着github开源项目越来越多,小黑们的技术水平也在越来越提高,这几天,在处理应急响应的时候,我注意到一个开源的被滥用的rootkit正在使用 即 `autochk.sys` 阅读全文 2023-03-07 huoji 0 条评论
二进制安全C/C++ [2023]VMP还原day3:模式匹配寻找VIP/VSP和Flow Entry 在找到vmstub后.我们需要开始做一些基本的操作,获取一些基本的信息.在此之前,介绍一下我们的基本思路 -模式匹配 阅读全文 2023-02-20 huoji 0 条评论
二进制安全C/C++汇编Shellcode [2023]经典永不过时-返回地址欺骗 在一些攻防场景中,经常会遇到函数调用者检查. 即检查调用者的地址,诺地址不在自己的模块里面,则可以判定为非法调用. 为了对抗这种检查,一种非常经典的技术诞生了,即返回地址欺骗.这项技术从199X年开始被发现,2000年后由于游戏的爆炸式发展加剧了对抗而被推向高峰 阅读全文 2023-02-04 huoji 1 条评论
公告 [2023]新的一年,新的开始 网站已经屏蔽国内地区IP访问. 技术与工具本质上是一样的,都是一把双刃剑,不要因为害怕它而就封锁它.站长认为最好的防止技术滥用的方法是提高入门门槛.屏蔽国内IP访问只是一个开始. 阅读全文 2023-02-03 huoji 0 条评论
系统安全二进制安全 [2022]不使用hypervisor接管windows内核异常 不使用hypervisor的情况下接管内核异常: how? 让我们检查一下内核处理流程: 触发异常后,在KdTrap中通过 KdpDebugRoutineSelect 来去进行异常处理选择(有调试器走1) ```cpp __int64 __fastcall KdTrap(int a1, int a2, int a3, int a4, char a5, char a6) { if ( KdpDebugRoutineSelect ) return KdpTrap_0(a1, a2, a3, a4, a5, a6); else return KdpStub_0(a1, a2, a3, a4, a5, a6); } ``` 在异常不等于STATUS_BREAKPOINT的情况下,也就是不是int3中断的情况下,走到kdreport ```cpp char __fastcall KdpTrap_0( __int64 trapInfo, __int64 commandString, __int64 commandType, __int64 debuggerContext, char response) { char v5; // dl _QWORD *contextPointer; // rbx unsigned __int64 addressValue; // rax __int64 previousAddressValue; // rdi int subtractionResult1; // eax int subtractionResult2; // eax int subtractionResult3; // eax int subtractionResult4; // eax int printFunctionReturnValue; // eax __int64 currentAddressValue; // rax v5 = 0; contextPointer = (_QWORD *)debuggerContext; if ( *(_DWORD *)commandType != 0x80000003 ) return KdpReport(trapInfo, 0, commandType, debuggerContext); ``` 只要不是 fast error或者单步异常,走到KdExitDebugger 里面 ```cpp if ( *a3 == -1073740768 || (unsigned int)(v6 + 2147483645) <= 1 || (unsigned int)(v6 - 1073741854) <= 1 || (NtGlobalFlag & 1) != 0 ) { v9 = a6; if ( a6 || (unsigned int)v6 > 0x4000001D && v6 != 0xC0000037 && v6 < 0x40000020 ) goto LABEL_6; } else { v9 = a6; if ( a6 ) { LABEL_6: v10 = ((__int64 (*)(void))KdEnterDebugger)(); CurrentPrcb = KeGetCurrentPrcb(); v12 = v10; KdpCopyContext(*(_QWORD *)&CurrentPrcb[1].PPPagedLookasideList[3].FreeMisses, *(unsigned int *)(a4 + 48), a4); KiSaveProcessorControlState((__int64)&CurrentPrcb->ProcessorState.SpecialRegisters.MsrLStar, v13); v14 = *(_QWORD *)&CurrentPrcb[1].PPPagedLookasideList[3].FreeMisses; LOBYTE(v15) = v9; v16 = *(_DWORD *)(v14 + 48); v17 = KdpReportExceptionStateChange((__int64)a3, v14, v15); KdpCopyContext(a4, v16, *(_QWORD *)&CurrentPrcb[1].PPPagedLookasideList[3].FreeMisses); KiRestoreProcessorControlState(&CurrentPrcb->ProcessorState.SpecialRegisters.MsrLStar); LOBYTE(v18) = v12; KdExitDebugger_0(v18); result = v17; KdpControlCPressed_0 = 0; return result; } } ``` KdExitDebugger在处理完一些必要的状态后,走到 KeThawExecution_0(v6);里面 而PoAllProcIntrDisabled_0只要为0 就会调用我们的老朋友 **KeQueryPerformanceCounter** ```cpp __int64 __fastcall KeThawExecution_0(char a1) { char v2; // di __int64 v3; // rcx unsigned __int8 v4; // bl unsigned __int64 v5; // rcx unsigned __int64 v6; // rax struct _KPRCB *CurrentPrcb; // rcx __int64 result; // rax v2 = 0; if ( (KiFreezeFlag & 8) == 0 ) v2 = KdPortLocked; ((void (__fastcall *)(_QWORD, _QWORD))off_401A88[0])(0i64, 0i64); if ( !PoAllProcIntrDisabled_0 ) { MEMORY[0xFFFFF78000000350] = KeQueryPerformanceCounter(0i64).QuadPart; KiInterruptTimeErrorAccumulator = 0i64; } ``` 为什么说 **KeQueryPerformanceCounter**是我们的老朋友呢,因为这个hal层的吊东西已经被日烂了,从infinity hook到infinity hook V2. v3 v4 他已经被日烂了 这次被日的原因和infinity hook v4一模一样,是这一步出了问题: ```cpp v2 = HalpPerformanceCounter; if ( *(_DWORD *)(HalpPerformanceCounter + 0xE4) == 5 ) { v37 = 10000000i64; if ( HalpTimerReferencePage ) { if ( (*(_DWORD *)(HalpPerformanceCounter + 224) & 0x10000) != 0 ) v20 = *(_QWORD *)(HalpPerformanceCounter + 72) + (unsigned int)(*(_DWORD *)(HalpPerformanceCounter + 0x50) * HIDWORD(KeGetPcr()[1].LockArray)); else v20 = *(_QWORD *)(HalpPerformanceCounter + 72); v21 = (*(__int64 (__fastcall **)(__int64))(HalpPerformanceCounter + 112))(v20); v22 = MEMORY[0xFFFFF780000003B8]; v10.QuadPart = v22 + RtlUnsignedMultiplyHigh(v21, *((_QWORD *)HalpTimerReferencePage + 1)); } else { do { v24 = *(_QWORD *)(v2 + 0xD0); do { v25 = *(_QWORD *)(v2 + 0xC8); InternalData = HalpTimerGetInternalData(v2); v27 = (*(__int64 (__fastcall **)(__int64))(v2 + 0x70))(InternalData); _InterlockedOr(v36, 0); v28 = *(_QWORD *)(v2 + 200); } while ( v25 != v28 ); } ``` 注意其中的 ```cpp v25 = *(_QWORD *)(v2 + 0xC8); InternalData = HalpTimerGetInternalData(v2); v27 = (*(__int64 (__fastcall **)(__int64))(v2 + 0x70))(InternalData); ``` v2+0x70指向的是HalpHvCounterQueryCounter 在最新的infinity hook中也是他出了毛病,没有被PG保护 因此在满足下列条件后,即可进行内核VEH操作: ```cpp KdpDebugRoutineSelect = 1 PoAllProcIntrDisabled = 0 HalpPerformanceCounter + 0xDC != 0x40 ``` **这会PG吗?** 不 他不会.别问咋知道的,某大型软件现在正在用它全局接管内核异常 完整调用栈: ```cpp 00 fffff803`3d12cfa8 fffff803`3d21ecf8 hal!HalpTimerGetInternalData 01 fffff803`3d12cfb0 fffff803`3d4fd046 hal!KeQueryPerformanceCounter+0x168 02 fffff803`3d12cff0 fffff803`3dabee65 nt!KeThawExecution+0x4a 03 fffff803`3d12d020 fffff803`3d4f4d34 nt!KdExitDebugger+0xb1 04 fffff803`3d12d050 fffff803`3dac2419 nt!KdpReport+0xd8 05 fffff803`3d12d090 fffff803`3d2b9b90 nt!KdpTrap+0x14d 06 fffff803`3d12d0e0 fffff803`3d2b97b0 nt!KdTrap+0x2c 07 fffff803`3d12d120 fffff803`3d453602 nt!KiDispatchException+0x1e0 08 fffff803`3d12d7d0 fffff803`3d44ccf0 nt!KiExceptionDispatch+0xc2 09 fffff803`3d12d9b0 fffff803`3d449471 nt!KiBreakpointTrap+0x370 0a fffff803`3d12db48 fffff803`3d4c2a7e nt!DbgBreakPointWithStatus+0x1 0b fffff803`3d12db50 fffff803`3d4810a4 nt!KdCheckForDebugBreak+0xdbbe2 0c fffff803`3d12db80 fffff803`3d309b8d nt!KeAccumulateTicks+0x1743e4 0d fffff803`3d12dbe0 fffff803`3d30ac73 nt!KiUpdateRunTime+0x5d 0e fffff803`3d12dc30 fffff803`3d21e883 nt!KeClockInterruptNotify+0x8f3 0f fffff803`3d12df40 fffff803`3d361195 hal!HalpTimerClockInterrupt+0x63 10 fffff803`3d12df70 fffff803`3d4420ea nt!KiCallInterruptServiceRoutine+0xa5 11 fffff803`3d12dfb0 fffff803`3d4426d7 nt!KiInterruptSubDispatchNoLockNoEtw+0xea 12 fffff803`3d11f540 fffff803`3d238a0f nt!KiInterruptDispatchNoLockNoEtw+0x37 13 fffff803`3d11f6d8 fffff803`3d413925 hal!HalProcessorIdle+0xf 14 fffff803`3d11f6e0 fffff803`3d30c3d8 nt!PpmIdleDefaultExecute+0x15 15 fffff803`3d11f710 fffff803`3d30bc05 nt!PpmIdleExecuteTransition+0x648 16 fffff803`3d11fb00 fffff803`3d44435c nt!PoIdle+0x345 17 fffff803`3d11fc60 00000000`00000000 nt!KiIdleLoop+0x2c ``` 阅读全文 2022-12-21 huoji 2 条评论
