This is a follow-up to my previous article. Much of the interesting traffic from the previous post was SSL encrypted. The easiest thing to get around that in your own setup is using Dug Song’s dsniff package. The problem is that the Wii does not send an HTTP V1.1 virtual host command, so you will have to hack webmitm.c to specify your own hosts. For best results, point all of the Nintendo sites to individual IPs on your private network and run several webmitm binaries to bind to each IP address. You can get the full transfers from there. If you are a clever person, you can code your own meta file (including hashes for all four parts of the binary) and use your own content.bin to create a new channel. Given all this information, why bother. Just buy the game, its less than or equal to the cost of a few pints at the bar.
(Next time you see a video proving to do all this, watch for the actual game play.)
So I decided to look at what the Wii actually does with it’s wireless capabilities. I connected a Linksys WAP54G access point to the ethernet port of my FreeBSD-equipped laptop and enabled both DNS lookups and network address translation. Essentially, the laptop connects the wireless network that the Wii is on with the wireless network that is connected to the internet and is able to capture all of the packets with Ethereal/Wireshark. Upon looking over the first set of dumps briefly, I noticed that most of the shop channel communications are done over SSL (good!) and that Wii seems to have IPv6 capability as it requests both A and AAAA records for hostnames. Once I analyze the dumps further, I will look at cooler experiments to do with this setup. Any requests for more specific network dumps can be made by commenting. So far, I have the connection test, update check, browsing the web with opera, and various activities on the shop channel captured. For now, I will try to investigate the messaging system and look at what actual communications happen when the system is in standby mode. Updates should appear later this week.
( wii-dumps.zip ) ( dumps are in pcap format and can be viewed with Ethereal, Wireshark, or almost any other packet capture program )
One of my few peeves with Firefox 2.0 has been the default tab setup where there is a minimum tab width defined, so eventually tabs go off the visible screen, and that each tab has an individual close button. If you have similar tastes, the way to tweak the tab settings is by entering “about:config” into the address bar and hit return. The first key to edit is browser.tabs.closeButtons and set it to 3 for Firefox 1.5 behavior. The second option is to set the browser.tabs.tabMinWidth to 0 pixels so the tabs adjust to fit the screen. More information can be found at the mozillalinks blog.
I have recently been looking at x86 bootup procedures to see what kind of fun can be had. Generically, all x86 systems start up by loading the contents of the BIOS EEPROM to a known ram location with known offsets for various I/O routines. All of this is done in real mode. Once the BIOS is loaded and the system hardware is probed, the boot drive is selected. The initial boot loader (boot0 on BSD) is located on the first 512 byte block of the device with the first word being an instruction and the last word being the magic number 0xAA55. This block is known as the master boot record. After the initial bootloader is loaded, it copies its self to a lower memory address and locates the secondary boot loader (boot1 on BSD, lilo or GRUB on Linux). From the secondary loader on, the boot up is pretty specific, resulting in loading the kernel, drivers and the filesystems for the target operating system. Below are links to two guides that deal with the bootstrapping in depth. Image above is from bootstrap.org.
( Chapter 2: FreeBSD System Programming )
( From power-up to bash prompt )
While looking at some low level system design documents, I came across this article from IBM by Lewin Edwards. His case is that the x86 architecture is not the most flexible and financially feasible path to developing embedded solution. The argument is that x86 boards, even single board computers, are designed to be used as black boxes where the developer is supposed to make it work for his or her design through available components and external modules. This is to say that designing an x86 embedded system from scratch is not often done. On the other hand, the PowerPC embedded systems offer plenty of flexibility with a broad range of processors featuring a vast array of built in features (JTAG, memory controllers, peripheral controllers, etc). This article gives an overview of getting Linux to run on a Kuro Box, essentially a $150 PowerPC embedded system. For those less interested in the actual process, there are plenty of interesting resource links in the first section.
Part 1: Robots and networked appliances on a shoestring
Part 2: Anatomy of the Linux boot process
Part 3: Kuro Box Linux up close
When dealing with two op-amp instrumentation amplifiers that have a small footprint, we are often faced with a non-unity minimal gain value. The minimum gain is 5 for the ina2332 for example. The reasoning behind this can be found in chapter two of the Analog Devices’ Op Amp Application Handbook. (Not to be confused with Texas Instrument’s Handbook of Operational Amplifier Applications.) By increasing the gain we increase the allowable common mode input range as well as improving the amplifier frequency response. Everything has its limits, so be mindful that the CMRR of the two op-amp instrumentation amplifier suffers at high frequency due to slight phase shift between the signal that goes through the first amp and the signal coming into the second amp.
( sboa092a.pdf ) ( Op_Amp_Applications.zip )
Every year I find myself looking up the physics behind the BJT. I usually look at Sedra and Smith, however, this time I will go to the source, the Bell Labs patent. Image is from AudioUK.
( 02569347.pdf )