It would be pretty easy to build an 'aiding and abetting' case against any of the AV companies. For years these guys have engaged in dialogue with virus authors. It is a fact that in some cases this dialogue has consisted of trading the source code to virii.
Jon
Frequency domain correlation (mp3cdda)
on
MP3.com's Beam-It
·
· Score: 1
That would be very nifty.
The frequency with which I've been getting beam errors, though, seems to indicate that they're doing some sort of straight-up threshold matching.
jon
Re:Strong Security Possible w/ Hashes
on
MP3.com's Beam-It
·
· Score: 1
Yes.
Cf my other post somewhere in this topic.
It looks like it does a challenge/response with an md5 hash. As far as I can tell, it doesn't hash the random data from the track, it asks the client to send it outright. And I've seen it request up to 203 seconds from a random offset...
So near as I can tell, they use a challenge/response scheme for authentication. This is fine, and a little debugging will fill in the details there.
Looks like the MDID setup call passes track offsets; note the parameters strictly increase. I'm guessing that the time= parameter has something to do with the time the TOC on the disc was burned, but I have yet to try to correlate it to actual time in seconds.
After the MDID call, we get 232 back; then the real fun starts.
VFCD kicks off what looks like a pretty solid verificatation process. The server uses 331's to ask for random numbers of seconds from random sector offsets, and the client replies with RVDT's and track data.
If all the tracks are verified, a 231 is replied from the server with the 'mdid', and the connection hangs up.
That's as far as I've gotten.
Looks pretty solid to me thus far. I have yet to try beaming the same disc twice from two different machines; if the verification code always asks for the same #seconds and starting sector, obviously we can build a db, and we're golden.
Anyone interested in continuing this work, drop me a mail.. (jdc@pobox.com)
Slashdot Mirror
It would be pretty easy to build an 'aiding and abetting' case against any of the AV companies. For years these guys have engaged in dialogue with virus authors. It is a fact that in some cases this dialogue has consisted of trading the source code to virii.
Jon
That would be very nifty.
The frequency with which I've been getting beam errors, though, seems to indicate that they're doing some sort of straight-up threshold matching.
jon
Yes.
Cf my other post somewhere in this topic.
It looks like it does a challenge/response with an md5 hash. As far as I can tell, it doesn't hash the random data from the track, it asks the client to send it outright. And I've seen it request up to 203 seconds from a random offset...
jon
Yep. It definitely looks like a challenge/response pair to me.
Unfortunately I have no real debugging tools here. Someone with softice could do this in a few seconds.
jon
It's not even the first 8k or so; I've seen it request 203 seconds from a random offset within a track.
:( But notice in your sniffing all the 331 requests and their responses...
The only question remaining is whether it always asks for the same chunk from the CD; if so, this can be put into a database.
I don't have time to mess with it more today, though.
I initially thought this would be easy too; I checked it out a little bit. Look at this (simplified) capture.
8 6545,197950
->20 20 20 20 20 00
HELO mail=XXXXXXX@earthlink.net vers=0.90 cver=win004 sern=3933243
0a 20 20 20 20 20
AUTH meth=md5 pass=7998e0845cc98a85930b51212204d619
0a 20 20 20 20 20
MDID time=19739 tkof=150,27502,83547,93115,114317,121907,142117,1
0a 00 00 00 00 00
VFCD mdid=508103
0a 00 00 00 00 00
20 20 20 20 20 00
->RVDT trck=1 sect=18032 nsec=203 rate=22050 chnl=stereo bits=17 size=238728
->(238728 bytes of track data)
0a 20 20 20 20 20
-350 size=238728
---more negotiation snipped---
-231 mdid=508103
Okay.
So near as I can tell, they use a challenge/response scheme for authentication. This is fine, and a little debugging will fill in the details there.
Looks like the MDID setup call passes track offsets; note the parameters strictly increase. I'm guessing that the time= parameter has something to do with the time the TOC on the disc was burned, but I have yet to try to correlate it to actual time in seconds.
After the MDID call, we get 232 back; then the real fun starts.
VFCD kicks off what looks like a pretty solid verificatation process. The server uses 331's to ask for random numbers of seconds from random sector offsets, and the client replies with RVDT's and track data.
If all the tracks are verified, a 231 is replied from the server with the 'mdid', and the connection hangs up.
That's as far as I've gotten.
Looks pretty solid to me thus far. I have yet to try beaming the same disc twice from two different machines; if the verification code always asks for the same #seconds and starting sector, obviously we can build a db, and we're golden.
Anyone interested in continuing this work, drop me a mail.. (jdc@pobox.com)