IOS/Kernel: Difference between revisions

From WiiBrew
< IOS
Jump to navigation Jump to search
Hallowizer (talk | contribs)
←Created page with 'The '''IOS kernel''' is responsible for dispatching interrupts to processes, handling syscalls, and running the IOSP threads. It is independent of...'
 
Hallowizer (talk | contribs)
memory allocation section
Line 30: Line 30:
}
}
</pre>
</pre>
== Memory allocation ==
Memory allocation is similar to in the [[IPC (SDK)|IPC]] library.
<pre>
struct HeapBlockHeader {
u16 magic; // 0xbabe
u16 status; // 0 = free, 1 = allocated, 2 = aligned alias for header
u32 size;
struct HeapBlockHeader *prev; // depends on status; status 0 has the previous free block, status 1 has NULL, status 2 has the main block
struct HeapBlockHeader *next; // NULL for anything besides status 0
}
struct Heap {
void *base;
u32 processId;
u32 size;
struct HeapBlockHeader *firstBlock;
}
</pre>
When writing an aligned copy of a block, IOS does not check if it overlaps the existing copy; this could potentially be exploited.

Revision as of 05:49, 9 April 2022

The IOS kernel is responsible for dispatching interrupts to processes, handling syscalls, and running the IOSP threads. It is independent of the Wii's specific architecture, as Wii-specific functions such as high-level title launching are provided by ES.

Threads

IOS uses this struct to keep track of a thread. The first 0x40 bytes may belong to an OSContext-like struct.

struct IOS_Thread {
	u32 cpsr; // 0x0
	u32 r0; // 0x4
	u32 r1; // 0x8
	u32 r2; // 0xC
	u32 r3; // 0x10
	u32 r4; // 0x14
	u32 r5; // 0x18
	u32 r6; // 0x1C
	u32 r7; // 0x20
	u32 r8; // 0x24
	u32 r9; // 0x28
	u32 r10; // 0x2C
	u32 r11; // 0x30
	u32 r12; // 0x34
	void *sp; // 0x38
	void *lr; // 0x3C
	void *resumeAddr; // 0x40
	struct IOS_Thread *next; // 0x44
	u32 unknown; // 0x48
	s32 priority; // 0x4C
	u32 state; // 0x50
	u32 unknown2[4]; // 0x54
	struct IOS_Thread **nextPointer; // 0x64
}

Memory allocation

Memory allocation is similar to in the IPC library.

struct HeapBlockHeader {
	u16 magic; // 0xbabe
	u16 status; // 0 = free, 1 = allocated, 2 = aligned alias for header
	u32 size;
	struct HeapBlockHeader *prev; // depends on status; status 0 has the previous free block, status 1 has NULL, status 2 has the main block
	struct HeapBlockHeader *next; // NULL for anything besides status 0
}

struct Heap {
	void *base;
	u32 processId;
	u32 size;
	struct HeapBlockHeader *firstBlock;
}

When writing an aligned copy of a block, IOS does not check if it overlaps the existing copy; this could potentially be exploited.