LCProcessLCProcess это acquisition backend поверх LeechCore и MemProcFS. Если LocalProcess работает с локальным процессом через обычный WinAPI, то LCProcess читает память через внешний источник. Главный автор этой экосистемы это Ulf Frisk.
Для Memory API это важно по одной причине: вы всё ещё получаете привычный IProcess-подобный слой с модулями, регионами, MemoryOfModule(...), импортами, экспортами и сигнатурами, но источник памяти уже другой.
DMA, FPGA и зачем здесь Hyper-VDMA — Direct Memory Access, это сценарий, где память читается не через обычный OpenProcess, а через более низкий и более внешний путь.FPGA — это программируемое железо, на базе которого в экосистеме Ulf Frisk строятся DMA-устройства.Hyper-V — это сценарий, где хост читает память гостевой виртуальной машины снаружи.Если совсем по-простому:
LocalProcess — "открой процесс как обычная программа"LCProcess — "получи память извне и потом уже работай с ней как с процессом"Именно поэтому LCProcess особенно интересен там, где обычный user-mode путь не хочется или не получается использовать.
LCProcess нужен, когда обычного WinAPI уже мало или он вообще не подходит.
Главные сценарии здесь такие:
FPGA — основной DMA-сценарийHyper-V — чтение памяти гостевой машины из хостаWinPMEM — локальный acquisition backend для проверки пайплайна без FPGAЕсли ничего из этого не нужно, почти всегда проще начать с LocalProcess.
Это основной сценарий для LCProcess. Именно ради него этот backend чаще всего и берут.
В экосистеме Ulf Frisk это путь, где память читается через DMA-устройство на базе FPGA, а сверху уже строится привычный process-shaped API:
using EyeAuras.Memory.MPFS;
var processes = LCProcess.FPGA().GetProcesses();
using var process = LCProcess.FPGA().ByProcessName("game.exe");
Практически это даёт главное преимущество LCProcess: чтение идёт внешним путём, а не через обычное открытие процесса. По документации PCILeech и PCILeech FPGA, именно FPGA-сценарий даёт полный доступ к 64-bit memory space без зависимости от обычного process handle на целевой системе.
Если хочется глубже в железную часть, смотри:
Это второй по важности сценарий. Здесь хост читает память гостевой Windows-машины снаружи.
Для старта есть отдельный builder:
using EyeAuras.Memory.MPFS;
var vms = LCProcess.HyperV().ListVirtualMachines();
using var process = LCProcess.HyperV()
.UseVirtualMachineByIndex(0)
.ByProcessName("game.exe");
Главная ценность здесь в том, что память читается снаружи виртуальной машины. Это даёт несколько очень понятных плюсов:
Практическая оговорка здесь одна и важная: для стабильной работы Hyper-V сценария обычно нужно отключить Dynamic Memory у виртуальной машины.
Полезные материалы по этой ветке:
WinPMEM полезен как более простой локальный вход в ту же acquisition-модель:
using EyeAuras.Memory.MPFS;
var processes = LCProcess.WinPMEM().GetProcesses();
using var process = LCProcess.WinPMEM().ByProcessId(1234);
Обычно это самый удобный способ проверить, что ваш сценарий вообще работает в модели LCProcess, ещё до перехода на FPGA.
По теме:
Если готовых builder'ов мало, можно уйти в свои аргументы LeechCore:
using EyeAuras.Memory.MPFS;
using var process = LCProcess.Custom("-device", "hvmm://id=0")
.ByProcessName("game.exe");
Сюда же относятся WithDevice(...), WithRemote(...), WithAdditionalArguments(...), WithPrinting(...) и WaitForInitialize(...).
Если вы интегрируете что-то своё, полезны:
Несмотря на acquisition-природу, сверху вы получаете знакомую модель:
process.MemoryGetProcessModules()GetThreads()GetMemoryRegions()MemoryOfModule(...)ReadImports(), ReadExports(), ReadSections()pattern scanningЭто и есть главный смысл LCProcess: менять транспорт чтения памяти, не меняя весь остальной инструментарий.
LCProcess это backend для чтения и анализа памяти, а не основной backend для управления процессом.
От него не стоит ждать того же профиля, что у LocalProcess:
DLL inject, APC и remote threadЕсли задача звучит как "открыть локальный процесс и быстро что-то пропатчить", почти всегда лучше LocalProcess или KDProcess, а не LCProcess.
Если хочется лучше понять именно разницу между внешним чтением памяти и internal-сценариями, полезны:
Если нужен самый практичный маршрут, я бы рекомендовал такой порядок:
WinPMEMFPGA или Hyper-VТак проще отделить проблемы логики от проблем acquisition stack.