Сохранить/восстановить состояние процесса

valterg
хотя тот же WarCraft со своим jass у него тоже есть стек, тоже надо сейвить, так что походу не проблема. Да и если функции перехвачены, то можно просто смотреть "если хендел старый" то дальше пускать с новым ( востановленым ) вот и все беде.

 

это если очень повезет и Create* + Use будут в одном кванте "сохранения".
при восстановлении все хендлы будут "старыми", и чтобы "дальше пускать с новым" даже с перехватом всех Create* + CloseHandle придется хранить все параметры Create* + адреса под хранение хендлов.
при восстановлении Creat'ить все "согласно списка" не забывая CloseHandle согласно того же списка. + придется перехватывать все что можно пользовать для модифицикации объекта (WriteFile к примеру) и "по списку" восстанавливать содержимое таких объектов.
тут логика где-то_как-то примерно понятна.
но что делать если хендл между Create* и use "висит" на регистрах?
да и не факт что mow [mem], eax будет идти сразу после Create*.
или Create* попал в один квант "сохранения" и use - в другой?
сложность реализации явно стремится к infinity

 

Вы ещё забыли о текстурах, которые лежат в памяти видюхи. (вы, вроде бы как для игры изначально хотели написать это)
В принципе, если игра написана правильно, то можно было бы послать ей сообщение, что потеряна поверхность и она сама бы заново загрузила тестуру. Только боюсь, что не все игры так написаны. Да и хэндлы, опять же....

А артмани по-моему просто сохраняет всю память процесса.

 

DMD
перехватывать не только создание и удаление, но и использование. причем паузить перед сохранением когда все потоки вне системных длл. все

 

spa
все это очевидно. как и то что все хендлы придется мониторить от запуска таргета до его exit.
и это, похоже, не самое сложное в реализации.
неочевидностей в перспективе тоже в достатке.
Z3N совершенно прав указав на IO...

кстати, как видится поведение таргета под этой штукой?

 

DMD
это если вариант воспроизведения использовать, то да, все время мониторить.

 

вчера под вечер пришла незатейлевая мысль\вопрос:
чем? как? когда? следует "тормозить" тартет-процесс?
самое надежное #DB - система сама сделает остальное.
в первый раз это ОЕР, а второй? третий?

"руками"?.. все утонет в синхронизации.

valterg

именно те. на hold-точках. -> в произвольном таргете предложить даже теор.модель stop/replay затруднительно, если не сказать "невозможно"...
есть другие мнения?

 

"я может быть скажу какую-нибудь глупость, ..." (c)

... но допустим, что вы при восстановлении процесса пропатчите нужные таблицы хэндлов/объектов в ядре и win32k, но как быть с состояниями объектов (относящихся к данному процессу), которые хранятся в драйверах, например directx, opengl, winsock/afd/tdi, ntfs, usb ?

Допустим даже, хрен с ней, с периферией, что с локальными-то делать? реверсить каждый драйвер и поддерживать туеву хучу таблиц приватных смещений или графов и тестировать их при выходе очередных патчей?

в общем, имхо, теоретически это возможно реализовать, но будет неоправданно дорого, либо не универсально.

 

wild_cosine
я уже назвал "простой" и универсальный способ, тут остается только проблема в том что востановление фактически рано времени работы приложения, это да беда, но тоже решаемо, но уже с нюансами

 

spa
а как быть, например, с рандом-генератором, хранящим seed в реестре (назовем его условно RtlGenRandom) ?
допустим, вы записали ваш изначальный сид, и восстановили его при воспроизведении.
тогда, если "в прошлой жизни" RtlGenRandom вызывался фоновыми процессами N раз, то в процессе воспроизведения он может вызваться совершенно иное число раз в зависимости от активности фоновых процессов, или в т.ч. сетевой активности.
таким образом как только контроль "окружающей среды" вылезает за рамки нашего процесса, возникает вопрос, а не проще ли было всю систему в хайбернейт свернуть?

моё имхо:
надо начинать копать с HibernationAware-процессов.
т.е. на текущий момент любой дженерик процесс сериализовать невозможно.
но возможность эта появляется у новых программ, которые типа Hibernation Aware, мол, знают и умеют своё состояние сохранить.
в таком случае система по запросу вызывает нужные колбэки процесса и сохраняет сформированный им дамп.

другое дело, что прога сама может не знать, как те или иные данные сериализуются, например графические контексты какие-нибудь...

вот если бы еще все драйвера имели бы интферейс типа GetProcessPrivateData(pid)... тогда ваще всё на мази.

 

Еще будет одна проблема (в частности если это игра), а что если в игре уже загружены в видеопамять все текстуры, шейдеры и прочие GPU'шные вещи, ведь тогда придется каким-то образом найти их в видео памяти, отделить от других, и сохранить, да и затормозить выполнение кода на GPU не так и легко будет. А отследить то, что туда загружается - это уже будет проблематично т.к. надо будет похукать весь DirectX + драйвера ответственные за (Cuda/Ati Stream/OpenCL)

 

wild_cosine
все функции которые могут содержать "рандомные" в том числе и изменяемые значения должны возвращать одно и тоже при записи и воспроизведении.

 

в соседней теме адресок на блог увидел
может оттуда в тему?!
http://blog.didierstevens.com/2011/04/27/suspender-dll/

 

spa

Чтобы это решить нужно полностью контролировать работу системы, что абсолютно не реально. Даже на уровне системы это не реально, ввиду того что нужно контролировать все драйвера, а они как известно бывают сторонние.
А восстановление равное времени работы приложения это извините утопия.

 

Booster
не надо контролировать все, надо лишь контролировать то что может работать и возвращаться вероятностный результат. А насчет времени, то его можно ускорить, в большинстве случаев можно. Согласен что задача не тривиальна, но восстанавливать все объекты точно ен проще, если вообще возможно.

 

Ждёт процесс на обьекте, допустим на глобальном синхрообьекте. После восстановления состояния процесса обьект может:
o Измениться до этого, многократно быть сигнализированным. Процесс этого не узнает.
o Может быть удалён из системы, тогда синхрорантайм вернёт #STATUS_INVALID_HANDLE.
Таким обьектом может быть любой обьект глобальный, как например поток или файл.

 

spa

Если я верно понял, то вы предлагаете проиграть внешнее окружение до состояния программы. К примеру файловый указатель в программе был на середине файла, то файл нужно будет открыть и переместить файловую позицию на необходимую величину. А последующее обращение к окружению, вы предлагаете контролировать хуками. Но проблема в том что программа может обращаться к окружению напрямую, без каких либо вызовов посредников. Яркий пример, программа лочит некую внешнюю область памяти(сама функция лочки системная) и начинает туда писать данные, если вы остановите программу в процессе записи в память, то после восстановления перехватить запись в эту память будет не возможно и залочить по тому же адресу, а тем более записать уже записанные данные нельзя. Кто вам выделит память по одним и тем же адресам?

 

Booster
все почти верно, мы проигрываем программу с начала, как вы заметили программа сама пишет и читает эту память, как следствие ( алгоритм же не менялся ) если программа будет запущенна в одной и тойже среде, то и результат выполнения алгоритма ( записи в память ) будет тот же. ну и конечно надо хранить свапшоты файлов и веток реестра.

 

spa

Как вы заставите систему дать память по тому же самому адресу что в первый раз? А затем ещё надо как-то вернуть эту память в прежнее состояние.

 

Booster
а зачем давать память по тому же адресу? ну будет она по другому, но приложение то будет знать где оно ( указатель создаться алгоритмом), хотя если приложение использует этот указатель как рандомное значение, то да. но думаю таких приложений не много.

Грубо говоря приложение берет только нажатие клавишь и еще вызывает rand() то если эмулировать нажатие ( все события, в теже моменты) и еще перехватить rand() то приложении будет вести себя как и во время записи.