一旦将 .NET 程序集加载到内存中，是否可以使用托管指针来更改它？
鉴于 .NET 元数据表格式包含显示程序集可能位于内存中位置的实际 RVA，是否可以使用 CLR 上的托管指针来访问内存中存储程序集的位置，以便可以将程序集存储在内存中。加载到内存后是否进行了修改？
Given that the .NET metadata table format contains actual RVAs that show where an assembly might be located in memory, would it be possible to use managed pointers on the CLR to access the places in memory where the assembly is being stored so that it can be modified after it has been loaded into memory?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从技术上讲，是的，这是可能的（假设 FullTrust + 不安全代码）——指针就是指针，托管代码一旦经过 JIT 处理，实际上就是非托管代码。也就是说，这似乎是实验之外的任何事情都会引发灾难的原因。您将无法修改 IL，因为它可能已经经过 JIT 编译，因此您必须去查找 JIT 编译的代码，并希望 CLR 不会将其从您下面重新定位，或者重新 JIT 代码（两者都允许这样做）。
如果你真的想这样做，有更简单的方法 - 一些元编程/模拟框架使用 CLR Profiling API 来完成类似的技巧（在之前运行、在之后运行、替换方法实现等）。即使如此，我也不会投入生产——引发恢复生成事件的简单方法，因为这些钩子没有真正测试到相同程度的稳定性（例如，它们泄漏、以奇怪的方式失败等）。 :)
Technically yes, it's possible (assuming FullTrust+unsafe code)- pointers are pointers, and managed code is really unmanaged code once it's been JIT'ed. That said, it seems like a recipe for disaster for anything beyond experimentation. You wouldn't be able to modify the IL, since it may have already been JIT'ed, so you'd have to go find the JIT'ed code, and hope that the CLR doesn't relocate it out from underneath you or re-JIT the code (both of which it's allowed to do).
If you really want to do this, there are easier ways- some metaprogramming/mocking frameworks use the CLR Profiling API to accomplish similar tricks (run before, run after, replace method impl, etc). Even that I wouldn't put into production though- easy way to cause a resume-producing-event, as those hooks aren't really tested for stability to the same degree (eg, they leak, fail in strange ways, etc). :)