Seen on bugtraq:
The way it works is fairly simple. Adder allows you to inject a python interpreter into any win32 process. That interpreter then runs a script within the context of your target process which is able to instrument and modify the target in any way it sees fit.
I've just started getting spam to an email address that I only disclosed to ebgames.com. The chance of spammers guessing it seems quite small. Someone should maintain a list of companies who sell email addresses to spammers. Fucking scum.
It's quite interesting to discover, from the inside, how the french justice system works. I'm back from Paris. I've just been indicted and charged of distributing programs that violated Intellectual Property rights (literally translated, it's "counterfeiting and concealment of counterfeiting"). Maximum punishment for these charges are two years in jail and a fine of 150.000 euros.
[...]
I showed that, unlike the advertizing claimed, this software didn't detect and stopped "100% of viruses".
[more]
Ouch.
A lot if Internet Explorer security holes can be closed by locking down the "My Computer" zone. Normally those settings are not exposed. This Microsoft KB article explains how to expose them in the GUI. In case the article goes away, the relevant regkey is HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0. Change the Flags value to 0x47 causes the zone settings to be visible. Setting it to 0x21 hides them.
PyCon 2004 starts this weekend in DC. I'm hoping to participate in sprinting again. Finishing off the AST compiler will be my top priority. If things go well, perhaps we can implement generator expressions too.
Based on the list of scheduled talks, it looks like this is going to be the best Python conference yet. The idea of a low-cost, community organized conference seems to be working well.
Finally, I hope some Debian developers will be in attendance. I need to get a new public key signed. Barry has organized a key signing party. Maybe some Debian people will show up for it.
To make things more concrete, here's an example transaction. Data sent by the client is prefixed by an S and data sent back by the device is prefixed with an R.
<open TCP port 8302> S 52 69 c5 8d 00 00 00 00 02 00 00 00 00 00 00 00 # VERSION R 52 69 c5 8d 00 00 00 00 02 00 00 00 00 00 00 00 S 52 69 c5 8d 00 00 00 00 02 00 00 00 00 00 00 00 # VERSION R 52 69 c5 8d 00 00 00 00 02 00 00 00 00 00 00 00 S 52 69 c5 8d 09 00 00 00 01 00 00 00 # LOCK R 52 69 c5 8d 09 00 00 00 5d 00 04 80 # error? S 52 69 c5 8d 03 00 00 00 # LOGIN1 R 52 69 c5 8d 03 00 00 00 b4 21 43 aa ec b9 1c da ce f8 2d 6f cc 6b cf 1e S 52 69 c5 8d 04 00 00 00 a8 27 3a 52 26 d9 7b b4 ac 80 57 17 83 7f a7 c2 # LOGIN2 (md5(salt + password)) R 52 69 c5 8d 04 00 00 00 00 00 00 00 01 00 00 00 # ok? S 52 69 c5 8d 09 00 00 00 01 00 00 00 # LOCK R 52 69 c5 8d 09 00 00 00 00 00 00 00 # success? S 52 69 c5 8d 07 00 00 00 # DEVICE_SETTINGS R 52 69 c5 8d 07 00 00 00 00 00 00 00 <settings> 00 00 00 00 S 52 69 c5 8d 0c 00 00 00 00 00 00 00 00 00 00 00 # WRITE 4e 11 00 00 00 00 00 00 10 0f 00 00 00 00 00 00 # file size, file id <file contents> 00 00 R 52 69 c5 8d 0c 00 00 00 00 00 00 00 S 52 69 c5 8d 0f 00 00 00 10 0f 00 00 # CHANGE_FILE_INFO <file info> 00 00 R 52 69 c5 8d 0f 00 00 00 00 00 00 00 S 52 69 c5 8d 0a 00 00 00 # UNLOCK R 52 69 c5 8d 02 00 00 00 00 00 00 00 20 00 00 00 # PROGRESS R 52 69 c5 8d 02 00 00 00 01 00 00 00 20 00 00 00 R 52 69 c5 8d 02 00 00 00 02 00 00 00 20 00 00 00 [...more PROGRESS messages...] R 52 69 c5 8d 02 00 00 00 20 00 00 00 20 00 00 00 R 52 69 c5 8d 0a 00 00 00 00 00 00 00 <close connection>
Why things are padded to 32-bit boundaries is a mystery. I'm also not sure how the client determines what "file ID" to use when uploading a new file. I suspect it first queries the device to find what IDs are used and then picks a free one.
At this point I have a little Python script that connects to the device, logins in, locks the device, unlocks it, and then closes the connection. My next goal is to have a script that can upload and delete files. It seems that non-music files are identified by having type=taxi and codec=taxi in their file info.
I want to use a Rio Karma for backing up some files but the software is not really friendly (at least to a CLI addict like me). The Karma comes with an ethernet dock. The device has an IP stack and configures itself with DHCP. Cool. The device also has a HTTP server. I haven't played with it yet but one of the response headers is "Server: Mercury-Content-Server/0.11". I think it is possible to stream music off of the device. Hmm, it also seems to broadcast UDP packets that contain "SERVER: Linux/2.4 UPnP/1.0 Pearl/1.0". Interesting.
The Karma does not work as a USB mass storage device, even though it has a USB2 connector. To use it as a general storage device, you need to use the Rio Taxi application. Using tcpdump and Ethereal, here is what I have learned about the protocol.
The protocol operates over TCP. The server port is 8302 (not sure if that's always true). The protocol seems to be organized into request and response messages. The client sends a request and the device responds with one or more than one response messages. Each message begins with a fixed string (52 69 c5 8d). The protocol seems be use mostly little-endian unsigned 32-bit integers. Following the fixed string (magic), is a u32 integer indicating the message type and optional message content (aligned to 32-bit boundaries?). I found a list of message types in the rmmlite.jar archive:
0=Get Version
1=NAK
2=Progress
3=Login Phase 1
4=Login Phase 2
5=Get Device Info
6=Get Storage Info
7=Get Device Settings
8=Change Device Settings
9=Lock
10=Unlock
11=Prepare
12=Write
13=Get All File Info
14=Get File Info
15=Change File Info
16=Read
17=Delete
18=Format
19=Device Operation
That little bit of information helps (although I had guess many of them before finding that file). After connecting there is a version handshake. The client sends a GET_VERSION message with the content 02 00 00 00 00 00 00 00 (probably major version 2, minor 0) and the device responds with the same message. For some reason the client does the handshake two times, perhaps due to sloppy programming.
Next, the client tries to lock the device (message content 01 00 00 00). The device responds with 5d 00 04 80. I suspect that is some kind of error message. Login needs to occur first, I think.
Login is done in two phases. First the client sends a LOGIN1 message (no content). The device responds with a 16 byte string. The client then sends a LOGIN2 message with another 16 byte string as content. Both strings look pretty random. I guessed it was an MD5 challenge-response, which turned out to be correct. The challenge is probably a random 16 byte string. The response is md5(challenge + password).
I figured out lots more things but this log entry is getting too long. I'll write more later. If you have a Rio Karma and are interested in helping me, please send me email.
I think everything is working again. Let me know if you notice something broken. I'm using Linode now. So far, so good.
[comments]