Интересуют изощрённые и нестандартные способы идентификации ПК на котором запускается программа. Классический вариант - собрать побольше информации о железе (проц, диски, серийники банок памяти, мат. платы и видеокарты, подключенная периферия) и отправить на сервер. Проблема - вся эта информация подменяется при спуфинге (обычно через драйвер режима ядра, буткит или системная ВМ). Варианты борьбы: 1) Постоянно находится в системе и мониторить изменения информации для идентификации - крайний случай, хотелось бы ограничиться ring3. 2) Найти ещё какой-то уникальный след который не подменяет спуфер и по нему идентифицировать пользователя - будет работать до того момента, пока разработчик спуфера не обновит своё детище, ненадёжное решение 3) При запуске приложения оставлять "следы" с уникальным отпечатком и регулярно их проверять. Если они изменились - либо спуфинг, либо пользователь воткнул другую железку в свой ПК. Накидайте идей молодому. Я призываю Indy, у него должны быть мыслишки. Ограничения: только в режиме пользователя, Win32 & Win64, Windows 7+. Только программная реализация.
Что можно будет сделать в ядре если в большинстве случаев мы вмешиваемся ПОСЛЕ исполнения спуфера? Получить доступ к некой области памяти которая доступна из ядра, выполнение превилигированных апи? Пришёл 4й вариант идентификации - наличие авторизации в различных приложениях, запущенных у пользователя - discord, тг и тд. Это вариант, но ненадёжно (поддерживаемых приложений просто может не быть установлено у пользователя).
Юзером (с правами админа) можно читать SMART дисков, где имеются поля точно определяющие хард конкретного пользователя. Ведь одинаковые винты могут быть у многих юзеров, зато параметр смарта "Sector Relocation Count" (кол-во скрытых секторов после переназначения Remap), с вероятностью 99% будут разные. А так с ринг(3) мало вариантов, и большая часть упирается в парсинг значений реестра - чисто ламерский ход. Можно чекать что-то связанное с безопасностью из либы secur32.dll, тестить железяки через менеджер конфигурации в setupapi.dll, и т.д.
Соцсети предоставляют авторизацию через апи (например чтоб каменты на некоторых сайтах оставлять), такой авторизацией зачем-то пользуется бесплатная nvidia experience, эффект кстати тот же - пошли они нахрен. ИМХО с такими вводными любое решение - "ненадежное решение". Потому что весь защитный алгоритм юзеру доступен для изучения и вмешательства.
Немного потешной истории. У процессора NES (6502 моторола) не было штатных вариаций генерации случайных чисел, поэтому рандом генерился исходя из нажатий клавиш джойстика. Если в эмуляторе вывести первый и второй геймпад на один и тот же джойстик и поставить тетрис на двоих, то левая и правая половина экрана будет сыпать идентичными деталями. Не знаю, поможет ли это с вопросом топика, но я хотел помочь)
Есть еще один потешный момент с этим связанный - эмуляторы NES как правило устроены так, что в game loop опрашивают устройства ввода в одном и том же месте и потому обновляют состояние виртуальных геймпадов ровно в одной и той же строки кадра видеосигнала с точки зрения эмулируемой программы. Настоящее же железо меняет эти данные в произвольные моменты времени без какой либо привязки к таймингу видеосигнала (а на VSync там всё измерение времени завязано). Сделав умное сканирование таким образом программа может понять, что работает из гипервизора (ну т.е. в эмуляторе) и отказаться работать как средство борьбы с пиратскими копиями.
