GameCube simple DOL reloader for PSOload V2.0 and SDload V1.0
21 March 2005, Albert "isobel" Herranz


1. INTRODUCTION

  There are several tools available that allow one to upload and execute
  custom code on the GameCube console. Two of them are PSOload and SDload.

  PSOload by Costis is a tool that uses some of Sega's PSO online gaming
  features to gain control of the GameCube through the BroadBand Adapter, and
  execute arbitrary code. PSOload includes a payload to load and reload DOLs
  and binary files through a network connection between a PC and the GameCube.

  SDload by Costis and Parasyte does a similar job by using the Action Replay
  software to patch itself, and run custom program code. SDload payload
  consists of a menu driven loader that can boot DOLs and binary files
  stored in a previously treated SD card. This loader includes too a network
  reloader stub compatible with the one found in PSOload.


  The PSOload reloader presented here, "psolore" from now on, is a program
  compatible with both PSOload and SDload network reloader resident stubs,
  thus allowing you to send DOLs to your already booted GameCube through the
  BroadBand Adapter without using PSOload again.

  It DOES NOT allow you to trigger the PSO exploit, so it can't be used as
  PSOload without the -r option.


2. WHY ANOTHER PROGRAM ?

  If psolore does nearly the same as PSOload -r, why the noise one may think.
  Indeed, if you use PSOload to boot your GameCube you need PSOload anyway.

  Given the fact that source code for PSOload and SDload has not been publicly
  released, these tools are available in binary-only forms for mortals. And
  documentation for the internal communication protocol used is unavailable
  too.

  So what if one wants to run PSOload -r from a GameCube to send code to
  another GameCube? Or from a WRT54G?
  Binaries doesn't exist for that. And could be fun, couldn't it?

  That, and curiosity, drove me into psolore development.
  So I ended up sniffing PSOload network traces and coding from scratch.
  And I thought that releasing the source code for the reloader was no harm at
  all, and could be of some use.


3. WHY NOT A COMPLETE PSOLOAD CLONE ?

  The PSO exploit is trivially reproducible by a simple replay attack.
  It is not that complicated to customize the attack for different IPs/ports
  and different PSO versions/regions.

  Indeed, there is already at least one PSOload-like clone with source code
  available (but with no reloading feature).

  So I lost interest in it.


4. COMPILING

  This release works at least on Linux, and has been compile-tested with
  gcc 3.2.

  To create a psolore binary from sources just run:

	$ gcc -o psolore psolore.c


5. RUNNING

  The usage of psolore is analogue to PSOload -r, except that you don't need
  to provide the -r option.
  All PSOload options related to the PSO exploit are not needed and are
  not supported.

  When using PSOload reloader feature, remember to start psolore before
  invoking the reloader code (this is a limitation in PSOload).
  That seems no longer needed in SDload reloader feature.

  - Print program usage 

	$ ./psolore --help
	Usage: psolore [OPTION] [FILE]
	  -d, --daemonize    run in the background
	  -x, --inetd        run through inetd
	  -i, --ip=ADDRESS   use local bind ADDRESS
	                       (default any)
	  -p, --port=PORT    use local bind PORT
	                       (default 9002)
	  -m, --many         serve many requests
	                       (default ON for -d or -x)

  - Send zImage.dol and exit

	$ ./psolore zImage.dol

  - Send zImage.dol and exit, listen only to requests on IP 192.168.0.49

	$ ./psolore -i 192.168.0.49 zImage.dol

  - Send zImage.dol as many times as requested until killed

	$ ./psolore -m zImage.dol

  - Daemonize and send zImage.dol as many times as requested until killed

	$ ./psolore -d zImage.dol


  It is possible to launch psolore through inetd too. A sample xinetd
  configuration file (to be placed at /etc/xinetd.d/psolore) is attached
  at the end. In inetd mode, psolore will be called transparently for you
  when the reloader gets called on your GameCube.


6. LIMITATIONS

  There are currently a number of artificial limitations, like the inability
  to send .bin files.
  Not really hard to fix. And you already have the source code.


7. CREDITS

  Special thanks go to:

  - Costis and Parasyte for their awesome work
  - groepaz for his great docu
  - all gc-linux and gcdev developers
  - all gamecube fans


8. DISCLAIMER

   THIS PROGRAM IS NOT AFFILIATED WITH NEITHER SEGA NOR NINTENDO.

   IN NO EVENT SHALL THE AUTHOR BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT,
   SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT
   OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE AUTHOR
   HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
   THE AUTHOR SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING,
   BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
   AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE PROVIDED HEREUNDER IS
   ON AN "AS IS" BASIS, AND THE AUTHOR HAS NO OBLIGATION TO
   PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.



--8<----8<----8<---- sample xinet config file for psolore ----8<----8<----8<--
# default: off
# description: one line \
#       last line
service psolore
{
        disable			= no
        socket_type             = dgram
        protocol                = udp
        port                    = 9002
        wait                    = yes
        user                    = root
        server                  = /path_to_your/psolore
        server_args             = -x /path_to_your_dol/zImage.dol
        flags                   = IPv4
}
--8<----8<----8<---- sample xinet config file for psolore ----8<----8<----8<--

