0

I'm making a C# DLL which will be injected in Skype, it is supposed to display a messagebox.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace L3n_Hack_DLL
{
    public class Class1
    {
        [DllImport("kernel32.dll")]
        public static extern IntPtr OpenProcess(int dwDesiredAccess, bool bInheritHandle, int dwProcessId);

        [DllImport("kernel32.dll")]
        public static extern bool ReadProcessMemory(int hProcess,
            int lpBaseAddress, byte[] lpBuffer, int dwSize, ref int lpNumberOfBytesRead);

        public static void Main()
        {
            MessageBox.Show("working", "teste", MessageBoxButtons.OK, MessageBoxIcon.Information);
        }
    }
}

Anyways, when injected, it doesn't show anything, the OpenProcess() and ReadProcessMemory() methods are for later.

My question is, where does a DLL start when injected?

Shouldn't it start in static void Main()?

David Gomes
  • 650
  • 2
  • 10
  • 34
  • 1
    [Dynamic-Link Library Entry-Point Function](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682596.aspx). – cbr Jul 10 '15 at 20:29
  • 4
    Instead of saying `(The code isn't well formatted)`, you can just format it yourself. It took me all of 20 seconds and you could have done it as well. – Jashaszun Jul 10 '15 at 20:32
  • A DLL is only a library and not a process that starts by itself. The entry point is really from where you call it. – XtremeBytes Jul 10 '15 at 20:33
  • @XtremeBytes a DLL has an [entry point function](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682596.aspx) as well, like cubrr pointed it out (although not one you can declare from C#). – Lucas Trzesniewski Jul 10 '15 at 20:39
  • @Jashaszun You're true, sorry for my laziness... – David Gomes Jul 10 '15 at 20:43
  • @cubrr That's for C++ :(... – David Gomes Jul 10 '15 at 20:43
  • Static constructor maybe? – James R. Jul 10 '15 at 20:53
  • @JamesR. Well, public static void Main() is static right ? – David Gomes Jul 10 '15 at 20:55
  • Static, yes. Not a constructor, though. – James R. Jul 10 '15 at 20:56
  • [C# equivalent of DllMain in C (WinAPI)](http://stackoverflow.com/questions/8206736/c-sharp-equivalent-of-dllmain-in-c-winapi) – James R. Jul 10 '15 at 21:11
  • According to the [C# specification](https://msdn.microsoft.com/en-us/library/aa645612(v=vs.71).aspx) static constructors are only called when a) An instance of the class is created. or b) Any of the static members of the class are referenced. Maybe [this](http://www.codeproject.com/Articles/607352/Injecting-Net-Assemblies-Into-Unmanaged-Processes) article helps you. From what it looks is seems to be a non-trivial task, though. – Suigi Jul 10 '15 at 21:15
  • @JamesR. Oh yeah I forgot what constructor meant :p – David Gomes Jul 10 '15 at 21:25
  • @Suigi Thanks!!!!!It worked!!!Write it as an answer and I can make it as the correct answer! – David Gomes Jul 10 '15 at 21:52

1 Answers1

1

This code project article gives you a nice walkthrough how to inject .Net assemblies into unmanaged processes. It first loads an unmanaged bootstrapper.dll which does the heavy lifting of loading the .Net runtime and your managed assembly.

Suigi
  • 216
  • 2
  • 4
  • Is injecting managed assemblies into other processes a good idea? I remember reading an article that if the process already has a .NET runtime loaded, though a different one from the one you're trying to load, you risk crashing the entire process. This was why writing shell extensions was not supported by .NET. Perhaps this has changed? – Lasse V. Karlsen Jul 11 '15 at 06:37
  • 2
    Here's [another code project article](http://www.codeproject.com/Articles/174369/How-to-Write-Windows-Shell-Extension-with-NET-Lang) on writing shell extensions with .Net. The author states that .Net 4 introduced the ability to have more that one runtime in a single process. So I guess the restriction you've mentioned has indeed changed. However, I would argue that injecting code into any foreign process is a risky endeavor of the "know exactly what you're doing" kind. If it's a process you control you can provide the architectural means to safely load and run more code (instead of injecting). – Suigi Jul 11 '15 at 07:08