куплю код детекта вм машин без црт

нужен не простой код,что типа процессы вирт машин,а даже если если антидетекторы включены у машины,всё равно ее детектировать,обойти все паблик антидетекторы надо.
ищу кодера кто возьмется, в лс

 

Норм способ такой https://wasm.in/threads/avanguard-the-win32-anti-intrusion-library.33212/page-11#post-416300

Обойти в принципе проблема, так как нет привязки ко временным счётчикам, те нет события по которому отличается исполнение под вм. Но для этого нужно снятие статистики по кучи инструкций на множестве архитектур и вм.

 

Какие антидетекторы ? Типа чтоб круче pafish был код или оттуда подойдет?
Хотя, вы не туда пришли. Вам тут сейчас напишут 10 страниц флуда, и что задача не имеет решения, и что надо юзать линукс, веровать в бога, и что можно майнить биткойн на МКС..

 

M0rg0t,

Крутое" это по твоему https://github.com/a0rtega/pafish ?

Эта фигня детектится и обходится за пол часа, procmon покажет все обьекты, трассировка инструкции rdtsc, cupid, I/O и есчо несколько

 

Indy_, это некий стандарт в плане детекта виртуалок.

Если можете круче, то напишите вот для ТСа, заработаете шекель. Не хотите , так напишите для паблика , выложим на форуме или на гитхабе, люди будут благодарны.

 

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

--- Сообщение объединено, 13 мар 2020 ---

1-2% уже подозрительно.

 

voffka0,

Что за бред.

TermoSINteZ,

Решения нет. Для него нужен метод, которого тоже паблик нет. Теоретические методы нужны что бы создать технику, механизм. Затем это можно будет реализовать на яп. Но пока нет механизма(концепта"), то и вопрос смысла не имеет. Для разработки можно обсудить. И советы в данном случае и есть способ решения. На сишке такой алго и вы запилите за десяток минут, зная технику.

Так что это никак не флуд.

 

Генерик решения может и нет, но можно искать баги в эмулях. Вчера случайно наткнулся, vmware не эмулит LBR, это сразу детект.

 

hiddy,

Что за LBR, аппаратная трассировка ?

За время которое ты думал можно было снять статистику и общим способом реализовать как сказано выше.

 

Аппаратная фича, которая записывает адреса ветвлений в msr. А еще эта фича раскрывает ядерный адрес KiSystemServiceExit даже из low il, и это на 10 винде. Еще ее пытались использовать для защиты от ROP атак, но так как эвента вызова системного сервиса нет, то не особо понятно, в какой момент запускать проверку для получения надежного результата. https://www1.cs.columbia.edu/~angelos/Papers/2013/kbouncer.pdf

Я слышал, что есть общая техника детекта - атака по времени, но особо не вникал. Это опять же из серии кривого эмуля или что-то другое?

 

hiddy, вопрос в том, не будет ли фолс детектов для Hyper-V

 

hiddy,

> Это опять же из серии кривого эмуля или что-то другое?

Каких извратов только не придумают

Чем же поможет трейс, если он полноценно эмулируется. Да есчо и ядерный механизм. Вроде как на каких то версиях нт можно это завести и в юзермод через манипуляции контекстом. Механим привязан к ос и железу, не нужно это.

> общая техника детекта - атака по времени

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

Другое дело если есть спец обработка(cupid etc). Тайминг изменяется, а относительный замер профайла напрямую показывает симуляцию.

--- Сообщение объединено, 21 мар 2020 ---

Тайминг замеряется относительный. Это значит без привязки к таймерам. Тоесть используется эталонный замер, например некоторое количество любых инструкций. Таким же образом и палится обычная трассировка - отношение времени для цикла без трассировки const, но так как трейс привязан к моду, то вызвав ядерный сервис как эталон времени можно просто обнаружить.

--- Сообщение объединено, 21 мар 2020 ---

TermoSINteZ,

Получается что при использовании хард вирты любой железный механизм автоматически поддерживается. Если софт вирта основанная на хард вм не поддерживает некоторый механизм, то при обновлении железа он автоматически реализуется. Это отвязка от железа.

--- Сообщение объединено, 21 мар 2020 ---

* от софт импл.

 

У амд тоже есть поддержка LBR, как раз из свежего мануала узнал об этом. Сколько ветвей попадает в лог - это вопрос, надо будет посмотреть в ядре. А вот аналога IPT кажется нет, Lightweight Profiling (LWP) - очень похоже, но не то, ибо работает только при CPL = 3 и не факт, что позволит инжектить код.

А где взять этот эталонный замер? И какой механизм использовать для снятия профайла? Вирта ведь и тайминги подделать может, в теории..

Hyper-V можно включить виртуализацию LBR, я на эту вм и мигрировал для отладки.

 

hiddy,

Длинный цикл, может даже пустой, это эталонное время. Другой такой же даст одинаковый тайминг. При этом нет привязки к таймерам, естественная задержка. Выше по ссылке был же тайминг с cupid/rdtsc.

Если например выбрать параметры цикла, тайминг которого окажется равным таймингу при вызове ядерного сервиса, тогда это обнаружит трассировку(тк время потока в ядре изменится).

--- Сообщение объединено, 22 мар 2020 ---

Вот простой пример. Первый цикл:

Код (Text):

1.     mov edi,80000000H
2.     .repeat
3.         dec edi
4.     .until Zero?

Второй цикл:

Код (Text):

1.     mov edi,800000H
2.     .repeat
3.         xor eax,eax
4.         cpuid
5.         dec edi
6.     .until Zero?

Время не важно как замерять, это может быть само число итераций, системное время или например число прерываний..

В данном случае врямя GetTickCount():
1047: 4875 -> 4.6 на варе.
875: 344 -> 0.4 на хосте.

Это очень не точно, так как у GTC точность низкая и он не линейный.

 

С чем сравнивать это время? Если нет хоста. ВМ ведь тоже разные бывают, у меня есть виртуалка с 256гб оперативки и 24 процессорами, врядли там будет медленнее, чем на дешевом ноуте.

 

M0rg0t,

Вот посмотри, у меня в результате варя 94:2:1:1, хост 6:1:1:1

--- Сообщение объединено, 22 мар 2020 ---

Если запустить на any.run 141:1:1:1 https://app.any.run/tasks/f8ea0146-13ee-4693-baf4-32827255ff13

--- Сообщение объединено, 22 мар 2020 ---

Интересно измерить тайминг для разных аргументов cupid: (eax: 0, 1, 0x80000008, -1), хост 7:21:16:19 это разница по числу итераций. Получается что процик разное время выполняет в зависимости от параметра. Тогда разница по циклам:
host 1:0.33:0.44:0.37 -- any.run 1:0.96:0.93:0.75 -- vmware 1:0.84:0.90:0.84

- на этом тоже можно построить детект.

 

если вирта и хост пашут на одном проце, то у вирты урезается процент времени прямого доступа к процу + увеличиваются промахи кэша.

1. в много-потоке сравниваются счётчики между потоками.
2. используется внешний таймер, если есть доступ к серверам.
3. можно записывать в файл показание счётчиков и отслеживать их вариацию.

для вирты с эксклюзивным доступом к жестянке измерять падение скоростей действительно бесполезно. Однако, можно прощупывать наборы используемых дров и настройки.