This time, an astute reader points us to the place where Guido Van Rossum speaks out on the Python license issues recently posted about here on Slashdot, and an Everquest enthusiast points to the Official Word (well, chatroom response) to Everquest server emulators. Oh, and remember that CueCat scanner you picked up last week (and quickly wrote a Linux kernel driver for) -- did anyone at Radio Shack mention something about an embedded serial number? Hmmmm. I thought not. Good thing reverse engineering isn't yet a capital offense ...
That's one long and winding snake of an issue ... Kevin Reichard writes: "Since you covered the original issues surrounding Python licensing, you may also want to note that Guido van Rossum of PythonLabs has officially responded in a Linux Today interview. He has many interesting things to say."
Which things notably include: "The sad thing is that all of this is based on technicalities: Stallman agrees that Python is free software, but a technicality in the licenses prevents compatibility. The choice of law clause in the CNRI license, which is causing the incompatibility, is very common is software licenses, and CNRI doesn't want to drop it because the validity of the general disclaimers in the license may depend on it. At the same time, Stallman doesn't want to allow any choice of law clauses, because one could stipulate the law of "Unfreedonia" which might reverse the meaning of the GPL."
Abort, retry, fail, bend, fold, spindle, mutilate? L Fitzgerald Sjoberg writes: " A recent posting on the official EverQuest boards by a spokesperson for Verant states that even RUNNING an EverQuest emulator violates the EverQuest license agreement.
If the emulator is legal, and emulators seem to be making a lot of legal headway these days, doesn't this essentially amount to Verant forbidding you to use a competitor's product? Not a good sign, if you ask me."
"Sir! Sir! There's something wrong -- this knob goes up to eleven!" Signal 11 writes: "I took apart a cuecat and did a rundown of the circuit tracings on the board. What follows is a short summary of what I found. I'm working on putting together a schematic for it and hope to have it together within a couple weeks.
The cuecat is fairly simple. It uses a pair of infrared LEDs to direct light onto the sheet of paper with the barcode on it. It is then picked up by an IR detector, whose output is tuned by a single potentiometer (adjusted at time of manufacture, I would guess) and then fed into the analog input of a microprocessor. The detector is the same type one can pickup at radioshack. All you do is enclose it in a box and then make a pinhole at one end. Cheap, but it works well enough.
The microprocessor I haven't had time to put together a circuit from the specs provided by texas instruments to download the microcode out of it. It is also a matter of me not wanting to learn about microprocessors although I understand it is common in the industry.. I'm an analog guy. :) I suspect it is nothing more than running the output through a ACD (analog->digital) inside the microprocessor and then referencing the binary input with a list of values to produce the barcode string. After that, as has been previously noted, it is passed to an XOR algorithm, and then modulated to be fed out onto the PS/2 interface. There are a pair of transistors on the board near the outputs of the microprocessor - I suspect these are used to either boost the signal to run over the PS/2 interface (the microprocessor may not have enough power), or as part of an oscillator to get a clock for the processor. Until I finish tracing out the board paths, I can't say for sure.
Somewhere in the chip they probably set the serial number into the nvram, which is prepended to the output. The software does the rest. As has been demonstrated, there isn't much to do on the software side either - one could just create an indexed array containing scancodes. One might even be able to write a new key definition file under linux.. no programming required.
This is a really simple device. This is also probably why they were so concerned about competitors.. it wouldn't take them more than one afternoon with an EE and a microcode programmer to reverse-engineer it and produce their own. Then again, the device was probably designed in the same amount of time, likely by a random contractor. The reason it took me so long? I've been messing around with electronics for all of three months, so yes, I'm not a professional - I also haven't gotten into DSP technology yet, which is all the cuecat is. As always, if someone could provide me with a basic circuit for reading the contents of the processor's memory out, I'd appreciate it!
Anyway, DigitalConvergence - I'm waiting for my cease and desist now."