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

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

Это куда лучше, чем изменять опкоды..

Тогда нужно генерировать эти адреса

Ну... да. Патчер найдёт эти адреса внутри другого процесса (GetProcAddress, GetModuleHandle, CreateToolhelp32Snapshot, etc.), запишет, и заинжектит шеллкод

А потом могут быть вот такие приколы:
mov rax, addr_of_func
call rax

А это здесь причём? Это уже проблема в коде... Хотя, такое вряд ли будет. Есть секция, есть массив, патчер записал туда адреса, в коде берёшь оттуда адреса, кастишь в функцию, вызываешь.. В случае ассемблера - просто вызываешь

Это предложение сделать секцию перед .text или внутри нее, которая по размеру будет равна таблице импортов * sizeof(ptr)?

Зачем "перед", или "внутри".
Просто создаётся секция, к примеру, ".addr", для ЯВУ туда нужно поместить массив, или что-то типа того, ибо ему нужно как-то обращаться к памяти этой секции (ибо там будут записаны адреса), с ассемблером всё проще, опять же - просто выделяешь в секции память, и берёшь оттуда адреса.
Так вот, секция выделена (".addr"), размер не важен, просто нужно, чтобы помещались туда нужные тебе  адреса. Ты же сам знаешь, сколько у тебя функций - (Total_functions*4) и выровнять на выравнивание секции и файла (структура PE).
После чего туда записываешь адреса патчером (берёшь эти адреса в процессе, куда хочешь заинжектить шеллкод), далее инжектишь шеллкод, и он будет брать адреса в этой секции.
Опять же, ещё проще - выделить место в конце шеллкода, и туда писать адреса. Чтобы без всяких секций и заморочек

А, вот мне не очень нравится идея кастов. Смысл в том, чтобы писать exe файл с winapi + /NODEFAULTLIB и его конвертить в шеллкод

Господи, ну это вообще другая мысль.
Сначала "нужно сделать независимый от адресов WinAPI шеллкод, причём на разном ЯВУ", теперь - "нужно конвертировать файл .exe с WinAPI и импорт таблицей в шеллкод"...

Возможно, что изначально не понятно было

Кстати, насчёт конвертера файла в шеллкод - идея довольно популярная. Даже на гитхабе такое уже видел (именно PE файл с импорт-таблицей WinAPI в шеллкод, вне зависимости от импорт-таблицы). Могу найти, если не найдёшь. На Python С++ (и С) писали

ссылки можно сюда кинуть 5а статью?

в личку написал

Какую такую статью?

про Самомодификация кода

А чего там сложного, чтобы прям статью писать?

Ну скинь

Вот, если что.
Но там, как и думал, просто операции с памятью и разъяснение, что такое опкоды ("вот здесь пишем такой dd 0x12345690, а перед этим хопа! И делаем так - mov dword[addr_instr], 0x83c00190, и теперь там add eax, 1, супер!")
Вообще часто вижу статьи на CodeBy про ассемблер, и не понимаю, как за такое можно платить (там же платят за статьи, вроде), знания для начинающих
https://codeby.net/threads/asm-texniki-iz-starogo-sunduka-2.78287/

это статья даёт первое понятие, как нужно думать в этом направлении, хотя на ассемблере методик может быть нескончаемое количество, я думаю)

Да, я это и понял. Этот Marylin пишет статьи только "можно было бы, а можно бы, но это вы сами додумайте". Вот взять ещё статью про скрытие процессов. В начале разъяснил про EPROCESS структуры, это всё понятно. Но дальше - он решил перехватить taskmgr. Но что он сделал на самом деле - написал программу, которая показывает список процессов в ZwQuerySystemInformation, и просто пропустил там нужный процесс. Ну и всё, а в конце - "Ну это вы можете сделать в виде шеллкода, (не написал) правда вам ещё нужно перехватить основной вывод, ну или занопить половину функционала taskmgr. Но это вы как-то сами".
Я считаю, намного легче было бы перехватить вывод ZwQuerySystemInformation (сначала идёт переход в wow64cpu, куда отдаются аргументы (ну в случае с wow64), на PE64 идёт сразу syscall, после чего - add esp, 4 и ret. Вместо этих двух инструкций вставить обработчик, в esp+8, esp+12, esp+... находятся аргументы 1, 2, 3, ..., соответственно получить буффер и обработать там список процессов)
Есть ещё вариант с перехватом самого сисколла для Wow64 (PE32) из-под usermode. Вот, к примеру - https://www.codereversing.com/blog/archives/date/2015/06, но это уже посложнее. Вариантов действительно много, но Marylin ничего об этом не сказал вообще