Ранг: 7.7 (гость) Активность: 0=0 Статус: Участник
Создано: 15 ноября 2011 21:43 · Поправил: GoldenJoe · Личное сообщение · #1
Как я себе это представляю: 1. Прога ставит бряки и внедряет либу в процесс-жертву 2. Либа устанавливает VEH 3. Когда возникает исключение, прога должна каким-то образом получить от внедренной DLL-ки EXCEPTION_RECORD с кодом исключения и прочей инфой. Прога должна проверить, а наш ли это бряк (а, может, совсем даже не бряк ) и неведомым образом сообщить внедренной либе, что делать дальше (CONTINUE_SEARCH или CONTINUE_EXECUTION вернуть, например).
По первым двум пунктам вопросов нет. С 3 пунктом посложнее. Есть именованный FileMapping да event-ы, есть сокеты. А КРАСИВЫХ решений, я так понимаю, нет?
Ранг: 793.4 (! !), 568thx Активность: 0.74↘0 Статус: Участник Шаман
Создано: 19 ноября 2011 20:24 · Поправил: PE_Kill · Личное сообщение · #3
PE_Kill пишет: Дальше пошло нереализуемое в юзермоде гавно. Как видишь с точностью до наоборот. Я никогда не лезу в ядро, поэтому в принципе его не обсуждаю.
spinz пишет: wbinvd push 12345678 invd cmp [esp],12345678 je vm самый ипучий фактор в том,что ни один гипервизор не позволит работать гостям без кэша. а эмулить сброс кэша ни один сраный гипервизор не умеет
spinz пишет: бональный кодеcwbinvdpush 12345678invdcmp [esp],12345678je vmпалит все вм И с вероятностью 1/5 вешает хост систему или роняет ее в бсод. Только что проверено. Проверялось на драйвере содержащем следующий код:
Точная причина не ясна, но ясно что инвалидация кэша бесследно не проходит и так делать нельзя. Возможно инвалидируются внешние кэши других процессоров, возможно инвалидация асинхронна, надо читать мануалы и пробовать. По-любому получается этот код в 5 строчек не уложится.
ntldr пишет: Точная причина не ясна, но ясно что инвалидация кэша бесследно не проходит и так делать нельзя. прична ясна, ты проверял по-любому на не одноядернике. на нескольких ядрах нужны синхронизация кэша, т.к. invd флашит и общий кэш в том числе
подскажу даже куда копать. между wbinvd и invd другое едро производит операцию с памятью, допустим обыный call. после invd стек невалиден. надо, очевидно тормозить другие ядра. непросто, но универсально
Спс, за оценку зрения. читать не разучился. а вот читать коменты разучился, ибо их нет. нтлдр задает грамотные вопросы, остальные видимо просто не поняли суть
Теперь работает стабильно, но не различает host и guest для Microsoft Hyper-V (на хосте IsVM() == 1). Дело в том что гиперв запускает хост внутри гипервизора и многие методы детекта аппаратного гипервизора дают фолс. Есть идеи как их различить?
а надо? мы хотим поймать факт, что мы внутри вм? или нам нужно понять где конкретно? т.е. в отдельных случаях надо отличать где хост-винда, а где гипервизор. я такой задачи не ставил в этом случае. а если мы под варей? важно ведь не это. важно то, что гость практически гарантированно может обнаружить факт эмуля. хотя челы, которые девелопят борщ, скорей всего скоро запилят эмуляцию кэша. несколько лет назад они запилили за месяц детект, о котором я говорил на васме.
spinz пишет: т.е. в отдельных случаях надо отличать где хост-винда, а где гипервизор Обязательно надо. Фолс-детекты недопустимы, лучше пропустить какую-нибудь вм чем зафолсить на Hyper-V сервере. Будут идеи как сделать надежный детект без обращения к гиперв через WMI?
На ум пока приходят 2 пути 1) Как то заюзать тот факт, что хосту разрешен direct i/o. Идеи есть, проверить пока не на чем. 2) В госте не эмулится unreal mode, можно использовать это для детекта. Правда инфа старая и не проверенная.
Всёже есть решение 2.3, хотябы чисто гипотетическое ?
spinz Вот вы вернулись к ответу выше - использовать I/O. Апик эмулится наверно всем чем тока можно. Вдобавок не следует забывать про непосредственное исполнение кода на камне, как в варе.