• Steam recently changed the default privacy settings for all users. This may impact tracking. Ensure your profile has the correct settings by following the guide on our forums.

advanced slim.tiff

m0skit0 said:
Yes, you're right too. It mostly depends if MS is fake (no MG). Those are pretty useless for anything anyway.


yep, we can do nothing about about that, but if $ra points after the code, then the branch gets executed. Just to get a slightly higher probability ;)
Click to expand...

Yes, if it points *exactly* on the branch. Otherwise not. There's quite a slim chance of it happening, especially if you didn't place the branch exactly 0x100 bytes after the original start of the code :-P
 
Crank said:
Yes, if it points *exactly* on the branch.
Click to expand...
Emm, nope. There's a bunch of NOPs after the egg, you can check it. If it lands anywhere after the jump to 0x08800000 (where h.bin gets loaded), it will execute the branch. If it was like you said I wouldn't have bothered to do it.
 
m0skit0 said:
Emm, nope. There's a bunch of NOPs after the egg, you can check it. If it lands anywhere after the jump to 0x08800000 (where h.bin gets loaded), it will execute the branch. If it was like you said I wouldn't have bothered to do it.
Click to expand...

Crank is correct. NOPS mean nothing to where it jumps to. It stores crap data at entry + 8 so it doesn't matter where it happens, you get the same probability. The theory of your code is correct and it's great to see someone trying to stabilze this, but you need to research the exploit more.
 
I can not for the life of me get the R2 to work anymore. IS there some magic speed or way to load it?

WHen I go into photos I see EGG's (4 pictures) than the slim but it just locks up and turns off

20/20 times..
 
I don't understand, Davee. Can you please explain a little more?

We got a bunch of NOPs + egg + another bunch of NOPs + strings, all right? When you say entry + 8, to which entry are you referring to?
 
m0skit0 said:
I don't understand, Davee. Can you please explain a little more?

We got a bunch of NOPs + egg + another bunch of NOPs + strings, all right? When you say entry + 8, to which entry are you referring to?
Click to expand...
Check how the exploit works in paf.prx. The entry Davee is referring to is the return address. It stores junk data (specifically the stack pointer address) to return address + 8. Addresses rarely form any usable instructions. If the return address points to 4 bytes before your branch, it fucks up the delay slot.

But yeah, the idea is appreciated, even if it really didn't work out. :-)
 
But if it stores junk in return address + 8, then nothing can gets executed properly, as you'll end up executing that junk from the stack and it'll most likely crash. Anyway, I'll modify the egg to do some dumping to check that out.

Thanks for the explanation Crank :)
 
m0skit0 said:
But if it stores junk in return address + 8, then nothing can gets executed properly, as you'll end up executing that junk from the stack and it'll most likely crash. Anyway, I'll modify the egg to do some dumping to check that out.

Thanks for the explanation Crank :)
Click to expand...

Nope, there's a branch right in start of the loader code, which skips the next few nops. The junk data will be written there, but it won't be executed because the return address points to a branch instruction, which skips it. ;-)
 
Yeah, you're totally right, theres a beq $zr,$zr,0x10 and I didn't pay attention to it. My mistake, thanks again for pointing that out.

But I'm a bit confused right now, because in my modification I got rid of all bits set before the egg, that is, I got this branch replaced by a nop, got rid of memory video writing and... it works better than the original exploit on my PSP (and also some other people reported better results). If there's always random stuff (from our point of view of course) at entry + 8, then this modification should work worse than the original one, yet it works better under some circumstances o_O
 
Hmm, that sure is interesting. It's possible that the slim stack pointer (0xBsomething) translates to a proper instruction, whereas the fat stack pointer (0x09FEE634 IIRC) just translates to a jump to somewhere around the 0x07xxxxxx region, which obviously causes an exception. :-)

If you're bored enough, you could write a h.bin that dumps the memory after the TIFF loader has executed, then you can disassemble it and check :-) The loader passes the address of scePaf_Module to the h.bin in $a0, you can trick out its imports that way. :-)
 
Yea, I'm bored enough to do it xD

Anyway, no big deal, as I have already modified the ChickHEN to dump the kernel memory, so it should be very similar. I'm going to code it this night. I'll pass the the egg's entry point to the h.bin, along with scePaf_Module one. I'll dump all registers (well this should be done at the start of the egg really) and the memory region where the egg is located. I'll even do it several times to see where it loads each time.

I'll keep you updated, of course. See you later.

Oh, btw, I got a 2K ta88v3. And also, if you want to check out my MaTiaZ exploit disassembly ('cause I didn't know he's released the source code, stooooopid me xD, anyway good training :P) check here: AdvancedPSP View topic - Explaining the egg of the ChickHEN
 
Fancy. :-)

But I guess it's just enough to just check what instruction the stack pointer data (offset 0x264D8 in the file IIRC) translates to. If the CPU doesn't crash when it's executed, I guess there's no need for the branch in the slim version. But in the fat version it definitely is needed :-)

Oh BTW, the TIFF loader patches a thread to call sceKernelExitDeleteThread (because otherwise it crashes), you might want to add that to the explanation. :-)
 
Finally I didn't have enough time to do the dumper, will do it anyway, probably next week.

Crank said:
the TIFF loader patches a thread to call sceKernelExitDeleteThread
Click to expand...
Really? At what offset does it do that?
 
Well I can't make this simple H.BIN work xD Any clues? I've written it in assembly, just for fun:

Code: 
   # a0 = SCEPAF_MODULE   
   # pc = 0x08800000
   
   # SCEPAF_MODULE ($s3)
   addu $s3,$zero,$a0
   
   # sceIoOpen()
   lui $t0,0x15       
   ori $t0,$t0,0xee70
   addu $t0,$t0,$s3
   # file path
   lui $a0,0x880     
   ori $a0,$a0,0x200
   # flags write & create
   addiu $a1,$zero,0x602
   jalr $ra,$t0
   # mode 0777
   addiu $a2,$zero,0x1ff
   
   # file descriptor ($s2)   
   or $s2,$zero,$v0   

   # sceIoWrite()
   lui $s1,0x880
   ori $s1,$s1,0x200
   lui $t0,0x15       
   ori $t0,$t0,0xee40
   addu $t0,$t0,$s3
   # file descriptor
   addu $a0,$zero,$s2
   # size
   addiu $a2,$zero,0x10
   jalr $ra,$t0
   # pointer to data
   addu $a1,$zero,$s1
   
   # sceIoClose()
   lui $t0, 0x15     
   ori $t0,$t0,0xee60
   jalr $ra,$t0
   # file descriptor
   addu $a0,$zero,$s2
   nop
   
   # Loop forever
   lui $t0,0x880
   ori $t0,$t0,0x60
   jr $t0
   nop
With the string ms0:/regdump at address 0x08800200.

Doesn't work, well at least not the write procedure, or maybe the close, because it creates the file but it is just empty.

Anyone sees anything wrong in here? Thanks!
 
Davee said:
TIFF instability is because of the padding set at module_start in vshbridge. It's based on boot clock, so it differs per launch.
Click to expand...

english please....
 
Psyko said:
english please....
Click to expand...
Have you ever tried to punch a target which keeps moving all the time and you can't move at all, only punch the one spot? It's the same thing as with this exploit.
 
You must log in or register to reply here.
Back
Top