none7

Это с точки зрения Ассемблера array это адрес. А с точки зрения Си uint32_t* array это глобальная статическая переменная в которой лежит указатель на uint32_t или соответствующий массив . То, что в Ассемблерах выглядит примерно так array_ptr dd offset array. А так как это bss, то естественно, что в этой переменной лежит ноль.

Инструкции x86 разбросаны довольно хаотично по числовому диапазону, не говоря уже про их длину, но самому процессору намного проще декодировать инструкции, чем программам. Он просто имеет внутри дерево, если старший бит первого байта инструкции равен 0 одна ветвь, иначе другая. Так по ветвям он спускается и например доходит до инструкции 01010b (push reg) и вот он уже знает, что длина этой инструкции 5 бит + 3 бита аргументов. И может даже сразу запустить найденную инструкцию, если это какой-нибудь i286. И всё за 1 такт.

В смысле .jpeg,.png,.gif? Нельзя. Если речь про прямой доступ к видеобуферу то он 0xA000:0x0000 представлен как массив RGB-структур.
Есть такой полезный сайт https://wiki.osdev.org/User:Omarrx024/VESA_Tutorial

На x64 под виндой эта функция лишена смысла, поскольку стандартное соглашение вызовов не предполагает смещения стека для передачи параметров. Независимо от флагов stdcall/cdecl, компилятор использует fastcall.

В Mac OS x86-64, rcx используется в качестве четвёртого параметра и не обязан сохранять свое значение после вызова функции. Храните значение счётчика в памяти или в одном из сохраняемым регистров(rbx, rbp, r12-r15), но помните Вы так же обязаны восстановить значения этих регистров, при выходе в код Си, если конечно меняли их.
Посколько rcx не сохраняется то лучше заменить loop на пару инструкций dec, jne.

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

Затем, что это писал системный программист, для системных программистов. Например разработчики антивирусов много бы страдали без этого чёткого разделения.

Зачем если у нас у каждого процесса своя личная память которую он сам занимает, его загружать в разные адреса.

ASLR

Я хочу просто перезаписат отделюную инструкцию, как мне это сделать, если она каждый раз находится на разных адресах.

EnumProcessModules GetModuleFileNameEx

Поле ImageBase указывающее системе в какую часть виртуальной памяти процесса нужно разместить исполняемый файл. Традиционно .exe файлы размещают по адресу 0x400000, это не значит, что он занимает 4 мегабайта, просто адрес. Dll традиционно размещают по адресу 0x10000000; поскольку для dll весьма возможен конфликт адресов, к ним обязательно прикрепляют релоки. Адрес размещения .exe и .dll строго говоря может быть любым кратным 0x10000, но не 0, не адрес ntdll.dll и не в пространстве ядра. Сам же исполняемый файл может занимать минимум 1 страницу(4Кбайт на x86) памяти + минимум по 1 странице на секцию, независимо от адреса размещения исполняемого файла.
То, что без таблицы импорта нельзя ничего сделать, строго говоря неверно. Можно через стандартные адреса выяснить где расположены системные .dll и их экспортируемые функции и через них загрузить всё, что необходимо. Но без самих системных .dll можно только зависнуть или умереть. Подгружать нужно то, что необходимо для работы кода приложения, это полностью зависит от самого приложения. Например для классического HelloWorld

void func() {
    MessageBoxA(NULL, "Hello", "Hello, World!", MB_OK);
    ExitProcess(0);
}

нужны user32.dll:MessageBoxA и kernel32.dll:ExitProcess.
Если обратиться к адресам памяти никак их не проинициализировав, то произойдёт исключение. Если при этом не настроены обработчики исключений, то выскочет традиционное окошко.

Код самого цикла с точки зрения ilspy выглядит так:

for (int i = 0; i < bytes.Length; i += 2)
    bytes[i] = (byte)((int)bytes[i] ^ 168 - i);

но по моему так:

for (int i = 0; i < bytes.Length; i += 2)
    bytes[i] = (byte)((i - 168) ^ bytes[i]);

Но выше цикла вообще ересь. Метод System.Console::WriteLine(string) требует 1 аргумент, а System.Text.Encoding::GetBytes(string) требует ещё и объект для которого будет вызван метод. И где же тогда соответствующие ldarg,ldloc ? Запустить этот кусок IL-кода мне также не удалось. Выплёвывает исключение System.InvalidProgramException, может быть этот кусок просто обманка, а реальный в обработчике исключения? Также вполне возможно, что данное приложение полиморф и этот код на самом деле будет переписан во время работы.

К чему искать проблем с исключениями, если способ через PEB работает от Win2k до Win10?

mov eax, fs:[18]
mov eax, [eax+30h]
mov eax, [eax+0ch]
mov eax, [eax+0ch]

Так находится структура описывающая основный .exe файл.
+0h Next
+18h HANDLE
+24h UNICODE_STRING FullFileName
+2Ch UNICODE_STRING ShortName
Через Next можно перечислить все загруженные модули, следующим после .exe файла гарантировано будет ntdll. От вас требуется только написание stricmp для структур UNICODE_STRING, ну или импортировать RtlEqualUnicodeString из ntdll.