Дмитрий

Если вам нужно быстро и просто, не вдаваясь в дизассемблеры и реверс-инжиниринг, то пройдите туториал утилиты Cheat Engine. Там отлично и просто рассказано, как искать такие адреса.
А дальше уже напишете свой сканер под это дело, если нужно.

Сохранить исходник в UTF8

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

Кроссплатформенным бывает код, который можно собирать под разные системы.

На сайте этого тулчейна написано же:

A compiler suite for 32- and 64-bit Windows based on the GNU toolchain

Значит, что он умеет только винду.

Кроссплатформенно можно писать на чём угодно. Графические приложения сейчас — это от силы 10 процентов всего, что пишется. Всё уходит в веб, если хотите хороший гуй и быстро, берите Chromium Engine Framework, верстайте дизайн на коленке, и всё быстро и круто получается, на нём сейчас пишут подавляющее большинство графических потребительских приложений.
Мало того, приличное количество последних популярных сред разработки, всяких редакторов, написано на... JavaScript! На Node.js и платформе Electron. Тупо, быстрее сверстать отдельно фронтенд, какую-то модель, бекенд, сразу видеть изменения, чем сидеть ждать, пока перекомпилируется Qt, выкинет ошибку, которая оказывается багом, который не хотят чинить, и т.п.
Вижуал студия очень хреново подходит для кроссплатформенной разработки, не как среда, а как компилятор, у неё своё представление о стандарте языка, базовые вещи могут не поддерживаться, либо поддерживаться в своём, очень странном виде.
Сначала нужно определиться, что вы хотите писать и нужен ли вообще графический интерфейс для этого.

Ну, так скомпилируйте с его поддержкой, в чём проблема то?

Ставьте хуки на функции работы с сокетами, типа send/sendto/recv/recvfrom. И в них можно изменять что угодно.

C++ -- это инструмент для "обёрток" над низкоуровневыми вещами. Трудно что-то на нём удачно писать, не зная при этом устройство ОС, работы менеджеров памяти, тонкостей реализации каких-то фич. Также обязательно знать ассемблер, уметь отлаживать код, юзать отладчики. Понимать что такое кэш, предсказатель переходов, как работать с этим всем, оптимизировать.
Библиотеки, фреймворки -- это всё для более высокоуровневых языков, в С++ только с этими знаниями будет очень тяжко. Ибо за вас он ничего не будет делать, к счастью.

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

Придумайте задачу, проект. Который будет интересен независимо от языка, который захочется делать хоть на брейнфаке. Тогда любая книга подойдёт. Главное, чтоб не откровенная устаревшая херня была. Желательно сразу учить начинать с С++11 или С++14, ибо они прилично отличаются от классического языка, и много чего объявлено устаревшим и удалено в следующих версиях.

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

Во-вторых, какая у вас стоит локаль терминала? Когда вы делаете вывод в консоль, данные идут в кодировке файла, а кодировка у терминала может отличаться, отсюда и идёт мусор.

Две самые популярные библиотеки:
Boost.Asio
и
POCO::Network.

POCO имеет реализацию вебсокетов.

kkrieger — это высший пилотаж. Там используются особенности загрузчика Windows, соответственно, его предварительно дизассемблировали и изучили, чтобы подстроиться под его косяки и убрать ненужные заголовки, которые будут занимать место.

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

Всё это, по сути, спорт, состязание демо-групп. Реальные вещи на этом делать слишком долго и затратно. Но в плане теории, можно хорошо подтянуться. Поковыряйте исходники движка, на котором написан кригер, они открыты, но довольно устарели уже.

Для реальных вещей, начните учить, например, OpenGL 3.2+, шейдеры, различные технологии, типа abmient occlusion, post processing effects.

А 40 мегабайт планка... это МНОГО. Если учить чистое графическое АПИ, и ничего лишнего не писать, у вас будет всё весить сотни килобайт. Но, опять же, это всё необходимо только для изучения основ и понимания, как оно всё там работает. Для реального продакшена или даже прототипирования лучше возьмите попсовый движок, тот же юнити или анрил. Будет и проще, и быстрее, и удобнее. Ибо, мобильные видеоадаптеры это костыль-driven development. Обычно видео-драйверы там ОЧЕНЬ сырые, ОЧЕНЬ баганые, их реализации графических апи могут абсолютно не соответствовать стандарту. То, что у вас запустилось на Mali, может совершенно не работать на PowerVR или другом чипе. Поэтому не советую привязываться к низкому уровню в мобильной разработке, берите уже проверенный временем движок, в котором решена большая часть этих проблем, и костыли уже расставлены на своих местах. Иначе, будете биться с косяками производителей видеочипов, а не работать с графикой.

Как уже сказали в комментах, открывайте с флагом binary. Строки -- это строки, а двоичные данные -- двоичные данные ©Кэп. Каждая функция предназначена для своей задачи, и не стоит её использовать для других. Если ваш пример иногда работает, а иногда нет, это заслуга только рака, который иногда свистит на горе, а иногда ленится. Это во-первых.

Во-вторых, в C++ нет стандартных средств для поиска в бинарных файлах. Придётся писать свою функцию, либо просто скопипастить со StackOverflow, там таких вопросов миллионы. Реализация давно уже написана за вас.

Подсказка: гуглите реализацию функции memmem().

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

Во-вторых, нет таких книг "под компилятор". Есть различные стандарты. Из современных сейчас практически полностью реализован во многих популярных компиляторах -- С++14. С++11 реализован на 99.99% обычно.
Сначала нужно решить, какой стандарт начать изучать -- 03 или 11/14. Т. к. 14-й -- это, по сути, минорный апдейт 11-го.

Чистый С++14 без всяких там костылей и экстеншенов лучше изучать на компиляторе clang с максимальными флагами ворнингов, педантиков и т. д. Это научит отличать стандартизованный С++ от миллионов расширений и костылей, которые в него успели внести за время его развития. Да и сообщения об ошибках у клэнга на порядок адекватнее, чем наркоманские простыни неверного инстанцирования шаблонов вижуал студии.

Если работаете под виндой, советую поставить Cygwin и на него clang и, если позволяет религия, vim. Можно clion, для новичка он неплохо поможет. Лучше сразу задать параметр -std=c++14, чтоб компилировать под 14-й стандарт. Чтобы отключить всевозможные расширения и не пропускать ни одного предупреждения, нужно добавить параметры -Weverything -Werror -pedantic-errors -Wno-c++98-compat.

Ещё, советую не использовать хидеры, начинающиеся на c*, т. к. они оставлены для совместимости с чистым языком Си. Ибо, используя их, будете путать и не различать чистый Си и C++. Лучше использовать чистый STL и пространство имён std, там всё необходимое есть для начала.

Референсы и хидеры для всяких фич лучше смотреть на C++ reference, ибо там всё по стандарту расписано более-менее.

ПС Ещё, существует два холиварных направления в C++: чистый STL, который предлагает Страуструп и Ко. Там, в основном, используются "3 кита языка: контейнеры, алгоритмы и итераторы". Это типа "тру C++", который изначально придумывался. В основном сюда хорошо накладываются паттерны GoF.
Второе направление -- "Си с классами", это когда, по сути, из ООП используется только полиморфизм, да и то, не там, где нужно. Здесь обычно мешают всё подряд: и Си, и С++, и STL, и макросы, и ещё чёрт знает что. Его использует большинство тех, кто перешёл из Си в С++. Много книг так же написано в данном стиле.
Лично я рекомендовал бы на случай ООП разработки всё-таки приучать себя использовать "тру C++", ибо там есть всё, что нужно, для нормального ООП. Ну, а если хочется просто учить прикладной язык и не париться насчёт хорошего кода, то можно учить как угодно.

Да не слушай ты этот бред, который пишут: "То бросай, это бросай, вакансий нету, всё пропало!".
Всё есть, если есть интерес.
Учить не важно какой движок, они все используют одни и те же концепции, паттерны примерно одинаковые.

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

А все эти анрилы и юнити только ключевыми словами, по сути, отличаются. Ну, и общий дизайн у них чуть более удобен в плане декомпозиции кода, грамотной архитектуры. Но, пока сам не дойдёшь до необходимости использовать эту декомпозицию, ничего особо не выиграешь, только запутаешься. При переходе достаточно будет ознакомиться с паттернами Gang of Four и всё станет ясно более-менее.

ПС Знаю разработчиков Юнити, которые начинали геймдев с этого движка и в шоке от того, что кто-то программирует не мышкой. Азы оптимизации им просто недоступны, ибо они даже понятия не имеют о нижележащем уровне API. Они искренне удивляются, как это знать чистый OpenGL и писать всё самому, а разве так можно? Точно так же, кстати, удивляются многие кодеры на плюсах: "А зачем мне знать ассемблер? Я с ним не сталкиваюсь никогда..."

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

А уж, если хочется просто изучить полезный скилл зарабатывания денег и как зомби рубить бабки, то тут, как описали выше, 2 варианта по сути: Unity (C#), Unreal (C++). По ним вакансий немерено.

Precompiled headers, же! И всё влёт собирается.
Ну, или для совсем тяжёлых случаев, можно юзать Ниндзю.

А писать однозначно на бусте.