Дмитрий

1. Брутфорс пароля не имеет смысла. Это слишком долго и затратно. Перебор минимального восьмизначного пароля это 6634204312890625 комбинаций, на современном железе это займёт тысячи лет.
2. Правильно он ответил. Перебирать на самом роутере это 1 комбинация в несколько секунд. Перебор хеша -- сотни тысяч комбинаций в секунду. И даже с такой скоростью это занимает десятки и сотни лет.
3. Смотря какой стандарт. Их там десятки. Ни в одном из них не передаётся пароль, это не имеет смысла. Стандарт для пользователей называется WPA2-PSK. Если бы ты не спрашивал у статистической модели, а просто погуглил, нашёл бы перевод этой аббревиатуры. PSK значит Pre-Shared Key. Pre-shared значит, что он заранее известен, зачем его передавать, если оба его знают? Достаточно просто статью открыть на википедии и почитать. Там всё расписано как и что происходит.

MITM не особо работает с отличным от HTTP/HTTPS протоколом

HTTPS и TLS это одно и то же, а в TLS ничего нового не придумано, и mitm как был рабочим, таким и остаётся.

Чтобы осуществить его, нужно отвязать клиент от Certificate Pinning. Для этого нужно провести реверс-инжиниринг приложения, найти место, где происходит проверка подписи сертификата и запатчить место статически либо динамически.

Близзард сейчас использует протобаф и собирать байты вручную не самое приятное и долгоиграющие решение.

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

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

Проходиться по Юникодным кодпоинтам и фильтровать по категории.

Нажми Cmd+Shift+P.
Там напиши c++ edit config, выбери пункт C/C++: Edit Configurations (UI).
Там внизу найди C++ standard и выбери c++23.

Учить ассемблер и писать свою ОС это примерно как учиться сварке и строить космический корабль.
Ассемблер это только 1% от всего, что нужно изучить.
Тебе нужно решить кучу архитектурных проблем сначала, а потом уже думать о графике.

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

Поставь питон через pyenv.

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

Питон в brew тоже довольно кривоват и нужно много с бубном плясать вокруг него, чтобы заставить адекватно работать с pip.

Прочитать с диска в память и передать управление?

Миллион статей в интернетах с девяностых годов же.
https://wiki.osdev.org/Rolling_Your_Own_Bootloader хотя бы посмотри.

Через int 13 читай следующий сектор и передавай управление через jump.

Плюсы и гуй в 2024-м это уже не смешно.

Графические интерфейсы на плюсах развиваются сейчас как полудолхая кляча. Баги по 15 лет не могут пофиксить в Кьюте, который тебе советуют. К тому же, Qt был на плюсах лет так 15 назад. Сейчас там всё на QML пишется и чистые плюсы самой компанией уже давно не поощряются. Нужно понять главное: каждой задаче -- свой инструмент. Если будешь писать такую программу на плюсах, будешь страдать. Много страдать. Не начало нулевых так-то, уже столько всего под эти задачи есть удобного, что стоило бы изучить эту сферу.

Например, посмотри на Flutter. Очень приятный у шустрый фреймворк для создания графических приложений. Язык Dart учится с нуля за 2-3 дня. Написал на одном языке один раз, а работать это всё будет начиная от мобил и ПК, заканчивая вебом, Raspberry Pi, бортовым компьютером Теслы и Тойоты, телевизорами, фоторамками и прочими экзотическими устройствами.

C++ сейчас учить нужно только для общего развития, писать на нём новые проекты не советую. Есть множество современных, куда более адекватных и не таких затратных по времени и силам языков, как Rust -- отличная замена C++, Zig -- крутая замена Си.

Ну он же чёрным по белому пишет:

Bad Request: strings must be encoded in UTF-8

Кодируй строку в UTF-8 и отправляй.

Самый адекватный способ использования сетевых устройств:
Оставлять наружу только SSH, а через него пробрасывать локально необходимые порты хоть с шифрованием, хоть без него.

Конечно разница есть. Не просто ж так вкладывают сотни миллиардов в исследования.
Даже если взять 2 процессора одинаковой частоты и с одинаковым количеством ядер, будет множество отличий.

1. Существует конвеер исполнения инструкций. Который состоит из портов выполнения. С каждым новым поколением процессора этот конвеер допиливают. Улучшают синхронизации кешей, меняют в целом принцип работы кешей и порядок выполнения инструкций. Добавляют новые порты. Перепиливают микрокод для инструкций, используя эти изменения.
2. Переупорядочивание выполнения инструкций. Каждый новый проц что-то да делает с этим. Улучшают сам алгоритм переупорядочивания, избавления потоков выполнения от лишних зависимостей данных, увеличивают внутренние буферы, используемые для этих целей. В итоге растёт retired instruction per clock.
3. Предсказатели переходов постоянно совершенствуются, меньше тупняков конвеера дают, меньше сбросов кеша.
4. Декодер инструкций. Fetch-буфер растёт, буфер декодинга растёт, буфер переупорядочивания растёт.
5. Интерфейсы взаимодействия с памятью тоже совершенствуются. Одноканальный DDR из 2003-го, который требует отдельного контроллера памяти на северном мосту, и мноканальный DDR6 из 2025-го -- мягко говоря, вещи из разных миров. Не только память должна быть быстрой, но и процессор должен уметь общаться с этой памятью. В конце нулевых контроллер памяти начали встраивать в сам процессор, это позволило снизить задержки доступа к памяти в разы.

А ещё много-много тонкостей, которые не афишируются публично и держатся в коммерческой тайне.

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

Не нужна никакая защита, если у тебя на сервере вся логика, а клиент просто рисует карты и анимации.

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

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

Есть 2 варианта:
1) Реверсить игру, инжектиться в память, вытаскивать внутренние структуры и использовать их для бота.
2) Писать на машинном зрении систему уровня автопилота Теслы.

В первом варианте нужно потратить несколько тысяч человеко-часов на реверс игры, извлечение нужных ресурсов и написание самой системы. Нужно знать как работают ОС на низком уровне, отлично знать реверс-инжиниринг.

Во втором: обмазаться лекциями каких-нибудь классических профессоров по этой тематике, тех же Andrew Ng и Sebastian Thrun. Изучить, как делается примитивный автопилот на машинном зрении, и пытаться применить его в боте.

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

К чёрту плюсы. Это гавно мамонта только на легаси поддержке сейчас остаётся у бородатых дедов. Учи Раст. На него переходит большинство адекватных команд. Язык в разы приятнее и эффективнее. Писать на нём в 5 раз быстрее, чем на плюсах. Спецификация не на 5 тысяч страниц, а от силы 500 не наберётся.

У тебя другая проблема: язык это инструмент. Ты нашёл молоток и ищешь гвозди. А когда в руках молоток, всё кажется гвоздём.
Сначала пойми, что тебе интересно. Какая сфера и область разработки. Пет-проекты нужно делать для себя. Никто за тебя их не придумает. Когда нет идей в голове, всё равно какой язык учить, если он не пригодится.

В WebAssembly изначально изолированная среда для исполнения. Он ничего не знает про DLL и вообще что-то за пределами модулей.
Браузеры тоже пишутся так, чтобы никакие левые дллки не могли вмешиваться в процесс их работы и делать, что хотят.

Единственный вариант -- это тяжёлый реверс браузера и инжект дллки и кода в рантайм.

Адекватно отлаживать код можно только на той платформе, для которой он пишется. Иначе никак.
C++ -- он и в Африке C++. Можно писать хоть в блокноте, главное тулчейн, которым он собирается. А у C++ с кросскомпиляцией всё не так уж радужно на практике, как это рисуют в теории.

Смотря для какого API вы писать хотите, для какой системы. Например, в Убунте тулчейны более древние, чем в Арче. Это накладывает весомый отпечаток на боль, которую придётся испытывать в разработке и отладке.

при работе по SSH некорректно работают практически все функции glut

При работе по ssh вообще сложно пробросить графический сервер, чтобы он работал адекватно. А ещё есть как минимум X и Wayland. У них разные методы удалённой отладки будут.

Проще будет VNC поднять и отлаживать таким образом, чем городить костыли.
И, как уже сказала копи-паста из бота, используйте GLFW или SDL, они намного проще собираются и отлаживаются, чем говно мамонта под названием GLUT.

При конвертации видео, аудио-поток вообще не трогается, а остаётся тем же, максимум ремуксится. Значит вы неверный параметр передаёте.

ощущение

какое может быть ощущение, если у вас под рукой ffmpeg, который всю досконально информацию по потоку даст вместо ваших "ощущений"? Сравните характеристики потока до и после транскодирования и избавитесь от сомнительных ощущений.

Банальный параметр -codec:a copy должен помочь в большинстве случаев.