Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Adam T. <ad...@io...>]

On Tue, 2004-04-13 at 01:58, Steven Looman wrote:
> Some reverse engineering could also be done on the programs and the sent packets.

Yeah, I *could* sit down with tcpdump or ethereal and just watch what's
happening, but I don't care enough to spend the time to do that. 

> I don't know why Costis fears piracy; with the thing he released it is already possible, I don't see how an open source solution would change this. Online cheating (in PSO) is also an argument I've heard but this is already happening, afaik.

I suspect that the average pirate is *more* likely to sit down and do a
traffic analysis to reverse-engineer the protocol than I am, anyway.

I tend to believe that it's the initial GC loader that's the tricky 
bit.  Presumably the protocol looks something like this:

(If DHCP is enabled, DHCP broadcast for GC to get IP address)
GC issues DNS request to server learned by DHCP or coded in network
parms to get the IP address of an appropriate host (we know these names,
of course; PSOload has a small DNS server to return the patch host
rather than the real one, but you can put the records in a zone file on
any old DNS server and it works fine)
GC contacts the IP address it just learned on UDP/9002 or something
(codeable in PSOload switches) and sends some magic set of packets
requesting patch <-- this is the part you'd have to reverse-engineer
Host sends "patch" (i.e. Linux kernel) appended or prepended to loader
stub, so that you overwrite memory with the Linux kernel and overlay
wherever the instruction pointer goes after receiving the patch with a
jump to the beginning of the kernel.  <-- this is the tricky bit, since
the loader stub probably has to do some work to fake out the GC and make
it believe that it is a legitimate patch.  I have no idea what that
entails.

Adam