深入Windows APC

最新推荐文章于 2024-02-28 11:30:00 发布
最新推荐文章于 2024-02-28 11:30:00 发布
阅读量653 收藏 1
点赞数
分类专栏： 计算机 文章标签： windows 计算机
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/pythonxxoo/article/details/122787793
版权
本文深入探讨Windows操作系统中的异步过程调用（APC）机制，涵盖了APC的内部实现、类型、内核与用户模式的使用细节，包括线程挂靠、APC的内存管理问题、内核与用户模式APC的执行特点。文章通过案例分析，揭示了早期注入Kernel32.dll的陷阱，并讨论了APC在不同Windows版本中的实现差异，对于理解和避免APC使用中的潜在问题提供了宝贵的洞见。
摘要由CSDN通过智能技术生成

Python微信订餐小程序课程视频

https://edu.csdn.net/course/detail/36074

Python实战量化交易理财系统

https://edu.csdn.net/course/detail/35475
  本篇原文为 寂静的羽夏(wingsummer) 中文翻译，非机翻，著作权归原作者 Rbmm 和 Dennis A. Babkin 所有。
  由于原文十分冗长，也十分干货，采用机翻辅助，人工阅读比对修改的方式进行，如有翻译不得当的地方，欢迎批评指正。翻译不易，如有闲钱，欢迎支持。注意在转载文章时注意保留原文的作者链接，我（译者）的相关信息。话不多说，正文开始：

本篇文章包含一些没有被原厂家（指微软）进行文档化的功能和特色。在阅读本篇文章的相关内容和建议之后，你应该为自己的所作所为负责。展示在本文的方法依赖于内部实现并且可能以后不再有效。

介绍

在我们的第一篇关于错综复杂的用户APC的博文发布之后，我们决定从细节的深度拓展该主题，将会介绍有关异步过程调用（APC）在Windows操作系统的内部实现。
  那我们就开始吧，这里介绍没有什么特别的先后顺序。

目录

以下所有主题之间的联系并不是特别紧密，所以你或许想要一个可以更容易查阅的目录表：

APC 内部实现概要

为了在后面的文章——《伸入 NT 内核的异步过程调用内幕》，能够更好让大家更深入的理解内核 APC 的内部实现，我们不会重复原来已经讲过的了，而是多多陈述一些其他且鲜为人知的 APC 相关的细节。

为了更简洁的描述，在技术上说 APC 就是一堆在内存里存储的二进制字节，也就是所谓的 KAPC 结构体：

typedef struct \_KAPC {
  UCHAR Type;
  UCHAR SpareByte0;
  UCHAR Size;
  UCHAR SpareByte1;
  ULONG SpareLong0;
  _KTHREAD * Thread;
  _LIST_ENTRY ApcListEntry;
  void (* KernelRoutine)( _KAPC * , void (* * )( void * , void * , void * ), void * * , void * * , void * * );
  void (* RundownRoutine)( _KAPC * );
  void (* NormalRoutine)( void * , void * , void * );
  void * Reserved[0x3];
  void * NormalContext;
  void * SystemArgument1;
  void * SystemArgument2;
  CHAR ApcStateIndex;
  CHAR ApcMode;
  UCHAR Inserted;
}KAPC, *PKAPC;

上述结构体是在KAPC_STATE结构体里面的双向链表一部分：

typedef struct \_KAPC\_STATE {
  _LIST_ENTRY ApcListHead[0x2];
  _KPROCESS * Process;
  UCHAR InProgressFlags;
  UCHAR KernelApcInProgress : 01; // 0x01;
  UCHAR SpecialApcInProgress : 01; // 0x02;
  UCHAR KernelApcPending;
  UCHAR UserApcPendingAll;
  UCHAR SpecialUserApcPending : 01; // 0x01;
  UCHAR UserApcPending : 01; // 0x02;
}KAPC_STATE, *PKAPC_STATE;

并且KAPC_STATE自身也是线程对象的一部分，存储在内核里的KTHREAD结构体中：

🔒 点击查看 KTHREAD 🔒

typedef struct \_KTHREAD {
  _DISPATCHER_HEADER Header;
  void * SListFaultAddress;
  ULONGLONG QuantumTarget;
  void * InitialStack;
  void * volatile StackLimit;
  void * StackBase;
  ULONGLONG ThreadLock;
  ULONGLONG volatile CycleTime;
  ULONG CurrentRunTime;
  ULONG ExpectedRunTime;
  void * KernelStack;
  _XSAVE_FORMAT * StateSaveArea;
  _KSCHEDULING_GROUP * volatile SchedulingGroup;
  _KWAIT_STATUS_REGISTER WaitRegister;
  UCHAR volatile Running;
  UCHAR Alerted[0x2];
  ULONG AutoBoostActive : 01; // 0x00000001;
  ULONG ReadyTransition : 01; // 0x00000002;
  ULONG WaitNext : 01; // 0x00000004;
  ULONG SystemAffinityActive : 01; // 0x00000008;
  ULONG Alertable : 01; // 0x00000010;
  ULONG UserStackWalkActive : 01; // 0x00000020;
  ULONG ApcInterruptRequest : 01; // 0x00000040;
  ULONG QuantumEndMigrate : 01; // 0x00000080;
  ULONG UmsDirectedSwitchEnable : 01; // 0x00000100;
  ULONG TimerActive : 01; // 0x00000200;
  ULONG SystemThread : 01; // 0x00000400;
  ULONG ProcessDetachActive : 01; // 0x00000800;
  ULONG CalloutActive : 01; // 0x00001000;
  ULONG ScbReadyQueue : 01; // 0x00002000;
  ULONG ApcQueueable : 01; // 0x00004000;
  ULONG ReservedStackInUse : 01; // 0x00008000;
  ULONG UmsPerformingSyscall : 01; // 0x00010000;
  ULONG TimerSuspended : 01; // 0x00020000;
  ULONG SuspendedWaitMode : 01; // 0x00040000;
  ULONG SuspendSchedulerApcWait : 01; // 0x00080000;
  ULONG CetUserShadowStack : 01; // 0x00100000;
  ULONG BypassProcessFreeze : 01; // 0x00200000;
  ULONG Reserved : 10; // 0xffc00000;
  LONG MiscFlags;
  ULONG BamQosLevel : 02; // 0x00000003;
  ULONG AutoAlignment : 01; // 0x00000004;
  ULONG DisableBoost : 01; // 0x00000008;
  ULONG AlertedByThreadId : 01; // 0x00000010;
  ULONG QuantumDonation : 01; // 0x00000020;
  ULONG EnableStackSwap : 01; // 0x00000040;
  ULONG GuiThread : 01; // 0x00000080;
  ULONG DisableQuantum : 01; // 0x00000100;
  ULONG ChargeOnlySchedulingGroup : 01; // 0x00000200;
  ULONG DeferPreemption : 01; // 0x00000400;
  ULONG QueueDeferPreemption : 01; // 0x00000800;
  ULONG ForceDeferSchedule : 01; // 0x00001000;
  ULONG SharedReadyQueueAffinity : 01; // 0x00002000;
  ULONG FreezeCount : 01; // 0x00004000;
  ULONG TerminationApcRequest : 01; // 0x00008000;
  ULONG AutoBoostEntriesExhausted : 01; // 0x00010000;
  ULONG KernelStackResident : 01; // 0x00020000;
  ULONG TerminateRequestReason : 02; // 0x000c0000;
  ULONG ProcessStackCountDecremented : 01; // 0x00100000;
  ULONG RestrictedGuiThread : 01; // 0x00200000;
  ULONG VpBackingThread : 01; // 0x00400000;
  ULONG ThreadFlagsSpare : 01; // 0x00800000;
  ULONG EtwStackTraceApcInserted : 08; // 0xff000000;
  LONG volatile ThreadFlags;
  UCHAR volatile Tag;
  UCHAR SystemHeteroCpuPolicy;
  UCHAR UserHeteroCpuPolicy : 07; // 0x7f;
  UCHAR ExplicitSystemHeteroCpuPolicy : 01; // 0x80;
  UCHAR RunningNonRetpolineCode : 01; // 0x01;
  UCHAR SpecCtrlSpare : 07; // 0xfe;
  UCHAR SpecCtrl;
  ULONG SystemCallNumber;
  ULONG ReadyTime;
  void * FirstArgument;
  _KTRAP_FRAME * TrapFrame;
  _KAPC_STATE ApcState;
  UCHAR ApcStateFill[0x2b];
  CHAR Priority;
  ULONG UserIdealProcessor;
  LONGLONG volatile WaitStatus;
  _KWAIT_BLOCK * WaitBlockList;
  _LIST_ENTRY WaitListEntry;
  _SINGLE_LIST_ENTRY SwapListEntry;
  _DISPATCHER_HEADER * volatile Queue;
  void * Teb;
  ULONGLONG RelativeTimerBias;
  _KTIMER Timer;
  _KWAIT_BLOCK WaitBlock[0x4];
  UCHAR WaitBlockFill4[0x14];
  ULONG ContextSwitches;
  UCHAR WaitBlockFill5[0x44];
  UCHAR volatile State;
  CHAR Spare13;
  UCHAR WaitIrql;
  CHAR WaitMode;
  UCHAR WaitBlockFill6[0x74];
  ULONG WaitTime;
  UCHAR WaitBlockFill7[0xa4];
  SHORT KernelApcDisable;
  SHORT SpecialApcDisable;
  ULONG CombinedApcDisable;
  UCHAR WaitBlockFill8[0x28];
  _KTHREAD_COUNTERS * ThreadCounters;
  UCHAR WaitBlockFill9[0x58];
  _XSTATE_SAVE * XStateSave;
  UCHAR WaitBlockFill10[0x88];
  void * volatile Win32Thread;
  UCHAR WaitBlockFill11[0xb0];
  _UMS_CONTROL_BLOCK * Ucb;
  _KUMS_CONTEXT_HEADER * volatile Uch;
  void * Spare21;
  _LIST_ENTRY QueueListEntry;
  ULONG volatile NextProcessor;
  ULONG NextProcessorNumber : 31; // 0x7fffffff;
  ULONG SharedReadyQueue : 01; // 0x80000000;
  LONG QueuePriority;
  _KPROCESS * Process;
  _GROUP_AFFINITY UserAffinity;
  UCHAR UserAffinityFill[0xa];
  CHAR PreviousMode;
  CHAR BasePriority;
  CHAR PriorityDecrement;
  UCHAR ForegroundBoost : 04; // 0x0f;
  UCHAR UnusualBoost : 04; // 0xf0;
  UCHAR Preempted;
  UCHAR AdjustReason;
  CHAR AdjustIncrement;
  ULONGLONG AffinityVersion;
  _GROUP_AFFINITY Affinity;
  UCHAR AffinityFill[0xa];
  UCHAR ApcStateIndex;
  UCHAR WaitBlockCount;
  ULONG IdealProcessor;
  ULONGLONG NpxState;
  _KAPC_STATE SavedApcState;
  UCHAR SavedApcStateFill[0x2b];
  UCHAR WaitReason;
  CHAR SuspendCount;
  CHAR Saturation;
  USHORT SListFaultCount;
  _KAPC SchedulerApc;
  UCHAR SchedulerApcFill0[0x1];
  UCHAR ResourceIndex;
  UCHAR SchedulerApcFill1[0x3];
  UCHAR QuantumReset;
  UCHAR SchedulerApcFill2[0x4];
  ULONG KernelTime;
  UCHAR SchedulerApcFill3[0x40];
  _KPRCB * volatile WaitPrcb;
  UCHAR SchedulerApcFill4[0x48];
  void * LegoData;
  UCHAR SchedulerApcFill5[0x53];
  UCHAR CallbackNestingLevel;
  ULONG UserTime;
  _KEVENT SuspendEvent;
  _LIST_ENTRY ThreadListEntry;
  _LIST_ENTRY MutantListHead;
  UCHAR AbEntrySummary;
  UCHAR AbWaitEntryCount;
  UCHAR AbAllocationRegionCount;
  CHAR SystemPriority;
  ULONG SecureThreadCookie;
  _KLOCK_ENTRY LockEntries[0x6];
  _SINGLE_LIST_ENTRY PropagateBoostsEntry;
  _SINGLE_LIST_ENTRY IoSelfBoostsEntry;
  UCHAR PriorityFloorCounts[0x10];
  ULONG PriorityFloorSummary;
  LONG volatile AbCompletedIoBoostCount;
  LONG volatile AbCompletedIoQoSBoostCount;
  SHORT volatile KeReferenceCount;
  UCHAR AbOrphanedEntrySummary;
  UCHAR AbOwnedEntryCount;
  ULONG ForegroundLossTime;
  _LIST_ENTRY GlobalForegroundListEntry;
  _SINGLE_LIST_ENTRY ForegroundDpcStackListEntry;
  ULONGLONG InGlobalForegroundList;
  LONGLONG ReadOperationCount;
  LONGLONG WriteOperationCount;
  LONGLONG OtherOperationCount;
  LONGLONG ReadTransferCount;
  LONGLONG WriteTransferCount;
  LONGLONG OtherTransferCount;
  _KSCB * QueuedScb;
  ULONG volatile ThreadTimerDelay;
  LONG volatile ThreadFlags2;
  ULONG PpmPolicy : 02; // 0x00000003;
  ULONG ThreadFlags2Reserved : 30; // 0xfffffffc;
  ULONGLONG TracingPrivate[0x1];
  void * SchedulerAssist;
  void * volatile AbWaitObject;
}KTHREAD, *PKTHREAD;

将线程挂靠到另一个进程

值得注意的一点就是任何一个线程都可以通过调用KeStackAttachProcess（该函数会接收KAPC_STATE对象，并查看它的ApcState参数）临时地挂靠到另一个进程上，也可以通过调用KeUnstackDetachProcess函数脱离进程。但是这会有会导致问题一点点的可能性，所以开发者需要把注意力放到上面。
  因此，有一个十分重要的事情去理解，我们需要通过使用一个未被文档化但是导出的KeInitializeApc调用初始化一个APC对象：

VOID KeInitializeApc(
  IN PRKAPC Apc,          //pointer to KAPC
  IN PKTHREAD Thread,
  IN KAPC_ENVIRONMENT Environment,
  IN PKKERNEL_ROUTINE KernelRoutine,
  IN PKRUNDOWN_ROUTINE RundownRoutine OPTIONAL,
  IN PKNORMAL_ROUTINE NormalRoutine OPTIONAL,
  IN KPROCESSOR_MODE ApcMode,
  IN PVOID NormalContext
);

我们使用该函数需要提供KAPC_ENVIRONMENT类型的参数，它的枚举如下：

typedef enum \_KAPC\_ENVIRONMENT {
  OriginalApcEnvironment,
  AttachedApcEnvironment,
  CurrentApcEnvironment
} KAPC_ENVIRONMENT;

这个参数指定了APC环境，换句话说，当我们插入一个APC，我们会告诉系统是应该为当前线程激活它，还是应该在线程挂靠到另一个进程之前为保存的状态（KTHREAD::SavedApcState）激活它。该参数将会在后面保存到KAPC::ApcStateIndex成员当中。
  为了更好的说明这个概念，让我们回顾如下的KiInsertQueueApc代码：

// KiInsertQueueApc() excerpt:

Thread = Apc->Thread;
PKAPC_STATE ApcState;

if (Apc->ApcStateIndex == 0 && Thread->ApcStateIndex != 0)
{
  ApcState = &Thread->SavedApcState;
}
else
{
  Apc->ApcStateIndex = Thread->ApcStateIndex;
  ApcState = &Thread->ApcState;
}

所以本质上KAPC::ApcStateIndex是一个布尔值：

  • 非0：指示APC插入到当前线程中，话句话说，APC应该执行在当前进程的上下文环境中，也就是线程当前运行的环境。
  • 0：指示当前APC应该仅仅在源进程的环境中运行，或者在线程在进程挂靠之前的进程环境中。

在KeStackAttachProcess函数中，有如下逻辑：

// KeStackAttachProcess() excerpt:

if (Thread->ApcStateIndex != 0)
{
  KiAttachProcess(Thread, Process, &LockHandle, ApcState);
}
else
{
  KiAttachProcess(Thread, Process, &LockHandle, &Thread->SavedApcState);
  ApcState->Process = NULL;
}

也就是意味着，当我们第一次挂靠到另一个进程，打个比方：如果它的KAPC::ApcStateIndex值为0，当前的KTHREAD::ApcState存储在KTHREAD::SavedApcState当中，并且以前的ApcState不会被使用，除非设置KAPC_STATE::Process为0表示这个状态存储在KTHREAD::SavedApcState。
  但是如果我们递归式挂靠，或当一个线程已经挂靠到另一个进程时我们已经调用了KeStackAttachProcess，在那种情况下APC的状态被保存在ApcState对象中，被作为参数传递到函数当中。
  这种逻辑处理是为了让系统始终可以访问线程的原始APC状态。这可以用于将APC插入原始线程，或通过调用KeUnstackDetachProcess将线程脱离原进程。

APC 的类型

APC有两个基础类型：内核APC和用户APC。内核APC给予了开发者更多便利来处理APC排列和处理（我们在本篇博文已讨论过用户APC）。内核APC不向用户层开发者们开放能够直接访问的权限。
  KAPC_STATE::ApcListHead里面包含了两个链表用来存放内核APC和用户APC。这两个链表分别有APC排队等待线程处理：

typedef enum \_MODE {
  KernelMode = 0x0,
  UserMode = 0x1,
  MaximumMode = 0x2
}MODE;

内核使用这些列表来维护每种类型的APC的状态。当APC排队或调用KeInsertQueueApc处理时，KAPC::ApcMode用作KAPC_STATE::ApcListHead的索引：

NTSTATUS NtQueueApcThread(
  IN HANDLE Thread,
  IN PKNORMAL_ROUTINE NormalRoutine,
  IN PVOID NormalContext,
  IN PVOID SystemArgument1,
  IN PVOID SystemArgument2
);

内核 APC 的使用内存的易错点

许多内核开发新手犯了一个错误：为内核模式APC指定了错误的内存类型。认识到这一点很重要，以防止各种意外的蓝屏死机（BSOD）。
  这是一定要记住经验，KAPC结构体只能使用从非分页内存分配的内存（或者从类似NonPagedPool*类型分配）。即使在PASSIVE_LEVEL的IRQL初始化并插入APC，这也是没问题的。
  为什么要有这样的内存类型限制呢？其他一些APC也可以插入到运行在更高调度级别IRQL的同一线程中。在插入双链接APC列表期间，系统将尝试访问列表中已经存在的其他KAPC结构。因此，如果其中任何一个使用的是从分页内存分配的内存，你将会从DISPATCH_LEVEL间接访问分页内存，这也是一种会导致蓝屏保护原因。
  比较棘手的是，我在描述如上的情况非常少见，在开发和测试阶段可能不会出现。这将很难在生产代码中进行诊断，正如我在上面解释的，可能过一段时间之后，会在你无法控制的环境中发生蓝屏。

中断和阻塞内核 APC

关于内核模式APC，需要记住的重要一点是，它通过中断实现，这意味着它可以发生在代码中的任意两个CPU指令之间。
  内核开发允许我们阻止APC的执行。只有在代码的某些特殊部分起作用：将IRQL提升到APC_LEVEL或更高级别或将写的代码放在KeEnterCriticalRegion和KeLeaveCriticalRegion的调用之间。（请注意，这些函数不会阻止所谓的特殊内核APC的执行，只有提高IRQL级别才能阻止这些APC的执行）。
  关于我在上面展示的IRQL条件限制，一个有趣的事实是，如果APC到达关键区域，它不会丢失，稍后将在以下任一函数中处理：KeLeaveGuardedRegion、 KeLeaveCriticalRegion、KeLowerIrql或者在临界区的结尾。

RundownRoutine 细节

如果我再次引用这篇博文：

简单点说，任何一种APC都可以定义一个有效的 RundownRoutine 。此例程必须驻留在内核内存中，并且仅在系统需要丢弃 APC 队列的内容时（例如线程退出时）调用。在这种情况下，既不执行 KernelRoutine ࿰

最低0.47元/天 解锁文章
pythonxxoo
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
Windows APC机制(一)
井底之蛙
06-23 1万+
      异步过程调用(APCs) 是NT异步处理体系结构中的一个基础部分，理解了它，对于了解NT怎样操作和执行几个核心的系统操作很有帮助。1) APCs允许用户程序和系统元件在一个进程的地址空间内某个线程的上下文中执行代码。2) I/O管理器使用APCs来完成一个线程发起的异步的I/O操作。例如：当一个设备驱动调用IoCompleteRequest来通知I/O管理器，它已经结束处理一个异步I/
Windows的APC机制.pdf
08-27
毛德操写的有关APC机制的资料，如果想写高效的windows程序，不妨参考一下。。
漫谈兼容内核之十二: Windows的APC机制（毛德操）
vbsourcecode的专栏
02-07 2345
前两篇漫谈中讲到，除ntdll.dll外，在启动一个新进程运行时，PE格式DLL映像的装入和动态连接是由ntdll.dll中的函数LdrInitializeThunk()作为APC函数执行而完成的。这就牵涉到了Windows的APC机制，APC是“异步过程调用(Asyncroneus Procedure Call)”的缩写。从大体上说，Windows的APC机制相当于Linux的Signal机制，
windows内核情景分析 --APC
maomao171314的专栏
04-04 2107
APC：异步过程调用。这是一种常见的技术。前面进程启动的初始过程就是：主线程在内核构造好运行环境后，从KiThreadStartup开始运行，然后调用PspUserThreadStartup，在该线程的apc队列中插入一个APC：LdrInitializeThunk,这样，当PspUserThreadStartup返回后，正式退回用户空间的总入口BaseProcessStartThunk前，会执行
Windows APC学习笔记（一）—— APC的本质&备用APC队列
qq_41988448的博客
01-12 2940
Windows APC机制学习笔记（一）—— APC的本质前言基础知识APCAPC队列APC结构总结分析 KiServiceExit 前言 一、学习自滴水编程达人中级班课程，官网：https://bcdaren.com 二、海东老师牛逼！ 基础知识 线程是不能被“杀掉”、“挂起”、“恢复”的，线程在执行的时候自己占据着CPU，别人怎么可能控制它呢？ 举个极端的例子：如果不调用API，屏蔽中断...
Apc.rar_APC_windows APC
09-23
通过阅读《Apc.pdf》文档，开发者将能深入理解APC的工作原理，掌握如何在Windows程序中有效地利用APC机制来提高程序的并发性和响应性。这不仅适用于系统程序员，也对任何希望优化Windows应用程序性能的开发人员具有...
深入探究Windows平台客户端安全问题-进程地址空间入侵和白加黑高阶利用1
08-08
深入探究 Windows 平台客户端安全问题 - 进程地址空间入侵和白加黑高阶利用 一、进程地址空间入侵概述 在 Windows 平台下，进程地址空间入侵是一种常见的安全问题。所谓进程地址空间入侵，就是使一个非目标进程所...
apc_inject.rar_APC_APC inject_inject
09-23
在深入理解APC注入时，需要熟悉Windows内核编程，包括线程上下文切换、APC的生命周期以及如何安全地处理内核对象。此外，了解系统安全机制，如DEP（Data Execution Prevention）和ASLR（Address Space Layout ...
易语言移植的APC注入源码
06-06
易语言移植的APC注入源码是一个涉及到Windows操作系统编程、进程通信和恶意代码技术的知识点。APC（Asynchronous Procedure Call）是Windows API提供的一种异步处理机制，常用于线程间的通信。在易语言中实现APC注入...
Windows APC机制(二)
it技术学习
01-28 633
上文中讲到投递User Mode APCs是很特殊的，道理很简单，因为User Mode APC是ring3下的回调函数，显然ring0中的KiDeliverAPC（）不能像Kernel Mode APC那样直接call，必须要先回到ring3环境下。当然不能像普通情况那样返回（否则就回到ring3系统调用的地方了），只有一个办法，那就是修改TrapFrame ，欺骗系统返回“APC回调函数”！K
Windows的APC机制
q87236316的专栏
01-17 441
   好文转之       前两篇漫谈中讲到，除ntdll.dll外，在启动一个新进程运行时，PE格式DLL映像的装入和动态连接是由ntdll.dll中的函数 LdrInitializeThunk()作为APC函数执行而完成的。这就牵涉到了Windows的APC机制，APC是“异步过程调用 (Asyncroneus Procedure Call)”的缩写。从大体上说，Windows的APC机制
Windows APC学习笔记（二）—— 挂入过程&执行过程
qq_41988448的博客
02-29 1300
Windows APC学习笔记（二）—— 挂入过程&执行过程前言基础知识挂入过程KeInitializeApcApcStateIndex 前言 一、学习自滴水编程达人中级班课程，官网：https://bcdaren.com 二、海东老师牛逼！ 基础知识 无论是正常状态还是挂靠状态，都有两个APC队列，一个内核队列，一个用户队列 每当要挂入一个APC函数时，不管是内核APC还是用户AP...
小Win，点一份APC（Apc机制详解）（一）
anhkgg的专栏
05-06 4131
翻开 翻开小Win的菜单，APC赫然在目... 做工讲究，味道不错，是小Win的热门菜，我们点一来尝尝！ 吃了可以做很多事情... APC注入APC注入APC注入... 细节来自于ReactOS源码分析。 如果对这个发神经的文风有任何不适，请谅解，因为我确实神经了 来一份APC ring3这么做的 点APC的正确姿势是使用QueueUs
Windows11_22H2下的APC机制分析
lkylky123789的博客
01-04 1122
APC机制分析
基于Windows APC写一个简单的多线程并发库
weixin_34067049的博客
05-17 88
Windows APC 首先我们要知道什么是APC。APC的全称是Asynchronous Procedure Call，异步过程调用。MSDN链接请猛击这里。用简短的话来总结就是： 每一个线程都有一个APC队列 APC分两种，分别是kernel-mode APC和user-mode APC 通过调用QueueUserAPC可以向user-mode APC队列中加入APC对象 每一个...
APC Injection of Windows 7 x86 in R0
weixin_30814319的博客
09-05 236
APC Injection of Windows 7 x86 in R0 Introduction When running in kernel mode, it may be necessary to inject code into a User-land process. We can use the Asynchronous Procedure Calls(APCs) to ac...
windows 内核原理与实现读书笔记之APC（异步过程调用）
maomao171314的专栏
11-24 1273
APC（异步过程调用） APC_LEVEL ,APC(异步过程调用，Asynchronous Procedure Call)的软件中断而保留的IRQL。 DPC是系统全局的，每个处理器都有DPC链表；APC是针对线程的，每个线程都有自己特有的APC链表。APC线程优先于普通的线程代码。 APC 对象定义如下： typedef struct _KAPC { CSHORT Type; CSHORT Size; ULONG Sp...
Windows 动态注入（远程线程、消息钩子、APC）
最新发布
wangluoanquan111的博客
02-28 1190
网络安全行业产业以来，随即新增加了几十个网络安全行业岗位︰网络安全专家、网络安全分析师、安全咨询师、网络安全工程师、安全架构师、安全运维工程师、渗透工程师、信息安全管理员、数据安全工程师、网络安全运营工程师、网络安全应急响应工程师、数据鉴定师、网络安全产品经理、网络安全服务工程师、网络安全培训师、网络安全审计员、威胁情报分析工程师、灾难恢复专业人员、实战攻防专业人员…一个比较关键的问题是创建的远程线程是在目标进程中执行，无法调用本地函数，因此要利用系统API实现加载dll文件的操作。
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值