C# EasyHook 实战：进程内 Hook 的注入、回调与避坑指南

简介：这份资源是面向C#开发者与调试爱好者的EasyHook远程钩子实战示例包，聚焦运行时函数拦截与跨进程注入这一进阶主题，适合已具备C#基础、希望掌握进程监控与行为修改技术的中级开发者参考。压缩包共91个文件、约854KB，以17个cs源码、15个dll依赖库、6个exe可执行程序及若干config、pdb、resx等配置与资源文件为主，并附sln解决方案与snk签名密钥，便于直接打开工程对照调试。资源已有917人学习下载，包含本地钩子创建、委托回调、ThreadACL设置及dll数字签名等关键环节的完整示例，读者可据此理解钩子注入流程、排查签名导致的注入失败问题，并在此基础上改造出符合自身需求的拦截逻辑。

1. 从一次“改不动”的调试说起：C# EasyHook 使用 Demo 能解决什么

接手一个老工控上位机时，最让人头疼的不是业务逻辑，而是某个第三方 DLL 里写死的一段校验——日志打不出来，参数改不了，出了问题只能靠猜。想动它，源码没有；想绕开它，调用链又埋得太深。这种时候，进程内 Hook 就是那把手术刀，而 C# EasyHook 使用 Demo 正是把“怎么下刀”这件事讲明白的一份可运行样例。它面向的是需要在 .NET 进程里拦截、观察甚至改写目标函数行为的开发者：可能是做协议分析、做兼容层、做行为监控，也可能只是想在别人的黑匣子里装一盏灯。这份 Demo 的价值不在于教你 Hook 的原理，而在于把注入、托管回调、原始函数转发这条链路用最小可跑的代码串起来，让你照着改就能落到自己的目标进程上。

2. 架构与运行链路：注入器、托管回调与原始函数转发

EasyHook 的核心模型并不复杂，但第一次接触时容易被“谁在谁的进程里跑”绕晕。它本质上是把一段托管代码注入到目标进程，在目标进程内建立一个 Hook 通道，当被拦截的函数被调用时，控制权先交给你的托管回调，回调里可以选择放行、修改参数、修改返回值，或者调用原始函数。理解这条链路，后面看代码才不会迷路。

2.1 三个角色：宿主进程、注入器、目标进程

整个 Demo 里其实有三个角色。宿主进程是你启动的那个控制台或 WinForms 程序，负责加载注入逻辑；注入器是 EasyHook 提供的RemoteHooking相关 API，负责把托管程序集送进目标进程；目标进程是被 Hook 的那个进程，可能是你自己写的一个测试程序，也可能是任意一个正在运行的 .NET 或原生进程。

常见做法是：宿主进程先枚举或按 PID 找到目标进程，然后调用注入接口，把包含 Hook 逻辑的托管 DLL 路径和通道名传进去。目标进程被注入后，会在内部加载这段托管代码，执行你写的Run或OnInject入口，在那里完成实际的 Hook 安装。这个“两段式”结构是理解 EasyHook 的关键——你的 Hook 代码不是跑在宿主里，而是跑在目标进程里。

// 宿主侧：按进程名找到目标并注入 var target = Process.GetProcessesByName("TargetApp").FirstOrDefault(); if (target == null) { Console.WriteLine("目标进程未启动"); return; } // 通道名用于宿主与目标进程内的 Hook 逻辑通信 string channelName = "hook_channel_" + Guid.NewGuid().ToString("N"); RemoteHooking.Inject( target.Id, // 目标进程 PID InjectionOptions.Default, // 注入选项，默认即可 typeof(HookEntry).Assembly.Location, // 注入的托管程序集 typeof(HookEntry).Assembly.Location, // 32/64 位可分别指定 channelName // 传给目标进程内入口的参数 );

这段代码里，Inject的第一个参数是目标 PID，第二个是注入选项，后面两个分别是 32 位和 64 位场景下要加载的程序集路径，最后一个参数会原样传到目标进程内的入口函数。参数说明看起来简单，但实际踩坑最多的就是程序集路径和位数匹配——路径写错、位数不匹配，注入会直接失败，而且错误信息往往不够直观。

2.2 目标进程内的入口：Hook 安装发生在哪里

注入成功后，目标进程会加载你指定的程序集，并调用约定的入口。EasyHook 的托管注入通常要求入口类实现特定接口，入口方法里拿到通道名，然后创建LocalHook实例。LocalHook是 EasyHook 里最常用的 Hook 类型，它针对当前进程内的某个函数地址建立拦截。

// 目标进程内：注入后执行的入口 public void Run(RemoteHooking.IContext context, string channelName) { // 通过通道与宿主建立通信，便于回传日志 _channel = RemoteHooking.IpcCreateServer<HookChannel>( ref channelName, WellKnownObjectMode.SingleCall); // 定位目标函数：这里以某个托管方法为例 var targetMethod = typeof(TargetClass).GetMethod("DoWork"); // 创建 LocalHook，回调指向我们的处理函数 _hook = LocalHook.Create( targetMethod.MethodHandle.GetFunctionPointer(), new DoWorkDelegate(DoWorkHandler), null); // 激活 Hook，只拦截当前线程之外的所有调用 _hook.ThreadACL.SetExclusiveACL(new[] { 0 }); // 通知宿主 Hook 已就绪 _channel.OnReady(); }

这里有几个关键点。LocalHook.Create的第一个参数是目标函数的地址，托管方法用MethodHandle.GetFunctionPointer()拿，原生函数则要用模块基址加偏移。第二个参数是委托，签名必须和目标函数一致，否则运行时会出问题。第三个参数是回调上下文，一般传null即可。SetExclusiveACL用来控制哪些线程不被拦截，传0表示当前线程放行，避免自己的 Hook 逻辑递归触发。

2.3 回调里的三岔路：放行、改写、调用原始函数

Hook 回调是整个 Demo 里最值得细看的部分。它决定了拦截之后到底做什么。EasyHook 的约定是：回调里如果要调用原始函数，必须通过HookRuntimeInfo拿到原始委托，否则直接调用目标方法会再次进入 Hook，形成递归。

// Hook 回调：拦截目标方法后的处理逻辑 private int DoWorkHandler(IntPtr thisPtr, int input) { try { // 记录入参，回传给宿主 _channel.OnLog($"DoWork 被调用，input={input}"); // 修改入参：把小于 0 的值纠正为 0 if (input < 0) { input = 0; } // 调用原始函数，拿到真实返回值 var original = Marshal.GetDelegateForFunctionPointer<DoWorkDelegate>( _hook.OriginalDelegate); int result = original(thisPtr, input); // 修改返回值：在原始结果上加 1，便于观察 _channel.OnLog($"原始返回 {result}，改写为 {result + 1}"); return result + 1; } catch (Exception ex) { _channel.OnLog("Hook 回调异常：" + ex.Message); return -1; } }

这段代码演示了回调里的三种典型操作：记录、改参数、改返回值。_hook.OriginalDelegate是 EasyHook 提供的原始函数指针，必须通过它来调用原逻辑。异常处理也不能省——Hook 回调里抛出的异常如果没被捕获，可能导致目标进程行为异常，排查起来非常痛苦。实际项目里，我一般会把回调体包在 try/catch 里，异常只记录不外抛，保证目标进程至少能继续跑。

3. 从零跑起来：环境准备、注入与验证的完整步骤

看懂链路之后，下一步是把它跑起来。这份 Demo 的结构不复杂，但涉及进程注入，对环境和位数比较敏感。下面按“准备—编译—注入—验证”的顺序走一遍，每一步都说明失败时该看什么。

3.1 环境与项目结构：先确认位数和框架版本

EasyHook 对 .NET 版本和平台位数有要求。常见做法是宿主和目标进程保持相同的位数，32 位对 32 位，64 位对 64 位，混用基本必失败。项目结构上，Demo 通常分成两个工程：一个是宿主控制台，负责注入；另一个是 Hook 逻辑的类库，被注入到目标进程。目标进程可以是一个简单的测试程序，也可以是你想观察的现成程序。

环境上，先确认目标框架版本，EasyHook 的托管注入对较新的 .NET 运行时支持有限，常见做法是宿主和 Hook 类库都编译为与目标进程匹配的框架版本。如果目标进程是原生程序，Hook 类库仍然可以是托管程序集，但入口和回调签名要按原生调用约定来写。

3.2 编译与注入：一条命令背后的参数含义

编译时最容易翻车的是平台目标。在项目属性里把平台目标显式设为 x86 或 x64，不要用 AnyCPU，否则注入时位数判断会出问题。编译完成后，宿主程序需要能定位到 Hook 类库的路径，常见做法是把两个工程的输出放到同一目录，或者用相对路径拼出程序集位置。

# 以命令行方式启动宿主，传入目标进程名 HostApp.exe --target TargetApp --assembly .\HookLib.dll

这条命令只是示意，实际 Demo 里可能是硬编码或通过配置文件读取。参数含义很直接：--target指定目标进程名，--assembly指定要注入的托管程序集路径。失败时先看宿主输出的错误码，再确认目标进程是否真的在运行、位数是否匹配、程序集路径是否存在。注入失败的错误信息有时只给一个 HRESULT，这时候对照 EasyHook 的文档查一下，通常能定位到是权限、位数还是路径问题。

3.3 验证 Hook 是否生效：日志、断点和返回值三路对照

注入成功不等于 Hook 生效。验证时我一般三路对照：宿主侧日志有没有收到回调记录、目标进程行为有没有变化、回调里的返回值改写有没有体现。最直接的办法是在目标方法里放一个明显的输入输出，比如传入负数看是否被纠正为 0，返回结果是否加了 1。

// 目标进程里的测试方法，用于验证 Hook 是否生效 public static int DoWork(int input) { Console.WriteLine($"[Target] DoWork 收到 {input}"); return input * 2; }

如果 Hook 生效，目标进程控制台里仍然会打印原始输入，但返回值会变成input * 2 + 1，同时宿主侧能看到回调日志。如果日志有但行为没变，检查是不是调用了原始函数后没有使用改写后的返回值；如果行为变了但日志没有，检查通道是否建立成功。断点方面，可以在 Hook 回调里下断点，但要注意调试器附加的是宿主还是目标进程，附加错了会看不到回调。

提示：第一次跑建议先用自己写的测试目标进程，确认链路通了再换成真实目标。直接对生产进程下手，出问题时很难判断是 Hook 逻辑的问题还是目标本身的问题。

4. 核心代码拆解：通道通信、委托签名与原始函数调用

跑通之后，真正决定这份 Demo 能不能改成自己项目的是几个核心细节：宿主和 Hook 逻辑之间怎么通信、委托签名怎么对齐、原始函数怎么安全调用。这三块拆明白了，改起来才有底。

4.1 通道通信：把目标进程里的日志送回宿主

Hook 逻辑跑在目标进程里，日志不能直接写宿主的控制台，需要通过 EasyHook 的 IPC 通道回传。Demo 里通常定义一个通道接口，宿主侧创建客户端，目标进程侧创建服务端，两边通过通道名配对。

// 通道接口：定义宿主与 Hook 逻辑之间的通信契约 public interface IHookChannel { void OnLog(string message); void OnReady(); } // 宿主侧：创建通道客户端并订阅回调 var channel = RemoteHooking.IpcCreateClient<IHookChannel>(channelName); channel.OnLog += msg => Console.WriteLine("[Hook] " + msg);

通道接口的方法不宜过多，回传日志和状态就够了。参数说明上，通道名必须在注入时传给目标进程，两边一致才能配对。常见坑是通道名带特殊字符或重复使用，导致连接失败；我一般用 GUID 生成，确保唯一。通道回调里不要做耗时操作，否则会拖慢目标进程的调用链。

4.2 委托签名：和目标函数一字不差

EasyHook 的 Hook 回调委托签名必须和目标函数完全一致，包括参数类型、顺序、返回值，甚至调用约定。托管方法相对好办，用反射拿到方法信息后照着写；原生函数则要按 Win32 的调用约定来，常见的是StdCall或Cdecl。

// 目标函数签名：两个 int 参数，返回 int [UnmanagedFunctionPointer(CallingConvention.StdCall)] public delegate int DoWorkDelegate(IntPtr thisPtr, int input);

这里的thisPtr是实例方法的隐式 this 指针，静态方法则没有这个参数。签名写错时，表现往往是目标进程直接崩溃或返回值错乱，而不是给出明确的类型错误。血泪经验是：先用一个最简单的函数验证签名，再逐步换成复杂签名，别一上来就 Hook 带结构体参数的方法。

4.3 原始函数调用：为什么不能直接调目标方法

回调里直接调用目标方法会再次触发 Hook，形成递归，轻则栈溢出，重则目标进程卡死。EasyHook 通过OriginalDelegate暴露原始函数指针，必须通过它来调用原逻辑。这个指针在 Hook 创建后可用，调用方式和普通委托一致。

// 通过 OriginalDelegate 调用原始函数，避免递归 var original = Marshal.GetDelegateForFunctionPointer<DoWorkDelegate>( _hook.OriginalDelegate); int result = original(thisPtr, input);

参数说明：OriginalDelegate是IntPtr，需要用Marshal.GetDelegateForFunctionPointer转成对应委托。转换时的泛型类型必须和 Hook 时用的委托一致，否则调用会出错。如果原始函数本身会抛异常，回调里要捕获，避免异常穿透到目标进程的调用栈。

5. 避坑与排查：注入失败、递归崩溃与位数不匹配

这份 Demo 跑通不难，难的是换到真实目标上之后各种莫名其妙的问题。下面几条是我在实际项目里反复遇到的，按“现象—原因—解决”记下来，省得每次重新查。

5.1 注入返回错误码，目标进程毫无反应

现象：宿主调用注入接口后返回一个错误码，目标进程没有任何变化，也没有日志。原因通常是权限不足、目标进程位数不匹配，或者注入的程序集路径不存在。解决：先确认宿主以管理员权限运行，再核对目标进程位数和 Hook 类库的平台目标是否一致，最后检查程序集路径是否是绝对路径且文件存在。错误码可以对照 EasyHook 的枚举值查，常见的是权限和位数两类。

5.2 Hook 装上后目标进程直接崩溃

现象：注入成功，但目标进程在第一次调用被 Hook 的函数时崩溃。原因多半是委托签名不匹配，或者回调里调用了目标方法导致递归。解决：先检查委托的参数类型、顺序、调用约定是否和目标函数完全一致；再确认回调里调用原始函数用的是OriginalDelegate而不是直接调目标方法。如果签名里有结构体，还要注意结构体布局和字符集。

5.3 日志有回调记录，但目标行为没变化

现象：宿主侧能看到回调日志，说明 Hook 确实触发了，但目标进程的实际行为没有改变。原因通常是回调里调用了原始函数后没有使用改写后的返回值，或者改的是参数副本而不是实际参数。解决：确认回调的返回值被正确返回，参数修改在调用原始函数之前完成。对于引用类型参数，修改字段和重新赋值是两回事，要看清目标函数实际读的是哪个。

5.4 调试时断点不命中，或者命中在错误的进程

现象：在 Hook 回调里下断点，调试器没有任何反应，或者断在了一个不相关的进程里。原因：调试器附加的是宿主进程，而 Hook 回调跑在目标进程里。解决：先启动宿主完成注入，再用调试器附加到目标进程；或者把 Hook 类库的调试符号一起部署到目标进程能加载的位置。附加错进程是新手最常见的翻车点，确认 PID 再附加。

5.5 多次注入后通道冲突或资源泄漏

现象：反复注入同一个目标进程，出现通道连接失败，或者目标进程句柄数持续上涨。原因：通道名重复、Hook 没有正确释放、IPC 服务端没有关闭。解决：每次注入用唯一通道名，Hook 用完调用Dispose，通道服务端在退出前关闭。长期运行的目标进程尤其要注意资源释放，否则跑一段时间就会出问题。

6. 二次开发改造：把 Demo 变成可复用的 Hook 框架

Demo 跑通只是起点，真正要用起来，得把它改造成能配置、能扩展、能验证的小框架。我一般从三个方向下手：把目标函数和回调配置化、把通道通信抽象成通用日志通道、把验证流程固化成可重复的测试。

6.1 配置化：目标函数、回调与参数不再硬编码

Demo 里目标函数和回调往往是写死的，换一个函数就要改代码。改造思路是把“目标函数定位”和“回调处理”抽成配置项：用配置文件描述目标模块、函数名或偏移、回调类型，运行时根据配置动态创建 Hook。这样同一套宿主可以服务多个目标，不用每次重新编译。

// 配置化 Hook 描述：目标与回调分离 public class HookSpec { public string ModuleName { get; set; } // 目标模块名 public string FunctionName { get; set; } // 函数名或导出名 public string HandlerType { get; set; } // 回调处理类型 public bool ModifyArgs { get; set; } // 是否改写参数 }

参数说明：ModuleName用于定位模块基址，FunctionName用于取导出地址或方法信息，HandlerType决定用哪个回调实现，ModifyArgs控制是否改写参数。改造后，新增一个 Hook 点只需要加一条配置和对应的处理类，不用动注入主流程。

6.2 通用日志通道：把回传数据标准化

通道接口如果每个项目都重新定义，复用性很差。我一般把它标准化成“日志 + 事件 + 指标”三类方法，日志走文本，事件走结构化对象，指标走数值。这样宿主侧可以统一做过滤、落盘和展示，Hook 逻辑侧只负责调用，不关心宿主怎么处理。

改造时注意通道方法不要设计得太重，目标进程里的调用链对延迟敏感，回传数据尽量轻量，复杂处理放到宿主侧做。

6.3 验证方法：用测试目标进程固化回归

每次改完 Hook 逻辑，最怕的是“这次改好了，下次又坏了”。我的习惯是保留一个专门的测试目标进程，里面放几个签名各异的测试方法，覆盖静态方法、实例方法、带结构体参数的方法。每次改造后跑一遍，看日志、返回值和目标行为是否都符合预期。这个测试进程不参与生产，只用于回归，成本很低但能挡住大部分低级错误。

// 测试目标：覆盖多种签名，便于回归验证 public static int Add(int a, int b) => a + b; public int Multiply(int a, int b) => a * b; public static string Concat(string a, string b) => a + b;

验证时重点看三件事：Hook 是否触发、原始逻辑是否仍被执行、改写是否按预期生效。三件事都对了，再换真实目标。从那以后我每次改 Hook 逻辑，都强制先在这个测试目标上走一遍，确认没有递归和签名问题，再碰真实进程。希望这份拆解能帮到你，少走几次注入失败的弯路。

本文还有配套的精品资源，点击获取