Why “eggsploit” is random.

So, a lot of people have been complaining about the unstability of the TIFF “eggsploit” (and thus the successful booting of HEN). The exploit relies on hardcoded memory addresses to succeed however a piece of code in the firmware ensures that memory addresses can randomly change.

As the vshbridge.prx is loaded and starts, two fixed memory pools are created and used for nothing else but random padding. The size of these mem pools are randomly assigned based on the system time. This can therefore affect the memory addresses of where modules are loaded into ram and therefore affect the hardcoded addresses the TIFF exploit relies on.

The code for the random memory padding (executed on vshbridge module_start):

view plain
C:
  1. int _vshVshBridgeStart()
  2. {
  3.     _vshPowerCallbackInit();
  4.     sceImposeSetStatus(4);
  5.     sceUmdSetSuspendResumeMode(1);
  6.    
  7.     int size;
  8.     int time = sceKernelGetSystemTimeLow(); // time since system start
  9.  
  10.     if (time & 3 == 0)
  11.     {
  12.         size = 0×400; // 1 KByte
  13.     }
  14.     else if (time & 3 == 1)
  15.     {
  16.         size = 0×300; // 768 Bytes
  17.     }
  18.     else if (time & 3 == 2)
  19.     {
  20.         size = 0×200; // 512 Bytes
  21.     }
  22.     else if (time & 3 == 3)
  23.     {
  24.         size = 0×100; // 256 Bytes
  25.     }
  26.  
  27.     sceKernelCreateFpl("SceVshRandomTopPadding", 2, 0, size, 1, NULL);
  28.  
  29.  
  30.     if ((time & 0xF)>> 2 == 0)
  31.     {
  32.         size = 0×400; // 1 KByte
  33.     }
  34.     else if ((time & 0xF)>> 2 == 1)
  35.     {
  36.         size = 0×300; // 768 Bytes
  37.     }
  38.     else if ((time & 0xF)>> 2 == 2)
  39.     {
  40.         size = 0×200; // 512 Bytes
  41.     }
  42.     else if ((time & 0xF)>> 2 == 3)
  43.     {
  44.         size = 0×100; // 256 Bytes
  45.     }
  46.  
  47.     sceKernelCreateFpl("SceVshRandomBottomPadding", 2, 0×4000, size, 1, NULL);
  48.    
  49.     return 0;
  50. }

This bit of random padding code was added in 2.50 firmware and still exists in the latest firmwares.

Because HEN uses the TIFF exploit to run there is nothing the HEN could do to improve it’s chances of booting successfully. It may be that it’s simply random luck.

Note: there is no doubt there are also many other factors which could affect the stability of the TIFF “eggsploit”.

This entry was posted on Thursday, July 9th, 2009 at 7:29 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

«
»

9 Responses to “Why “eggsploit” is random.”

  1. thedicemaster Says:
    July 9th, 2009 at 7:49 pm

    from this i don’t really understand why i can still boot HEN 100% consistently.

  2. BBTGP Says:
    July 13th, 2009 at 11:10 am

    Try booting hen at different times of the day and see if your luck holds out.

    Very informative article, i had no idea Sony used random memory padding.

  3. MaxMouseDLL Says:
    July 13th, 2009 at 10:23 pm

    I agree with thedicemaster, i can boot the HEN 100% of the time without fail at all times of the day/night, why is this?

  4. wololo Says:
    July 17th, 2009 at 12:20 pm

    This explains why people have to reboot a few times before getting it to work, not why some people try hundreds of times with no success and have to change their config settings to get it to work…

    Also, why did Sony implement this? Against hackers? It doesn’t look like a good protection…
    (compared to the cycling they perform on the framebuffer’s 4th byte of each address)

  5. Bubbletune Says:
    July 18th, 2009 at 12:18 am

    It’s because it hasn’t got anything to do with the actual system time, but the time it took to load up all modules till it reached vshbridge. There is various factors that can affect this, including, but not limited to, memory stick initialization. This may be why these so-called stability packs and instructions on removing files seem to work, but the truth is it differs heavily between PSP’s.

  6. MaxMouseDLL Says:
    July 21st, 2009 at 10:15 pm

    The time it took to load all modules until vshbridge? that seems a little half-arsed to me… even so, my unit boots chickhen without issue 100% of the time.

  7. m0skit0 Says:
    July 29th, 2009 at 5:37 pm

    That’s a good explanation SilverSpring. I always wondered that. Thank you very much!

  8. lukas Says:
    July 29th, 2009 at 9:22 pm

    This random padding is simply done to make it harder to succesfully run such overflow exploits, didn’t the first one was found some firmware versions before 2.50?

  9. draedan Says:
    October 4th, 2009 at 4:57 pm

    Using psp 3k with OFW 5.03 , I’ve been trying to load ChickHEN R2 and ChickHEN R2 Mod2 for days, still it doesnt work. Interesting really. Wondering if the memory sticks have effect , – using 16gb sandisk -

Leave a Reply