Why “eggsploit” is random.

July 9th, 2009 silverspring

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”.

Posted in Uncategorized | 9 Comments »