none7

Проприетарное ПО в принципе не может распространятся вместе с GPL кодом. Даже если если он идёт в отдельном исполняемом файле. С LGPL ещё можно динамически линковаться не изменяя, а полностью свободные в этом плане только BSD, MIT, Apache.

Вот говорил же злые хакеры всё уже сделали за Вас. Утилита PE Tools, выбрать процесс, выбрать исполняемый файл, ПКМ, PE editor -> read only, FLC(File Location Calculator), RVA, VA, file offset, считает, что угодно из чего угодно. Делать подсчёт в патчере смысла нет, если это не тот самый исполняемый файл, что и у Вас, то Вы его своим RVA to FO попросту сломаете. Просто запишите хеш файла и смещение в файле в исходник патчера. Кстати нагуглить код функции было проще простого rva to file offset

Если речь о небольшом буфере, то смысла действительно не много. Но если речь о нескольких десятках мегабайт памяти, то ОС свапать начнёт раньше, чем запустит полную сборку мусора. Да и придумывался этот паттерн в первую очередь для блокирующих ресурсов. Таких как файлы, открытые порты, дескрипторы окон, потоки и т.д.

Таблицу импорта пофиксить трудно. Нужно тщательно изучить формат PE, разобрать EXE-шник на части, добавить новую секцию перед секцией ресурсов, в которой сформировать новую таблицу импорта, оставив старые "Thunk RVA". Затем собрать заново пересчитав расположение каждой секции на диске. Но всё уже написано за Вас злобными вирмейкерами :), а Вы похоже даже не пытались найти такие утилиты. подсказываю Google: add dll to import

Вам нужно раздать адреса другим серверам или сетям? Если нет, то и не трогайте её вообще, иначе создавайте виртуальные интерфейсы, дробите эту /56 на отдельные /64(или как Вам угодно), вешайте их на эти интерфейсы и настраивайте маршрутизацию.

Да не обязательно копировать файл с именем "банковская_карта_и_пинкод.txt". Вы ведь наверняка используете не анонимный доступ, а имея возможность для MITM перехватить сессию не составит труда. Авторизированный пользователь может влезть в скрытые директории \\host\c$ и получить удалённый доступ к реестру уж не говоря про RDP. Закончится всё может запуском червя. Так, что без шифрования гонять SMB трафик через интернет действительно не стоит и ставить слабые пароли на открытую для Интернета машину тоже.

Код будет системозависимый. В Linux первые 6 аргументов передаются в регистрах (rdi, rsi, rdx, rcx, r8, r9), остальные по старинке . В Windows первые четыре в регистрах(rcx, rdx, r8, r9), остальные в стеке, НО место в стеке под первые 4 всё равно нужно выделить и лучше сохранить туда аргументы тоже; ради va_arg функций. Стек нужно выровнить по границе 16 байт ибо sse2 используется повсюду.
Кстати лучше всё таки реализовывать такую функцию не в C++ исходнике, а в отдельном .s файле. Ведь если функция возвращает double, то нет никаких гарантий, что всё вернётся в целости.

Что возвращают функции то и заталкиваем, то есть:

invoke  AllocConsole
    invoke  GetStdHandle, STD_INPUT_HANDLE
        push    eax ;InputHandle
        push    eax ;InputHandle
    invoke  GetStdHandle, STD_OUTPUT_HANDLE
        push    eax ; OutputHandle
    invoke  SetConsoleMode, eax, ENABLE_PROCESSED_OUTPUT ; OutputHandle
        pop eax
    invoke  WriteConsole, eax, hello, msgsz, NULL, NULL ; OutputHandle
    invoke  FlushConsoleInputBuffer ; функция сама забирает 1 аргумент, InputHandle
        pop eax
    invoke  ReadConsole, eax, buf, bufsz, cnt, NULL ; InputHandle
    invoke  FreeConsole
    invoke  ExitProcess,0

Компиляторы кстати так делать не будут. Они или сохранят значения в ebx, esi, edi или будут сохранять в стек через [ebp-x].

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

А зачем у Вас вообще include 'win32a.inc' и .code, если Вы под DOS пишете. Там никаких WinAPI и секций кода и данных нет. А вот org 100h в начале не помешал бы. Хоть fasm и может компилировать под различные системы, но оформление кода всегда разное; в википедии есть примеры для каждой из систем.

Первая же строчка в логе: unable to find the sources of your current linux kernel. Дополнение из исходников собирается, бинарник в ядро неизвестной версии запихнуть проблематично. А для сборки ядерных модулей нужны заголовочные файлы ядра. Обзывают это обычно пакетом linux-headers и придётся пересобирать после каждого обновления ядра. Так, что действительно лучше попытаться поставить пакет virtualbox-guest-x11

Насколько я помню у gogoNET клиента проблемы с Win8/10 и разработчики забили на него вообще и запретили регистрацию новых бесплатных аккаунтов(только анонимные). Есть ещё Sixxs, но это несколько сложнее чем с gogoNET и требует терпения, ибо процесс не автоматизирован. Других брокеров обходящих NAT на сколько мне известно нет.
Можно конечно довольствоваться Teredo и dyndns. Оно конечно работает с некоторым лагом на старте, но в целом лучше брокеров, тем, что трафик не гуляет через Амстердам и не теряется по пути.

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

Чтобы натравить готовый эксплоит на сайт знать вообще ничего не нужно. А при поиске уязвимостей не имея исходника и даже бинарника, нужно как можно больше знаний обо всех смежных областях. Так как дыры обычно случаются, когда программисты и админы используют инструмент, технологию, язык не до конца понимая как оно всё работает. SQL-инъекции самый отличный пример, того. Впрочем дыр в софте нынче всё меньше, сейчас модно искать дыры в мозгах людей.

Вся эта модель не более чем условность, нужно её рассматривать, как иерархию структур данных, а вовсе не незыблемые и скрытые друг от друга уровни. В некоторых случаях в направлении отправки пакета может учитываться даже прикладной уровень, а HTTP разбираться непосредственно из Ethernet-кадров. HTTP ничто не мешает содержать Ethernet кадры. NAT определяющий направление отправки по номеру порта TCP и UDP вообще уже стал обыденностью. Прикладных протоколов содержащих IP-адреса и порты, вообще не должно быть в OSI, так как не позволяет абстрагироваться, но их полно. И это вышло боком при появлении IPv6, а с другими протоколами сетевого уровня они вообще несовместимы и на это закрыли глаза. И весь этот бардак нынче зовётся сетевым стеком.
IP конечно содержит механизм фрагментации, но по причине неудачного проектирования используется редко и не для TCP. TCP изначально создан для фрагментации бесконечных потоков данных с проверкой факта доставки, поэтому влезает на сетевой уровень, чтобы знать MTU, а получив некоторые ICMP пакеты даже разрывать соединение(no route, unreachable). Удалённому узлу, TCP тоже сообщает свой MTU.