How to Patch (IL Edit) of Assembles loaded from Resource

[cracki]

I'm currently debugging a .NET DLL that, upon execution, loads some dependencies using the:
C#:

Assembly.Load

from its own resources. These new References (DLLs) appear in the dnSpy list, but how can I edit them?

[Stingered]

The only thing I can think of is to insert a DebugBreak() into the .NET DLL. Maybe some has a better solution.

[th3tuga]

Originally Posted by cracki

I'm currently debugging a .NET DLL that, upon execution, loads some dependencies using the:
C#:

Assembly.Load

from its own resources. These new References (DLLs) appear in the dnSpy list, but how can I edit them?

You need to follow the techniques similar to the ones described here, although it's for another protector:

https://insinuator.net/2018/04/reversing-and-patching-net-binaries-with-embedded-references/

[Stingered]

@th3tuga, would ILmerge be useful here?

[cracki]

Originally Posted by th3tuga

You need to follow the techniques similar to the ones described here, although it's for another protector:

Thank you for your response and the guidance you provided!


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?

[Levis]

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.

[cracki]

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?

[cracki]

And how i can Patch something like this in 0Harmony?
The name of method is "\uE000"

private LicenseStatus \uE000(){
...

[sendersu]

have you tried dnSpyEx?
patch inside it (at IL level) then save patched binary -> Profit

[cracki]

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?

[sendersu]

you happiness in any measurable values

[th3tuga]

Originally Posted by cracki

Thank you for your response and the guidance you provided!


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?

Yes it will work.
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.

[NON]

Originally Posted by th3tuga

Yes it will work.
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.

I do not understand. Can someone explain with a simple example?

[Stingered]

If you read the details from the link (example) th3tuga provided, it shows how to remove the Module Initializer code from said DLL.

[Levis]

Originally Posted by cracki

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?

Yes, all you need is to find a DLL or something that being called right before your target method, from the main executable, or any 3rd parties DLL,... then inject some small pieces of code to Reflective load your DLL into AppDomain, then you can do whatever you want, in this case, you're able to perform IL patch before the target method being called.
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.