How can I process the header of an exe when disassembling with iced_x86? - x86-64

Question

I want to disassemble a list of executables with an output format for the instructions that I can customize. As a prior web developer, iced-x86 with Node.js seems like an easy way to start. I want to use this.
The code I'm using is exactly what's listed on the documentation for iced-x86:
Disassemble (decode and format instructions), although I'm loading the Uint8Array from my own exe and set the RIP to 0x0, I'm not sure how this value should be decided - it seems like an arbitrary equivalent to uint64_t exampleRip = 0x00007FFAC46ACDA4:
// iced-x86 features needed: --features "decoder nasm"
const { Decoder, DecoderOptions, Formatter, FormatterSyntax } = require("iced-x86");
/*
This code produces the following output:
00007FFAC46ACDA4 48895C2410 mov [rsp+10h],rbx
00007FFAC46ACDA9 4889742418 mov [rsp+18h],rsi
00007FFAC46ACDAE 55 push rbp
00007FFAC46ACDAF 57 push rdi
00007FFAC46ACDB0 4156 push r14
00007FFAC46ACDB2 488DAC2400FFFFFF lea rbp,[rsp-100h]
00007FFAC46ACDBA 4881EC00020000 sub rsp,200h
00007FFAC46ACDC1 488B0518570A00 mov rax,[rel 7FFA`C475`24E0h]
00007FFAC46ACDC8 4833C4 xor rax,rsp
00007FFAC46ACDCB 488985F0000000 mov [rbp+0F0h],rax
00007FFAC46ACDD2 4C8B052F240A00 mov r8,[rel 7FFA`C474`F208h]
00007FFAC46ACDD9 488D05787C0400 lea rax,[rel 7FFA`C46F`4A58h]
00007FFAC46ACDE0 33FF xor edi,edi
*/
const exampleBitness = 64;
const exampleRipLo = 0xC46ACDA4;
const exampleRipHi = 0x00007FFA;
const exampleCode = new Uint8Array([
0x48, 0x89, 0x5C, 0x24, 0x10, 0x48, 0x89, 0x74, 0x24, 0x18, 0x55, 0x57, 0x41, 0x56, 0x48, 0x8D,
0xAC, 0x24, 0x00, 0xFF, 0xFF, 0xFF, 0x48, 0x81, 0xEC, 0x00, 0x02, 0x00, 0x00, 0x48, 0x8B, 0x05,
0x18, 0x57, 0x0A, 0x00, 0x48, 0x33, 0xC4, 0x48, 0x89, 0x85, 0xF0, 0x00, 0x00, 0x00, 0x4C, 0x8B,
0x05, 0x2F, 0x24, 0x0A, 0x00, 0x48, 0x8D, 0x05, 0x78, 0x7C, 0x04, 0x00, 0x33, 0xFF
]);
const hexBytesColumnByteLength = 10;
const decoder = new Decoder(exampleBitness, exampleCode, DecoderOptions.None);
// You have to enable the bigint feature to get i64/u64 APIs, not all browsers support BigInt
decoder.ipLo = exampleRipLo;
decoder.ipHi = exampleRipHi;
// This decodes all bytes. There's also `decode()` which decodes the next instruction,
// `decodeInstructions(count)` which decodes `count` instructions and `decodeOut(instruction)`
// which overwrites an existing instruction.
const instructions = decoder.decodeAll();
// Create a nasm formatter. It supports: Masm, Nasm, Gas (AT&T) and Intel (XED).
// There's also `FastFormatter` which uses less code (smaller wasm files).
// const formatter = new FastFormatter();
const formatter = new Formatter(FormatterSyntax.Nasm);
// Change some options, there are many more
formatter.digitSeparator = "`";
formatter.firstOperandCharIndex = 10;
// Format the instructions
instructions.forEach(instruction => {
const disasm = formatter.format(instruction);
// Eg. "00007FFAC46ACDB2 488DAC2400FFFFFF lea rbp,[rsp-100h]"
let line = ("0000000" + instruction.ipHi.toString(16)).substr(-8).toUpperCase() +
("0000000" + instruction.ipLo.toString(16)).substr(-8).toUpperCase();
line += " ";
const startIndex = instruction.ipLo - exampleRipLo;
exampleCode.slice(startIndex, startIndex + instruction.length).forEach(b => {
line += ("0" + b.toString(16)).substr(-2).toUpperCase();
});
for (let i = instruction.length; i < hexBytesColumnByteLength; i++)
line += " ";
line += " ";
line += disasm;
console.log(line);
});
// Free wasm memory
instructions.forEach(instruction => instruction.free());
formatter.free();
decoder.free();
Meanwhile, I'm also disassembling the same file with Ghidra to check my work.
Ghidra outputs the correct disassembly of the header:
//
// Headers
// ram:00400000-ram:004001ff
//
assume DF = 0x0 (Default)
IMAGE_DOS_HEADER_00400000 XREF[1]: 004000b4(*)
00400000 4d 5a 90 IMAGE_DO
00 03 00
00 00 04
00400000 4d 5a char[2] "MZ" e_magic
00400002 90 00 dw 90h e_cblp Bytes of last page
00400004 03 00 dw 3h e_cp Pages in file
00400006 00 00 dw 0h e_crlc Relocations
00400008 04 00 dw 4h e_cparhdr Size of header in
0040000a 00 00 dw 0h e_minalloc Minimum extra para
0040000c ff ff dw FFFFh e_maxalloc Maximum extra para
0040000e 00 00 dw 0h e_ss Initial (relative)
00400010 b8 00 dw B8h e_sp Initial SP value
00400012 00 00 dw 0h e_csum Checksum
00400014 00 00 dw 0h e_ip Initial IP value
00400016 00 00 dw 0h e_cs Initial (relative)
00400018 40 00 dw 40h e_lfarlc File address of re
0040001a 00 00 dw 0h e_ovno Overlay number
While iced_x86 outputs the following, clearing not correctly handling the header:
0000000000000000 4D5A pop r10
0000000000000002 90 nop
0000000000000003 0003 add [rbx],al
0000000000000005 0000 add [rax],al
0000000000000007 000400 add [rax+rax],al
000000000000000A 0000 add [rax],al
000000000000000C FFFF (bad)
000000000000000E 0000 add [rax],al
0000000000000010 B800000000 mov eax,0
0000000000000015 0000 add [rax],al
0000000000000017 004000 add [rax],al
000000000000001A 0000 add [rax],al
I'm newly learning Assembly; I don't know how the header data needs to be disassembled differently from the the rest of the instructions. How can I handle this? Is there a feature of iced_x86 I should be using?
What I've tried:
I'm looking through documentation on the topic, and found this representation in C:
struct DOS_Header
{
// short is 2 bytes, long is 4 bytes
char signature[2] = { 'M', 'Z' };
short lastsize;
short nblocks;
short nreloc;
short hdrsize;
short minalloc;
short maxalloc;
void *ss; // 2 byte value
void *sp; // 2 byte value
short checksum;
void *ip; // 2 byte value
void *cs; // 2 byte value
short relocpos;
short noverlay;
short reserved1[4];
short oem_id;
short oem_info;
short reserved2[10];
long e_lfanew; // Offset to the 'PE\0\0' signature relative to the beginning of the file
}
Which seems straightforward enough. But I'm still unsure whether I need to write code for this in the Node.js script, or if the iced_x86 library supports it already.