LocalProcess

Основной WinAPI backend в EyeAuras и то, что он реально умеет

LocalProcess

LocalProcess это основной user-mode backend в EyeAuras. Если нужен самый прямой путь к локальному процессу через WinAPI, почти всегда начинать стоит с него. По духу это тот же внешний сценарий, что и в External Memory Hack, только с более удобным верхним слоем.

Получить модули выбранного процесса

В C#-скрипте EyeAuras с загруженным MemoryModule можно открыть текущий процесс и вывести имена модулей:

csharp
using System.Diagnostics;
using EyeAuras.Memory;

{
    using var process = LocalProcess.ByProcessId(Process.GetCurrentProcess().Id);
    foreach (var module in process.GetProcessModules())
        Log.Info($"{module.ModuleName}: 0x{module.BaseAddress:X}");
}

Результат — снимок модулей процесса EyeAuras. Для другой цели используйте выбранный PID; поиск по имени выбирает первое совпадение и не различает несколько одинаковых процессов.

В EyeAuras 20fd3d4 LocalProcess — статический фасад metadata-сборки, возвращающий ILocalProcess. Реальный builder регистрирует MemoryModule. В embedded-хосте нужен UseMemory() и завершённый EnsureReadyAsync() после запуска WPF/Prism runtime; ссылка на SDK сама builder не создаёт.

Reader владеет лениво открываемыми OS handle и закрывает их при Dispose. Его Memory заимствуется на время жизни reader. IsValid проверяет состояние reader/процесса, но не доступность конкретного адреса. Чтение и перечисление синхронны; токен отмены их не прерывает. Нужные права, разрядность и успешный OpenProcess проверяются в реальном окружении.

Когда подходит, а когда нет

LocalProcess хорош, когда:

  • нужен обычный локальный процесс
  • нужен быстрый старт без кастомного backend'а
  • кроме чтения памяти нужен и обычный process control

Главное ограничение одно:

  • он сам открывает процесс обычным WinAPI-путём, поэтому с защищёнными процессами не подходит

В таких случаях обычно смотрят на:

  • NativeLocalProcess — если нужный handle уже получен заранее
  • LCProcess — если память читается внешне, например через DMA
  • KDProcess — если нужен более глубокий доступ через kernel driver

Как его открыть

csharp
using System.Diagnostics;
using EyeAuras.Memory;

{
    using var byPid = LocalProcess.ByProcessId(Process.GetCurrentProcess().Id);
    using var byName = LocalProcess.ByProcessName("notepad");

    var processes = LocalProcess.GetProcesses();
}

Что он даёт

Через LocalProcess вы получаете сразу две вещи:

  • нормальный доступ к памяти через process.Memory
  • обычный user-mode контроль процесса

Из этого сразу вырастают:

  • MemoryOfModule(...)
  • ReadExports(), ReadImports(), ReadSections()
  • pattern scanning
  • code caves
  • DLL inject, manual mapping, APC, remote thread

Именно поэтому это основной backend для большинства практических сценариев.

Типичный маршрут

csharp
using EyeAuras.Memory;
using EyeAuras.Memory.Scaffolding;

{
    using var process = LocalProcess.ByProcessName("game");
    using var moduleMemory = process.MemoryOfModule("game.exe");

    var sections = moduleMemory.ReadSections();
    var imports = moduleMemory.ReadImports();
    var exports = moduleMemory.ReadExports();
}

Если потом хотите перейти от внешнего чтения к более активной internal-практике, полезны DLL Memory Hack, DLL Injector и Code Caves & DLL's.

Где NativeLocalProcess лучше

NativeLocalProcess нужен не вместо LocalProcess, а когда процесс уже открыт нужным вам способом и вы хотите положить Memory API поверх готового handle.

Что читать дальше