Nothing Is Secret

Cache为什么能提升性能

1. Cache的容量设计

上篇文章中介绍到CPU Cache是分级的，L1 Cache是集成在Core内部的，L2则是紧贴着Core，而L3是多个Core共享的。离Core（流水线）越近的分级速度越快，但容量也更小，并且造价愈贵。Cache的实现采用了高速的SRAM电路 (静态随机存取存储器: Static Random-Access Memory)，SRAM相对DRAM (动态随机存取存储器: Dynamic Random Access Memory)要复杂和庞大的多，即使不考虑成本能做到无限增大，但因为电路复杂度的提升其性能即访问速度必然会下降，另外也会使得CPU的面积急速膨胀。最终，CPU的每一级Cache的容量都是在设计之初考虑各方面因素折中后的结果（trade-off）。下图是AMD Zen的CCX的die shot[来源：1. Zen - Microarchitectures - AMD]，从图中我们就能看中L2及L3 Cache占据了很大一部分的面积： AMD ZEN die shot

一般而言L1 Cache约几十K，L2则是几百K，L3是几M或几十、几百M，但相比较内存动不动几十G的大小来说还是小了太多，根本不在一个数量级上。那么问题来了：Cache容量比内存小了太多，为什么根本不在一个数据量级的Cache能够大副度提升系统性能？

2. 局部性原理 (Principle of Locality)

简言之，程序倾向于访问（或执行）刚刚访问过的数据（执行过的指令）或与之相临近的数据（指令）

2.1 时间局部性 (Temporal locality):

刚刚被访问的地址（数据）在未来有很大的可能性被再次访问，即用过的数据可能会再次被用到

2.2 空间局部性 (Spatial locality):

刚刚被访问的地址的临近位置在未来有很大的可能被访问，以数组D[]为例，当前访问的是D[i]，那么D[i+1]有很大的可能将被访问

2.3 算法局部性：

程序代码也遵守2/8法则，即帕累托法则（Pareto principle，亦称关键少数法则），80%的时间都是在执行20%的代码

正是因为局部性原理，少量的Cache大大减少了数据的访问延迟，从而提升了整体性能。

3. Cache的放大效应

先来考虑一个问题：Cache命中率(Cache Hit) 99%与98%的差别会有多大？从数值上来看二者本身仅相差1%，性能上最终能有多大差别呢？

假设命中L1的延时为4 cycles，不命中的话需要从内存中读取数据的延时为150 cycles，那么： 99%命中率的情况: 0.99 4 + 0.01 150 = 5.46 98%命中率的情况: 0.98 4 + 0.02 150 = 6.92

后者比前者的延时多了(6.92 - 5.46) / 5.46 = 26.7% 之多。换成95%的命中率的话，延时将高达99%命中率时的一倍之多。由此看来，不命中（Cache Miss）所带的性能惩罚巨大，这也预示了未来Cache发展的趋势，即容量将越来越大，拥有GB级Cache容量的CPU将指日可待，另外增加L4分级也将是不可避免的，有兴趣的读者可进一步参阅 [2. The Next Platform: Cache Is King]。

4. Cache Miss的原因

前面说了Cache Miss的惩罚，下面说一下会导致Cache Miss的因素，可以简单归纳为3C:

  1. Cold (Compulsory) Miss： 第一次访问数据时，数据根本不在Cache中
  2. Conflict Miss： 因冲突导致Cache Line被驱逐出Cache，上一篇文章中提到了相关的方法，如Evict(驱逐)、Prime(装填)等，当然冲突所导致的Cache Miss只针对组相联的Cache结构（直接映射可以认为是单路组相联），而全相联的Cache结构是没有Conflict Miss的，后续还会针对此课题做详细的介绍
  3. Capacity Miss： Cache的容量毕竟有限，如果程序确实需要密集访问大量内存时，Cache必然是不够的

在指定的CPU硬件上如果想提升Cache Hit的话就要从这几个因素上着手，如通过硬件预取以减少Cold Miss，通过程序算法改进及结构重组可减少2和3所带来的Cache Miss的发生概率，本文先点到为止，后面将进行详细拆解。

5. 参考资料

  1. wikichip: Zen - Microarchitectures - AMD
  2. The Next Platform: Cache Is King

CPU Cache测量方法

通过上一篇文章《通过TSC观察CPU》知道了可以通过TSC来测量CPU的内部行为，本文将介绍CPU Cache的结构及几种常用的测量手法：

Cache的分级结构

Memory & Cache的分级结构

  • Cache 是分级的：一般分为3级，较老的CPU如Core 2 Duo只有2级。L1是集成是core内部的，指令与数据Cache是分离的，好L1C和L1D；L2是紧贴core的；L3是多核共享的，每个core有自己的Slice，通过Ring Bus或Mesh结构互联互访
  • Cache以Cache Line为访问单位，即Cache及内存的访问是以块为单位的，而不是字节单位。较新的X86 CPU的Cache Line一般是64字节。上一篇文章通过TSC观察CPU曾注意到一个有趣的测量结果：X86程序访问一个1字节与访问2个、4个及8个字节的延进均为31个指令周期，并不是线性增长的，就是这个原因
  • 层级包含与否由CPU实现决定：L2一般都是包含L1的全部内容的，L3可以是Non-inclusive，也可以是Exclusive。Intel的CPU一般是包含的，但AMD的Zen系列CPU的L3就是定义为L1/L2的Victim Cache，Victim是指从L1及L2中移除的Cache项
  • Cache自身的构造采用“组相联”方式

Cache不同分级的性能

Memory & Cache性能数据

在上图中看到Cache是分级的，用不同级的访问速度有很大不同，故我们可以通过制造冲突或直接Flush Cache的方式将数据从Cache中清除，从而通过前后内存访问的时间差来进行判定。

测量方法

制造冲突以清除Cache的常用手段有以下几种【参阅 1：Cache side channel attacks: CPU Design as a security problem by Anders Fog]】：

  1. Evict (驱逐) + Time (测量) ： 通过制造冲突以达成被测量目标数据从cache中清除的目的
  2. Prime (装填) + Probe (探测) ：与1)方法一样，只是作用对象是反的
  3. Flush (冲刷) + Reload (加载) ) ：最主动和最快的办法，直接利用clflush指令刷新，然后再读取内存，此时会发生Cache Miss事件。
  4. Flush (冲刷) + Flush (冲刷) ) ：与3)类似，但测量的是clflush指令针对数据在不在cache中的执行周期的不同 在条件许可的情况下，尽量采用第3种，即最快的办法。

实例：Flush + Reload

Flush即clflush指令，Visual C++中定义如下：

        extern void _mm_clflush(void const*_P);

测量代码：

        /* flush */
        _mm_clflush(&data[0]);

        /* measure cache miss latency */
        ts = rdtscp(&ui);
        m |= data[0];
        te = rdtscp(&ui);

实战：Cache Line的测量

原理： Cache性能测量方法

结论： Cache性能结果

从图中我们可以看到64字节是一个明显的分界点。

硬件预取: Hardware Prefetcher

如果你在自己的电脑上进行测试，你看到的可能不是上图所示的样子，很大的可能如下图所示，明显的分界点不是64字节而是128字节： Cache性能结果

这是因为硬件预取即HWPrefetcher的缘故，并且硬件预取默都是开启的。硬件预取功能会在每次Cache Miss的情况下多读一个Cache Line，可以理解为每次读取两个Cache Line即64 * 2 = 128字节，但数据并不是同时到达的，第二个Cache Line的数据的到达周期会晚些，这也是为什么在128这个点上的延时会比64高。 CPU Cache Prefetcher

如何关闭硬件预取:

  1. 通过BIOS设置： 通过BIOS选项来关闭hwprefetcher，对所有的CPU生效
  2. 通过内核调试器windbg直接关闭：通过直接改写msr寄存器关闭当前核的硬件预取功能: 
    0: kd> rdmsr 0x1a4
msr[1a4] = 00000000`00000000
0: kd> wrmsr 0x1a4 0x0f
0: kd> ~1
1: kd> rdmsr 0x1a4
msr[1a4] = 00000000`00000000
1: kd> wrmsr 0x1a4 0x0f
1: kd> rdmsr 0x1a4
msr[1a4] = 00000000`0000000f
1: kd> ~0

实战：Cache不同分级的访问延时测量

如果我们以更大的的stride进行同样的测试则可以测量出Cache每一级的大小，即L1D，L2，LLC和内存访问的延时。下图中我们分别以1K、2K，直至64M的stride测量出来结果： Cache性能结果 可以看到整个曲线有4个平台，分别表示L1D、L2、LLC和内存。L1D的大小为32K，L2为256K，这部分和CPUZ的输出是一致的。 但第三个平台包含了512K、1M及2M，从4M开始延进有明显的跃升，从8M之后基本稳定在高位。这里就涉及到了LLC组织的不同：L1D及L2 Cache都是与物理核（Core）绑定的，而LLC是绑定CPU的，即2核的CPU的两个核心会共享同一个LLC，整个LLC是平均分配给每个核的，然后每个核心的LLC通过Ring Bus互联，即每个核又可以访问所有的LLC。这里在4M的stride发生波动的原因有两个：

  1. 当前运行测量程序的CPU核心用尽自己的LLC后会通过Ring Bus竞争访问另一个核心的LLC
  2. 测量程序运行时整个操作系统也在运行，所以整个系统均会竞争使用LLC，必然会带来挤出效应，从而增大了延时

参考资料

  1. CSCA: Cache side channel attacks: CPU Design as a security problem by Anders Fogh
  2. HWPF: Disclosure of Hardware Prefetcher Control on Some Intel® Processors
  3. SourceCode: CacheLatency Github Repo

通过TSC观察CPU

自Pentium开始x86 CPU均引入TSC了，可提供指令级执行时间度量的64位时间戳计数寄存器，随着CPU时钟自动增加。

CPU指令：

rdtsc: Real Time-Stamp Counter rdtscp: Real Time-Stamp Counter and Processor ID

调用:

Microsoft Visual C++:

unsigned __int64 __rdtsc();
unsigned __int64 __rdtscp( unsigned int * AUX );

Linux & gcc :

extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__rdtsc (void) {
  return __builtin_ia32_rdtsc ();
}
extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__rdtscp (unsigned int *__A)
{
  return __builtin_ia32_rdtscp (__A);
}

示例：

1: L1 cache及内存的延迟测量:

代码：

{
    ......
    /* flush cache line */
    _mm_clflush(&data[0]);

    /* measure cache miss latency */
    ts = rdtscp(&ui);
    m |= data[0];
    te = rdtscp(&ui);
    CALC_MIN(csci[0], ts, te);

    /* measure cache hit latency */
    ts = rdtscp(&ui);
    m &= data[0];
    te = rdtscp(&ui);
      /* flush cache line */
    _mm_clflush(&data[0]);

    /* measure cache miss latency */
    ts = rdtscp(&ui);
    m |= data[0];
    te = rdtscp(&ui);
    CALC_MIN(csci[0], ts, te);

    /* measure cache hit latency */
    ts = rdtscp(&ui);
    m &= data[0];
    te = rdtscp(&ui);
    CALC_MIN(csci[1], ts, te);
    CALC_MIN(csci[1], ts, te);
}

结果：

rdtscp指令自身耗时：X86: 31 X64: 33

架构 X86 X64
长度 BYTE WORD DWORD QWORD BYTE WORD DWORD QWORD
冷：内存 244 241 246 250 254 254 260 261
热：L1 31 31 31 31 35 35 35 35

问题：读取1个字节与8个字节的所用的时间是一样的，为什么？

2: 常见整型运算及多条指令执行周期:

代码：

{
    ......
    /* measure mul latency */
    ts = rdtscp(&ui);
    m *= *((U32 *)&data[0]);
    te = rdtscp(&ui);
    CALC_MIN(csci[2], ts, te);

    /* measure div latnecy */
    ts = rdtscp(&ui);
    m /= *((U32 *)&data[0]);
    te = rdtscp(&ui);
    CALC_MIN(csci[3], ts, te);

    /* measure 2*mul latnecy */
    ts = rdtscp(&ui);
    m *= *((U32 *)&data[0]);
    m *= *((U32 *)&data[0]);
    te = rdtscp(&ui);
    CALC_MIN(csci2[0], ts, te);

    /* double div */
    ts = rdtscp(&ui);
    m /= *((U32 *)&data[0]);
    m /= *((U32 *)&data[0]);
    te = rdtscp(&ui);
    CALC_MIN(csci2[1], ts, te);

    /* mul + div */
    ts = rdtscp(&ui);
    m *= *((U32 *)&data[0]);
    m /= *((U32 *)&data[0]);
    te = rdtscp(&ui);
    CALC_MIN(csci2[2], ts, te);

    /* measure float mul latency */
    ts = rdtscp(&ui);
    f = f * m;
    te = rdtscp(&ui);
    CALC_MIN(csci[4], ts, te);

    /* measure float div latency */
    while (!m)
        m = rand();
    ts = rdtscp(&ui);
    f = f / m;
    te = rdtscp(&ui);
    CALC_MIN(csci[5], ts, te);
}

结果：

指令周期
数据类型 整型 浮点数
指令组合 m* m/ m, m m, n m/, m/ m/, n/ m*, m/ f* f/
指行时间 2 20 4 4 48 26 24 17 26

问题：m及n的除法运算的耗时只比m的除法多了一点，但却明显少于m的两次除法，为什么？

注意事项：

  1. 考虑到CPU乱序执行的问题，rdtsc需要配合cpuid或lfence指令，以保证计这一刻流水线已排空，即rdtsc要测量的指令已执行完。后来的CPU提供了rdtscp指令，相当于cpuid + rdtsc，但cpuid指令本身的执行周期有波动，而rdtscp指令的执行更稳定。不过rdtscp不是所有的CPU都支持，使用前要通过cpuid指令查询是不是支持： 即CPUID.80000001H:EDX.RDTSCP[bit 27]是不是为1
  2. 多核系统：新的CPU支持了Invariant TSC特性，可以保证在默认情况下各核心看到的TSC是一致的，否则测量代码执行时不能调度至其它核心上。另外TSC是可以通过MSR来修改的，这种情况下也要注意： Invariant TSC: Software can modify the value of the time-stamp counter (TSC) of a logical processor by using the WRMSR instruction to write to the IA32_TIME_STAMP_COUNTER MSR
  3. CPU降频问题：第一代TSC的实现是Varient TSC，没有考虑到降频的问题，故在低功耗TSC计数会变慢，甚至停止；后来又有了Constant TSC，解决了降频的问题，但在DEEP-C状态下依然会发生停止计数的情况，所以又有了最新的Invariant TSC的特性： The time stamp counter in newer processors may support an enhancement, referred to as invariant TSC. Processor’s support for invariant TSC is indicated by CPUID.80000007H:EDX[8]. The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states. This is the architectural behavior moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition or access to a platform resource.
  4. 指令本身的时间开销 Pentinum Gold G5500T: 31 cycles Core i7-7820HQ: 25 cycles
  5. 权限问题（此指令可用于时序攻击，如Meltdown及Spectre）: CR4.TSD: Time Stamp Disable (bit 2 of CR4) — Restricts the execution of the RDTSC instruction to procedures running at privilege level 0 when set; allows RDTSC instruction to be executed at any privilege level when clear. This bit also applies to the RDTSCP instruction if supported (if CPUID.80000001H:EDX[27] = 1).
  6. 计数器溢出可能：计算器本身是64位的，即使是主频4G的CPU，也要100多年才会溢出，对于我们的测量来说可以不用考虑
  7. 时序测量容易被干扰（线程调度、抢占、系统中断、虚拟化等），要求测量的指令序列尽量短，并且需要进行多次测量

Linux内核监控

本文将简单罗列Linux监控的实现方式，安全及审计软件的前提就是能在关键点上接管系统的执行流程，而关键点的接管必须依赖Linux内核的监控能力：

1 LSM HOOK

Linux内核中为发实现其安全机制，已经预留了LSM HOOK埋点，以4.4.131的内核为例，系统共提供了多达198个监控点回调，4.4.131是当前麒麟操作操作系统的内核版本，而较新的5.4.2内核已经支持多达216监控回调：

类别 钩子函数个数 功能
ptrace 2 Ptrace操作的权限检查
能力机制 3 Capabilities相关操作的权限检查
磁盘配额 2 配盘配额管理操作的权限检查
超级块 13 mount/umount/文件系统/超级块相关操作的权限检查
dentry 2 dentry相关操作的权限检查
文件路径 11 文件名/路径相关操作的权限检查
inode 27 inode相关操作的权限检查
file 13 file相关操作的权限检查
程序加载 5 运行程序时的权限检查
进程 27 进程/进程相关操作的权限检查
IPC 21 IPC消息/共享内存/信号量等操作的权限检查
proc文件系统 2 proc文件系统相关操作的权限检查
系统设置 2 日志，时间等相关操作的权限检查
内存管理 1 内存管理相关操作的权限检查
安全属性 7 对安全相关数据结构的操作的权限检查
网络 37 网络相关操作的权限检查
XFRM 11 XFRM架构想要关操作的权限检查
密钥 4 密钥管理相关操作的权限检查
审计 4 内核审计相关操作的权限检查
Android Binder 4 Android Binder架构有关操作的权限检查
总计 198

其中我们最关心的是进程、程序加载、内存及文件相关的监控回调，从数量及功能上已足够强大，但具体能否满足我们的需求，还要在实现过程中进行分析和验证。比如以进程创建为例，Linux内核的进程创建是通过sys_clone（sys_fork/sys_vfork）及sys_execve实现的，但LSM的监控点为了避免多入口的问题，放在了task_alloc这个点上：调用栈如下所示：

backtrace
#0  security_task_alloc (task=0xffff923cad2f8000, clone_flags=4001536) at security/security.c:1472
#1  0xffffffffa0a88ff4 in copy_process (clone_flags=4001536, stack_start=<optimized out>, stack_size=<optimized out>, child_tidptr=<optimized out>, pid=0x0, trace=<optimized out>, tls=<optimized out>, node=-1) at kernel/fork.c:1746
#2  0xffffffffa0a8a59f in copy_process (node=<optimized out>, tls=<optimized out>, trace=<optimized out>, pid=<optimized out>, child_tidptr=<optimized out>, stack_size=<optimized out>, stack_start=<optimized out>, clone_flags=<optimized out>) at kernel/fork.c:1574
#3  _do_fork (clone_flags=4001536, stack_start=<optimized out>, stack_size=<optimized out>, parent_tidptr=<optimized out>, child_tidptr=<optimized out>, tls=<optimized out>) at kernel/fork.c:2056
#4  0xffffffffa0a8a969 in SYSC_clone (tls=<optimized out>, child_tidptr=<optimized out>, parent_tidptr=<optimized out>, newsp=<optimized out>, clone_flags=<optimized out>) at kernel/fork.c:2166
#5  SyS_clone (clone_flags=<optimized out>, newsp=<optimized out>, parent_tidptr=<optimized out>, child_tidptr=<optimized out>, tls=<optimized out>) at kernel/fork.c:2160
#6  0xffffffffa0a03ae3 in do_syscall_64 (regs=0xffff923cad2f8000) at arch/x86/entry/common.c:287
#7  0xffffffffa1400081 in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:237
#8  0x00007ffc00600600 in ?? ()
#9  0x000056066c0ceec0 in ?? ()
#10 0x0000000000000000 in ?? ()

在进程创建这个点上我们需要取到哪些信息：主进程、子进程、调用栈及相应的符号信息等等，但security_task_alloc这个点不能满足我们的需求，但再利用程序加载（BPRM）的相关回调我们即可将所有的信息串联起来，有了这个信息我们就能够做进详细的检测与判定，以上就是我们解决问题的主要思路。

2 Syscall_Table HOOK

这种方式就类似于 SSDT HOOK，但Linux内核并没有类似于Windows内核的PatchGuard （KPP）的防护机制，目前天擎国产化就是使用的此技术，但在PKS系统上，可信计算以及澜起安全内存对syscall table以及内核镜像都是有安全度量以及内存防改保护。另外为了解决Meltdown，Linux内核引入的KPTI以及ARM64系统上引入的Syscall Table Wrapper （4.19之后）都给Syscall Table HOOK带来挑战

需要注意的事，Linux内核中会存存多个syscall table，比如X64为了支持32位的x86程序会保留32位移程序的syscall table，另外Linux还有一项特殊的syscall tabke专为X64_32程序使用，X64_32类别程序内部直接使用的是64位的syscall id

3 代码Inline HOOK

代码Inline hook做为针对Syscall Table hook的延伸，但同样亦面临可信度量及内存保护的挑战

4 ftrace & kprobe机制

Linux内核为了提升在线解决问题的效率，实现了动态插桩机制，可以在内核”任意函数“点进行插桩，用以输出参数及函数变量，甚至改变函数执行流程。当然这种技术主要是用于排错应急，如果用于生产环境还需要更多的技术验证。这种技术的明显限制是针对同一个函数只能进行一个插桩，并且插桩行为是能够被可信计算发现的，亦可被阻止。

5 中断向量HOOK

X86体系下应用层通过syscall或sysenter切换至内核模式，ARM体系下通过SVC或SWI可以切换至内核，切换模式的指令最终是通过自陷阱（Trap）触使CPU进行模式切换，并自动执行事先指定位置处的代码。我们可以通过接管中断向量的方式实现Syscall的HOOK，但是此方式会有以下难点：

  1. 入口片要处理相当多的初始化工作，只能用汇编级指令实现
  2. 针对开启KPTI的内核，要保证入口代码在Shadow内核空间

6 GhostHOOK

依赖于硬件PMU的HOOK实现方式，Intel及AMD在各自的CPU上均实现了类似的机制，ARM架构上的CP15协处理器亦实现了类似的功能，但相对Intel的PMU在功能上要弱一些，但均可以达成类似的HOOK效果。

当然通过高精度时间中断亦可达成同样效果

7 内核hot patch

ARM64平台可利用 aarch64_insn_patch_text 进行函数层的hook。

Windows系统通用回调

Windows系统通用回调 本文将针对Windows操作系统所提供系统回调操作做逐一分析，以了解每个回调所能达成什么样的功能及效果。比如部分回调只是用于通知，我们只能通过此回调来了解某一类型事件的发生，只能做审计，拦截动作需要通过其它途径实现；也有回调可以实现即时拦截，通过回调即可阻止恶意程序的攻击企图。 Windows系统在内核及应用层均有提供回调机制，下面分为两部分作介绍：

1 内核回调

内核回调机制 OS版本 功能描述 备注
PsSetCreateProcessNotifyRoutine WIN2K 只是进程创建及退出通知
PsSetCreateProcessNotifyRoutineEx VISTA SP1/SRV2008 可通过返回值阻止进程创建
PsSetCreateProcessNotifyRoutineEx2 WIN10 1703 可接收到WSL/PICO进程创建及退出通知；可阻止进程创建
PsSetCreateThreadNotifyRoutine (PsRemoveCreateThreadNotifyRoutine) WIN2K 线程创建及退出通知 创建时的context为创建者，可用以判断是不是远程线程
PsSetCreateThreadNotifyRoutineEx (PsRemoveCreateThreadNotifyRoutine) WIN10 线程创建及退出通知 创建时的context为新线程环境
PsSetLoadImageNotifyRoutine (PsRemoveLoadImageNotifyRoutine) WIN2K 模块加载通知：支持驱动及应用层DLL加载通知 无模块卸载通知
PsSetLoadImageNotifyRoutineEx (PsRemoveLoadImageNotifyRoutine) WIN10 1709 模块加载通知：支持驱动及应用层DLL加载通知 无模块卸载通知
IoRegisterBootDriverCallback (IoUnRegisterBootDriverCallback) WIN8 Boot-Start驱动加载通知，可拦截，但拦截的后果即BSOD 加载顺序问题；ELAM驱动最早加载，需要特殊签名
SeRegisterImageVerificationCallback (SeUnregisterImageVerificationCallback) WIN8.1 ? 驱动加载回调，可以验证驱动签名信息 函数未公开，目前Windows Defender会使用
ObRegisterCallbacks (ObUnRegisterCallbacks) VISTA SP1 SRV2008 针对进程及线程对象句柄的创建提供前置及后置回调，可修改句柄权限，如针对进程对象无VM映射权限。子进程继承句柄不会通知 WIN7系统可监控文件句柄的创建，需要修改未公开的系统结构（ObjectType->SupportsObjectCallbacks），WIN8后PG会监控。WIN10系统增加了桌面对象的监控支持
CmRegisterCallback (CmUnRegisterCallback) XP 注册表操作回调，可修改、转向或拦截原访问请求 XP/SRV2003/VISTA行为有差异
CmRegisterCallbackEx (CmUnRegisterCallback) VISTA 注册表操作回调，可修改、转向或拦截原访问请求
ExRegisterCallback
-- \Callback\SetSystemTime WIN2K 系统时钟修改回调
-- \Callback\PowerState WIN2K 电源状态改变回调（AC/DC，电源策略，待机或关机） 早于Power Manager的IRP_SET_POWER请求
-- \Callback\ProcessorAdd VISTA 动态增加新CPU事件通知
KeRegisterBoundCallback (KeDeregisterBoundCallback) WIN10 用以捕获应用层边界检测异常，可用于应用层HOOK
Standard Event Objects for VM : 所有 主要用于监控内存状态
-- \KernelObjects\HighMemoryCondition
-- \KernelObjects\LowMemoryCondition
-- \KernelObjects\HighPagedPoolCondition
-- \KernelObjects\LowPagedPoolCondition
-- \KernelObjects\HighNonPagedPoolCondition
-- \KernelObjects\LowNonPagedPoolCondition
-- \KernelObjects\LowCommitCondition
-- \KernelObjects\HighCommitCondition
-- \KernelObjects\MaximumCommitCondition
KeRegisterBugCheckCallback (KeDeregisterBugCheckCallback) WIN2K 系统出错准备蓝屏时的回调通知
KeRegisterBugCheckReasonCallback (KeDeregisterBugCheckReasonCallback) XP SP1 SRV2003 蓝屏后DUMP生成通知，可写入额外1-PAGE信息
FsRtlRegisterFileSystemFilterCallbacks XP 文件系统或过滤驱动回调，一般由I/o Manager，VM及CM发起
IoRegisterFsRegistrationChange (IoUnregisterFsRegistrationChange) 所有 文件系统注册事件通知回调 WIN2K: 已注册文件系统驱动不再通知；XP: 均会通知
IoRegisterFsRegistrationChangeEx (IoUnregisterFsRegistrationChange) WIN2K SP4 文件系统注册事件通知回调，忽略RAW设备 同IoRegisterFsRegistrationChange
IoRegisterFsRegistrationChangeMountAware (IoUnregisterFsRegistrationChange) WIN7 文件系统注册事件通知回调，忽略RAW设备 会额外处理与挂载/Mount的竞争问题
TmEnableCallbacks VISTA 文件事务操作回调
IoRegisterContainerNotification (IoUnregisterContainerNotification) WIN7 会话/Session改变通知，如新用户登录或登出，功能类似于用户层的WTSRegisterSessionNotification
KeRegisterProcessorChangeCallback (KeDeregisterProcessorChangeCallback) WIN2K 动态CPU添加事件回调 有Pre和Post处理
KeRegisterNmiCallback (KeDeregisterNmiCallback) SRV2003 发生不可屏蔽中断时的回调通知
IoRegisterShutdownNotification (IoUnregisterShutdownNotification) WIN2K IRP_MJ_SHUTDOWN请求回调
IoRegisterLastChanceShutdownNotification (IoUnregisterShutdownNotification) WIN2K IRP_MJ_SHUTDOWN请求回调 调用时机晚，在文件系统处理完毕之后
PoRegisterPowerSettingCallback (PoUnregisterPowerSettingCallback) VISTA 电源管理事件响应回调
IoRegisterPlugPlayNotification (IoUnregisterPlugPlayNotification[Ex]) WIN2K PNP事件回调（设备热插拔）
IoWMISetNotificationCallback XP WMI事件回调
DbgSetDebugPrintCallback 未公开 VISTA 捕获内核打印事件（DbgPrint）
IoRegisterPriorityCallback (IoUnregisterPriorityCallback) 未公开 WIN7 SP1 ? I/O 请求优先级调整
PoRegisterCoalescingCallback (PoUnregisterCoalescingCallback) 未公开 WIN8.1 CM和文件系统相关：在系统空闲的时候实施cache的聚合刷新
PsSetLegoNotifyRoutine 未公开 XP 类似TLS，可以实现线程终结时的回调通知

2 应用层回调

应用层回调 OS 功能 备注
LdrRegisterDllNotification (LdrUnregisterDllNotification) VISTA 可接收进程内DLL模块加载及卸载事件，不可拦截
ProcessInstrumentationCallback WIN7 可在程序每次Ring 0至3切换后收到通知，在系统服务调用结束时刻 需要进程注入后主动调用NtSetInformationProcess，需要SeDebugPrivilege等
RegisterServiceCtrlHandler(Ex) XP 在应用层服务中接收系统事件：设备热插拔、用户登录、电源管理等
RegisterDeviceNotification 所有 GUI程序获取硬件改变通知
RegNotifyChangeKeyValue WIN2K 监控注册表指定键的子键及值的改变
ReadDirectoryChange 所有 监控指定目录中的文件及子目录的变化
AddSecureMemoryCacheCallback (RemoveSecureMemoryCacheCallback) VISTA SP1 可监控Secure类型的共享内存的释放
LdrSetDllManifestProber 未公开 XP 可收到DLL模块加载事件，可用于拦截
LdrInitShimEngineDynamic 未公开 WIN7 可接收Shim Engine通知，可接管DLL加载等 调用时机有要求，需要R3 HOOK; 不同Windows版本如WIN7及8.1差别较大
RtlSetThreadPoolStartFunc 未公开 WIN2K 设置线程初始化及退出函数，kernel32内部使用

3 通用回调的限制

Windows系统虽然提供了回调接口，但因为性能等各种因素的原因还会限定回调的数量：

  • CmRegisterCallback限制为最多100个，无高度号设置，后注册的回调可能收不到请求
  • PsSetLoadImageNotifyRoutine限制为最多8个，64位系统共64个
  • PsSetCreateProcessNotifyRoutine限制为最多8个
  • PsSetCreateThreadNotifyRoutine限制为最多8个 不少驱动安装为了防止注册失败的情况选择了尽早启动并完成相关回调的注册，也有一些工具如PcHunter会通过DKOM方式进行动态扩展。 另外不同的OS版本的支持限制，在上表中也有说明，如Vista之后的Windows系统才开始支持注册表事务操作，这部分在使用中也要注意，Ob Callback也有类似的问题。

4 参考链接

  1. Magnesium Object Manager Sandbox, A More Effective Sandbox Method for Windows 7
  2. MSDN: Filtering Registry Calls
  3. Filter Manager Support for Minifilter Drivers
  4. MSDN: REG_NOTIFY_CLASS enumeration
  5. CodeMachine: Kernel Callback Functions
  6. OSR: Kernel Mode Extensions Driver
  7. WDK Samples: Registry Logging
  8. https://blog.csdn.net/whatday/article/details/52623878
  9. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/handling-notifications

Windows进程注入

0 前言

安全软件为了达成进程安全及行为审计的目标经常会采用进程注入的方式，即将自己的DLL注入至用户进程中，以对恶意的注入模块进行对抗。就进程注入方法来说有多种方式，木马及攻击方可使用的手段更多，毕竟攻击者对稳定性及善后部分不用做过多考虑。 本文将对注入方式做一个简单的汇总对比，下面分别从应用层及内核层的不同实现方案进行拆解：

1 应用层注入手段

本章节将主要介绍完全应用层的注入实现。

1.1 远程线程及APC注入、SetThreadContext

这两种方式的实现机制是不同的，但思路是一样的，都需要上传负载（Payload）至要注入的进程空间，一般的操作过程如下：

通过OpenProcess获取进程句柄(HANDLE)，然后在目标进程空间申请内存（VirtualAlloc或VirtualAllocEx]），然后调用WriteProcessMemory将shellcode负载写入目标进程空间，最后调用CreateRemoteThread、NtCreateThreadEx、RtlCreateUserThread等创建用户线程，或者添加APC（QueueUserApc）至用户线程以完成shellcode的执行目的。

SetThreadContxt机制是将原线程挂起（SuspendThread），通过修改线程Context中的eip/rip指针至上传的shellcode地址。

Shellcode的设计一般只是简单的LdrLoadDll的调用，复杂的有如DoublePulsar木马所采用的，直接将Payload DLL进行展开并手工加载。

用户层注入的问题是权限受限，另外很容易被检测到，现在的杀软普遍都会特殊关照上述的这些特征函数。

1.2 Win32消息钩子

通过Win32 API SetWindowsHookEx注册系统级消息钩子，以截获同一桌面上所有线程的消息通信，从而实现了DLL模块的注入。当然消息钩子的局限也很明显：

  1. 被注入进程必须接受用户输入，使用了消息队列，如带GUI界面程序；服务进程一般无需用户输入，所以此种注入方法对服务进程无效 64位系统中，64位进程只能设置针对64位程序的消息HOOK，32位进程只针对32位程序，不可交叉混用。和SetWindowsHookEx类似的2. SetWinEventHook 虽然同样可以取到所有进程的消息，但并不能导致DLL注入。
  2. Windows Automation API：Windows Automation API提供给程序访问其它程序窗口及组件（UI elements）的能力，一般用于自动化测试。利用Windows Automation API实现注入的过程，和消息钩子的方式没有本质区别，也有着同样的限制。

    1.3 系统提供机制（注册表选项）

    1) App Init DLLs

    所有加载User32.dll的程序均会自动加载此键值下的DLL，主要针对Win7及之前的Windows版本，从Win8之后此机制不被推荐使用，在UEFI Secure Boot模式下此项被默认关闭。

所在注册表位置：

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

使用此方式的木马及病毒：Ginwui、Cherry Picker、T9000

2) App Cert DLLs

所有调用下面Win32 API的程序均会自动加载上述注册表中所列的DLL文件：

  • CreateProcess
  • CreateProcessAsUser
  • CreateProcessWithLoginW
  • CreateProcessWithTokenW
  • WinExec

所在注册表位置：

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager

使用此方式的木马及病毒：Honeybee、FIN8 PUNCHBUGGY

3) Image File Execution Options

这是Windows系统提供的一个调试辅助机制，用以在特定进程启动或退出时启动指定程序（如调试器等）。用户通过更改IFEO键值达成启动不同进程的目的，从而导致原进程加载请求失败。

所在注册表位置：

  • HKLM\SOFTWARE{\Wow6432Node}\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\

4) Shim Database (SDB)攻击

Windows系统通过Shim数据库（SDB文件，位于%windir%\AppPatch\sysmain.sdb）以提升应用程序的向后兼容（backward compatibility）。SDB数据库中包含针对上千个程序的上百种配置，只要有管理员权限就可操纵此数据库，就可以修改任意程序的各种属性，如以下多种属性：

  • InjectDll
  • LoadLibraryRedirectFlag
  • ForceAdminAccess
  • RelaunchElevated
  • WrpMitigation
  • DisableNX
  • ModifyShellLinkPath
  • VirtualRegistry
  • DisableAdvancedRPCClientHardening
  • CorrectFilePaths
  • DisableSeh
  • DisableWindowsDefender
  • ShellExecuteXP

涉及注册表项：

  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB

使用此方式的木马及病毒：BlackEnergy, GooKit, Roaming Tiger,QianSet.exe,VzQqgi.dll木马

1.4 PE程序IAT表静态修改

早期的Win32病毒常采用的就是静态感染方式，会将自身的代码写入被被感染程序，然后修改PE入口函数至病毒的代码段；同样的方式，静态修改PE文件的导入表以增加新的DLL注入亦不是难事。

针对有签名的PE程序，类似的修改会导致签名校验失败。

1.5 DLL替换

创建一个假个但导出一模一样的DLL文件用以替换原系统的，替换办法一般有两种办法：

  1. 系统原DLL文件改名，并替换系统DLL
  2. 更改DLL搜索路径（SetDLLDirectory）

这种方式要处理的问题：

  1. 系统模块签名问题无法处理：PPL进程将无法运行
  2. 不同版本的系统DLL处理堆积

2 内核层注入手段

内核R0层注入要比应用层R3的手段少了很多，实现难度会大一些，但内核实现更加隐蔽，难以被屏蔽。通过创建用户层线程或插入APC以实现注入的方式被普遍使用，原理上同R3的远程线程及APC注入的思路基本一致，均需要向目标进程空间上载参数及shellcode代码，只是R0及R3各自使用的支持函数不同。

2.1 IAT表注入

在进程创建过程中，内核驱动通过PsSetCreateProcessNotifyRoutine或PsSetCreateProcessNotifyRoutineEx得到通知，此时用户进程的创建过程是被阻塞的，在处理通知的回调中，内核驱动可以修改进程的内存镜像中的导入表，将要注入的驱动加入其中。

以wermgr.exe进程（PID: 0x6bc）的创建为例，此进程由services.exe（PID: 0x2bc）创建： Windows注入-IAT表 后续会收到模块加载的通知回调，加载模块的顺序依次为wermgr.exe自身、ntdll.dll、kernel32.dll、KernelBase.dll、msvcrt.dll等，回调时的调用栈为： Windows IAT注入 导入表修改动作是在进程镜像本身的模块加载回调中执行的，即程序本身模块加载的时机。

IAT表注入的主要问题：

  1. .NET程序的兼容性问题
  2. 托管代码与非托管DLL代码的混合
  3. 64位.NET程序没有导入表项
  4. 受保护进程的注入问题，必须要通过NTDLL HOOK来解决，因为创建Section对象时内核会验证DLL签名等，在IAT已注入的情况下签名又无法签证通过时会导致程序加载失败

2.2 Shellcode注入

创建用户线程及插入APC的注入手段均需要上载shellcode代码至目标进程，shellcode可以只是简单的LdrLoadDll调用用以加载HOOK引擎及工作模块，复杂一些的话可以在内核层将DLL手工加载至目标进程空间，正如木马DoublePulsar所实现的加载器【D23】"Generic Relective DLL Loader"或者内核层Turla Driver Loader（TDL）驱动加载器【D18】。

常用shellcode/payload构造（BlackBone的实现）：

// shellcode for X64
UCHAR code[] =
{
0x48, 0x83, 0xEC, 0x28,             // sub rsp, 0x28
0x48, 0x31, 0xC9,                   // xor rcx, rcx
0x48, 0x31, 0xD2,                   // xor rdx, rdx
0x49, 0xB8, 0, 0, 0, 0, 0, 0, 0, 0, // mov r8, ModuleFileName   offset+12
0x49, 0xB9, 0, 0, 0, 0, 0, 0, 0, 0, // mov r9, ModuleHandle     offset+28
0x48, 0xB8, 0, 0, 0, 0, 0, 0, 0, 0, // mov rax, LdrLoadDll      offset+32
0xFF, 0xD0,                         // call rax
0x48, 0xBA, 0, 0, 0, 0, 0, 0, 0, 0, // mov rdx, COMPLETE_OFFSET offset+44
0xC7, 0x02, 0x7E, 0x1E, 0x37, 0xC0, // mov [rdx], CALL_COMPLETE
0x48, 0x83, 0xC4, 0x28,             // add rsp, 0x28
0xC3                                // ret
};

// shellcode for X86
UCHAR code[] =
{
0x68, 0, 0, 0, 0,                   // push ModuleHandle        offset+01
0x68, 0, 0, 0, 0,                   // push ModuleFileName      offset+06
0x6A, 0,                            // push Flags
0x6A, 0,                            // push PathToFile
0xE8, 0, 0, 0, 0,                   // call LdrLoadDll          offset+15
0xBA, 0, 0, 0, 0,                   // mov edx, COMPLETE_OFFSET offset+20
0xC7, 0x02, 0x7E, 0x1E, 0x37, 0xC0, // mov [edx], CALL_COMPLETE
0xC2, 0x04, 0x00                    // ret 4
};

1) 创建用户线程

创建用户线程一般通过NtCreateThreadEx（Visata及以后OS）或NtCreateThread（XP），这两个函数在内核中均未导出且是未公开的，其地址获取可以通过SSDT或者ntoskrnl镜像解析完成。

NTKERNELAPI NTSTATUS NTAPI
NtCreateThread(
__out PHANDLE ThreadHandle,
__in ACCESS_MASK DesiredAccess,
__in_opt POBJECT_ATTRIBUTES ObjectAttributes,
__in HANDLE ProcessHandle,
__out PCLIENT_ID ClientId,
__in PCONTEXT ThreadContext,
__in PINITIAL_TEB InitialTeb,
__in BOOLEAN CreateSuspended
);

NTKERNELAPI NTSTATUS NTAPI
NtCreateThreadEx(
OUT PHANDLE hThread,
IN ACCESS_MASK DesiredAccess,
IN PVOID ObjectAttributes,
IN HANDLE ProcessHandle,
IN PVOID lpStartAddress,
IN PVOID lpParameter,
IN ULONG Flags,
IN SIZE_T StackZeroBits,
IN SIZE_T SizeOfStackCommit,
IN SIZE_T SizeOfStackReserve,
OUT PVOID lpBytesBuffer
);

2) APC注入

在内核中构造一个APC结构并添加至用户线程的APC队列，等条件满足时系统会执行APC中设定的callback，从而达成进程DLL注入的目的。

相关函数原型如下：

NTKERNELAPI VOID NTAPI
KeInitializeApc (
__out PRKAPC    Apc,
__in PRKTHREAD  Thread,
__in KAPC_ENVIRONMENT   Environment,
__in PKKERNEL_ROUTINE   KernelRoutine,
__in_opt PKRUNDOWN_ROUTINE  RundownRoutine,
__in_opt PKNORMAL_ROUTINE   NormalRoutine,
__in_opt KPROCESSOR_MODE    ProcessorMode,
__in_opt PVOID  NormalContext
);

NTKERNELAPI BOOLEAN NTAPI
KeInsertQueueApc    (
__inout PRKAPC  Apc,
__in_opt PVOID  SystemArgument1,
__in_opt PVOID  SystemArgument2,
__in KPRIORITY  Increment
);

360安全卫士的驱动360fsflt.sys、木马DoublePulsar【D22】等所采用的方式就是Kernel APC注入，这种方式被普遍使用。但APC注入要注意以下问题：

  1. 时机问题：要求所注入进程已经创建了线程并且已经执行（主线程都是紧随进程创建的）
  2. 依赖线程状态：APC的执行依赖于所注入线程的状态：一般是从内核态切换回用户态时执行
  3. 必须与注入线程做同步，或者在所注入线程环境中插入APC，不然可能会注入至错误进程，另外与第三方驱动同时注入APC存在竞争及一致性问题，当然竞争窗口极小; 每个线程均有两个APC队列，当线程在内核态下调用KeAttachProcess时会做切换，切换过程中没有任何保护

3) HOOK NTDLL方式

内核驱动可以通过内核的回调机制截获用户进程创建及PE加载器加载并初始化DLL链的每个环节，可以监控到指定模块加载时同步进行inline hook，并将关注点的执行流程导向至已上载的shellcode负载。

回调本身是串行在程序的加载流程中的，即回调不返回，进程的创建及DLL的加载过程是被阻塞的，省却了同步与不一致性的问题的处理。

之所以要选择ntdll.dll的原因是，ntdll.dll是所有的Win32程序必须加载的，并且其执行过程比程序本身的入口执行要早；另外选择ntdll.dll而不是Kernel32.dll等模块的原因是，Kernel32.dll等模块并不是必须的，比如Native程序如csrss,exe、autochk.exe等，还有一些程序将Kernel32.dll等模块设置为Delay-Loading-DLL，并不会在程序启动之初就立即加载并执行。

为了尽早地获取控制权，常用的HOOK点一般放在ntdll!LdrInitializeThunk、ntdll!NtOpenDirectoryObject或者ntdll!LdrLoadDLL等关键函数点。Haiheiwang木马【D16】就是通过修改ntdll!NtTestAlert的流程将自己的工作模块加入被感染进程的，当然ntdll!NtTestAlert也存在时机较晚的问题，并不能满足咱们的需求。

这种方式在安全软件中也广泛使用，特别是对针对Win8系统年引入的受保护进程的注入问题，由内核注入Shellcode并通过HOOK ntdll!NtCreateSection来加载非系统模块是最实用且有效方式，目前360安全卫士的注入亦是采用此方式。受保护PPL进程只对用户层的Section对象创建有签名验证，我们通过将内核层创建Section对象映射至用户空间的方式达成向受保护PPL进程注入的目的。

其它的替代方案会导致受保护进行安全性的妥协等，比如短暂取消受保护进行的保护状态以达成注入目的，此种方式有可能会触发KPP/PG检测失效，另外也很容易被第三方恶意利用，比如MalwareFox AntiMalware的一个被曝光的漏洞【D24: MalwareFox AntiMalware 2.74.0.150 LPE】。

Shellcode内存映射可以在HOOK引擎模块加载之后进行销毁，存在窗口时间非常短，被其它安全软件查到或被其它恶意程序所利用的可能比较小。

3 参考资料

3.1 浏览器自身防护资讯

B1: About Google Chrome's incompatible applications warning

B2: Firefox will block DLL Injections

B3: Protecting Microsoft Edge against binary injection

3.2 进程DLL注入资料

D1: DLL Injection with SetThreadContext

D2: R3 DLL Injection: Inject All The Things

D3: COUNTERCEPT: Analyzing the DOUBLEPULSAR Kernel DLL Injection Technique

D4: COUNTERCEPT: Dynamic Shellcode Execution

D5: Ten Process Injection Techniques

D6: DLL Injector via Windows Automation API

D7: Microsoft: AppInit DLLs and Secure Boot

D8: BlackHat: Malicious Application Compatibility Shims

D9: To SDB, Or Not To SDB: FIN7 Leveraging Shim Databases for Persistence

D10: FreeBuf: 走近微软安全技术Shim

D11: ABICC: Windows API/ABI Changes Analysis

D12: MITRE ATT&CK: Application Shimming

D13: FireEye: The Real Shim Shady

D14: iSIGHTPARTNERS: 固守: 微软Fix It补丁机制原理及攻击利用

D15: 腾讯：木马牟利再出新招-恶意利用Windows shim技术锁主页

D16: 腾讯：Haiheiwang木马分析

D17: Windows Vista APC Internals

D18: TDL: Turla Driver Loader

D19: Scylla and API Set Map

D20: Microsoft Docs: Windows API Sets

D21: Windows_7_Kernel_Changes: api-ms-win-core DLLs

D22: DOUBLEPULSAR Kernel DLL Injection Technique

D23: DOUBLEPULSAR: Generic Reflective DLL Loader

D24: MalwareFox AntiMalware 2.74.0.150 - LPE

D25：DLL Injection via SetDLLDirectory

D26: CodeProject: Create your Proxy DLLs automatically

D27: Proxy WS2_32.DLL to create your own firewall

D28: CodeProject: API hooking revealed

3.3 DLL注入商业方案

D30: Shellter Pro: DLL Injection Kit

D31: madCodeHook: DLL Injection Kit

3.4 开源HOOK引擎

H1: Microsoft Detours

H2: Detours NT

H3: minhook

H4: mhook

H5: EasyHook

H6: Deviare Hook Engine

3.5 Instrumentation Callback

I1: 利用KPROCESS结构的InstrumentationCallback域实现Hook

I2: Hooking-via-InstrumentationCallback

I3: Alex Ionescu: Hooking Nirvana

3.6 PPL (Protected Process Light)

P1: Injecting Code into Windows Protected Processes using COM - Part 1

P2: Injecting Code into Windows Protected Processes using COM - Part 2

P3: The Evolution of Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1

P4: The Evolution of Protected Processes Part 2: Exploit/Jailbreak Mitigations, Unkillable Processes and Protected Services

P5: Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers)

P6: Protected Processes Light killer

P7: Why Protected Processes Are A Bad Idea

P8: Micorosft: Protecting Anti-Malware Services

P9: Microsoft: Early launch antimalware

P10: Microsoft Virus Initiative

P11: Early Launch Anti-Malware Driver

3.7 WSL (Windows Subsystem for Linux)

W1: The Linux kernel hidden inside Windows 10

W2: Fun with the Windows Subsystem for Linux (WSL/LXSS)

W3: Hunting for Windows Subsystem for Linux

W4: Exploring Windows Subsystem for Linux

W5: Windows 10 and the Anti-malware Ecosystem

W6: Pico Process Overview

W7: WSL System Calls

--- END ---

Pages:  1 2 3 4 5 6 7 ... 46 47