# # sputool README -- ~medusa aka DNE # AUTHOR ------ ~medusa LICENSE ------- Sputool is released unter the terms of GPL v2.0. INSTALLATION ------------ To install sputool, unpack the tar.gz, cd to sputool and just type make. It is supposed at least libxorhack.a and xorhack.h are installed at some common place. USAGE ----- Load the xorhack kernel module (if this is not done at startup). Then type ./sputool to get the available options. ABOUT ----- My first intention was to unlock the 7th SPU by simple lv1 manipulation. Geohot mentioned the decryptor SPU is idle under Linux, so I digged deep into the SPU related kernel source. However, everything inside the PME is locked quite hard so if you don't want to open up your Black Lady (which I'm not [yet]) that dream passes away... I just set things up to be ready for exploit. It turned out this must be done with older kernel under Debian. Xorloser mentioned he used Ubuntu 8.10 which had kernels 2.6.25 and 2.6.27; the closest Debian kernel is 2.6.26, and indeed for the latter the exploit code at least runs. What is left: Sputool modification of the HV repository partition already works if there are only the partition SPU values are decreased (sputool -d) and the the Debian ppc64 kernel is restarted using kexec. Linux then comes up with the number of SPUs you set up but that's fewer than before so it's boring. It just demonstrates that even without exploiting the PS3 things can be manipulated without letting the HV know about. Repo entries can be queried, modified, created and deleted. See sputool.c for examples. However, increasing SPU number is not that simple, it will crash the kernel during kexec if just the partition values were increased before. Creating a SPU does not better, and it cannot be enabled. Destroying SPUs makes things more worse, and don't even think to kexec after you used sputool -x. So I think without exploit I came to an end here. Shooting down the decrytor SPU of the system, manipulation of the sys.be repo entries and restarting the 7th SPU in user mode is left to exploited PS3s - if at all. Nevertheless, thanx to geohot and xorloser for making even the bits I've done possible. NEWER KERNEL PROBLEMS --------------------- Originally using kernel 2.6.32 the exploit code for me didn't work just for try (without any hardware mod); it crashed with a segfault at 0xd000080080001000 (HTAB + 4k page). Looking up /proc/vmallocinfo, this area seems to be already allocated by the SPU init calls not the HTAB as supposed by the exploit code. Seems there had been major changes in ioremap code lately. For kernel 2.6.26, ioremap stuff starts at 0xd000080080100000 which is a long way behind the HTAB area. Also, for newer kernel 2.6.32 the xorhack module wants to use a symbol .irq_to_desc during build; however, the kernel doesn't export this so no chance to get a loadable module without a patch. Believe me, I had a few hard days until I found out what really was wrong. ;) CONCLUSION: get the 2.6.26 kernel source for your distro and build & install it to work with the exploit. DEBIAN XORHACK USAGE FOR NEWER KERNELS >= 2.6.32: --------------------------------------- Xorhack won't build without errors for kernel 2.6.32 (well, warnings but these kick your module out when trying to insert it) if no minor patch is made. However, you'll have to compile kernel from sources anyway if you want to build a module. So it's a minor effort to do a simple patch before. To allow for proper xorhack build a kernel must export the symbol .irq_to_desc. To enable, edit the file /kernel/irq/handle.c by the editor of your choice. Look for a short function definition like this: struct irg_desc *irq_to_desc(unsigned int) { [...some code...] } It should appear twice, at line 192 and 237 for we have an #ifdef...#else...#endif preprocessor structure in the file. Append in both cases after the closing "}" bracket the line EXPORT_SYMBOL(irq_to_desc); and save the file. Then compile and install your kernel, and after that xorhack.ko should build without a warning. As mentioned above, the exploit code will not run but at least you can use the xorhack lv1 syscall interface for experimentation. Most of the development of sputool I did so. Maybe a simpler method is to edit xorhack's makefile in kmod/ directory and kick exploit.o out (.irq_to_desc is undefined only here, use "nm exploit.o" to check); but anyway you have to build the kernel to build the module successfully so a patch is a nice excercise. DEBIAN KEXEC USAGE: ------------------- Install kexec Debian package as usual. This is the 32-bit version, it will not load 64-bit kernel but execute it (don't ask me why, I just know it works). Additionally, we need 64-bit kexec to load kernel (it will crash on execute, just use it to load). So, install kexec again from source (the executable must be renamed to avoid conflicts): (1) unpack kexec-tools-2.0.1-rc1.tar.gz (2) ./configure --without-zlib CFLAGS=-m64 LD_FLAGS=-static (3) make (will abort with error) (4) at prompt, copy & paste last (failed) gcc command performed, DO NOT PRESS (5) edit that line, insert -m64 -static after gcc and press , it now finishes build without any error (6) cp build/sbin/kexec /usr/local/sbin/kexec64 cp build/sbin/kdump /usr/local/sbin/kdump64 Use kexec/kexec64 with: init 1 /usr/local/sbin/kexec64 -l /boot/vmlinux-2.6.32-3-powerpc64 \ --initrd=/boot/initrd.img-2.6.32-3-powerpc64 --append="root=/dev/ps3da1 video=720p" swapoff -a sync kexec -e ...which very well can be put into a shell script (see the warmboot script). This so far works for me only with the Debian ppc64 kernel shipped with the distribution and the 2.6.26 kernel rebuild from source with Debian 2.6.26 config file. Other ps3 related configs, default or some homebrewed I found in the web always hang when kexec -e was used.