On Saturday 12 July 2008, Malcolm wrote:
> 1) Use IOS sockets to implement a network driver
> - How?
>
> 2) Use IOS sockets from userspace
> - Only works with modified programs
>
> 3) Write a driver that can send and receive UDP packets using IOS
> sockets. Implement IP over UDP using TUN/TAP in a similar way to IP over
> DNS. http://thomer.com/howtos/nstx.html
> - Requires another computer on the network to act as a proxy
> + Could work
A combination of TUN and exposing IOS sockets to user space would allow all
three options:
1) Figure out from the IP packets what socket calls the Linux program was
making and replay that using the IOS sockets.
2) Ignore TUN and only use the IOS sockets.
3) Traffic from the TUN device is tunneled over IOS sockets.
Also, debugging is a lot easier in user space, so even if option 1 in kernel
space is your long-term goal, implementing it in user space first is
probably a good idea.
> 4) Hope that the IOS interface for sending DS demos is low level
> enough to do normal wifi.
> - Requires reverse engineering work
> - May not be possible
How does the demo sending work? Does the Wii act like an access point to the
DS? Or are the Wii and the DS just two normal hosts connected to a normal
access point?
The device nodes "/dev/net/ip/bottom" and "/dev/wl0" haven't been reverse
engineered yet (at least, no public documentation seems to be available),
maybe one of these allow lower level access?
> 5) Replace IOS
> - Requires lots of reverse engineering work
> - Risky
Patching the IOS to add ioctls that allow you to send and receive raw IP
packets would be sufficient. Still not an easy task, but not as hard as
replacing IOS entirely.
> 6) Give up and use a USB wifi adaptor
It would be a shame to ignore the hardware that every Wii has built in.
Possibly another option:
7) Use ptrace() from an external process to intercept socket system calls
from a process and perform IOS socket calls instead.
- Not a transparent solution
+ Works with existing binaries
Bye,
Maarten
|
