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/

[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?

[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?

[th3tuga]

Originally Posted by Gregory Morse

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

Dump the dll that is loaded from the resource, using DnSpy after it's loaded.
Then edit the dumped dll with your patches.
Remove the dll module initialize including the load statements from the exe.
Place the edited dll in the same folder with the exe and run. That's all.

I also use the nick Selya on some forums, since you cannot PM me here.
I respond only to known people though (no crack requests please).

[Stingered]

@th3tuga, would ILmerge be useful here?

[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?

[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.

[cracki]

Originally Posted by Levis

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.

Thanks a lot for your guidance! The approach you suggested seems quite practical for my case

One other question:
How i can "resolve method using Method token" by HarmonyLib? is this possible?

Thanks again for the valuable insight!

[cracki]

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

private LicenseStatus \uE000(){
...

[Aakriti]

Originally Posted by 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.

Using LibHarmony to create a custom hooking program for dynamic DLL patching is an efficient solution. This solution speeds the patching process by utilizing in-memory patching and waiting for DLL loading, hence increasing adaptability and runtime flexibility.

[sendersu]

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