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

Тема в разделе "WASM.NT.KERNEL", создана пользователем x64, 1 авг 2008.

  1. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    valterg
    хотя тот же WarCraft со своим jass у него тоже есть стек, тоже надо сейвить, так что походу не проблема. Да и если функции перехвачены, то можно просто смотреть "если хендел старый" то дальше пускать с новым ( востановленым ) вот и все беде.
     
  2. DMD

    DMD Member

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

    Z3N New Member

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

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

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    DMD
    перехватывать не только создание и удаление, но и использование. причем паузить перед сохранением когда все потоки вне системных длл. все
     
  5. DMD

    DMD Member

    Публикаций:
    0
    Регистрация:
    21 ноя 2005
    Сообщения:
    56
    spa
    все это очевидно. как и то что все хендлы придется мониторить от запуска таргета до его exit.
    и это, похоже, не самое сложное в реализации.
    неочевидностей в перспективе тоже в достатке.
    Z3N совершенно прав указав на IO...

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

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    DMD
    это если вариант воспроизведения использовать, то да, все время мониторить.
     
  7. DMD

    DMD Member

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

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

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

    wild_cosine New Member

    Публикаций:
    0
    Регистрация:
    19 дек 2010
    Сообщения:
    11
    "я может быть скажу какую-нибудь глупость, ..." (c)

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

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

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

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    wild_cosine
    я уже назвал "простой" и универсальный способ, тут остается только проблема в том что востановление фактически рано времени работы приложения, это да беда, но тоже решаемо, но уже с нюансами
     
  10. wild_cosine

    wild_cosine New Member

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

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

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

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

    slesh New Member

    Публикаций:
    0
    Регистрация:
    6 фев 2009
    Сообщения:
    214
    Еще будет одна проблема (в частности если это игра), а что если в игре уже загружены в видеопамять все текстуры, шейдеры и прочие GPU'шные вещи, ведь тогда придется каким-то образом найти их в видео памяти, отделить от других, и сохранить, да и затормозить выполнение кода на GPU не так и легко будет. А отследить то, что туда загружается - это уже будет проблематично т.к. надо будет похукать весь DirectX + драйвера ответственные за (Cuda/Ati Stream/OpenCL)
     
  12. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    wild_cosine
    все функции которые могут содержать "рандомные" в том числе и изменяемые значения должны возвращать одно и тоже при записи и воспроизведении.
     
  13. Ra_

    Ra_ New Member

    Публикаций:
    0
    Регистрация:
    4 мар 2007
    Сообщения:
    289
    в соседней теме адресок на блог увидел
    может оттуда в тему?!
    http://blog.didierstevens.com/2011/04/27/suspender-dll/
     
  14. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.860
    spa
    Чтобы это решить нужно полностью контролировать работу системы, что абсолютно не реально. Даже на уровне системы это не реально, ввиду того что нужно контролировать все драйвера, а они как известно бывают сторонние.
    А восстановление равное времени работы приложения это извините утопия.
     
  15. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    Booster
    не надо контролировать все, надо лишь контролировать то что может работать и возвращаться вероятностный результат. А насчет времени, то его можно ускорить, в большинстве случаев можно. Согласен что задача не тривиальна, но восстанавливать все объекты точно ен проще, если вообще возможно.
     
  16. klzlk

    klzlk New Member

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

    Booster New Member

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

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    Booster
    все почти верно, мы проигрываем программу с начала, как вы заметили программа сама пишет и читает эту память, как следствие ( алгоритм же не менялся ) если программа будет запущенна в одной и тойже среде, то и результат выполнения алгоритма ( записи в память ) будет тот же. ну и конечно надо хранить свапшоты файлов и веток реестра.
     
  19. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.860
    spa
    Как вы заставите систему дать память по тому же самому адресу что в первый раз? А затем ещё надо как-то вернуть эту память в прежнее состояние.
     
  20. spa

    spa Active Member

    Публикаций:
    0
    Регистрация:
    9 мар 2005
    Сообщения:
    2.240
    Booster
    а зачем давать память по тому же адресу? ну будет она по другому, но приложение то будет знать где оно ( указатель создаться алгоритмом), хотя если приложение использует этот указатель как рандомное значение, то да. но думаю таких приложений не много.

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