![]() |
How to Patch (IL Edit) of Assembles loaded from Resource
I'm currently debugging a .NET DLL that, upon execution, loads some dependencies using the:
C#: Code:
Assembly.Load |
The only thing I can think of is to insert a DebugBreak() into the .NET DLL. Maybe some has a better solution.
|
Quote:
Quote:
|
@th3tuga, would ILmerge be useful here?
|
Quote:
If I save a version of the DLL that has been extracted from the embedded state alongside the program and somehow (as per the techniques mentioned in the tutorial you provided) remove the "module initializer" so that "the embedded references will be ignored when running the binary" will the program then use the file I saved and patched? |
In this case I think that you should write your own hooking program to dynamically patching the DLL during runtime. LibHarmony should make in-memory patching becomes easier. Just need to wait until the dll is loaded into memory and then call your patching module.
|
Thanks a bunch for the tip!
My target is a .NET Core app without plugin support. What's the best way to inject LibHarmony Patcher? One of examples in the docs that works on my case, involve npm, which seems odd for my case. Any other methods you know of? |
And how i can Patch something like this in 0Harmony? :(
The name of method is "\uE000" Code:
private LicenseStatus \uE000(){ |
have you tried dnSpyEx?
patch inside it (at IL level) then save patched binary -> Profit |
Yeah, I've explored that route and performed the patching within dnSpyEx at the IL level. However, I'm a bit puzzled by the 'binary -> Profit' part. What exactly do you mean by 'Profit' in this context?
|
you happiness in any measurable values
;) |
Quote:
As long as the executable has import references to functions in the patched DLL. You should save it in the same folder the calling executable is in. This is same principle why proxy dll or DLL hijacking works. |
Quote:
|
If you read the details from the link (example) th3tuga provided, it shows how to remove the Module Initializer code from said DLL.
|
Quote:
Remember that if your target is .NET Core, your hooking DLL must be .NET Core, too. Exact Runtime and exact version. For e.g, Target is .NET 6, then your code must be .NET 6, and so on. If using function name is hard (when it's obfuscated), then you can try to resolve method using Method token. There is no big difference. |
| All times are GMT +8. The time now is 02:23. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2026, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX