none7

Поле 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.
Если обратиться к адресам памяти никак их не проинициализировав, то произойдёт исключение. Если при этом не настроены обработчики исключений, то выскочет традиционное окошко.

А разве для отправки запроса не нужно вызвать xmlHttp.send() ?

ОС может блокировать для приложения возможность чтения, записи, исполнения определённых диапазонов виртуальной памяти. Например код *((char*)GetProcAddress(hkernel32, "GetProcAddress")) = 0 по умолчанию вызовет исключение. Но если выдать региону памяти права на запись, то первый байт функции в данном процессе будет успешно перезаписан.

Код самого цикла с точки зрения 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, может быть этот кусок просто обманка, а реальный в обработчике исключения? Также вполне возможно, что данное приложение полиморф и этот код на самом деле будет переписан во время работы.

В нынешнем Интернете это вероятно не нужно. В Ethernet и оптоволокне шумы приводящие к ошибкам, возможны только при грубом нарушении правил строительства сети. В Wi-Fi, xDSL, сотовых сетях обеспечивают больший контроль целостности на канальном уровне. В IPv6 по этому поводу даже чексумму убрали, осталась только в TCP и UDP. Таких ошибок было много во времена Dial-Up, где контроль целостности на канальном уровне был явно недостаточен.

Для первого набора байт подходит такой простой код:

static byte[] crc(byte[] data) {
    ushort sum = 0;
    foreach (byte b in data)
        sum += b;
    return new byte[] {(byte)(sum & 255), (byte)(sum >> 8)};
}

Те есть сумма всех байтов сообщения включая код операции и длину сообщения, но без чексуммы. То есть в документации косяк чексумма считается с 0 по 4+n без -1, n длина данных для команды. Но там ведь сказано, что чексумма это «сумма байтов пакета».

А вот собственно и полный тест:

static ushort crc(byte[] data, ushort sum = 0) {
    foreach (byte b in data) sum += b;
    return sum;
}
static void Main(string[] args)
{
    // пакеты без чексумм
    byte[] mass1 = new byte[] { 75, 0, 25, 0, 3, 48, 117, 0, 126, 37, 0, 188, 138, 169, 53, 66, 15, 52, 115, 203, 112, 103, 220, 16, 92, 237, 76, 80, 254};
    byte[] mass2 = new byte[] { 75, 0, 25, 0, 3, 64, 156, 0, 126, 37, 0, 188, 138, 169, 245, 165, 14, 52, 115, 203, 96, 64, 220, 16, 92, 237, 76, 80, 254};
    byte[] mass3 = new byte[] { 75, 0, 25, 0, 3, 80, 195, 0, 126, 37, 0, 88, 138, 169, 181, 9, 14, 52, 115, 203, 120, 60, 220, 32, 131, 237, 236, 214, 255};
    byte[] mass4 = new byte[] { 75, 0, 25, 0, 3, 112, 17, 1, 126, 37, 0, 88, 138, 169, 181, 9, 14, 52, 115, 203, 120, 60, 220, 32, 131, 237, 236, 214, 255};
    byte[] mass5 = new byte[] { 75, 0, 25, 0, 3, 60, 134, 1, 126, 37, 0, 88, 138, 169, 181, 9, 14, 52, 115, 203, 120, 60, 220, 32, 131, 237, 236, 214, 255};

    foreach(var mass in new byte[][] {mass1, mass2, mass3, mass4, mass5}) {
        bool first = true;
        Console.Write("{");
        foreach (var b in mass)  {
            if (!first) Console.Write(", ");
            else first = false;

            Console.Write(b);
        }
        var sum = BitConverter.GetBytes(crc(mass));
        // вывод чексуммы
        Console.WriteLine(", {0}, {1}}}", sum[0], sum[1]);
    }
}

With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default):
x64: 8 TB
Intel Itanium-based systems: 7 TB
Windows 8.1 and Windows Server 2012 R2: 128 TB
2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared
Отсюда.

К чему искать проблем с исключениями, если способ через 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.

cacls