LocalProcess
Основной WinAPI backend в EyeAuras и то, что он реально умеет
LocalProcess
LocalProcess это основной user-mode backend в EyeAuras. Если нужен самый прямой путь к локальному процессу через WinAPI, почти всегда начинать стоит с него. По духу это тот же внешний сценарий, что и в External Memory Hack, только с более удобным верхним слоем.
Получить модули выбранного процесса
В C#-скрипте EyeAuras с загруженным MemoryModule можно открыть текущий процесс и вывести имена модулей:
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— если память читается внешне, например черезDMAKDProcess— если нужен более глубокий доступ через kernel driver
Как его открыть
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 scanningcode cavesDLL inject,manual mapping,APC,remote thread
Именно поэтому это основной backend для большинства практических сценариев.
Типичный маршрут
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.