Tiff Exploit - HEN Information

[irekski]

really guys you aint paying any shit for davee to do this... so shut up and wait. damn how ignoramus can you guys get... heck davee should charge LOL..

damn... if i were davee and this is what i get for doing something for the PSP world and free i would stop the project so people would realize how ungrateful and disrespectful you assess can be tsk3...

 

[TRFyuki]

really guys you aint paying any shit for davee to do this... so shut up and wait. damn how ignoramus can you guys get... heck davee should charge LOL..

damn... if i were davee and this is what i get for doing something for the PSP world and free i would stop the project so people would realize how ungrateful and disrespectful you assess can be tsk3...

I look at the current president of USA; he wants to help everyone. In that group of "everyone", there are people who like him and will benefit from his work. There are people who hate him or think he's too slow, but Obama has to help them too. Ya just can't make everyone happy - no matter how much you try or don't try.

That being said - it was the missed HEN date that started this fire. Then there was little word of what was going on and the skeptics and haters started to sprout up. Not sayin' they're justified; but people aways find something to hate on... and for DaveeHEN, the missed HEN date is the excuse for all the "is-it-done-yet" posts.

I just hope DaveeHEN comes out this month.

 

[Taneko91]

I have the same problem(psp store work only at 5.50and the hen only at 5.03)

 

[Wolfking77]

No the ps store wont be able to be used anymore untell a homebrew or CFW or something is released for davees hen in order to acess ps store (for example 5.0M33-6 can acess ps store even though its not right firmware). So you just need to use the media thingy that lets you download ps store stuff onto your computer, and then just put a usb in psp and computer and put the files in the approprate folder
(oh god my spelling is getting worse :scared

 

[brnards13]

Davee post a picture on MfM Chats

Link : http://www.x-fusion.co.uk/gpsp3000.jpg

 

[PSP767]

Davee post a picture on MfM Chats

Link : http://www.x-fusion.co.uk/gpsp3000.jpg

More proof that he is making progress, good sign

 

[cloudcatcher]

Davee post a picture on MfM Chats

Link : http://www.x-fusion.co.uk/gpsp3000.jpg

yes that's what we wanna see

and it's the difficult 3k

 

[TRFyuki]

Also, for those who are curious about why this is difficult - the technical stuff going on behind homebrew... particularly why 1.50 FolderName% home won't work on DaveeHEN(newer firmware) ...here's the stuff I learned about when I was messing around with dev'ing for 1.50 PSP.

*Disclaimer* : I bet someone is gonna come in and tell me how wrong I am, but I still think the issues are somewhere around what I'm about to say .

First, an exploit is found(BufferOverflow) so that homebrew code can be run. I leave it to the reader to look up the concept of BufferOverflow. It's already known that the PSP runs compiled C code; cuz C is fastest and all modern game consoles are written in C/C++ and PC games tend to be VC++.

Spoiler: Hide

First, the address of all the sce(Sony Computer Entertainment) functions. I don't know what's going on today, but back in the day hackers had to dump kernel and/or memory to find all those values and they went into an assembly language file. I was on the forums back when people were arguing about the "sce" prefix. I'm very happy to see Davee stuck with that standard with the src code on the Davee-Bubbletune site. It's illogical not to do it that way. My file was really long with all kinds of address.. but it looked like this:

STUB_START "ModuleMgrForKernel",0x40010000,0x00130005
  STUB_FUNC 0xabe84f8a,sceKernelLoadModuleBufferWithApitype
  STUB_FUNC 0xba889c07,sceKernelLoadModuleBuffer
  STUB_FUNC 0xb7f46618,sceKernelLoadModuleByID
  STUB_FUNC 0x437214ae,sceKernelLoadModuleWithApitype
  STUB_FUNC 0x977de386,sceKernelLoadModule
  STUB_FUNC 0x710f61b5,sceKernelLoadModuleMS
  STUB_FUNC 0x91b87fae,sceKernelLoadModuleVSHByID
  STUB_FUNC 0xa4370e7c,sceKernelLoadModuleVSH
  STUB_FUNC 0x23425e93,sceKernelLoadModuleVSHPlain
  STUB_FUNC 0xf9275d98,sceKernelLoadModuleBufferUsbWlan
  STUB_FUNC 0xf0cac59e,sceKernelLoadModuleBufferVSH
  STUB_FUNC 0x50f0c1ec,sceKernelStartModule
  STUB_FUNC 0xd1ff982a,sceKernelStopModule
  STUB_FUNC 0x2e0911aa,sceKernelUnloadModule
  STUB_FUNC 0xd675ebb8,sceKernelSelfStopUnloadModule
.......blah blah...

Those hex numbers were obtained by dumping memory. Different embedded systems support different types of compiled C. I believe hackers had to take a PSP physically apart and identify the chipset on them; then lookup their specs on line. In the end.. the compile-line looked like this(for cygwin)

C:\PSPCYGWIN\ee\bin\ee-gcc.exe -march=r4000 -g -mgp32 -c -xassembler -O -o startup_ex.o startup_ex.s
C:\PSPCYGWIN\ee\bin\ee-gcc.exe -march=r4000 -g -mgp32 -mlong32 -c ExitCallback.c
C:\PSPCYGWIN\ee\bin\ee-gcc.exe -march=r4000 -g -mgp32 -mlong32 -c WorldGroove
C:\PSPCYGWIN\ee\bin\ee-ld.exe -O0 -G0 -lc startup_ex.o WorldGroove.o ExitCallback.o  -M -Ttext 8900000 -q -o out

And then there was an ELF patching to the "out" binary. Google ELF Object file format for that. I have no idea what that patching was about, but I assume the "out" binary created by all those compile commands above produces something close, but not exact, to what the PSP 1.50 would run.

You'd have to wrap up that out inside of an EBOOT.PBP, which contained the icon displayed "ICON0.PNG". The parameters of the code to boot; like size 'n stuff "PARAM.SFO" and finally the "out" bin file that was compiled previously. It'd be renamed to "DATA.PSP", if I remember correctly.
There was a tool for all that "PBP Unpacker"(which also can pack).

Inside the WorldGroove.c file, it would import constants that hackers would figure out. Back then, it looked something like:

#define SCREEN_WIDTH  480
#define SCREEN_HEIGHT 272

#define PIXELSIZE 1
#define LINESIZE 512
#define FRAMESIZE 0x44000

#define CTRL_SQUARE      0x8000
#define CTRL_TRIANGLE   0x1000
#define CTRL_CIRCLE      0x2000
#define CTRL_CROSS      0x4000
#define CTRL_UP         0x0010
#define CTRL_DOWN      0x0040
#define CTRL_LEFT      0x0080
#define CTRL_RIGHT      0x0020
#define CTRL_START      0x0008
#define CTRL_SELECT      0x0001
#define CTRL_LTRIGGER   0x0100
#define CTRL_RTRIGGER   0x0200
blah blah...

And finally... the WorldGroove.c file itself was

int xmain()
{
 int retc;
 char* buf;
 int hFile;

 //Enable HOME Button
 SetupCallbacks();

 retc = 7;
 buf = "Here we go!"; 

 hFile = sceIoOpen("ms0:/PSP/INIT.txt", O_CREAT|O_WRONLY|O_TRUNC, 0777);
 sceIoWrite(hFile, buf, sizeof(11));
 sceIoClose(hFile);  	 

 retc = sceKernelLoadModuleMS("ms0:/PSP/PRX/pspnet.prx", 0, 0);
 sceKernelStartModule(retc); 

 hFile = sceIoOpen("ms0:/PSP/sceLoadModule.txt", O_CREAT|O_WRONLY|O_TRUNC, 0777);
 sceIoWrite(hFile, "Still going!", 5);
 sceIoClose(hFile);  	 
   
 return 0; 
}

The reason it's "xmain", is because the assembly code that runs before it was called main and it figured out where xmain was...

_start:
		addiu 	$sp, 0x10
		sw		$ra, 0($sp)	
		sw		$s0, 4($sp)
		sw		$s1, 8($sp)

		move	$s0, $a0				# Save args
		move	$s1, $a1

		la  	$a0, _main_thread_name	# Main thread setup
		la		$a1, xmain
		li		$a2, 0x20				# Priority
		li		$a3, 0x40000			# Stack size
		lui		$t0, 0x8000				# Attributes
		jal		sceKernelCreateThread
		move	$t1, $0

		move	$a0, $v0				# Start thread
		move	$a1, $s0
		jal		sceKernelStartThread
		move	$a2, $s1

		lw		$ra, 0($sp)
		lw		$s0, 4($sp)
		lw		$s1, 8($sp)
		move	$v0, $0
		jr 		$ra
		addiu	$sp, 0x10

So... I'm people can see how new firmware/motherboards/etc can screw all that stuff above up!

 

[Wolfking77]

Davee post a picture on MfM Chats

Link : http://www.x-fusion.co.uk/gpsp3000.jpg

ROFL :laugh: i havn't seen that game in years lol. it could be fake but i dought it since davees not a faker this just means were 1 step closer to the HEN.
alittle off topic but anyways did anyone find the .gif files that granite used in the video, to be a little weird :huh: i mean they were named chickhena thats sorta funny but weird

 

[Atnas]

Davee post a picture on MfM Chats

Link : http://www.x-fusion.co.uk/gpsp3000.jpg

Wouldnt have been my first choice of game, but still good to see

 

[Nightmare270891]

OMG Pokemon....i miss those old days

 

[urgfman]

great work. Davee is really efficient.

 

[NoEffex]

Also, for those who are curious about why this is difficult - the technical stuff going on behind homebrew... particularly why 1.50 FolderName% home won't work on DaveeHEN(newer firmware) ...here's the stuff I learned about when I was messing around with dev'ing for 1.50 PSP.

*Disclaimer* : I bet someone is gonna come in and tell me how wrong I am, but I still think the issues are somewhere around what I'm about to say .

First, an exploit is found(BufferOverflow) so that homebrew code can be run. I leave it to the reader to look up the concept of BufferOverflow. It's already known that the PSP runs compiled C code; cuz C is fastest and all modern game consoles are written in C/C++ and PC games tend to be VC++.

Spoiler: Hide

First, the address of all the sce(Sony Computer Entertainment) functions. I don't know what's going on today, but back in the day hackers had to dump kernel and/or memory to find all those values and they went into an assembly language file. I was on the forums back when people were arguing about the "sce" prefix. I'm very happy to see Davee stuck with that standard with the src code on the Davee-Bubbletune site. It's illogical not to do it that way. My file was really long with all kinds of address.. but it looked like this:

STUB_START "ModuleMgrForKernel",0x40010000,0x00130005
  STUB_FUNC 0xabe84f8a,sceKernelLoadModuleBufferWithApitype
  STUB_FUNC 0xba889c07,sceKernelLoadModuleBuffer
  STUB_FUNC 0xb7f46618,sceKernelLoadModuleByID
  STUB_FUNC 0x437214ae,sceKernelLoadModuleWithApitype
  STUB_FUNC 0x977de386,sceKernelLoadModule
  STUB_FUNC 0x710f61b5,sceKernelLoadModuleMS
  STUB_FUNC 0x91b87fae,sceKernelLoadModuleVSHByID
  STUB_FUNC 0xa4370e7c,sceKernelLoadModuleVSH
  STUB_FUNC 0x23425e93,sceKernelLoadModuleVSHPlain
  STUB_FUNC 0xf9275d98,sceKernelLoadModuleBufferUsbWlan
  STUB_FUNC 0xf0cac59e,sceKernelLoadModuleBufferVSH
  STUB_FUNC 0x50f0c1ec,sceKernelStartModule
  STUB_FUNC 0xd1ff982a,sceKernelStopModule
  STUB_FUNC 0x2e0911aa,sceKernelUnloadModule
  STUB_FUNC 0xd675ebb8,sceKernelSelfStopUnloadModule
.......blah blah...

Those hex numbers were obtained by dumping memory. Different embedded systems support different types of compiled C. I believe hackers had to take a PSP physically apart and identify the chipset on them; then lookup their specs on line. In the end.. the compile-line looked like this(for cygwin)

C:\PSPCYGWIN\ee\bin\ee-gcc.exe -march=r4000 -g -mgp32 -c -xassembler -O -o startup_ex.o startup_ex.s
C:\PSPCYGWIN\ee\bin\ee-gcc.exe -march=r4000 -g -mgp32 -mlong32 -c ExitCallback.c
C:\PSPCYGWIN\ee\bin\ee-gcc.exe -march=r4000 -g -mgp32 -mlong32 -c WorldGroove
C:\PSPCYGWIN\ee\bin\ee-ld.exe -O0 -G0 -lc startup_ex.o WorldGroove.o ExitCallback.o  -M -Ttext 8900000 -q -o out

And then there was an ELF patching to the "out" binary. Google ELF Object file format for that. I have no idea what that patching was about, but I assume the "out" binary created by all those compile commands above produces something close, but not exact, to what the PSP 1.50 would run.

You'd have to wrap up that out inside of an EBOOT.PBP, which contained the icon displayed "ICON0.PNG". The parameters of the code to boot; like size 'n stuff "PARAM.SFO" and finally the "out" bin file that was compiled previously. It'd be renamed to "DATA.PSP", if I remember correctly.
There was a tool for all that "PBP Unpacker"(which also can pack).

Inside the WorldGroove.c file, it would import constants that hackers would figure out. Back then, it looked something like:

#define SCREEN_WIDTH  480
#define SCREEN_HEIGHT 272

#define PIXELSIZE 1
#define LINESIZE 512
#define FRAMESIZE 0x44000

#define CTRL_SQUARE      0x8000
#define CTRL_TRIANGLE   0x1000
#define CTRL_CIRCLE      0x2000
#define CTRL_CROSS      0x4000
#define CTRL_UP         0x0010
#define CTRL_DOWN      0x0040
#define CTRL_LEFT      0x0080
#define CTRL_RIGHT      0x0020
#define CTRL_START      0x0008
#define CTRL_SELECT      0x0001
#define CTRL_LTRIGGER   0x0100
#define CTRL_RTRIGGER   0x0200
blah blah...

And finally... the WorldGroove.c file itself was

int xmain()
{
 int retc;
 char* buf;
 int hFile;

 //Enable HOME Button
 SetupCallbacks();

 retc = 7;
 buf = "Here we go!"; 

 hFile = sceIoOpen("ms0:/PSP/INIT.txt", O_CREAT|O_WRONLY|O_TRUNC, 0777);
 sceIoWrite(hFile, buf, sizeof(11));
 sceIoClose(hFile);  	 

 retc = sceKernelLoadModuleMS("ms0:/PSP/PRX/pspnet.prx", 0, 0);
 sceKernelStartModule(retc); 

 hFile = sceIoOpen("ms0:/PSP/sceLoadModule.txt", O_CREAT|O_WRONLY|O_TRUNC, 0777);
 sceIoWrite(hFile, "Still going!", 5);
 sceIoClose(hFile);  	 
   
 return 0; 
}

The reason it's "xmain", is because the assembly code that runs before it was called main and it figured out where xmain was...

_start:
		addiu 	$sp, 0x10
		sw		$ra, 0($sp)	
		sw		$s0, 4($sp)
		sw		$s1, 8($sp)

		move	$s0, $a0				# Save args
		move	$s1, $a1

		la  	$a0, _main_thread_name	# Main thread setup
		la		$a1, xmain
		li		$a2, 0x20				# Priority
		li		$a3, 0x40000			# Stack size
		lui		$t0, 0x8000				# Attributes
		jal		sceKernelCreateThread
		move	$t1, $0

		move	$a0, $v0				# Start thread
		move	$a1, $s0
		jal		sceKernelStartThread
		move	$a2, $s1

		lw		$ra, 0($sp)
		lw		$s0, 4($sp)
		lw		$s1, 8($sp)
		move	$v0, $0
		jr 		$ra
		addiu	$sp, 0x10

So... I'm people can see how new firmware/motherboards/etc can screw all that stuff above up!

The PSP can run pretty much any compiled code so long as it is compiled into asm(MIPS r4000 I think it was) and the proper layout.

 

[jedimaster]

past time.. i love this game. haha

 

[tomcat70]

Great Davee! This picture explain everything. Thanx for your efforts mate!

 

[Perfect-skillz]

well at least we know that the HEN supports the GBA emulator that runs on 4.xx - 5.xx kernel's.

also it means that the PSP 3000 will run the 2000 apps/modules/plugins with little problem as long as no addresses are changed. which it doesn't look like sony made any real improvement besides the IPL and Pre-IPL address change.

 

[NoEffex]

well at least we know that the HEN supports the GBA emulator that runs on 4.xx - 5.xx kernel's.

also it means that the PSP 3000 will run the 2000 apps/modules/plugins with little problem as long as no addresses are changed. which it doesn't look like sony made any real improvement besides the IPL and Pre-IPL address change.

It can run pretty much anything that cfw can run so long as it doesn't import anything from the cfw lib, from what I understand.

 

[mikeevd]

Picture makes me happy, looks pretty good and almost finished. Then again I have no idea how things work under the hood so it might not even be close. But good pic.

 

[Perfect-skillz]

It can run pretty much anything that cfw can run so long as it doesn't import anything from the cfw lib, from what I understand.

right!!!!! but as people know the PSP 2000 series is slightly more limited in the Homebrew scene then the 1000 series, because of address changes(big one), IPL/ Pre-IPL address change, and the inability to run the 1.5 Kernel natively and must become a plugin that has to be added and either run off the MS on start-up or added (flashed) to flash 0.
but from what i'm getting, it runs the 2000 series 5.03 .tiff exploit with slight difficulty and seems to run the HEN with no problem :mellow:
so it could run 2000 series plugins/modules/apps so it will be easier to get CFW on it then we think

 

[UserUnknown]

So, with psp3k running HEN it should run any kernel?