вводят код C# в другой процесс и вызывают целевые функции

Question

Я пытаюсь вызвать игровые функции с помощью инъекции кода. после некоторой попытки я нахожу dll, который сделал то, что я хочу.

поэтому я увидел DLL с ILSpy, но не могу понять код.

class <Module> 
{ 
[SecurityCritical, SuppressUnmanagedCodeSecurity] 
    [DllImport("", CallingConvention = CallingConvention.ThisCall, SetLastError = true)] 
    [MethodImpl(MethodImplOptions.Unmanaged)] 
    internal unsafe static extern float* GetHealth(AttackableUnit*); 
} 
-------------------------- 
namespace Native 
{ 
    [NativeCppClass] 
    [StructLayout(LayoutKind.Sequential, Size = 1)] 
    internal struct AttackableUnit 
    { 
    } 
} 
--------------------- 
public unsafe float MaxHealth 
     { 
      get 
      { 
       Native.AttackableUnit* ptr = (Native.AttackableUnit*)base.GetPtr(); 
       if (ptr != null) 
       { 
        return *<Module>.Native.AttackableUnit.GetMaxHealth(ptr); 
       } 
       return 0f; 
      } 
     } 

кажется дллы INJECT C# код для целевого приложения с C++ DLL и самозагрузок .net в цели.

И теперь я не могу понять, что смысл

[DllImport ("", CallingConvention = CallingConvention.ThisCall, SetLastError = истинный)]

Почему путь к файлу пустым ? Как DLL управляет вызовом класса и функции? Я имею в виду, какую технику использует программист?

EDIT: Название библиотеки, которую я пытаюсь понять, возможно, помогает Elobuddy.

Answer 1

Попытка не открывать широко открытую дверь, язык C# не участвовал в создании этой сборки. Вы видите результат проекта C++/CLI. A смешанный режим сборка, он содержит как MSIL, так и собственный код. Вы должны создать аналогичную сборку с помощью File> New> Project> Visual C++> CLR> Class Library.

Автор, вероятно, предпочел решить проблему с CLR-инъекцией. Невозможно внедрить чистую управляемую DLL в другой процесс, сначала CLR должен быть загружен и инициализирован, прежде чем он сможет выполнить любой управляемый код. Проблема с курицей и яйцом, которая требует обратного вывода (собственный код, вызывающий управляемый код), напротив того, что делает [DllImport]. C++/CLI делает это очень просто, я описываю эту технику в this answer. Утилита Unmanaged Exports популярна (google DllExport), сборщик, который использует тот же метод, что использует C++/CLI.

Но автор также хотел использовать собственный код на C++ для реализации взлома игры. Он использует чистую родную DLL, он содержит функцию GetHealth() и определение класса AttackableUnit. Эта DLL неявно загружается загрузчиком ОС, например, как обычно DLL, причина, по которой пустая строка для атрибута [DllImport] достаточно хороша. В противном случае компилятор не может знать, какая DLL имеет этот собственный код, который не сортируется до запуска компоновщика и использует библиотеку импорта собственной DLL.

Компилятор C++/CLI немного перегружает метаданные для чистых нативных конструкций в коде. Но делает все возможное, чтобы заставить их выглядеть как можно больше, как их управляемые эквиваленты. Заметьте, что он очень неполный, вы не можете, например, увидеть имена членов класса AttackableUnit C++. Вы найдете лот другого извержения в сборке, много объявлений CRT также попадают в метаданные. Нативный компоновщик не делает потрясающую работу по ее укрытию. В основном, потому что это не обязательно, этот код довольно хорошо изолирован от внутреннего класса <Module>.

Декомпиляция машинного кода для собственных функций, таких как GetHealth, обратно к исходному коду C++, вообще не возможна. Особенно оптимизатор, встроенный в конец компилятора, делает потрясающую работу, позволяя себе практически невозможно догадаться, как выглядел бы оригинальный код. Hex-Rays обычно упоминается как декомпилятор машинного кода, который делает достоверную работу, по крайней мере, правильно идентифицируя код и данные.