The Windows NT Startup Process – Detailed!

This document is for Windows NT v3.1 to Server 2003, x86 architecture. Alpha, Mips, and PowerPC is not documented in this article :).

NT Startup begins with the bootcode itself, we’ll take a look at the FAT version.

During initial system startup, the BIOS scans for devices to boot from, now, the Hard Disk is one of them (if it is installed), if it is installed, we call the bootcode for it by loading the first 512 bytes into RAM, this is the bootsector. The bootsector or bootcode scans for NTLDR in the filesystem file table. NTLDR loads itself with the following register contents when one uses FAT16/FAT12:

BX => Starting cluster number of Nt loader
DL => Int 13h drive number
DS:SI => Boot media BPB
BS:DI => argument structure
1000:0000 => entire FAT table

Then, we read NTLDR and execute a far jump to 2000:0003, where NTLDR starts. NTLDR is formally called with prototype:

[c]VOID
NtProcessStartup(
IN PBOOT_CONTEXT BootContextRecord
);[/c]

Then, we have a hacky subroutine known as BlStartup, which fools the ARC NT loader into thinking that we’re actually running on a ARC system. We call it with parameters:

load osloader=\System32\NTLDR systempartition=%s
osloadfilename=%s osloadpartition=%s osloadoptions=%s
consoleinputname=multi(0)key(0)keyboard(0)
consoleout=multi(0)video(0)monitor(0) x86systempartition=%s

NTLDR then loads its own configuration subsystem, and memory manager and creates the initial kernel loader block structure.

[c]typedef struct _LOADER_PARAMETER_BLOCK
{
LIST_ENTRY LoadOrderListHead;
LIST_ENTRY MemoryDescriptorListHead;
LIST_ENTRY BootDriverListHead;
ULONG KernelStack;
ULONG Prcb;
ULONG Process;
ULONG Thread;
ULONG RegistryLength;
PVOID RegistryBase;
PCONFIGURATION_COMPONENT_DATA ConfigurationRoot;
CHAR * ArcBootDeviceName;
CHAR * ArcHalDeviceName;
CHAR * NtBootPathName;
CHAR * NtHalPathName;
CHAR * LoadOptions;
PNLS_DATA_BLOCK NlsData;
PARC_DISK_INFORMATION ArcDiskInformation;
PVOID OemFontFile;
_SETUP_LOADER_BLOCK * SetupLoaderBlock;
PLOADER_PARAMETER_EXTENSION Extension;
BYTE u[12];
FIRMWARE_INFORMATION_LOADER_BLOCK FirmwareInformation;
} LOADER_PARAMETER_BLOCK, *PLOADER_PARAMETER_BLOCK;[/c]

This structure gets passed to the kernel after NTLDR loads all device driver PE objects into RAM, then we call SystemInitRoutine, which has prototype:

[c]typedef
VOID
(*PTRANSFER_ROUTINE) (
PLOADER_PARAMETER_BLOCK LoaderBlock
);[/c]

Which, in reality is _KiSystemStartup@24 in ntoskrnl. Ntoskrnl then reserves its own memory space and gets processor number and checks if the current processor is the boot processor. Next, we initialize the PCR (processor control region), another large structure:

[c]typedef struct _KPCR
{
union
{
NT_TIB NtTib;
struct
{
PEXCEPTION_REGISTRATION_RECORD Used_ExceptionList;
PVOID Used_StackBase;
PVOID Spare2;
PVOID TssCopy;
ULONG ContextSwitches;
ULONG SetMemberCopy;
PVOID Used_Self;
};
};
PKPCR SelfPcr;
PKPRCB Prcb;
UCHAR Irql;
ULONG IRR;
ULONG IrrActive;
ULONG IDR;
PVOID KdVersionBlock;
PKIDTENTRY IDT;
PKGDTENTRY GDT;
PKTSS TSS;
WORD MajorVersion;
WORD MinorVersion;
ULONG SetMember;
ULONG StallScaleFactor;
UCHAR SpareUnused;
UCHAR Number;
UCHAR Spare0;
UCHAR SecondLevelCacheAssociativity;
ULONG VdmAlert;
ULONG KernelReserved[14];
ULONG SecondLevelCacheSize;
ULONG HalReserved[16];
ULONG InterruptMode;
UCHAR Spare1;
ULONG KernelReserved2[17];
KPRCB PrcbData;
} KPCR, *PKPCR;[/c]

After this, Ntoskrnl initializes TSS structure, and then setup the NMI handler to handle NMI faults if raised by the hardware. After this, Ntoskrnl initializes the interprocessor interrupt vector and the processor count value to enable the kernel debugger subsystem. Then ntoskrnl calls KiInitializeKernel with prototype:

[c]VOID
KiInitializeKernel (
IN PKPROCESS Process,
IN PKTHREAD Thread,
IN PVOID IdleStack,
IN PKPRCB Prcb,
IN CCHAR Number,
PLOADER_PARAMETER_BLOCK LoaderBlock
);[/c]

This function gains control of the system after the bootstrap code was called, this function also initializes more core system structures, idle thread and process objects and the PCRB structure. After this, we call ExpInitializeExecutive to perform phase 0 initialization of the kernel subsystems, it has prototype:

[c]VOID
ExpInitializeExecutive(
IN ULONG Number,
IN PLOADER_PARAMETER_BLOCK LoaderBlock
);[/c]

The kernel then enables interrupts for x86, and initializes the translation tables by using the images that Ntldr passed to the kernel. ExpInitializeExecutive then initializes the crypto key exponent. Internal kernels can be built with a different key exponent, but it is always set to 0 when the kernels leave Microsoft. Then the kernel reinitializes hal.dll, and loads symbols for each driver (symbol loading in this stage was deprecated in Windows 2000). Then we retrieve the system control values (CmNtGlobalFlag) out of the registry and we do a logical OR on NtGlobalFlag with CmNtGlobalFlag’s values. Mm or Memory manager is then initialized along with page burning (/BURNMEMORY or /MAXMEM). Now, we initialize bootvid/Inbv in Windows 2000 or later, and we display system version on the console. After this, we initialize the Object Manager (ObInitSystem), Security subsystem (SeInitSystem) and process manager (PsInitSystem). These subsystems form the core of the NT kernel’s base functionality, along with Rtl or runtime library. Then, we initialize the plug and play subsystem (PpInitSystem). PsInitSystem creates a new thread using PsCreateSystemThread:

[c] //
// Phase 1 System initialization
//

if ( !NT_SUCCESS(PsCreateSystemThread(
&ThreadHandle,
THREAD_ALL_ACCESS,
&ObjectAttributes,
0L,
NULL,
Phase1Initialization,
(PVOID)LoaderBlock
)) ) {
return FALSE;
}[/c]

This thread controls phase 1 initialization. Phase 1 reinitializes Hal, Po, Ob, Se subsystems along with Executive (Ex), and kernel phase 1 (Ke) subsystems. We also start all non-boot processors in the SMP kernel (Ntkrnlmp) by calling KeStartAllProcessors();, processor licensing is also enforced.

[c] if ( KeLicensedProcessors ) {
if ( KeRegisteredProcessors > KeLicensedProcessors ) {
KeRegisteredProcessors = KeLicensedProcessors;
}
}[/c]

Ntoskrnl then creates the symbolic link to \SystemRoot and maps the System DLL (ntdll.dll) into userspace and loads it after Lpc subsystem and I/O subsystem are initialized. We then null out the loaderblock so that drivers can’t get ahold of it anymore ;). Then we execute smss.exe from %SystemRoot%\System32\smss.exe to start the rest of the user-mode subsystems such as Win32.

We leave kernel mode once the thread has started, and you see the windows desktop/windowstation in a matter of seconds after win32k/csrss is loaded. 🙂

eEID splitter

[c]#include <stdio.h>
#include <stdlib.h>

void
DumpEidData (FILE * pFile, int iInputSize, int iEidCount)
{
FILE *pOutput;
char szFileName[8];
char *szBuf;
int iRes, iSize;

printf("dumping EID%s from eEID at %p, size %d (%x)..\n",
iEidCount, pFile, iInputSize, iInputSize
);

szBuf = (char *) malloc (iInputSize + 1);

if (szBuf == NULL)
{
perror ("malloc");
exit (1);
};

iSize = fread (szBuf, iInputSize, 1, pFile);
sprintf (szFileName, "EID%d", iEidCount);
pOutput = fopen (szFileName, "wb");
iRes = fwrite (szBuf, iInputSize, 1, pOutput);

if (iRes != iSize)
{
perror ("fwrite");
exit (1);
};

free (szBuf);
}

int
main (int argc, char **argv)
{
FILE *pFile;

pFile = fopen (argv[1], "rb");
if (pFile == NULL)
{
printf ("usage: %s <eEID>\n");
exit (1);
}

fseek (pFile, 0x70, SEEK_SET);

DumpEidData (pFile, 2144, 0);
DumpEidData (pFile, 672, 1);
DumpEidData (pFile, 1840, 2);
DumpEidData (pFile, 256, 3);
DumpEidData (pFile, 48, 4);
DumpEidData (pFile, 2560, 5);
}[/c]

Let's blow some fuses

Today, let’s take a little break from PS3, and look at the Xbox360. Now, let’s start at kernel entrypoint, KiProcessorStartup, which calls KiInitializeKernel on the boot processor, KiInitializeKernel has prototype (on x86/x64):

[c]VOID
KiInitializeKernel (
IN PKPROCESS Process,
IN PKTHREAD Thread,
IN PVOID IdleStack,
IN PKPRCB Prcb,
IN CCHAR Number,
PLOADER_PARAMETER_BLOCK LoaderBlock
);[/c]

You get a good feeling what the real prototype would be on Xbox. Now, KiInitializeKernel, like on x86, initializes Xbox Hardware, boot processor, HV subsystem, and kernel debugger subsystem (KdInitializeSystem). Then, it calls XexScanKernelImage to scan a shadow kernel on \Device\Flash, and load it, and then we call KiInitializeKernel2, which does part of Phase 1 System initialization. KiInitializeKernel2 initializes symbolic Object Manager (ObInitializeSystem), and FS Subsystem (FscInitializeSystem), then we use ExCreateThread to create a new thread with the function Phase1Initialization. If this thread terminates, we have a bugcheck or “BSOD” for you Windows newbies :p. Phase1Initialization does SMP Processor initialization by calling KeStartupProcessors, which uses the HAL to start the processors. Then, we see it loading XeKeysInitialize, which is literally the “key vault”. Next, we call the hal again to initialize phase 1 of it, and also initialize RTC and system time, and also set delta because of SMP init, then we load the internal driver “Sfcx”, and then load yet another key vault, XeKeysExLoadKeyVault, then ExpInitializeSettings is called to load system settings, then it does Power init, including TV init. After this, Xboxkrnl loads the other drivers: “SataDisk”, “SataCdrom”, “XInputd”, “Usbd”, and charge mode monitor driver. Then, we see the animation loaded with AniStartBootAnimation. Right before this, we initialize the Audio and Video systems with XMADecoderDriverInitialize/XAudioRenderDriverInitialize and for video VdDriverEntry. Then, we reinitialize SataDisk and SataCdrom, along with Dump subsystem. Then, we initialize more drivers: “Mass”, “Omni”, “Wvc”, “Rvc”, “Xcam”, “Mic”, “Nic” and STFS filesystem. Right after this we load Xam.xex from \Device\Cdrom0, and then dash.xex from \Device\Flash and transfer control to it. If these fail to initialize, we get a nice bugcheck, and the thread terminates.

Bugchecks just send the output to the local debug port, and the host running WinDbg.

And to finish this off, I shall leave you with this:

[c].text:800701E0
.text:800701E0 HvxBlowFuses:
.text:800701E0 li %r0, 0x22
.text:800701E4 sc
.text:800701E8 blr
.text:800701E8 # End of function HvxBlowFuses
.text:800701E8[/c]

Yet another rant on 3.56 CFW

First off, shout out to eussNL and adrianc for providing the entertainment and links to this article. 🙂

Let’s look at this so called ONYX project made by some NGU kid.

“1st of all thanx guys 4 the support & emails, taking friday off work, gonna dig deep today into these pesky rootkit sub-routines, 3rd workstation working like a charm in picking up the speed in allocating classes & variables…recursion of these algorithms is making a bit simpler for me to understand what sony implemented in 3.56 OFW….that’s a rap for now…..peace….”

OK, so what’s wrong here? There’s no rootkit in 3.56 at all, hint, keyword, no. Next, what does he mean by algorithm recursion making life simpler? Loops in code (for(…)), sure they make life simpler, but they can also be used for hacky situations and all, any programmer should know about those. Algorithm is also the wrong word to even use there. Now, Lv-2 is programmed mainly in C++, so yes, it uses Classes and Namespaces, but there are some functions with linkage “extern C { … }”, so yeah, no Classes for them. Lv-2 in retail and debug firmware is also stripped using ppu-lv2-strip or something quite similar to it. Luckiest you’ll get is a .strtab section. Variable names are never kept in the .symtab section as far as I know, maybe an assertion though. 🙂

So now I’ve got 2 issues to work on at once, ONYX 3.56 CFW & a new approach on bypassing 3.56 OFW.
OFW 3.56 BYPASS is EMINENT : Please read thread above.
As far as ONYX goes, I’m adding a third workstation to my server to keep up with the computing demand of my other 2 stations. Both of them are maxing out at 100% CPU usage…stay tuned…peace…

Uh, if I can reverse engineer/program on one regular old dual Pentium 4 PC at 2.66GHz with 2GB ram well, why would one need 3 more? It’s not like you’re running 5 instances of SharePoint 2010 with Office WebApps and SQL Server 2010 with a 100 user load on one box, THAT is overkill. My CPU load averages around 25% to 50%, now, thats because I multitask and all. 🙂

A lot of people have been asking me bout project ONYX 3.56 CFW. After couple of weeks of tweeking code, i’m almost done with my ONYX 3.56 CFW,. I should have this done by the end of February. I’ve been working on some key generation issues at the moment… trying to get the root kit bypass to work without sony spoofing dynamic IP addresses, DNS bypasses, and Proxy servers.

Oh god, don’t tell me, he’s pretending to make false keys, now we all know the ECDSA fail was fixed in 3.56 by making the ‘r’ value in the ECDSA signature field/struct random, thus not allowing us to use algebra to get the private key (dA or k).

I’m almost home free with re-compiling all the coding, I have 2 workstations running diagnostics & deassembling the thousand’s of lines of decoy coding sony implemented in their 3.56OFW….

Decoy coding? What the hell are you speaking?! Uh, never heard of it, ever, and I /do/ know programming, Mr. EndeverouX.

Now, I have a challenge for you Mr. EndeverouX, make sense of this:

.text:00002348                 ori     $r81, $r8, 0
.text:0000234C                 stqd    $r89, -0xA0($SP)
.text:00002350                 ori     $r88, $r3, 0
.text:00002354                 stqd    $r94, -0xF0($SP)
.text:00002358                 ori     $r89, $r4, 0
.text:0000235C                 stqd    $r95, -0x100($SP)
.text:00002360                 ori     $r94, $r6, 0
.text:00002364                 stqd    $r82, -0x30($SP)
.text:00002368                 ori     $r95, $r7, 0
.text:0000236C                 stqd    $r83, -0x40($SP)
.text:00002370                 il      $r3, -2
.text:00002374                 lno

Tell me when you figure out what that does.

Fun with LEDs

PS3 LED fun

That is all. 🙂

How to fix the Wankybrick for NAND consoles

OK, so we all know about how the original Waninkoko firmware broke the older large NAND consoles, that was due to him overwriting some portions of Cell-OS Lv2 and the segment boundaries, god knows about the signature also. He also zeroed out a good section of the kernel, and also breaks some NAND consoles due to that. Now, you want to fix this issue? Well, you have to have:

1) A NAND Dumper
2) CORE_OS_PACKAGE.PKG patched to remove signature checks or Official Core OS/PS3 in Service Mode
3) A NAND Flasher
4) Flow Rebuilder
5) Hex editor
6) PS3 with firmware less than 3.55

OK, so you first have to dump both NAND chips (2 128MB NANDs for a total of 256MB) and interleave them using Flow Rebuilder, then decrypt the CORE_OS package to give you a raw core OS image, then open your combined NAND dump in a hex editor and search for “6F FF E0” in the search for hex section. Once there, you should see:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 6f ff e0  |.............o..|
00000010  00 00 00 01 00 00 00 17  00 00 00 00 00 6f ff e0  |.............o..|

Right after the second “6F FF E0”, remove the next 7,340,000 bytes, then, insert the unpacked Core OS (7,340,000 bytes). Then split the image using Flow Rebuilder (use ECC!) and flash. Hopefully it should work, and then you can just Lv2diag your way out.

Do not overwrite anything else.

This guide should help you fix any NAND console with Core OS fail.

New hosting!

A shout out to Dukio for getting me some better hosting, much better than the previous one I used. It’s really nice.

Well, Update your bookmarks to http://rms.dukio.com. I’ll be here from now on. =)

NOR Unpkg – The Tool

[c]/*
# ../norunpkg norflash.bin norflash
unpacking asecure_loader (size: 190xxx bytes)…
unpacking eEID (size: 65536 bytes)…
unpacking cISD (size: 2048 bytes)…
unpacking cCSD (size: 2048 bytes)…
unpacking trvk_prg0 (size: 131072 bytes)…
unpacking trvk_prg1 (size: 131072 bytes)…
unpacking trvk_pkg0 (size: 131072 bytes)…
unpacking trvk_pkg1 (size: 131072 bytes)…
unpacking ros0 (size: 7340032 bytes)…
unpacking ros1 (size: 7340032 bytes)…
unpacking cvtrm (size: 262144 bytes)…
*/

// Copyright 2010 Sven Peter
// Licensed under the terms of the GNU GPL, version 2
// http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
// nor modifications by rms.

#include "tools.h"
#include "types.h"

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/stat.h>

#ifdef WIN32
#define MKDIR(x,y) mkdir(x)
#else
#define MKDIR(x,y) mkdir(x,y)
#endif

u8 *pkg = NULL;

static void unpack_file(u32 i)
{
u8 *ptr;
u8 name[33];
u64 offset;
u64 size;

ptr = pkg + 0x10 + 0x30 * i;

offset = be64(ptr + 0x00);
size = be64(ptr + 0x08);

memset(name, 0, sizeof name);
strncpy((char *)name, (char *)(ptr + 0x10), 0x20);

printf("unpacking %s (size: %d bytes)…\n", name, size);
memcpy_to_file((char *)name, pkg + offset, size);
}

static void unpack_pkg(void)
{
u32 n_files;
u64 size;
u32 i;

n_files = be32(pkg + 4);
size = be64(pkg + 8);

for (i = 0; i &lt; n_files; i++)
unpack_file(i);
}

int main(int argc, char *argv[])
{
if (argc != 3)
fail("usage: norunpkg filename.nor target");

pkg = mmap_file(argv[1]);

/* kludge for header, i do not do sanity checks at the moment */
pkg += 1024;

MKDIR(argv[2], 0777);

if (chdir(argv[2]) != 0)
fail("chdir");

unpack_pkg();

return 0;
}[/c]

Enjoy.

The downgrade process

Ok, so today’s topic is on how the service mode updater works, and why it does what it does, and what the updater logs on /dev_usb000 mean.

manufacturing updating start
PackageName = /dev_usb000/PS3UPDAT.PUP
settle polling interval success

This means that the manufacturing_updater_for_reset.self file was started successfully, and it found a PS3 update file on the drive, and it set the polling interval so the SELF can retrieve the file using some poll() like function. Now, here’s where updaters diverge. Older PS3s use NAND and newer PS3s use NOR and vFlash. vFlash is where the flash device is actually the hard disk. If vflash is enabled, you get this in the updater log:

vflash is enabled...
creating system regions...
create storage region: (region id = 1)
create storage region: (region id = 2)
format partition: (region_id = 2, CELL_FS_UTILITY:HDD0, CELL_FS_UFS)
create storage region: (region id = 3)
format partition: (region_id = 3, CELL_FS_UTILITY:HDD1, CELL_FS_FAT)
creating system regions done.

What this means, is that its creating 3 regions, 1 FAT16, that’s where the dev_flash directory is, and one UFS partition, along with another raw. If you’re using NAND, you’ll see:

vflash is disabled...
boot from nand flash...
creating flash regions...
create storage region: (region id = 2)
format partition: (region_id = 2, CELL_FS_IOS:BUILTIN_FLSH1, CELL_FS_FAT)
create storage region: (region id = 3)
format partition: (region_id = 3, CELL_FS_IOS:BUILTIN_FLSH2, CELL_FS_FAT)
create storage region: (region id = 4)
format partition: (region_id = 4, CELL_FS_IOS:BUILTIN_FLSH3, CELL_FS_FAT)
create storage region: (region id = 5)
create storage region: (region id = 6)

What’s happening here is that it’s formatting /dev_flash, dev_flash2, and dev_flash3 as FAT16, and flagging the other 2 regions as ROS, both backup and current Core OS. If one uses NOR, they will see:

boot from nor flash...
creating nor flash regions...
create storage region: (region id = 2)
create storage region: (region id = 3)
creating flash regions...
create storage region: (region id = 1)
create storage region: (region id = 2)
format partition: (region_id = 2, CELL_FS_IOS:BUILTIN_FLSH1, CELL_FS_FAT)
create storage region: (region id = 3)
format partition: (region_id = 3, CELL_FS_IOS:BUILTIN_FLSH2, CELL_FS_FAT)
create storage region: (region id = 4)
format partition: (region_id = 4, CELL_FS_IOS:BUILTIN_FLSH3, CELL_FS_FAT)
create storage region: (region id = 5)
create storage region: (region id = 6)

What’s happening is here that the regions on the hard disk are abstracted to the fake devices dev_flash2/3 and dev_flash, along with the 2 ROS regions. Remember, the header stays static, but the 7,340,000 byte part is replaced. ROS is never formatted. Then UPL.xml.pkg is read and then the updater enumerated which packages to install. It first starts with Package revoke, which is stored as trvk_pkg0/1 in NOR/NAND, then it updates Core OS, followed by VSH and all of the tarballs it has. Then, the updater updates the Bluray drive Revoke list which it calls “Bul-ray”. Here’s another place where the 2 PS3 types diverge:

read bdp revoke package (1904 bytes) elapsed = 27 msec
decrypt and verify bdp revoke package elapsed = 49 msec
write bdp revoke package elapsed = 135 msec
flush_cache(0x100000000000001)
flush_cache() SUCCESS
compare bdprevoke package elapsed = 101 msec

Here, we can see that the BD revoke list is also updated, but on NAND, since the dev_flash3 files were wiped, we have the out of sync situation. Then the program revoke list is flashed as trvk_prg0/1. On NOR consoles, the BD drive firmware is also flashed:

Update BD firmware
read BD firmware package (1966992 bytes) elapsed = 224 msec
update BD firmware elapsed = 293 msec
read BD firmware package (951040 bytes) elapsed = 123 msec
update BD firmware elapsed = 251 msec
read BD firmware package (951040 bytes) elapsed = 127 msec
update BD firmware elapsed = 250 msec
read BD firmware package (951040 bytes) elapsed = 126 msec
update BD firmware elapsed = 256 msec
read BD firmware package (1639296 bytes) elapsed = 199 msec
update BD firmware elapsed = 263 msec
read BD firmware package (787200 bytes) elapsed = 111 msec
update BD firmware elapsed = 250 msec
Update BD firmware done(0x8002f000)

After this BD firmware is also updated. Following that, MultiCard firmware is flashed, followed by Bluetooth firmware, then we see that the SYSCON is patched with the 4864 byte firmware update. Then, the updater does some postprocessing on the system to finalize firmware installation, then verifies the firmware. We then see the output of the log, the final installed system information, along with updater time:

cleanup update status (ret = 0)
os version = 03.1500
build_version = 38031,20091206
region of core os package = 0x40000000
build_target = CEX-ww
build target id = 0x83
manufacturing updating SUCCESS(0x8002f000)
set product mode (ret = 0)
Total Elapsed time = 163245 msec

Let's look at SYSCON.

Hi, today’s PS3 subject is about the SYSCON. SYSCON or SC controls the system, it’s a SM Bus Controller if you think about it. SYSCON controls the System LEDs (Green, Yellow, Blue, and Red), and whether they flash slowly, quickly or are turned off entirely. SYSCON also does temperature control, along with some other fun things, let’s look at them.

Ok, so in graf_chokolo’s documentation on HV, we see that the SYSCON Manager or SC manager lies in Lv-1, process ID (PID) 5, and controls SYSCON obviously, but we cannot access that due to restrictions in DM or Dispatch Manager in HV. Now, what’s in SC Manager you ask. Once can set RTC, or prepare TRM. TRM in HV decrypts certain keys such as the USB Master Dongle Authentication key, or revoked QA tokens I believe. SC Manager can also set the region of the console, or get the region, along with other fun things. Do note that DM ignores packet requests for services, so you have to use the Update Manager or UM to do things.

SYSCON EEPROM has several fun offsets:

Offset	Size	Description
0x48C06	1	FSELF Control Flag
0x48C07	1	Product Mode (UM allows to read this offset, it can be also written but only when already in product mode)
0x48C0A	1	QA Flag
0x48C13	1	Device Type
0x48C42	1	HDD Copy Mode
0x48C50	0x10	Debug Support Flag
0x48C60	1	Update Status
0x48C61	1	Recover Mode Flag
0x48D3E	0x50	QA Token (UM doesn’t allow access to this offset but SC Manager can read/write it)
0x48C30	0x01	Number of usable SPEs, usually set to 0x06, can be set to 0x07 to enable all 8 SPEs in Cell/BE

That’s from graf_chokolo’s HV documentation, but do note, it /is/ possible to generate a “working” token for QA token, using another part of the system, but it is what you would call a “false-token”. It does not unlock anything fancy, only the repository node in Lv-1. Token requires a seed and it is formed from that seed and the EID0 of your console I think. QA Flag requires the QA Token to work. FSELF flag controls whether FSELFs can run as “root” or have modified control flags, sort of like the way PSGroove does things with 3.41. Debug Support is currently unexplored territory, but it has to do with debug permissions. Recover Flag allows backup (ros1) Core OS in NOR/NAND, (see previous post) to be run instead of ros0 (regular Core OS), I’ve never seen this flag set. Update Status determines whether you are in updater mode, and whether to run ps3swu.self from /dev_hdd0. Device Type controls whether you are in Service mode or not, value 0xFF is retail, and 0x00 is Factory/Service mode.  HDD Copy Mode is pretty much self explanatory.

It is also possible to visualize this data as a struct if you want to:

struct {
   unsigned char fselfControl;
   unsigned char productMode;
   unsigned char qaFlag;
   unsigned char deviceType;
   unsigned char hddCopyMode;
   unsigned char debugSupport[10];
   unsigned char updaterMode;
   unsigned char recoverRosMode;
   unsigned char qaToken[50];
} sc_eeprom_t;

Oh, and token seed is 0x50 bytes also, it can be calculated also.

You can still write to SC EEPROM using PSGroove, it’s not really hard, just use some Lv-1 undocumented functions in your payload. 😉