rPman

Хранение блобов в файле программы (оно будет мапиться на адресное пространство и читаться эффективнее fread) в .data секции, создать объектные файлы с помощью objcopy или генерировать константы массивов с 0xXX с помощью xdd

https://caiorss.github.io/C-Cpp-Notes/resources-ex...

Почти все нормальные криптовалюты имеют кошелек с api (часто rpc) по работе с ним.
Так же для облегчения веса в мегабайтах результата, пользуются (часто неофициальными) библиотеками.
Для криптовалют с поддержкой контрактов бывают особенности реализации, так же надстройки меняют картину, например lightning network требует отдельный кошелек/демон lnd когда как обычные переводы bitcoin можно делать только офф кошельком.

гуглить: имя твоей криптовалюты + имя языка программирования + library + опционально название/версия контракта

В коде, указанном в вопросе написана белиберда
В конструкторе предлагаешь сделать присваивание
vProtect = Protect;
глобальной переменной vProtect имя класса Protect (потому что у тебя Protect и класс и переменная типа cProtect, (то что компилятор тебе это позволил уже бардак), если переименовать cProtect мембер Protect в protect (как рекомендует большинство code styling - имена классов с большой буквы, имена переменных - с маленькой, чтобы не запутаться), а еще тип vProtect у тебя - указатель, а Protect - нет, если будут оба указатели то само собой все будет собираться, но все равно смысла это иметь не будет.
-----------------------

Теперь про твой вопрос в заголовке, почти ничего не имеющий общего с текстом вопроса:

Как скрыть адрес вызываемой функции в C++?

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

В c++ для этого реализован класс std::function, пример использования для вызова именно метода класса (для простоты пример без аргументов но с аргументами все то же самое, надеюсь ты понимаешь, что у тебя должны быть одинаковые аргументы и типы во всех методах, или должны быть группы для разных типов, но чем больше групп тем проще анализ кода, иначе тупо по типам и количеству аргументов все можно будет понять)

// определяем класс
class MyClass
{
  public:
  void myFunA(){std::cout<<"A";};
  void myFunB(){std::cout<<"B";};
};

однократно где то инициализируешь массив адресов функций (никто не мешает по коду это перемешивать)

std::function<void(MyClass*)> functions[]={&MyClass::myFunA,&MyClass::myFunB};

вызов метода по номеру x

MyClass obj;
functions[x](&obj);

Date.parse

returns the number of milliseconds since January 1, 1970, 00:00:00 UTC

new Date(value)

An integer value representing the number of milliseconds since January 1, 1970, 00:00:00 UTC

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

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

Есть еще оптимизация кода, скорее всего именно это определяет объем и сложность задачи, так как без нее это уже не так сложно.

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

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

Или наоборот, вместо генерации машинного кода, используется коды выдуманной виртуальной машины, которая будет запускаться (транслироваться в реальном времени в машинный код) на разных архитектурах одинаково (например jvm и clr).

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