galaxy.prx and march33.prx

[COLINx86]

what are they? do they even have a purpose?

[Anti-QuickJay]

They must have a purpose if they are in the firmware. -_-

[brethren]

Originally Posted by COLINx86

what are they? do they even have a purpose?

they are prx's from m33 custom firmware. galaxy.prx i believe does the patches that enable us to use sonys inbuilt iso loader. just coz their names aren't descriptive of their purpose doesn't mean they aren't important

[wrcsti]

galaxy seems to be the np9669.prx patcher for no umd. as for march33.prx i would need a way to decompres it to a .c file and see a bit of what it does

[Anti-QuickJay]

Galaxy.prx ~ M33GalaxyController
March33.prx ~ pspMarch33_Driver

Galaxy.prx has something to do with sceNp9660_driver
I'm guessing March33.prx is the thing that changes the time/date to march after you update to M33 firmware.

Spoiler for Galaxy.prx:

Released OE source

// galaxy.prx from M33 3.51
//
// Not complete
//

SceUID SceNpUmdMount_thid = -1;

int _start()
{
	u32 *mod = sceKernelFindModuleByName("sceThreadManager");
	u32 text_addr = *(mod+27);

	// Patch within ThreadManForKernel Library Export Table

	// Replace sceKernelCreateThread export with our own
	// Use this to capture when np9660.prx creates its threads
	_sw(sceKernelCreateThread_fake, text_addr+0x16BC0);

	// Replace sceKernelStartThread export with our own
	_sw(sceKernelStartThread_fake, text_addr+0x16D54);

	clear_cache();

	return 0;
}

SceUID sceKernelCreateThread_fake(char *name, SceKernelThreadEntry entry, int initPri, int stackSize, int attr, SceKernelThreadOptParam *option)
{
	SceUID thid = sceKernelCreateThread(*name, entry, initPri, stackSize, attr, *option);

	// Check if np9660.prx is the one creating thread
	if (strncmp(*name, "SceNpUmdMount", 13) == 0)
	{
		SceNpUmdMount_thid = thid;
	}

	return(thid);
}

int sceKernelStartThread_fake()
{
	if (thid != SceNpUmdMount_thid)
	{
		return (sceKernelStartThread(thid, argSize, argp));
	}

	u32 *mod = sceKernelFindModuleByName("sceNp9660_driver");
	sceNp9660_text_addr = *(mod+27);

	// Patch within the open_disc_image function

	// Patch InitForKernel_48348387 function to return 0x80000000
	// Function returns address of iso image
	_sw(0x3C028000, sceNp9660_text_addr+0x1808);

	// Replace the decryption function with our own
	_sw(MIPS_JAL(sub_324), sceNp9660_text_addr+0x181C);

	// Patch functions called by the new np9660 ioread & iodevctl funcs
	_sw(MIPS_JAL(sub_244), sceNp9660_text_addr+0x1D68);
	_sw(MIPS_JAL(sub_244), sceNp9660_text_addr+0x2DAC);

	_sw(MIPS_J(sceIoClose_fake), sceNp9660_text_addr+0x4348);

	dword_1100 = sceNp9660_text_addr+0x1220; // _sceUmdCheckMedium
	dword_1104 = sceNp9660_text_addr+0x2290; // _Np9660FdMutexLock
	dword_1118 = sceNp9660_text_addr+0x22CC; // _Np9660FdMutexUnLock
	
	return (sceKernelStartThread(thid, argSize, argp));
}

[wrcsti]

actually, i just decompressed march33.prx and i think its the other no umd mode as it says m33 driver something. hope we helped

[TMadd]

why does team m33 like the number 3 so much??? march33 = m33 march equals third month and when you upgrade to their firmware it even says something about the time: 3:33 whats with 3???

[explosions]

Originally Posted by TMadd

why does team m33 like the number 3 so much??? march33 = m33 march equals third month and when you upgrade to their firmware it even says something about the time: 3:33 whats with 3???

Ask this guy.