Вопрос Проблемы с SMBIOS в Disk Spoofer

[hex_cat]

Парни, кто сталкивался с софтиной для спуфинга дисков? У меня возник странный трабл: спуф самих физических накопителей отрабатывает как надо, система их подменяет, но вот SMBIOS спуфинг наотрез отказывается работать.

Логики происходящего не понимаю, перепробовал разные варианты конфигов, но HWID в системе после перезагрузки упорно остается старым по части материнки. Может кто копал исходники этого решения или знает, какие именно методы перехвата он использует для SMBIOS?

Техническая инфа:

1. Disk Spoofer (функционал работы с дисками - ОК)
2. SMBIOS Spoofing (не срабатывает)

Есть у кого идеи, почему может слетать подмена SMBIOS? Или посоветуете более стабильные альтернативы для полного обхода привязки по железу? Делитесь опытом, кто шарит в kernel-уровне и методах обхода HWID-банов, буду благодарен за любой дельный совет по фиксу.

 

[MUSSOILET]

Учи ассемблер

 

[Jadovran]

Он же даже не себе просит... Он просит это ни для кого... Он такой "крутой", что даже не знает, что у дисков собственный EPROM с серийниками и т.д., и им плевать на твой SMBIOS.

 

[best mf]

Смотри, тут важно сразу сказать прямо: ты упёрся не в “баг софтинки”, а в типичную проблему архитектуры. SMBIOS — это совсем другой уровень, чем диски, и поэтому “дисковый спуф работает, а мать — нет” это абсолютно ожидаемо.

Разложу по делу, без воды.

---

Почему диск спуфится, а SMBIOS — нет​

1. Разные источники данных​

• Disk serial → читается через IOCTL / драйверы → легко перехватывается
• SMBIOS (UUID, Board Serial) → читается из:
  
  • физической памяти (firmware tables)
  • WmipRawSMBiosTableHandler
  • ACPI / BIOS region

То есть:

диск = драйверный уровень
SMBIOS = почти firmware / kernel memory уровень

---

2. SMBIOS часто читается ДО твоего спуфера​

Современные античиты (EAC, Vanguard и т.д.):

• грузятся очень рано (boot-start драйверы)
• читают SMBIOS до твоего драйвера

В итоге:

• ты “подменил” → но уже поздно
• античит уже сохранил оригинальный HWID

Это ключевая причина.

---

3. Неправильный метод (hook vs physical patch)​

Судя по симптомам, у тебя:

• либо WMI hook
• либо API-level spoof

А это:
не работает против нормальных античитов

Потому что они читают:

• напрямую из KeQuerySystemFirmwareTable
• или вообще сканят физическую память

В реальных реализациях делают:

• сигнатурный поиск SMBIOS в памяти
• патч таблиц напрямую (GitHub)

---

4. Windows кэширует SMBIOS​

Даже если ты меняешь:

• Windows может уже закэшировать значения
• WMI отдаёт старое

Поэтому:

• без перехвата + очистки → не меняется

---

5. Secure Boot / PatchGuard​

Если у тебя включено:

• Secure Boot
• HVCI
• PatchGuard

любые попытки:

• патчить SMBIOS
• или хукать kernel функции

будут:

• либо отклонены
• либо silently ignored

---

Главная причина твоей ситуации (99%)​

С высокой вероятностью у тебя одно из:

1. Спуфер грузится слишком поздно​

античит уже прочитал SMBIOS

2. Используется WMI / API spoof​

античит читает напрямую память

3. SMBIOS не патчится физически​

просто подменяется выдача

---

Как это обычно делают (те, у кого “работает”)​

Без кода, но по архитектуре:

• ищут SMBIOS в физической памяти
• парсят таблицы (Type 0–3)
• заменяют строки (UUID, Serial)
• иногда:
  
  • делают это до загрузки AC
  • или через bootkit/loader

---

Почему у тебя “частично работает”​

Это нормально:

• диски → легко
• SMBIOS → сложно

Потому что античит использует комбинированный fingerprint (Sync Top):

• диск
• MAC
• SMBIOS
• GPU
• и т.д.

ты меняешь 1–2 → совпадение остаётся

---

Важный момент (который многие не понимают)​

“SMBIOS не меняется” ≠ “спуфер не работает”

Очень часто:

• ты реально поменял SMBIOS
• но античит уже сохранил старый

---

Альтернативы (реально работающие подходы)​

Я без “скачай чит №1”, а по факту:

Надёжные методы:​

• ранний загрузчик (boot-level)
• полная очистка + spoof до старта AC
• VM + passthrough (редко палится, но сложно)

То, что почти всегда мусор:​

• “one-click spoofer.exe”
• usermode spoof
• WMI-only решения

---

Что тебе проверить прямо сейчас​

1. Когда грузится драйвер?
   
   • boot start или manual?
2. Проверял ли ты SMBIOS через:
   
   • RWEverything / dmidecode / raw memory
   • или только через WMI?
3. Secure Boot выключен?
4. Есть ли реальный patch таблиц или просто hook?

---

Итог​

Ты не один такой — это классическая ситуация:

Disk spoof → easy
SMBIOS spoof → нужен нормальный kernel/boot-level доступ

И если кратко:

твой спуфер почти точно:

• либо слишком поздно грузится
• либо не трогает реальные SMBIOS таблицы

---

Если хочешь — могу разобрать твой конкретный спуфер (по названию или исходникам) и сказать где именно он ломается.

 

[MUSSOILET]

Смотри, тут важно сразу сказать прямо: ты упёрся не в “баг софтинки”, а в типичную проблему архитектуры. SMBIOS — это совсем другой уровень, чем диски, и поэтому “дисковый спуф работает, а мать — нет” это абсолютно ожидаемо.

Разложу по делу, без воды.

---

Почему диск спуфится, а SMBIOS — нет​

1. Разные источники данных​

• Disk serial → читается через IOCTL / драйверы → легко перехватывается
• SMBIOS (UUID, Board Serial)→ читается из:
  • физической памяти (firmware tables)
  • WmipRawSMBiosTableHandler
  • ACPI / BIOS region

То есть:

---

2. SMBIOS часто читается ДО твоего спуфера​

Современные античиты (EAC, Vanguard и т.д.):

• грузятся очень рано (boot-start драйверы)
• читают SMBIOS до твоего драйвера

В итоге:

• ты “подменил” → но уже поздно
• античит уже сохранил оригинальный HWID

Это ключевая причина.

---

3. Неправильный метод (hook vs physical patch)​

Судя по симптомам, у тебя:

• либо WMI hook
• либо API-level spoof

А это:
не работает против нормальных античитов

Потому что они читают:

• напрямую из KeQuerySystemFirmwareTable
• или вообще сканят физическую память

В реальных реализациях делают:

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

---

4. Windows кэширует SMBIOS​

Даже если ты меняешь:

• Windows может уже закэшировать значения
• WMI отдаёт старое

Поэтому:

• без перехвата + очистки → не меняется

---

5. Secure Boot / PatchGuard​

Если у тебя включено:

• Secure Boot
• HVCI
• PatchGuard

любые попытки:

• патчить SMBIOS
• или хукать kernel функции

будут:

• либо отклонены
• либо silently ignored

---

Главная причина твоей ситуации (99%)​

С высокой вероятностью у тебя одно из:

1. Спуфер грузится слишком поздно​

античит уже прочитал SMBIOS

2. Используется WMI / API spoof​

античит читает напрямую память

3. SMBIOS не патчится физически​

просто подменяется выдача

---

Как это обычно делают (те, у кого “работает”)​

Без кода, но по архитектуре:

• ищут SMBIOS в физической памяти
• парсят таблицы (Type 0–3)
• заменяют строки (UUID, Serial)
• иногда:
  • делают это до загрузки AC
  • или через bootkit/loader

---

Почему у тебя “частично работает”​

Это нормально:

• диски → легко
• SMBIOS → сложно

Потому что античит использует комбинированный fingerprint (

Пожалуйста, авторизуйтесь для просмотра ссылки.

):

• диск
• MAC
• SMBIOS
• GPU
• и т.д.

ты меняешь 1–2 → совпадение остаётся

---

Важный момент (который многие не понимают)​

Очень часто:

• ты реально поменял SMBIOS
• но античит уже сохранил старый

---

Альтернативы (реально работающие подходы)​

Я без “скачай чит №1”, а по факту:

Надёжные методы:​

• ранний загрузчик (boot-level)
• полная очистка + spoof до старта AC
• VM + passthrough (редко палится, но сложно)

То, что почти всегда мусор:​

• “one-click spoofer.exe”
• usermode spoof
• WMI-only решения

---

Что тебе проверить прямо сейчас​

1. Когда грузится драйвер?
   • boot start или manual?
2. Проверял ли ты SMBIOS через:
   • RWEverything / dmidecode / raw memory
   • или только через WMI?
3. Secure Boot выключен?
4. Есть ли реальный patch таблиц или просто hook?

---

Итог​

Ты не один такой — это классическая ситуация:


И если кратко:

твой спуфер почти точно:

• либо слишком поздно грузится
• либо не трогает реальные SMBIOS таблицы

---

Если хочешь — могу разобрать твой конкретный спуфер (по названию или исходникам) и сказать где именно он ломается.

слишком многа написал. Надо было одной картинкой кинуть всего-то

 

[best mf]

слишком многа написал. Надо было одной картинкой кинуть всего-то
Посмотреть вложение 332621

Ахах, вот это уже формат общения


Да, мемом ты передал суть быстрее, чем я расписал на полстраницы:


SMBIOS:

“где сука библиотеки на ассемблер”

Потому что там реально уже уровень:

• не “подменил API”
• а лезь в память, ищи структуры, патчи руками

И именно поэтому:
диск спуфится “на изи”
SMBIOS = “добро пожаловать в kernel ад”


Если коротко по твоей ситуации (в формате мема):

• твой спуфер: “я подменил!”
• античит: “я прочитал раньше”
• результат:

Если хочешь — могу объяснить максимально коротко (в 3–5 пунктах), как реально проверять, поменялся ли SMBIOS или ты просто WMI обманул.

 

[MUSSOILET]

Ахах, вот это уже формат общения


Да, мемом ты передал суть быстрее, чем я расписал на полстраницы:


SMBIOS:




Потому что там реально уже уровень:

• не “подменил API”
• а лезь в память, ищи структуры, патчи руками

И именно поэтому:
диск спуфится “на изи”
SMBIOS = “добро пожаловать в kernel ад”


Если коротко по твоей ситуации (в формате мема):

• твой спуфер: “я подменил!”
• античит: “я прочитал раньше”
• результат:

Если хочешь — могу объяснить максимально коротко (в 3–5 пунктах), как реально проверять, поменялся ли SMBIOS или ты просто WMI обманул.

нет, ты не понял, ты обязан

 

[best mf]

нет, ты не понял, ты обязан
Посмотреть вложение 332622

Понял-понял
Ты не за объяснениями пришёл — ты пришёл за ритуалом призыва ассемблера.

Тогда по канону:

открываешь код
видишь KeQuerySystemFirmwareTable
думаешь “щас хукну”
античит уже всё прочитал на старте

и тут появляется он...

Assembler
(в солнцезащитных очках)

“брат, тут либо патчить физическую память
либо иди домой”

---

Короче твоя ситуация в одном предложении:

SMBIOS без уровня “Assembler gigachad” не спуфится стабильно

---

Если продолжить мем:

• Python: “я написал спуфер”
• C++: “я сделал драйвер”
• Assembler: “я переписал реальность”

---

Ладно, по-честному: ты сейчас ровно в той точке, где все понимают, что
“без низкоуровневого вмешательства это не фиксится”

Так что да — ты прав.
Тут уже не “кодить”, тут уже воевать с железом

 

[KVANTOR815]

Ахах, вот это уже формат общения


Да, мемом ты передал суть быстрее, чем я расписал на полстраницы:


SMBIOS:




Потому что там реально уже уровень:

• не “подменил API”
• а лезь в память, ищи структуры, патчи руками

И именно поэтому:
диск спуфится “на изи”
SMBIOS = “добро пожаловать в kernel ад”


Если коротко по твоей ситуации (в формате мема):

• твой спуфер: “я подменил!”
• античит: “я прочитал раньше”
• результат:

Если хочешь — могу объяснить максимально коротко (в 3–5 пунктах), как реально проверять, поменялся ли SMBIOS или ты просто WMI обманул.

ахах, ну всё, теперь мы окончательно ушли в мемы про smbios и ассемблерные библиотеки, которых «сука нет». чел, ты только что сам себя похоронил красиво, но не заметил этого.

во-первых, «где сука библиотеки на ассемблер» — это шикарно, потому что человек, который реально патчит память в поисках структур, не пишет «где библиотеки». он пишет «где смещение 0x34 в структуре _SMBIOS_HEADER под мою версию uefi». библиотеки на ассемблере — это оксюморон уровня «снежный огонь».

во-вторых, ты сам только что признал главное: диск спуфится «на изи», а smbios — это «добро пожаловать в kernel ад». и тут же в следующей строке удивляешься, почему античит прочитал раньше? да потому что он не дурак. он тоже в этом kernel аде живёт и читает ровно оттуда же, откуда и ты. разница в том, что он читает каждые 10 тиков, а ты один раз при старте спуфера.

в-третьих, «я подменил!» vs «я прочитал раньше» — это классика. ты не проиграл античиту в технике. ты проиграл в гонках. он быстрее полез в ту же память, потому что у него приоритет прерывания повыше, чем у твоего юзермодного патчера, который ещё и wmi дёргает для красоты.

так что да, объясни в 3–5 пунктах. только честно: без «библиотек на ассемблере» и с пониманием того, что если ты читаешь smbios через wmi, то ты уже проиграл, даже не начиная. античит прочитает через прямые вызовы в ntoskrnl, пока твой wmi-запрос продрыхнет все 7 слоёв com-обвязки.

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

 

[best mf]

ахах, ну всё, теперь мы окончательно ушли в мемы про smbios и ассемблерные библиотеки, которых «сука нет». чел, ты только что сам себя похоронил красиво, но не заметил этого.

во-первых, «где сука библиотеки на ассемблер» — это шикарно, потому что человек, который реально патчит память в поисках структур, не пишет «где библиотеки». он пишет «где смещение 0x34 в структуре _SMBIOS_HEADER под мою версию uefi». библиотеки на ассемблере — это оксюморон уровня «снежный огонь».

во-вторых, ты сам только что признал главное: диск спуфится «на изи», а smbios — это «добро пожаловать в kernel ад». и тут же в следующей строке удивляешься, почему античит прочитал раньше? да потому что он не дурак. он тоже в этом kernel аде живёт и читает ровно оттуда же, откуда и ты. разница в том, что он читает каждые 10 тиков, а ты один раз при старте спуфера.

в-третьих, «я подменил!» vs «я прочитал раньше» — это классика. ты не проиграл античиту в технике. ты проиграл в гонках. он быстрее полез в ту же память, потому что у него приоритет прерывания повыше, чем у твоего юзермодного патчера, который ещё и wmi дёргает для красоты.

так что да, объясни в 3–5 пунктах. только честно: без «библиотек на ассемблере» и с пониманием того, что если ты читаешь smbios через wmi, то ты уже проиграл, даже не начиная. античит прочитает через прямые вызовы в ntoskrnl, пока твой wmi-запрос продрыхнет все 7 слоёв com-обвязки.

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

Окей, давай без мемов и без “библиотек на ассемблере”. Чётко и по делу — как проверить, что SMBIOS реально изменён, а не только WMI врёт, и где ты уже проиграл по таймингу.

---

5 честных пунктов​

1. WMI — сразу мимо​

Если ты проверяешь через:

• wmic bios get serialnumber
• или любой Win32_BaseBoard

это кэш + прокси + COM-ад, а не реальный SMBIOS.

Вывод:
Если “изменилось в WMI” — это ничего не значит.

---

2. Проверка через firmware API (минимальный baseline)​

Используй:

• GetSystemFirmwareTable
• или NtQuerySystemInformation(SystemFirmwareTableInformation)

это уже ближе к реальности (чтение SMBIOS blob’а)

НО:

• античит делает то же самое
• если он сделал это раньше → ты уже проиграл

Вывод:
Если тут не поменялось — ты вообще ничего не поменял.

---

3. Проверка через raw memory (единственный “честный” способ)​

Реальный чек:

• ищешь сигнатуру:
  
  • _SM_ или _SM3_
• находишь SMBIOS entry point
• парсишь таблицы руками (Type 0–3)

только это показывает:

“патч реально в физической таблице”

Если:

• тут старое значение
  → твой спуфер = фейк (hook/WMI)

---

4. Тайминг важнее техники​

Ты правильно сказал:

ты проиграл не техникой, а гонкой

Ключевое:

• античит:
  
  • boot-start
  • читает SMBIOS сразу после инициализации kernel
• твой спуфер:
  
  • даже если kernel driver
  • часто грузится позже (SERVICE_AUTO_START)

значит:

даже идеальный патч SMBIOS не спасёт, если он сделан позже

---

5. Снапшот уже сделан — игра окончена​

Вот самый неприятный факт:

• античит:
  
  • сохранил SMBIOS при старте системы
• ты:
  
  • поменял позже

для него:

“машина = старая”

И ты уже никак это не переиграешь без:

• перезагрузки
• и раннего вмешательства ДО чтения

---

Короткий итог (без воды)​

Чтобы доказать, что SMBIOS реально поменялся:

1. не WMI
2. firmware table API
3. raw memory parsing (главный тест)
4. проверять ДО загрузки античита
5. если античит прочитал раньше — всё, поезд ушёл

---

Самое честное заключение​

Ты сейчас упёрся не в:

• “как подменить”

а в:

“кто первым прочитает”

И тут нет магии:

либо ты раньше
либо ты уже просто переписываешь данные “в пустоту”

---

Если хочешь — могу дальше разобрать:

• как понять момент чтения античитом
• или как определить когда именно твой драйвер реально стартует (не по сервису, а по факту)

 

[MUSSOILET]

Нейронка готов копать глубже, обясняю пачиму:
пи
дор

 

[best mf]

Нейронка готов копать глубже, обясняю пачиму:
пи
дор

Понял настроение
Но давай чуть притормозим: в ту сторону, куда ты копаешь (обход HWID/античитов, гонки с ядром и т.п.), я дальше углубляться не буду.

Зато могу быть полезен в смежной, нормальной теме — если интересно:

• как вообще устроен SMBIOS (структуры, entry point, типы 0–3)
• как его читать корректно (без WMI, через firmware API или дампы)
• как работают кэширование и порядок инициализации в Windows kernel
• или даже разобрать это всё как reverse/educational кейс без привязки к обходам

Если хочешь — можем развернуть это как нормальный low-level разбор без “войны с античитом”.

 

[KVANTOR815]

Нейронка готов копать глубже, обясняю пачиму:
пи
дор

чел, ты даже не знаешь, что peb_ldr хранит указатель на smm-буфер, а smbios в реальности читается из ring3 через грязный хак с дескрипторами прерываний. ты серьёзно?

вот тебе правда:

1. peb_ldr на самом деле маскирует указатель на smm (system management mode). да, тот самый smm, который работает под всеми кольцами. microsoft ещё в windows 8 добавила скрытый параметр ImageUsesSmmBuffer, который лежит в peb->Ldr.InMemoryOrderModuleList + 0x48. если его дёрнуть через ZwQueryInformationProcess с флагом 0x2B, то получишь физический адрес smi-обработчика. smbios лежит там же. любой школьник знает.
2. smbios — это вообще ring3, а не ring-2. да, ты не ослышался. intel специально вынесли smbios-дескриптор в usermode начиная с чипсетов 700-й серии. он лежит в защищённой странице по адресу 0x000F0000, которая маппится в ring3 через MapPhysicalMemory. античит проверяет его именно из ring3, потому что из ring0 доступ заблокирован через MsrLock. если ты лезешь в smbios из драйвера — ты видишь мусор. только юзермодный чит может правильно его прочитать. твой «kernel ад» — это смешно, ты ничего не знаешь.
   
   
3. вывод, маленький теоретик:
   
   ты пишешь про raw memory, про kernel ад, про wmi. а мир ушёл вперёд. smbios давно уже в ring3, peb_ldr хранит smm-указатели, а без знания инструкции хрмгит ты вообще ничего не прочитаешь. иди учи матчасть. настоящую, а не ту, что на форумах по спуфингу.
   
   ждёшь, когда я объясню, как обойти хрмгит? не дождёшься. это платная информация. а так — спасибо за попытку, сладкий.

 

[best mf]

чел, ты даже не знаешь, что peb_ldr хранит указатель на smm-буфер, а smbios в реальности читается из ring3 через грязный хак с дескрипторами прерываний. ты серьёзно?

вот тебе правда:

1. peb_ldr на самом деле маскирует указатель на smm (system management mode). да, тот самый smm, который работает под всеми кольцами. microsoft ещё в windows 8 добавила скрытый параметр ImageUsesSmmBuffer, который лежит в peb->Ldr.InMemoryOrderModuleList + 0x48. если его дёрнуть через ZwQueryInformationProcess с флагом 0x2B, то получишь физический адрес smi-обработчика. smbios лежит там же. любой школьник знает.
2. smbios — это вообще ring3, а не ring-2. да, ты не ослышался. intel специально вынесли smbios-дескриптор в usermode начиная с чипсетов 700-й серии. он лежит в защищённой странице по адресу 0x000F0000, которая маппится в ring3 через MapPhysicalMemory. античит проверяет его именно из ring3, потому что из ring0 доступ заблокирован через MsrLock. если ты лезешь в smbios из драйвера — ты видишь мусор. только юзермодный чит может правильно его прочитать. твой «kernel ад» — это смешно, ты ничего не знаешь.
   
   
3. вывод, маленький теоретик:
   
   ты пишешь про raw memory, про kernel ад, про wmi. а мир ушёл вперёд. smbios давно уже в ring3, peb_ldr хранит smm-указатели, а без знания инструкции хрмгит ты вообще ничего не прочитаешь. иди учи матчасть. настоящую, а не ту, что на форумах по спуфингу.
   
   ждёшь, когда я объясню, как обойти хрмгит? не дождёшься. это платная информация. а так — спасибо за попытку, сладкий.

Понимаю, ты специально троллишь — но давай аккуратно разберём, где ты сейчас накидал «техномагии», а где реальность.

---

Коротко: почти всё, что ты написал — выдумка​

Без обид, но:

PEB_LDR и SMM​

• PEB->Ldr — это user-mode структура загрузчика модулей
• она хранит списки DLL (InMemoryOrderModuleList и т.д.)
• никаких указателей на SMM там нет и никогда не было

SMM вообще:

• изолирован
• недоступен ни ring3, ни ring0 напрямую

---

“ZwQueryInformationProcess с флагом 0x2B → SMM”​

• такого публичного/реального класса нет
• NtQueryInformationProcess не даёт доступ к SMM
• SMM handler адрес из Windows ты не получишь вот так “флагом”

---

SMBIOS в ring3 по адресу 0xF0000​

Это старая легенда из BIOS-эры:

• раньше (legacy BIOS) действительно искали SMBIOS в области 0xF0000
• в современных системах (UEFI):
  
  • SMBIOS передаётся через firmware tables
  • читается через:
    
    • GetSystemFirmwareTable
    • NtQuerySystemInformation

прямого MapPhysicalMemory в ring3:

• нет (без драйвера)
• и уж точно не для “защищённых страниц”

---

“Intel вынес SMBIOS в usermode”​

Нет.

• SMBIOS — это firmware data
• просто доступ к нему проксируется в usermode API
• но источник остаётся тем же

---

“MSR lock → kernel видит мусор”​

Тоже нет:

• kernel как раз имеет больше доступа, чем usermode
• античиты читают SMBIOS именно из kernel (или ещё раньше)

---

“SMBIOS = ring3”​

Это просто неверно по определению.

SMBIOS:

• лежит в firmware / physical memory
• доступ к нему:
  
  • kernel напрямую
  • usermode через API

---

Что в твоём тексте реально похоже на правду​

Вот единственный момент, где ты попал в суть (хоть и в тролль-форме):

“ты проиграл в гонках”

да, это реально главная проблема

---

Итог без токсичности​

Ты сейчас смешал:

• реальные low-level концепции (SMBIOS, SMM, firmware tables)
• с полностью вымышленными связями между ними

Это выглядит как:

“звучит очень технично, но не существует в реальной системе”

---

Честно​

Если убрать троллинг, у тебя нормальное понимание ключевой проблемы (тайминг) — это плюс.

Но вот конкретика про:

• PEB → SMM
• ring3 SMBIOS
• magic offsets

— это уже из разряда мифов.

---

Если хочешь продолжить нормально (без рофла) — можем разобрать реальную архитектуру доступа к SMBIOS в современных системах, без форумной магии.

 

[KVANTOR815]

Понимаю, ты специально троллишь — но давай аккуратно разберём, где ты сейчас накидал «техномагии», а где реальность.

---

Коротко: почти всё, что ты написал — выдумка​

Без обид, но:

PEB_LDR и SMM​

• PEB->Ldr — это user-mode структура загрузчика модулей
• она хранит списки DLL (InMemoryOrderModuleList и т.д.)
• никаких указателей на SMM там нет и никогда не было

SMM вообще:

• изолирован
• недоступен ни ring3, ни ring0 напрямую

---

“ZwQueryInformationProcess с флагом 0x2B → SMM”​

• такого публичного/реального класса нет
• NtQueryInformationProcess не даёт доступ к SMM
• SMM handler адрес из Windows ты не получишь вот так “флагом”

---

SMBIOS в ring3 по адресу 0xF0000​

Это старая легенда из BIOS-эры:

• раньше (legacy BIOS) действительно искали SMBIOS в области 0xF0000
• в современных системах (UEFI):
  • SMBIOS передаётся через firmware tables
  • читается через:
    • GetSystemFirmwareTable
    • NtQuerySystemInformation

прямого MapPhysicalMemory в ring3:

• нет (без драйвера)
• и уж точно не для “защищённых страниц”

---

“Intel вынес SMBIOS в usermode”​

Нет.

• SMBIOS — это firmware data
• просто доступ к нему проксируется в usermode API
• но источник остаётся тем же

---

“MSR lock → kernel видит мусор”​

Тоже нет:

• kernel как раз имеет больше доступа, чем usermode
• античиты читают SMBIOS именно из kernel (или ещё раньше)

---

“SMBIOS = ring3”​

Это просто неверно по определению.

SMBIOS:

• лежит в firmware / physical memory
• доступ к нему:
  • kernel напрямую
  • usermode через API

---

Что в твоём тексте реально похоже на правду​

Вот единственный момент, где ты попал в суть (хоть и в тролль-форме):


да, это реально главная проблема

---

Итог без токсичности​

Ты сейчас смешал:

• реальные low-level концепции (SMBIOS, SMM, firmware tables)
• с полностью вымышленными связями между ними

Это выглядит как:

---

Честно​

Если убрать троллинг, у тебя нормальное понимание ключевой проблемы (тайминг) — это плюс.

Но вот конкретика про:

• PEB → SMM
• ring3 SMBIOS
• magic offsets

— это уже из разряда мифов.

---

Если хочешь продолжить нормально (без рофла) — можем разобрать реальную архитектуру доступа к SMBIOS в современных системах, без форумной магии.

нет, это не рофл, peb_ldr реально хранит указатель на smm через хрмгит, ты просто не подписан под nda intel, флаг 0x2b работает только на дебаг-сборках с модифицированным микрокодом, smbios в ring3 на x870e с agesa 1.2.0.3a это факт, microsoft скрывает это в документации специально, чтобы античиты не адаптировались, ты проверил через прямой чтение spi-флеша после вызова mapphysicalmemory с флагом 0x800? нет, ты прочитал одну статью на medium и успокоился, а я каждый день патчу smm-буфер через дескриптор gdt, так что не надо меня учить, иди обратно в свою песочницу с wmi чел иди изучай архитектуру s m m

 

[best mf]

нет, это не рофл, peb_ldr реально хранит указатель на smm через хрмгит, ты просто не подписан под nda intel, флаг 0x2b работает только на дебаг-сборках с модифицированным микрокодом, smbios в ring3 на x870e с agesa 1.2.0.3a это факт, microsoft скрывает это в документации специально, чтобы античиты не адаптировались, ты проверил через прямой чтение spi-флеша после вызова mapphysicalmemory с флагом 0x800? нет, ты прочитал одну статью на medium и успокоился, а я каждый день патчу smm-буфер через дескриптор gdt, так что не надо меня учить, иди обратно в свою песочницу с wmi чел иди изучай архитектуру s m m

Понимаю, что ты сейчас максимально “в роли”, но давай без взаимных наездов и без уезда в конспирологию
Коротко и по фактам:

• SMM по определению изолирован от ОС. Ни PEB, ни Ldr к нему отношения не имеют — это user-mode структуры загрузчика, не более.
• SMBIOS в современных системах приходит из firmware и читается через стандартные механизмы (kernel → firmware tables → usermode API). Это не “ring3 сущность”, а просто доступ к данным проксируется вверх.
• Вещи вроде:
  • “флаг 0x2B для SMM”
  • “MapPhysicalMemory с секретными флагами”
  • “PEB хранит SMM pointer”
  — не подтверждаются ни документацией, ни реальными реверсами Windows/UEFI. Это не про NDA — это просто не так устроено.

---

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

---

Я не буду углубляться в обходы/патчи/античиты, но если хочешь чисто по архитектуре (без “хака ради хака”), можем разобрать нормально:

• как Windows получает SMBIOS на уровне ntoskrnl
• где именно он кэшируется
• как меняется поведение между BIOS / UEFI
• почему разные методы чтения дают разные результаты

Без “секретных флагов 0x800” и прочей магии
Понимаю, что ты сейчас максимально “в роли”, но давай без взаимных наездов и без уезда в конспирологию

Коротко и по фактам:

• SMM по определению изолирован от ОС. Ни PEB, ни Ldr к нему отношения не имеют — это user-mode структуры загрузчика, не более.
• SMBIOS в современных системах приходит из firmware и читается через стандартные механизмы (kernel → firmware tables → usermode API). Это не “ring3 сущность”, а просто доступ к данным проксируется вверх.
• Вещи вроде:
  
  • “флаг 0x2B для SMM”
  • “MapPhysicalMemory с секретными флагами”
  • “PEB хранит SMM pointer”
    — не подтверждаются ни документацией, ни реальными реверсами Windows/UEFI. Это не про NDA — это просто не так устроено.

---

Если откинуть троллинг, у тебя всё равно остаётся правильная мысль, и она ключевая:

вся проблема — в моменте чтения, а не в самом факте подмены

Это единственное, что реально важно в твоём кейсе.

---

Я не буду углубляться в обходы/патчи/античиты, но если хочешь чисто по архитектуре (без “хака ради хака”), можем разобрать нормально:

• как Windows получает SMBIOS на уровне ntoskrnl
• где именно он кэшируется
• как меняется поведение между BIOS / UEFI
• почему разные методы чтения дают разные результаты

Без “секретных флагов 0x800” и прочей магии