Someone has released a patched version of the kazaa binary.
If you want it, come into #gift on irc.openprojects.net and ask.
The problem is that Fast Track is NOT open source and uses encryption between usersusers/supernodes.
I think they still want to figure out the protocol, since the kazaa binary only runs on linux x86.
Oh, it should also be noted that Fast Track DOES use central servers, so the blurb in this/. article is WRONG. Since they use centralised servers (For log on/serving up ads/etc) they can be shut down just as well as napster.
I also don't beleive the EFF should be defending these guys, as earlier posters have said kazaa/morpheus is full of spyware and ads.
Re:You can customize Linux
on
Tiny Apps
·
· Score: 1
That's right..
Hell, who needs toolbars, and window's and such in X? If you want a gui (X) without the bloat, try RatPoison
It's small, very light and very fast. It's not so much as a window manager as a... well, go see for yourself. It's sort of retro;) Try it out.
That said, anything that uses GNOME/KDE/etc IS bloat.. I've had to download boatloads of crap. I installed off a debian 2.2r3 iso.. whew. It's amazing how many different damn libraries you have to download.. why can't you make do with gtk?? Oh well.
Whoever says linux is ready for the desktop (like your grandma) is bullshiting themselves.. It's not ready, yet.
CDex has support for Vorbis, although im not sure what version encoder they're using.
You can get CDex from The CDex page
Also there are plugins and an "official" encoder at Vorbis.com
Now, one thing I haven't seen discussed... Has anyone approached the CCA about becoming a licensed user of CSS? How much can be published? If the licensed app is GPL'ed, how much of the CSS code goes for the ride? $10k isn't all that much, in the scheme of things.
Auctally, the contract/license agreement you sign doesn't allow open sourcing of the code, because then otherwise anyone could just find out how it works. So, you can't "legally" license an open source DVD player.
Also, who's going to pay the $10k? What's the point of paying that $10k and then not being able to open source it, at which point you'd have to sell it to recoup the $10k, so on and so forth.
I beleive LiVid and maybe other groups have approached the DVDCCA about licensing it, but a) it's not free and b) No source code.
Auctally, no. Simon Travaglia (aka BoFH) is from New Zealand. He used to work (Or currently does, im not sure) at the Waikato Univerisity.
The register has the latest BoFH installments.
Oh, and be careful about saying he's from Australia, your keyboard might curiously become electrified.
20 April 2001. Thanks to Anonymous
From cryptome.org
[Letter, 3 pp.]
MATTHEW J. OPPENHEIM, ESQ. Address illegible
RIAA
April 9, 2001
Professor Edward Felton
Department of Computer Science
Princeton University
Princeton, NJ 08544
Dear Professor Felten,
We understand that in conjunction with the 4th International Information
Hiding Workshop to be held April 25-29, 2001, you and your colleagues who
participated in last year's Secure Digital Music Initiative ("SDMI") Public
Challenge are planning to publicly release information concerning the
technologies that were included in that challenge and certain methods you
and your colleagues developed as part of your participation in the challenge.
On behalf of the SDMI Foundation, I urge you to reconsider your intentions
and to refrain from any public disclosure of confidential information derived
from the Challenge and instead engage SDMI in a constructive dialogue on
how the academic aspects of your research can be shared without jeopardizing
the commercial interests of the owners of the various technologies.
As you are aware, at least one of the technologies that was the subject of
the Public Challenge, the Verance Watermark, is already in commercial use
and the disclosure of any information that might assist others to remove
this watermark would seriously jeopardize the technology and the content
it protects.1 Other technologies that were part of the Challenge
are either likewise in commercial use or could be could be utilized in this
capacity in the near future. Therefore, any disclosure of information that
would allow the defeat of those technologies would violate both the spirit
and the terms of the Click-Through Agreement (the "Agreement"). In addition,
any disclosure of information gained from participating in the Public Challenge
would be outside the scope of activities permitted by the Agreement and could
subject you and your research team to actions under the Digital Millennium
Copyright Act ("DCMA").
____________________
1 The Verance Watermark is currently used for DVD-Audio and SDMI Phase
I products and certain portions of that technology are trade
secrets.
We appreciate your position, as articulated in the Frequently Asked Questions
document, that the purpose of releasing your research is not designed to
"help anyone impose or steal anything." Further more, you participation in
the Challenge and your contemplated disclosure appears to be motivated by
a desire to engage in scientific research that will ensure that SDMI does
not deploy a flawed system. Unfortunately, the disclosure that you are
contemplating could result in significantly broader consequences and could
directly lead to the illegal distribution of copyrighted material. Such
disclosure is not authorized in the Agreement, would constitute a violation
of the Agreement and would subject your research team to enforcement actions
under the DMCA and possibly other federal laws.
As you are aware, the Agreement covering the Public challenge narrowly authorizes
participants to attack the limited number of music samples and files that
were provided by SDMI. The specific purpose of providing these encoded files
and for setting up the Challenge was to assist SDMI in determining which
of the proposed technologies are best suited to protect content in Phase
II products. The limited waiver of rights (including possible DMCA claims)
that was contained in the Agreement specifically prohibits participants from
attacking content protected by SDMI technologies outside the Public Challenge.
If your research is released to the public this is exactly what could occur.
In short, you would be facilitating and encouraging the attack of copyrighted
content outside the limited boundaries of the Public Challenge and thus places
you and your researchers in direct violation of the Agreement.
In addition, because public disclosure of your research would be outside
the limited authorization of the Agreement, you could be subject to enforcement
actions under federal law, including the DMCA. The Agreement specifically
reserves any rights that proponents of the technology being attacked may
have "under any applicable law, including, without limitation, the U.S. Digital
Millennium Copyright Act, for any acts not expressly authorized by their
Agreement." The Agreement simply does not "expressly authorize" participants
to disclose information and research developed through participating in the
Public challenge and such disclosure could be the subject of a DMCA action.
We recognize and appreciate your position, made clear throughout this process,
that it is not your intention to engage in any illegal behavior or to otherwise
jeopardize the legitimate commercial interests of others. We are concerned
that your actions are outside the peer review process established by the
Public Challenge and setup by engineers and other experts to ensure the academic
integrity of this project. With these facts in mind, we invite you to work
with the SDMI Foundation to find a way for you to share the academic components
of your research while remaining true to your intention to not violate the
law or the Agreement. In the meantime, we urge you to withdraw the paper
submitted for the upcoming Information Hiding Workshop, assure that it is
removed from the Workshop distribution materials and destroyed, and avoid
a public discussion of confidential information.
Sincerely,
[Signature]
Matthew Oppenheim, Secretary
The SDMI Foundation
cc: Mr. Ira S. Moskowitz, Program Chair, Information Hiding Workshop, Naval
Research Laboratory
Cpt. Douglas S. Rau, USN, Commanding Officer, Naval Research Laboratory
Mr. Howard Ende, General Counsel of Princeton
Mr. Edward Dobkin, Computer Science Department Head of Princeton
[Paper, 15 pp.]
Reading Between the Lines:
Lessons from the SDMI Challenge
Scott A. Craver1, John R McGregor1, Min Wu1,
Bede Liu1,
Adam Stubblefield2, Ben Swartzlander2, Dan S.
Wallach2,
Drew Dean3, and Edward W. Felten4
1 Dept. of Electrical Engineering, Princeton University
2 Dept. of Computer Science, Rice University
3 Computer Science Laboratory, Xerox Palo Alto Research Center
4 Dept. of Computer Science, Princeton University
Abstract. The Secure Digital Music Initiative is a consortium of parties
interested in preventing piracy of digital music, and to this end they are
developing architectures for content protection on untrusted platforms. SDMI
recently held a challenge to test the strength of 4 watermarking technologies,
and 2 other security technologies. No documentation explained the implementations
of the technologies, and neither watermark embedding nor detecting software
was directly accessible to challenge participants. We nevertheless accepted
the challenge, and learned a great deal about the inner workings of the
technologies. We report on our results here.
1 Introduction
The Secure Digital Music Initiative (SDMI), a consortium of music-industry
companies, is working to develop and standardize technologies that give music
publishers more control over what consumers can do with recorded music that
they buy. SDMI has been a somewhat secretive organization, releasing little
information to the public about its goals, deliberations, and technology.
In September 2000, SDMI announced a "public challenge" in which it invited
members of the public to try to break certain data-encoding technologies
that SDMI had developed [3]. The challenge offered a valuable window into
SDMI, not only into its technologies but also into its plans and goals. We
decided to use the challenge to learn as much as we could about SDMI. This
paper is the result of our study.1 Section 2 presents an overview
of the HackSDMI challenge. Section 3 analyzes the watermark challenges. Section
4 analyzes the non-watermark challenges. Finally, we present our conclusions
in section 5.
____________________
1 The SDMI challenge offered a small cash payment to be shared among
everyone who broke at least one of the technologies and was willing to sign
a confidentiality agreement giving up all rights to discuss their findings.
The cash prize amounted to the price of a few days of time from a skilled
computer security consultant, and it was to be split among all successful
entrants, a group that we suspected might be significant in size. We chose
to forgo the payment and retain our right to publish this paper.
2 The SDMI Challenge
The SDMI challenge extended over roughly a three-week period, from September
15, 2000 until October 8, 2000. The challenge actually consisted of six
sub-challenges, named with the letters A through F, each involving a different
technology developed by SDMI. We believe these challenges correspond to
submissions to the SDMI's Call for Proposals for Phase II Screening Technology
[4]. According to this proposal, the watermark's purpose is to restrict an
audio clip which is compressed or has previously been compressed. That is,
if the watermark is present an audio clip may yet be admitted into an SDMI
device, but only if it has not been degraded by compression. For each challenge,
SDMI provided some information about how a technology worked, and then challenged
the public to create an object with a certain property. The exact information
provided varied among the challenges. We note, though, that in all six cases
SDMI provided less information than a music pirate would have access to in
practice.
2.1 Watermark Challenges
Four of the challenges (A, B, C, and F), involved watermarking technologies,
in which subtle modifications are made to an audio file, to encode copyright
control information without perceptible change in how the file sounds. Watermarks
can be either robust or fragile. Robust watermarks are designed to survive
common transformations like digital-to-audio conversion, compression and
decompression, and the addition of small amounts of noise to the file. Fragile
watermarks do not survive such transformations, and are used to indicate
modification of the file. For each of the four watermark challenges, SDMI
provided three files:
-
File 1: an unwatermarked song;
- File 2: File 1, with a watermark added; and
- File 3: another watermarked song.
The challenge was to produce a file that sounded just like File 3 but did
not have a watermark -- in other words, to remove the watermark from File
3.
SDMI provided an on-line "oracle" for each challenge. Entrants could email
a file to the oracle, and the oracle would tell them whether their submission
satisfied the challenge, that is, whether it contained no detectable watermark
while still sounding like File 3. Entrants were given no information about
how watermark information was stored in the file or how the oracle detected
watermarks, beyond the information that could be deduced from inspection
of the three provided files.
2.2 Challenges D and E
Challenge D concerned a technology designed to prevent a song from being
separated from the album in which it was issued. Normally, every Compact
Disc contains a table of contents, indicating the offsets and lengths of
each audio track, followed by the audio data itself. Challenge D adds an
"authenticator" track (approximately 50ms of very quiet audio,) a digital
signature derived from the table of contents, which is supposed to be difficult
to compute for an arbitrary CD. Challenge D is discussed in more detail in
Section 4.1.
Challenge E involved a technology similar to D, but one which would be immune
the obvious attack on technology D, in which one compiled an unauthorized
CD with the same table of contents as an authorized one, for which the
authenticator track is given. Unfortunately, this challenge was constructed
in a way that made it impossible to even start analyzing the technology.
SDMI provided an oracle for this challenge, but unfortunately provided no
music samples of any kind, so there was no way to determine what the oracle
might be testing for.
Given these facts, we decided not to analyze Challenge E. It is discussed
briefly in Section 4.2.
3 The Watermarking Schemes
In this section, we describe our attack(s) on each of the four watermark
challenges (A,B,C,F). Our success was confirmed by emails received from SDMI's
oracles.
Fig. 1. The SDMI watermark attack problem. For
each of the four watermark challenges, Sample-1, sample-2, and sample-3 are
provided by SDMI sample-4 is generated by participants in the challenge and
submitted to SDMI oracle for testing.
Figure 1 provides an overview of the challenge goal. As mentioned earlier,
there are three audio files per watermark challenge: an original and watermarked
version of one clip, and then a watermarked version of a second clip, from
which the mark is to be removed. All clips were 2 minutes long, sampled at
44.1kHz with 16-bit precision.
The reader should note one serious flaw with this challenge arrangement.
The goal is to remove a robust mark, while these proposals appear to be Phase
II watermark screening technologies [4]. As we mentioned earlier, a Phase
II screen is intended to reject audio clips if they have been compressed,
and presumably compression degrades a fragile component of the watermark.
An attacker need not remove the robust watermark to foil the Phase II screen,
but could instead repair the modified fragile component in compressed audio.
This attack was not possible under the challenge setup.
3.1 Attack and Analysis of Technology A
A reasonable first step in analyzing watermarked content with original, unmarked
samples is differencing the original and marked versions in some way. Initially,
we used sample-by-sample differences in order to determine roughly what kinds
of watermark- ing methods were taking place. Unfortunately, technology A
involved a slowly varying phase distortion which masked any other cues in
a sample-by-sample difference. We ultimately decided this distortion was
a pre-processing separate from the watermark, in part because undoing the
distortion alone did not foil the oracle.
The phase distortion nevertheless led us to attempt an attack in which both
the phase and magnitude change between sample 1 and sample 2 is applied to
sample 3. This attack was confirmed by SDMI's oracle as successful, and
illustrates the general attack approach of imposing the difference in an
original-watermark pair upon another media clip. Here, the "difference" is
taken in the FFT domain rather than the time domain, based on our suspicions
regarding the domain of embedding. Note that this attack did not require
much information about the watermarking scheme itself, and conversely did
not provide much extra insight into its workings.
A next step, then, is to compute the frequency response H(w) =
W(w)/O(w) of the watermarking process for segments of audio,
and observe both |H(w)| and the corresponding impulse response
h(t). If the watermark is based on some kind of linear filter,
whose properties change slowly enough relative to the size of a frame of
samples, then this approach is ideal.
Figure 2 illustrates one frequency response and impulse response about 0.3
seconds into the music. These responses are based on FFTs of 882 samples,
or one fiftieth second of music. As can be clearly seen, a pair of sinusoidal
ripples are present within a certain frequency band, approximately 8-16Khz.
Ripples in the frequency domain are indicative of echoes in the time domain,
and a sum of sinusoids suggested the presence of multiple echoes. The
corresponding impulse response h(t) confirms this. This pattern
of ripples changes quite rapidly from frame to frame.
Thus, we had reason to suspect a complex echo hiding system, involving multiple
time-varying echoes. It was at this point that we considered a patent search,
knowing enough about the data hiding method that we could look for specific
search terms, and we were pleased to discover that this particular scheme
appears to be listed as an alternative embodiment in US patent number 05940135,
awarded to Aris corporation, now part of Verance [5]. This provided us with
little more detail than we had already discovered, but confirmed that we
were on the right track, as well as providing the probable identity of the
company which developed the scheme. It also spurred no small amount of discussion
of the validity of Kerckhoffs's criterion, the driving principle in security
that one must not rely upon the obscurity of an algorithm. This is, surely,
doubly true when the algorithm is patented.
Fig. 2. A short-term complex echo. Above, the
frequency response between the watermarked and original music, taken over
1/50 second, showing a sinusoidal ripple between 8 and 16 KHz. Below, the
corresponding impulse response. The sinusoidal pattern in the frequency domain
corresponds to a pair of echoes in the time domain.
The most useful technical detail provided by the patent was that the "delay
hopping" pattern was likely discrete rather than continuous, allowing us
to search for appropriate frame sizes during which the echo parameters were
constant. Data collection from the first second of audio showed a frame size
of approximately 882 samples, or 1/50 second. We also observed that the mark
did not begin until 10 frames after the start of the music, and that activity
also existed in a band of lower frequency, approximately 4-8 Khz. This could
be the same echo obscured by other operations, or could be a second band
used for another component in the watermarking scheme. A very clear ripple
in this band, indicating a single echo with a delay of about 34 samples,
appears shortly before the main echo-hopping pattern begins.
The next step in our analysis was the determination of the delay hopping
pattern used in the watermarking method, as this appeared to be the "secret
key" of the data embedding scheme. It is reasonable to suspect that the pattern
repeats itself in short order, since a watermark detector should be able
to find a mark in a subclip of music, without any assistance initially aligning
the mark with the detector's hopping pattern. Again, an analysis of the first
second revealed a pattern of echo pairs that appeared to repeat every 16
frames, as outlined in figure 3. The delays appear to fall within six general
categories, each delay approximately a multiple of 1/4 millisecond. The exact
values of the delays vary slightly, but this could be the result of the phase
distortion present in the music.
Fig. 3. The hypothesized delay hopping pattern
of technology A. Here two stretches of 16 frames are illustrated side-by-side,
with observed echoes in each frame categorized by six distinct delays: 2,
3, 4, 5, 6 or 7 times 0.00025 sec. Aside from several missing echoes, a pattern
appears to repeat every 16 frames. Note also that in each frame the echo
gain is the same for both echoes.
The reader will also note that in apparently two frames there is only one
echo. If this pattern were the union of two pseudorandom patterns chosen
from six possible delay choices, two "collisions" would be within what is
expected by chance.
Next, there is the issue of the actual encoded bits. Further work shows the
sign of the echo gain does not repeat with the delay-hopping pattern, and
so is likely at least part of an embedded message. Extracting such data without
the help of an original can be problematic, although the patent, of course,
outlines numerous detector structors which can be used to this end. We developed
several tools for cepstral analysis to assist us in the process. See [2]
for in introduction to cepstral analysis; Anderson and Petitcolas [1] illustrate
its use in attacks on echo hiding watermark systems.
With a rapidly changing delay, normal cepstral analysis does not seem a good
choice. However, if we know that the same echo is likely to occur at multiples
of 16/50 of a second, we can improve detector capability by combining the
information of multiple liftered2 log spectra.
____________________
2 in accordance with the flopped vocabulary used with cepstral analysis,
"liftering" refers to the process of filtering data in the frequency domain
rather than the time domain. Similarly, "quefrencies" are frequencies of
ripples which occur in the frequency domain rather than the time domain.
Three detector structures are shown in figure 4. In all three, a collection
of frames are selected for which the echo delays are believed to be the same.
For each, the liftered log of an FFT or PSD of the frame is taken. In the
first two structures, we compute a cepstrum, for each frame, then either
average their squared magnitudes, or simply their squares, in hopes that
a spike of the appropriate quefrency will be clear in the combination. The
motivation for merely squaring the spectral coefficients comes from the
observation that a spike due to an echo will either possess a phase of
theta or theta + pi for some value theta. Squaring
without taking magnitudes can cause the echo phases to reinforce, whilst
still permitting other elements to combine destructively.
Fig. 4. Three cepstral detector structures.
In each case we have a collection of distinct frames, each believed to possess
echoes of the same delay. The first two compute cepstral data for each frame,
and sum their squares (or squared magnitudes) to constructively combine the
echo signal in all frames. The third structure illustrates a method for testing
a hypothesized pattern of positive and negative gains, possibly useful for
brute-forcing or testing for the presence of a known "ciphertext."
In the final structure, one cepstrum. is taken using a guess of the gain
sign for each suspect frame. With the correct guess, the ripple should be
strongest, resulting in the largest spike from the cepstral detector. Figure
5 shows the output of this detector on several sets of suspect frames. While
this requires an exponential amount of work for a given amount of frames,
it has a different intended purpose: this is a brute-forcing tool, a utility
for determining the most probable among a set of suspected short strings
of gain signs as an aid to extracting possible ciphertext values.
Fig. 5. Detection of an echo. A screenshot of
our CepstroMatic utility shows a combination of 4 separate frames of music,
each a fiftieth of a second long, in which the same echo delay was believed
to exist. Their combination shows a very clear ripple on the right, corresponding
to a clear cepstral spike on the left. This is a single echo at a delay of
33 samples, the delay suggested for these intervalus by the hypothesized
delay-hopping pattern.
Finally, there is the issue of what this embedded watermark means. Again,
we are uncertain about a possible signalling band below 8Khz. This could
be a robust mark, signalling presence of a fragile mark of echoes between
8 and 16 KHz. The 8-16KHz band does seem like an unusual place to hide robust
data, unless it does indeed extend further down, and so this could very easily
be hidden information whose degredation is used to determine if music has
already been compressed.
Of course, knowledge of either the robust or fragile component of
the mark is enough for an attacker to circumvent the scheme, because one
can either remove the robust mark, or repair or reinstate the fragile mark
after compression has damaged it. As mentioned earlier, this possible attack
of repairing the fragile component appears to have been ruled out by the
nature of the SDMI challenge oracles. One must wait and see if real-world
attackers will attempt such an approach, or resort to more brute methods
or oracle attacks to remove the robust component.
3.2 Attack on Challenge B
We analyzed samp1b.wav and samp2b.wav using short-time FFT. Shown in Fig.
6 are the two FFT magnitudes for 1000 samples at 98.67 sec. Also shown is
the difference of the two magnitudes. A spectrum notch around 2800Hz is observed
for some segments of samp2b.wav and another notch around 3500Hz is observed
for some other segments of samp2b.wav. Similar notches are observed in
samp3b.wav. The attack fills in those notches of samp3b.wav with random but
bounded coefficient values. We also submitted a variation of this attack
involving different parameters for notch description. Both attacks were confirmed
by SDMI oracle as successful.
Fig. 6. Technology-B: FFT magnitudes of samp1b.wav
and samp2b.wav and their difference for 1000 samples at 98.67 sec.
3.3 Attacks on Challenge C
By taking the difference of samp1c.wav and samp2c.wav, bursts of narrowband
signal are observed, as shown in Fig. 7. These narrow band bursts appear
to be centered around 1350 Hz. Two different attacks were applied to Challenge
C. In the first at- tack, we shifted the pitch of the audio by about a
quartertone. In the second attack, we passed the signal through a bandstop
filter centered around 1350Hz. Our submissions were confirmed by SDMI oracle
as successful. In addition, the perceptual quality of both attacks has passed
the "golden ear" testing conducted by SDMI after the 3-week challenge.
Fig. 7. Challenge-C: Waveform of the difference
between samp1c.wav and samp2c.wav.
3.4 Attack on Challenge F
For Challenge F, we warped the time axis, by inserting a periodically varying
delay. The delay function comes from our study on Technology-A, and was in
fact initially intended to undo the phase distortion applied by technology
A. Therefore the perceptual quality of our attacked audio is expected to
be better than or comparable to that of the audio watermarked by Technology-A.
We also submitted variations of this at- tack involving different warping
parameters and different delay function. They were confirmed by SDMI oracle
as successful.
4 The Non-Watermark Technologies
The HackSDMI challenge contained two "non-watermark" technologies. Together,
they appear to be intended to prevent the creation of "mix" CDs, where a
consumer might compile audio files from various locations to a writable CD.
This would be enforced by universally embedding SMDI logic into consumer
audio CD players.
4.1 Technology D
According to SDMI, Technology D was designed to require "the presence of
a CD in order to 'rip' or extract a song for SDMI purposes." The technology
aimed to accomplish this by adding a 53.3 ms audio track (four blocks of
CD audio), which we will refer to as the authenticator, to each CD.
The authenticator, combined with the CD's table of contents (TOC), would
allow a SDMI device to recognize SDMI compliant CDs. For the challenge, SDMI
provided 100 different "correct" TOC-authenticator pairs as well as 20 "rogue
tracks". A rogue track is a track length that does not match any of the track
lengths in the 100 provided TOCs. The goal of the challenge was to submit
to the SDMI oracle a correct authenticator for a TOC that contained at least
one of the rogue tracks.
The oracle for Technology D allowed several different query types. In the
first type, an SDMI provided TOC-authenticator combination is submitted so
a that user can "understand and verify the Oracle." According to SDMI, the
result of this query should either be "admit" for a correct pair or "reject"
for an incorrect pair. When we attempted this test a SDMI-provided pair,
the oracle responded that the submission was "invalid." After verifying that
we had indeed submitted a correct pair, we attempted several other submissions
using different TOC-authenticator pairs as well as different browsers and
operating systems3. We also submitted some pairs that the oracle
should have rejected; these submissions were also declared "invalid." Though
we alerted SDMI to this problem during the challenge, the oracle was never
repaired. For this reason, our analysis of Technology D is incomplete and
we lack definitive proof that it is correct. That having been said, we think
that what we learned about this technology, even without the benefit of a
correctly functioning oracle, is interesting.
____________________
3 Specifically, Netscape Navigator and Mozilla under Linux, Netscape
Navigator under Windows NT, and Internet Explorer under Windows 98 and 2000.
Analyzing the Signal Upon examination of the authenticator audio files,
we discovered several patterns. First, the left and right channels contain
the same information. The two channels differ by a "noise vector" u,
which is a vector of small integer values that range from -8 and 8. Since
the magnitude of the noise is so small, the noise vector does not significantly
affect the frequency characteristics of the signal. The noise values appear
to be random, but the noise vector is the same for each of the 100 provided
authenticator files. In other other words, in any authenticator file, the
difference between the left and right channels of the ith sample is
a constant fixed value u[i]. This implies that the noise vector
u does not encode any TOC-specific information.
Second, the signal repeats with a period of 1024 samples. Because the full
signal is 2352 samples long, the block repeats approximately 1.3 times. Similarly
to the left and right channels of the signal, the first two iterations of
the repeating signal differ by a constant noise vector v. The difference
between the ith sample of the first iteration and the ith sample
of the second iteration differ by a small (and apparently random) integer
value v[i] ranging from -15 to 15. In addition, v is
the same for each of the provided authenticator files, so v does not
encode any TOC-specific information.
Third, the first 100 samples and last 100 samples of the full signal are
faded in and faded out, respectively. This is illustrated in Figure 8. The
fade-in and fade-out are meaningless, however, because they simply destroy
data that is repeated in the middle of the file. We conjecture that this
fade-in and fade-out are included so that the audio signal does not sound
offensive to a human ear.
Fig. 8. In a Technology D Authenticator, the
signal fades in, repeats, and fades out.
Extracting the Data Frequency analysis on the 1024 sample block shows
that almost all of the signal energy is concentrated in the 16-20kHz range,
as shown in Figure 9. We believe this range was chosen because these frequencies
are less audible to the human ear. Closer examination shows that this l6-20kHz
range is divided up into 80 discrete bins, each of which appears to carry
one bit of information. As shown in Figure 10, these bits can be manually
counted by a human using a graph of the magnitude of signal in the frequency
domain.
Fig. 9. Magnitude vs. Frequency of Technology
D Authenticator
Fig. 10. Individual Bits From a Technology D
Authenticator
Close inspection and pattern matching on these 80 bits of information reveals
that there are only 16 bits of information repeated 5 times using different
permutations. using the letters A-P to symbolize the 16 bits, these 5
permutations are described in Figure 11.
ABCDEFGHIJKLMNOP
OMILANHGPBDCKJFE
PKINHODFMJBCAGLE
FCKLGMEPNOADJBHI
PMGHLECAKDONIFJB
Fig. 11. The encoding of the 16 bits of data
in Technology D
Because of the malfunctioning oracle, we were unable to determine the function
used to map TOCs to authenticators, but given an actual SDMI device, it would
be trivial to brute force all 216 possibilities. Likewise, without
the oracle, we could not determine if there was any other signal present
in the authenticator (e.g., in the phase of the frequency components
with nonzero magnitude).
For the moment, let us assume that the hash function used in Technology D
has only 16 bits of output. Given the number of distinct CDs available, an
attacker should be able to acquire almost, if not all, of the authenticators.
We note that at 9 kilobytes each, a collection of 65,536 files would fit
nicely on a single CD. Many people have CD collections of 300+ discs, which
by the birthday paradox makes it more likely than not that there is a hash
collision among their own collection.
Our results indicated that the hash function used in Technology D could be
weak or may have less than 16 bits of output. In the 100 authenticator samples
provided in the Technology D challenge, there were 2 pairs of 16-bit hash
collisions. We will not step through the derivation here, but the probability
of two or more collisions occurring in n samples of X equally
likely possibilities is:
If the 16-bit hash function output has 16 bits of entropy, the probability
of 2 collisions occurring in n = 100 samples of X =
216 possibilities is 0.00254 (by the above 1.5 equation). If
X ~ 211.5, the chances of two collisions occurring is about
even. This suggests that either 4 bits of the 16-bit hash output may be outputs
of functions of the other 12 bits or the hash function used to generate the
16-bit signature is weak. It is also possible that the challenge designers
purposefully selected TOCs that yield collisions. The designers could gauge
the progress of the contestants by observing whether anyone submits authenticator
A with TOC B to the oracle, where authenticator A is equal to authenticator
B. Besides the relatively large number of collisions in the provided
authenticators, it appears that there are no strong biases in the authenticator
bits such as significantly more or less 1's than 0's.
4.2 Technology E
Technology E is designed to fix a specific bug in Technology D: the TOC only
mentions the length of each song but says nothing about the contents
of that song. As such, an attacker wishing to produce a mix CD would only
need to find a TOC approximately the same as the desired mix CD, then copy
the TOC and authenticator from that CD onto the mix CD. If the TOC does not
perfectly match the CD, the track skipping functionality will still work
but will only get "close" to track boundaries rather than reaching them
precisely. Likewise, if a TOC specified a track length longer than the track
we wished to put there, we could pad the track with digital silence (or properly
SDMI-watermarked silence, copied from another valid track). Regardless, a
mix CD played from start to end would work perfectly. Technology E is designed
to counter this attack, using the audio data itself as part of the authentication
process.
The Technology E challenge presented insufficient information to be properly
studied. Rather than giving us the original audio tracks (from which we might
study the unspecified watermarking scheme), we were instead given the tables
of contents for 1000 CDs and a simple scripting language to specify a
concatenation of music clips from any of these CDs. 'Me oracle would process
one of these scripts and then state whether the resulting CD would be rejected.
While we could have mounted a detailed statistical analysis, submitting hundreds
or thousands of queries to the oracle, we believe the challenge was fundamentally
flawed. In practice, given a functioning SDMI device and actual SDMI-protected
content, we could study the audio tracks in detail and determine the structure
of the watermarking scheme.
5 Conclusion
In this paper, we have presented an analysis of the technology challenges
issued by the Secure Digital Music Initiative. Each technology challenge
described a specific goal (e.g., remove a watermark from an audio
track) and offered a Web-based oracle that would confirm whether the challenge
was successfully defeated.
We have reverse-engineered and defeated all four of their audio watermarking
technologies. We have studied and analyzed both of their "non-watermarking"
technologies to the best of our abilities given the lack of information available
to us and given a broken oracle in one case.
Some debate remains on whether our attacks damaged the audio beyond standards
measured by "golden ear" human listeners. Given a sufficient body of
SDMI-protected content using the watermark schemes presented here, we are
confident we could refine our attacks to introduce distortion no worse than
the watermarks themselves introduce to the the audio. Likewise, debate remains
on whether we have truly defeated technologies D and E. Given a functioning
implementation of these technologies, we are confident we can defeat them.
Do we believe we can defeat any audio protection scheme? Certainly, the technical
details of any scheme will become known publicly through reverse engineering.
Using the techniques we have presented here, we believe no public watermark-based
scheme intended to thwart copying will succeed. Other techniques may or may
not be strong against attacks. For example, the encryption used to protect
consumer DVDs was easily defeated. Ultimately, if it is possible for a consumer
to hear or see protected content, then it will be technically possible for
the consumer to copy that content.
References
1. R. J. ANDERSON, AND F. A. P. PETITCOLAs. On the limits of steganography.
IEEE Journal of Selected Areas in Communications 16,4 (May 1998),474-481.
2. R. P. BOGERT, M., AND J. W. TUKEY. The quefrency alanysis of time series
for echoes: Cepstrum, pseudo-autocovariance, cross-ceptsrum and saphe-cracking.
In Proceedings of the Symposium on Time Series Analysis (Brown University,
June 1962), pp. 209-243.
3. R. PETROVIC, J. M. WINOGRAD, K., AND E. METOIS. Apparatus and method for
encoding and decoding information in analog signals, Aug. 1999. US Patent
No 05940135
http://www.delphion.com/details?pn=US05940135__.
>Am I afraid of people with homosexual behaviors? >Hardly. Am I "afraid" of what homosexualbehavior
does to people?
This sounds like homophobia to me.
Homosexual behaviour doesn't "do" anything to people. I happen to be gay and I view it as just another attribute, like having green eyes or black hair.
There are lots of straight AND gay people that do lots of different things not because they are gay or straight but because that's the kind of person they are. Their sexual orientation has nothing to do with that behaviour.
You mean like OpenNap and all the other servers out there that use the napster protocol? Napster was REed yonks ago, and the servers have been around a while to. for a list, check out Napigator
>What is going to happen if somebody creates a >mirror of these sites in a server operating >outside the jurorsdiction of a USA court
You mean like this?
I agree with the principle of "punish the crime, not the tool," but it's not that simple here. DVD-CCA developed CSS and licenses it, just like Microsoft developed Windows and licenses it to people. If you reverse engineer their tool and distribute the source code, you're violating their intellectual property
So you're basically saying thatr WINE is violating
Microsoft's "IP"?
Im sorry, it's people like you that seem to think that you can crush the human spirit along with the very idea of curosity. Even if you dont mean it.
The DVDCCA licenses CSS out to people, because it's a (or was) a trade secret. It's no longer secret, so now people can do whatever the hell they want to/with CSS without a license.
No one broke any NDA's or anything like that, so the cat is out of the bag, and you can't stuff it back in.
It's like saying I can't develop my own kind of tyre because I figured out how to put tyres on cars.
My mirror of DeCSS stuff Contains lots of various decss related stuff along with livid/decss + source/mirrors etcetc
I happen to live in NZ, so none of this court crap
affects me
Well, all comments are owned by the poster right?
So the MPAA can come after me, in good old NZ.
I present to you css_descramble.c
(The same file printed on the back of my now illeagl t-shirt) I'll make a note not to ever visit the good ole US of A
/*
* css_descramble.c
*
* Released under the version 2 of the GPL.
*
* Copyright 1999 Derek Fawcus
*
* This file contains functions to descramble CSS encrypted DVD content
*
*/
/*
* Still in progress: Remove the use of the bit_reverse[] table by recoding
* the generation of LFSR1. Finish combining this with
* the css authentication code.
*
*/
#include
#include
#include "css-descramble.h"
typedef unsigned char byte;
/*
*
* some tables used for descrambling sectors and/or decrypting title keys
*
*/
0x07,0x87,0x47,0xc7,0x27,0xa7,0x67,0xe7,0x17,0x97, 0x57,0xd7,0x37,0xb7,0x77,0xf7,
0x0f,0x8f,0x4f,0xcf,0x2f,0xaf,0x6f,0xef,0x1f,0x9f, 0x5f,0xdf,0x3f,0xbf,0x7f,0xff
};
/*
*
* this function is only used internally when decrypting title key
*
*/
static void css_titlekey(byte *key, byte *im, byte invert)
{
unsigned int lfsr1_lo,lfsr1_hi,lfsr0,combined;
byte o_lfsr0, o_lfsr1;
byte k[5];
int i;
lfsr1_lo = im[0] | 0x100;
lfsr1_hi = im[1];
lfsr0 = ((im[4] >8)&0xff] >16)&0xff]>24)&0xff];
combined = 0;
for (i = 0; i >1;
lfsr1_lo = ((lfsr1_lo&1)>7)^(lfsr0>>10)^(lfsr0>>11)^(lfsr0>>1 9);*/
o_lfsr0 = (((((((lfsr0>>8)^lfsr0)>>1)^lfsr0)>>3)^lfsr0)>>7); lfsr0 = (lfsr0>>8)|(o_lfsr0>= 8;
}
key[4]=k[4]^csstab1[key[4]]^key[3];
key[3]=k[3]^csstab1[key[3]]^key[2];
key[2]=k[2]^csstab1[key[2]]^key[1];
key[1]=k[1]^csstab1[key[1]]^key[0];
key[0]=k[0]^csstab1[key[0]];
}
/*
*
* this function decrypts a title key with the specified disk key
*
* tkey: the unobfuscated title key (XORed with BusKey)
* dkey: the unobfuscated disk key (XORed with BusKey)
* 2048 bytes in length (though only 5 bytes are needed, see below)
* pkey: array of pointers to player keys and disk key offsets
*
*
* use the result returned in tkey with css_descramble
*
*/
int css_decrypttitlekey(byte *tkey, byte *dkey, struct playkey **pkey)
{
byte test[5], pretkey[5];
int i = 0;
Errr, there is auctally. LiViD is one such open source DVD player. css-auth (which authenticates with the drive) was auctally written by someone on the LiViD team and was used in DeCSS (which is GPLed thus).
It does work, a few months ago I saw the Matrix played off DVD under Linux. So yes, it does work, and there is player (Which, I am in no doubt that if the MPAA wins will be delcared illegal, at least in the US.) Fortunatly, it is GPLed. They can't stop Open Source software, because it will simply be "smuggled" over borders, and the developers will still develop it. All it will mean is that you will have to get it from foriegn soil.
>Big money and big companies don't always win. >They will in this case in part because 2600 tried to disobey the court when they were asked to take >the DeCSS code down. They removed the code and then published a list of mirrors in an attempt to circumvent the court order. They lost a lot of >credibility with the court by doing that. Goldstein is somewhat lucky to have not done jail time for contempt Auctally, they started listing mirrors when they put up the DeCSS code. The court injunction only said to remove DeCSS itself. (It's in the transcripts people!) http://www.eff.org/IP/Video/MPAA_DVD_ca ses/
Also, the MPAA tried to get the injunction modified so that anything that was "unauthorised" (such as LiViD) was also made illegal. I dont think has been granted, because they also wanted the injunction to including linking to the DeCSS bin/source. WHich is funny, because they'd have to shut down their own search engines;) (Try "DeCSS" in Disney's/Go's search engine. Fun)
Qoute: 1. For an Order, pursuant to Rule 65 of the Federal Rules of Civil Procedure, modifying this Court's preliminary injunction Order, dated January 20, 2000, by adding the following to the indicated paragraphs of said order:
a) add to paragraph 2 the name of additional defendant 2600 Enterprises, Inc., and delete the names of defendants Shawn C. Reimerdes and Roman Kazan,
b) add to paragraphs 2(a) and 2(b), after the words "posting on," the language "or linking to," and insert commas after the words "trafficking in,"
c) revise paragraph 3(b) to read "'CSS' means the Contents Scramble System used to encrypt, scramble or otherwise protect the contents of certain DVDs from unauthorized access or copying,"
d) revise paragraph 3(c) to read " 'DeCSS' means any computer program, file or device that may be used to decrypt or unscramble the contents of DVDs that are protected, or otherwise to circumvent the protection afforded, by CSS and that permits the unauthorized access or copying of the contents or any portion thereof,"
e) add (d) to paragraph 3 as follows: "a 'hyperlink' means software instructions which, when executed, cause a signal to be sent to another location where data or material can be retrieved for viewing, copying or further transmission,"
f) add (e) to paragraph 3 as follows: " 'linking' means provision by the defendants, at their respective websites, of hyperlinks to other websites which are offering to the public, providing, providing hyperlinks to, or otherwise trafficking in DeCSS or any technology, product, service, device, component, or part thereof described in paragraph 2(b),"
Auctally they did have dreams of a DVD player for Linux. The reason it was written as a windows executable was because linux didn't have UDF support at the time. If you want proof, read the court transcripts (and depositions) from the MPAAv2600.. Jon Johanson has testified himself. http://www.eff.org/IP/Video/MPAA_DVD_ca ses/
Selling your soul to the devil? License it instead
on
Copyrant
·
· Score: 5
I just thought of something, inspired by the devil incarinate himself. Since this seems to be the future of propietory software, I figure, why not instead of having to SELL my soul to the devil, I can (while retaining full copyright, trademark rights and everything other prexisting right over it) sell him a LICENSE for the use of my soul. Now, I leave the exact details of this license to the reader, but im sure you can all come up with some nifty EULA's (or DSULA (Devil Soul Usage License Agreements). Email me some;)
Excuse me, but how do you run an OS ontop of another OS? Not counting things like VMWare, Plex86 and others, running an OS straight ontop of an other is impossible. Unless they mean compiling things and such? And no, using a "launcher" doesn't count either (Like the BeOS PE). It would have been nice if the author of the article that/. linked to had known what he was talking about, or even elaborated on just HOW they were going to run the next Workbench ontop of Red hat. (and why not just say Linux?)
Re:Some differences BeOS for Linux / Windows
on
BeOS For Linux!
·
· Score: 1
> 2. If you boot BeOS from an ext2 partition, BeOS will be > unable to use virtual memory. BeOS' VM works on FAT, not on > ext2 *blinks* I assume you mean if you keep the BeOS image on an ext2fs partition? I don't think this is right, because both top and ProcessControler under BeOS show apps using virtual memory..
Auctally, it says "Unfortunately, BeOS 5 Personal Edition, because of technical reasons, can only recognize one processor." Those technical reasons are the fact that your average joe will be using Windows 9x, and just running the bootstrap inside windows. Windows 9x does not support SMP, it disables any other CPU's. So in order to get SMP, you have to use the bootdisk. I beleive www.benews.com has something about it.. ahhh, here.. http://www.benews.com/story/2931.2.html
Ok, I keep seeing people post stuff that isn't true about the BeOS "Personal edition" so here are the _facts_ BeOS 5 PE is NOT a trial version, crippled or an "evaluation". It is the entire OS, all of it.. just the same BeOS "Pro Version" It IS BeOS.. Another thing. The title of the article is wrong.. The linux "version" just includes a readme, be partition image and a bootdisk image. Copy the image to/beos, use the boot disk and you're off. Im guessing it's just for users of OS's other then windows, since they wouldn't be able to run the installer exe that the windows "version" needs. Also, BeOS "PE" does support SMP, and various other things. You just have to use the bootdisk, instead of using the windows loader. (Windows 9x disables all the other CPU's) Also, you are NOT limited to just the BFS image partition. Once you have it running, you can use Installer to copy/install BeOS (your current setyp) to any other partition. So, make some free space, run BeOS from the image and install it there.
Summary: BeOS 5 PE is the entire OS, it has no limitations. The only thing different between PE and the Pro version is what Be has told you. Realplayer, mp3 encoders (which you can download anyway) etcetc. Do not let anyone fool you, including Be.
Hmm, this isn't very useful, but amusing for the first few minutes. You can change the characters in that semingly random bunch of chars that they use, such as http://X199DAASOFTWARE84PATENTS71CBLOW3E.sevenva l.com/ *grins* As long as it remains the same length, you can replace mostly of the garbage with words.. Enjoy.
Slashdot Mirror
Someone has released a patched version of the kazaa binary. If you want it, come into #gift on irc.openprojects.net and ask.
/. article is WRONG. Since they use centralised servers (For log on/serving up ads/etc) they can be shut down just as well as napster.
The problem is that Fast Track is NOT open source and uses encryption between usersusers/supernodes.
I think they still want to figure out the protocol, since the kazaa binary only runs on linux x86.
Oh, it should also be noted that Fast Track DOES use central servers, so the blurb in this
I also don't beleive the EFF should be defending these guys, as earlier posters have said kazaa/morpheus is full of spyware and ads.
Mission Accomplished.
If you want a gui (X) without the bloat, try RatPoison
It's small, very light and very fast. It's not so much as a window manager as a... well, go see for yourself.
It's sort of retro
That said, anything that uses GNOME/KDE/etc IS bloat.. I've had to download boatloads of crap.
I installed off a debian 2.2r3 iso.. whew. It's amazing how many different damn libraries you have to download.. why can't you make do with gtk?? Oh well.
Whoever says linux is ready for the desktop (like your grandma) is bullshiting themselves.. It's not ready, yet.
CDex has support for Vorbis, although im not sure what version encoder they're using.
You can get CDex from The CDex page
Also there are plugins and an "official" encoder at Vorbis.com
WTF? This is supposed to be news for nerds, or whatever. Not CNN. If you want to hear this, turn on a TV or something, geez
Now, one thing I haven't seen discussed... Has anyone approached the CCA about becoming a licensed user of CSS? How much can be published? If the licensed app is GPL'ed, how much of the CSS code goes for the ride? $10k isn't all that much, in the scheme of things.
Auctally, the contract/license agreement you sign doesn't allow open sourcing of the code, because then otherwise anyone could just find out how it works. So, you can't "legally" license an open source DVD player.
Also, who's going to pay the $10k? What's the point of paying that $10k and then not being able to open source it, at which point you'd have to sell it to recoup the $10k, so on and so forth.
I beleive LiVid and maybe other groups have approached the DVDCCA about licensing it, but a) it's not free and b) No source code.
Of course, if you lose the reader, you would also have to go back and buy all the ebooks again.
(since you'd only be allowed "one copy" etc)
Auctally, no. Simon Travaglia (aka BoFH) is from New Zealand.
He used to work (Or currently does, im not sure) at the Waikato Univerisity.
The register has the latest BoFH installments.
Oh, and be careful about saying he's from Australia, your keyboard might curiously become electrified.
20 April 2001. Thanks to Anonymous
From cryptome.org
[Letter, 3 pp.]
MATTHEW J. OPPENHEIM, ESQ.
Address illegible
RIAA
April 9, 2001
Professor Edward Felton
Department of Computer Science
Princeton University
Princeton, NJ 08544
Dear Professor Felten,
We understand that in conjunction with the 4th International Information Hiding Workshop to be held April 25-29, 2001, you and your colleagues who participated in last year's Secure Digital Music Initiative ("SDMI") Public Challenge are planning to publicly release information concerning the technologies that were included in that challenge and certain methods you and your colleagues developed as part of your participation in the challenge. On behalf of the SDMI Foundation, I urge you to reconsider your intentions and to refrain from any public disclosure of confidential information derived from the Challenge and instead engage SDMI in a constructive dialogue on how the academic aspects of your research can be shared without jeopardizing the commercial interests of the owners of the various technologies.
As you are aware, at least one of the technologies that was the subject of the Public Challenge, the Verance Watermark, is already in commercial use and the disclosure of any information that might assist others to remove this watermark would seriously jeopardize the technology and the content it protects.1 Other technologies that were part of the Challenge are either likewise in commercial use or could be could be utilized in this capacity in the near future. Therefore, any disclosure of information that would allow the defeat of those technologies would violate both the spirit and the terms of the Click-Through Agreement (the "Agreement"). In addition, any disclosure of information gained from participating in the Public Challenge would be outside the scope of activities permitted by the Agreement and could subject you and your research team to actions under the Digital Millennium Copyright Act ("DCMA").
____________________
We appreciate your position, as articulated in the Frequently Asked Questions document, that the purpose of releasing your research is not designed to "help anyone impose or steal anything." Further more, you participation in the Challenge and your contemplated disclosure appears to be motivated by a desire to engage in scientific research that will ensure that SDMI does not deploy a flawed system. Unfortunately, the disclosure that you are contemplating could result in significantly broader consequences and could directly lead to the illegal distribution of copyrighted material. Such disclosure is not authorized in the Agreement, would constitute a violation of the Agreement and would subject your research team to enforcement actions under the DMCA and possibly other federal laws.
As you are aware, the Agreement covering the Public challenge narrowly authorizes participants to attack the limited number of music samples and files that were provided by SDMI. The specific purpose of providing these encoded files and for setting up the Challenge was to assist SDMI in determining which of the proposed technologies are best suited to protect content in Phase II products. The limited waiver of rights (including possible DMCA claims) that was contained in the Agreement specifically prohibits participants from attacking content protected by SDMI technologies outside the Public Challenge. If your research is released to the public this is exactly what could occur. In short, you would be facilitating and encouraging the attack of copyrighted content outside the limited boundaries of the Public Challenge and thus places you and your researchers in direct violation of the Agreement.
In addition, because public disclosure of your research would be outside the limited authorization of the Agreement, you could be subject to enforcement actions under federal law, including the DMCA. The Agreement specifically reserves any rights that proponents of the technology being attacked may have "under any applicable law, including, without limitation, the U.S. Digital Millennium Copyright Act, for any acts not expressly authorized by their Agreement." The Agreement simply does not "expressly authorize" participants to disclose information and research developed through participating in the Public challenge and such disclosure could be the subject of a DMCA action.
We recognize and appreciate your position, made clear throughout this process, that it is not your intention to engage in any illegal behavior or to otherwise jeopardize the legitimate commercial interests of others. We are concerned that your actions are outside the peer review process established by the Public Challenge and setup by engineers and other experts to ensure the academic integrity of this project. With these facts in mind, we invite you to work with the SDMI Foundation to find a way for you to share the academic components of your research while remaining true to your intention to not violate the law or the Agreement. In the meantime, we urge you to withdraw the paper submitted for the upcoming Information Hiding Workshop, assure that it is removed from the Workshop distribution materials and destroyed, and avoid a public discussion of confidential information.
Sincerely,
[Signature]
Matthew Oppenheim, Secretary
The SDMI Foundation
cc: Mr. Ira S. Moskowitz, Program Chair, Information Hiding Workshop, Naval Research Laboratory
Cpt. Douglas S. Rau, USN, Commanding Officer, Naval Research Laboratory
Mr. Howard Ende, General Counsel of Princeton
Mr. Edward Dobkin, Computer Science Department Head of Princeton
[Paper, 15 pp.]
Reading Between the Lines:
1 IntroductionLessons from the SDMI Challenge
Scott A. Craver1, John R McGregor1, Min Wu1, Bede Liu1,
Adam Stubblefield2, Ben Swartzlander2, Dan S. Wallach2,
Drew Dean3, and Edward W. Felten4 1 Dept. of Electrical Engineering, Princeton University
2 Dept. of Computer Science, Rice University
3 Computer Science Laboratory, Xerox Palo Alto Research Center
4 Dept. of Computer Science, Princeton University
The Secure Digital Music Initiative (SDMI), a consortium of music-industry companies, is working to develop and standardize technologies that give music publishers more control over what consumers can do with recorded music that they buy. SDMI has been a somewhat secretive organization, releasing little information to the public about its goals, deliberations, and technology.
In September 2000, SDMI announced a "public challenge" in which it invited members of the public to try to break certain data-encoding technologies that SDMI had developed [3]. The challenge offered a valuable window into SDMI, not only into its technologies but also into its plans and goals. We decided to use the challenge to learn as much as we could about SDMI. This paper is the result of our study.1 Section 2 presents an overview of the HackSDMI challenge. Section 3 analyzes the watermark challenges. Section 4 analyzes the non-watermark challenges. Finally, we present our conclusions in section 5.
____________________
2 The SDMI ChallengeThe SDMI challenge extended over roughly a three-week period, from September 15, 2000 until October 8, 2000. The challenge actually consisted of six sub-challenges, named with the letters A through F, each involving a different technology developed by SDMI. We believe these challenges correspond to submissions to the SDMI's Call for Proposals for Phase II Screening Technology [4]. According to this proposal, the watermark's purpose is to restrict an audio clip which is compressed or has previously been compressed. That is, if the watermark is present an audio clip may yet be admitted into an SDMI device, but only if it has not been degraded by compression. For each challenge, SDMI provided some information about how a technology worked, and then challenged the public to create an object with a certain property. The exact information provided varied among the challenges. We note, though, that in all six cases SDMI provided less information than a music pirate would have access to in practice.
2.1 Watermark Challenges
Four of the challenges (A, B, C, and F), involved watermarking technologies, in which subtle modifications are made to an audio file, to encode copyright control information without perceptible change in how the file sounds. Watermarks can be either robust or fragile. Robust watermarks are designed to survive common transformations like digital-to-audio conversion, compression and decompression, and the addition of small amounts of noise to the file. Fragile watermarks do not survive such transformations, and are used to indicate modification of the file. For each of the four watermark challenges, SDMI provided three files:
The challenge was to produce a file that sounded just like File 3 but did not have a watermark -- in other words, to remove the watermark from File 3.
SDMI provided an on-line "oracle" for each challenge. Entrants could email a file to the oracle, and the oracle would tell them whether their submission satisfied the challenge, that is, whether it contained no detectable watermark while still sounding like File 3. Entrants were given no information about how watermark information was stored in the file or how the oracle detected watermarks, beyond the information that could be deduced from inspection of the three provided files.
2.2 Challenges D and E
Challenge D concerned a technology designed to prevent a song from being separated from the album in which it was issued. Normally, every Compact Disc contains a table of contents, indicating the offsets and lengths of each audio track, followed by the audio data itself. Challenge D adds an "authenticator" track (approximately 50ms of very quiet audio,) a digital signature derived from the table of contents, which is supposed to be difficult to compute for an arbitrary CD. Challenge D is discussed in more detail in Section 4.1.
Challenge E involved a technology similar to D, but one which would be immune the obvious attack on technology D, in which one compiled an unauthorized CD with the same table of contents as an authorized one, for which the authenticator track is given. Unfortunately, this challenge was constructed in a way that made it impossible to even start analyzing the technology. SDMI provided an oracle for this challenge, but unfortunately provided no music samples of any kind, so there was no way to determine what the oracle might be testing for.
Given these facts, we decided not to analyze Challenge E. It is discussed briefly in Section 4.2.
3 The Watermarking Schemes
In this section, we describe our attack(s) on each of the four watermark challenges (A,B,C,F). Our success was confirmed by emails received from SDMI's oracles. Fig. 1. The SDMI watermark attack problem. For each of the four watermark challenges, Sample-1, sample-2, and sample-3 are provided by SDMI sample-4 is generated by participants in the challenge and submitted to SDMI oracle for testing.
Figure 1 provides an overview of the challenge goal. As mentioned earlier, there are three audio files per watermark challenge: an original and watermarked version of one clip, and then a watermarked version of a second clip, from which the mark is to be removed. All clips were 2 minutes long, sampled at 44.1kHz with 16-bit precision.
The reader should note one serious flaw with this challenge arrangement. The goal is to remove a robust mark, while these proposals appear to be Phase II watermark screening technologies [4]. As we mentioned earlier, a Phase II screen is intended to reject audio clips if they have been compressed, and presumably compression degrades a fragile component of the watermark. An attacker need not remove the robust watermark to foil the Phase II screen, but could instead repair the modified fragile component in compressed audio. This attack was not possible under the challenge setup.
3.1 Attack and Analysis of Technology A
A reasonable first step in analyzing watermarked content with original, unmarked samples is differencing the original and marked versions in some way. Initially, we used sample-by-sample differences in order to determine roughly what kinds of watermark- ing methods were taking place. Unfortunately, technology A involved a slowly varying phase distortion which masked any other cues in a sample-by-sample difference. We ultimately decided this distortion was a pre-processing separate from the watermark, in part because undoing the distortion alone did not foil the oracle.
The phase distortion nevertheless led us to attempt an attack in which both the phase and magnitude change between sample 1 and sample 2 is applied to sample 3. This attack was confirmed by SDMI's oracle as successful, and illustrates the general attack approach of imposing the difference in an original-watermark pair upon another media clip. Here, the "difference" is taken in the FFT domain rather than the time domain, based on our suspicions regarding the domain of embedding. Note that this attack did not require much information about the watermarking scheme itself, and conversely did not provide much extra insight into its workings.
A next step, then, is to compute the frequency response H(w) = W(w)/O(w) of the watermarking process for segments of audio, and observe both |H(w)| and the corresponding impulse response h(t). If the watermark is based on some kind of linear filter, whose properties change slowly enough relative to the size of a frame of samples, then this approach is ideal.
Figure 2 illustrates one frequency response and impulse response about 0.3 seconds into the music. These responses are based on FFTs of 882 samples, or one fiftieth second of music. As can be clearly seen, a pair of sinusoidal ripples are present within a certain frequency band, approximately 8-16Khz. Ripples in the frequency domain are indicative of echoes in the time domain, and a sum of sinusoids suggested the presence of multiple echoes. The corresponding impulse response h(t) confirms this. This pattern of ripples changes quite rapidly from frame to frame.
Thus, we had reason to suspect a complex echo hiding system, involving multiple time-varying echoes. It was at this point that we considered a patent search, knowing enough about the data hiding method that we could look for specific search terms, and we were pleased to discover that this particular scheme appears to be listed as an alternative embodiment in US patent number 05940135, awarded to Aris corporation, now part of Verance [5]. This provided us with little more detail than we had already discovered, but confirmed that we were on the right track, as well as providing the probable identity of the company which developed the scheme. It also spurred no small amount of discussion of the validity of Kerckhoffs's criterion, the driving principle in security that one must not rely upon the obscurity of an algorithm. This is, surely, doubly true when the algorithm is patented. Fig. 2. A short-term complex echo. Above, the frequency response between the watermarked and original music, taken over 1/50 second, showing a sinusoidal ripple between 8 and 16 KHz. Below, the corresponding impulse response. The sinusoidal pattern in the frequency domain corresponds to a pair of echoes in the time domain.
The most useful technical detail provided by the patent was that the "delay hopping" pattern was likely discrete rather than continuous, allowing us to search for appropriate frame sizes during which the echo parameters were constant. Data collection from the first second of audio showed a frame size of approximately 882 samples, or 1/50 second. We also observed that the mark did not begin until 10 frames after the start of the music, and that activity also existed in a band of lower frequency, approximately 4-8 Khz. This could be the same echo obscured by other operations, or could be a second band used for another component in the watermarking scheme. A very clear ripple in this band, indicating a single echo with a delay of about 34 samples, appears shortly before the main echo-hopping pattern begins.
The next step in our analysis was the determination of the delay hopping pattern used in the watermarking method, as this appeared to be the "secret key" of the data embedding scheme. It is reasonable to suspect that the pattern repeats itself in short order, since a watermark detector should be able to find a mark in a subclip of music, without any assistance initially aligning the mark with the detector's hopping pattern. Again, an analysis of the first second revealed a pattern of echo pairs that appeared to repeat every 16 frames, as outlined in figure 3. The delays appear to fall within six general categories, each delay approximately a multiple of 1/4 millisecond. The exact values of the delays vary slightly, but this could be the result of the phase distortion present in the music. Fig. 3. The hypothesized delay hopping pattern of technology A. Here two stretches of 16 frames are illustrated side-by-side, with observed echoes in each frame categorized by six distinct delays: 2, 3, 4, 5, 6 or 7 times 0.00025 sec. Aside from several missing echoes, a pattern appears to repeat every 16 frames. Note also that in each frame the echo gain is the same for both echoes.
The reader will also note that in apparently two frames there is only one echo. If this pattern were the union of two pseudorandom patterns chosen from six possible delay choices, two "collisions" would be within what is expected by chance.
Next, there is the issue of the actual encoded bits. Further work shows the sign of the echo gain does not repeat with the delay-hopping pattern, and so is likely at least part of an embedded message. Extracting such data without the help of an original can be problematic, although the patent, of course, outlines numerous detector structors which can be used to this end. We developed several tools for cepstral analysis to assist us in the process. See [2] for in introduction to cepstral analysis; Anderson and Petitcolas [1] illustrate its use in attacks on echo hiding watermark systems.
With a rapidly changing delay, normal cepstral analysis does not seem a good choice. However, if we know that the same echo is likely to occur at multiples of 16/50 of a second, we can improve detector capability by combining the information of multiple liftered2 log spectra.
____________________
Three detector structures are shown in figure 4. In all three, a collection of frames are selected for which the echo delays are believed to be the same. For each, the liftered log of an FFT or PSD of the frame is taken. In the first two structures, we compute a cepstrum, for each frame, then either average their squared magnitudes, or simply their squares, in hopes that a spike of the appropriate quefrency will be clear in the combination. The motivation for merely squaring the spectral coefficients comes from the observation that a spike due to an echo will either possess a phase of theta or theta + pi for some value theta. Squaring without taking magnitudes can cause the echo phases to reinforce, whilst still permitting other elements to combine destructively. Fig. 4. Three cepstral detector structures. In each case we have a collection of distinct frames, each believed to possess echoes of the same delay. The first two compute cepstral data for each frame, and sum their squares (or squared magnitudes) to constructively combine the echo signal in all frames. The third structure illustrates a method for testing a hypothesized pattern of positive and negative gains, possibly useful for brute-forcing or testing for the presence of a known "ciphertext."
In the final structure, one cepstrum. is taken using a guess of the gain sign for each suspect frame. With the correct guess, the ripple should be strongest, resulting in the largest spike from the cepstral detector. Figure 5 shows the output of this detector on several sets of suspect frames. While this requires an exponential amount of work for a given amount of frames, it has a different intended purpose: this is a brute-forcing tool, a utility for determining the most probable among a set of suspected short strings of gain signs as an aid to extracting possible ciphertext values. Fig. 5. Detection of an echo. A screenshot of our CepstroMatic utility shows a combination of 4 separate frames of music, each a fiftieth of a second long, in which the same echo delay was believed to exist. Their combination shows a very clear ripple on the right, corresponding to a clear cepstral spike on the left. This is a single echo at a delay of 33 samples, the delay suggested for these intervalus by the hypothesized delay-hopping pattern.
Finally, there is the issue of what this embedded watermark means. Again, we are uncertain about a possible signalling band below 8Khz. This could be a robust mark, signalling presence of a fragile mark of echoes between 8 and 16 KHz. The 8-16KHz band does seem like an unusual place to hide robust data, unless it does indeed extend further down, and so this could very easily be hidden information whose degredation is used to determine if music has already been compressed.
Of course, knowledge of either the robust or fragile component of the mark is enough for an attacker to circumvent the scheme, because one can either remove the robust mark, or repair or reinstate the fragile mark after compression has damaged it. As mentioned earlier, this possible attack of repairing the fragile component appears to have been ruled out by the nature of the SDMI challenge oracles. One must wait and see if real-world attackers will attempt such an approach, or resort to more brute methods or oracle attacks to remove the robust component.
3.2 Attack on Challenge B
We analyzed samp1b.wav and samp2b.wav using short-time FFT. Shown in Fig. 6 are the two FFT magnitudes for 1000 samples at 98.67 sec. Also shown is the difference of the two magnitudes. A spectrum notch around 2800Hz is observed for some segments of samp2b.wav and another notch around 3500Hz is observed for some other segments of samp2b.wav. Similar notches are observed in samp3b.wav. The attack fills in those notches of samp3b.wav with random but bounded coefficient values. We also submitted a variation of this attack involving different parameters for notch description. Both attacks were confirmed by SDMI oracle as successful. Fig. 6. Technology-B: FFT magnitudes of samp1b.wav and samp2b.wav and their difference for 1000 samples at 98.67 sec.
3.3 Attacks on Challenge C
By taking the difference of samp1c.wav and samp2c.wav, bursts of narrowband signal are observed, as shown in Fig. 7. These narrow band bursts appear to be centered around 1350 Hz. Two different attacks were applied to Challenge C. In the first at- tack, we shifted the pitch of the audio by about a quartertone. In the second attack, we passed the signal through a bandstop filter centered around 1350Hz. Our submissions were confirmed by SDMI oracle as successful. In addition, the perceptual quality of both attacks has passed the "golden ear" testing conducted by SDMI after the 3-week challenge. Fig. 7. Challenge-C: Waveform of the difference between samp1c.wav and samp2c.wav.
3.4 Attack on Challenge F
For Challenge F, we warped the time axis, by inserting a periodically varying delay. The delay function comes from our study on Technology-A, and was in fact initially intended to undo the phase distortion applied by technology A. Therefore the perceptual quality of our attacked audio is expected to be better than or comparable to that of the audio watermarked by Technology-A. We also submitted variations of this at- tack involving different warping parameters and different delay function. They were confirmed by SDMI oracle as successful.
4 The Non-Watermark Technologies
The HackSDMI challenge contained two "non-watermark" technologies. Together, they appear to be intended to prevent the creation of "mix" CDs, where a consumer might compile audio files from various locations to a writable CD. This would be enforced by universally embedding SMDI logic into consumer audio CD players.
4.1 Technology D
According to SDMI, Technology D was designed to require "the presence of a CD in order to 'rip' or extract a song for SDMI purposes." The technology aimed to accomplish this by adding a 53.3 ms audio track (four blocks of CD audio), which we will refer to as the authenticator, to each CD. The authenticator, combined with the CD's table of contents (TOC), would allow a SDMI device to recognize SDMI compliant CDs. For the challenge, SDMI provided 100 different "correct" TOC-authenticator pairs as well as 20 "rogue tracks". A rogue track is a track length that does not match any of the track lengths in the 100 provided TOCs. The goal of the challenge was to submit to the SDMI oracle a correct authenticator for a TOC that contained at least one of the rogue tracks.
The oracle for Technology D allowed several different query types. In the first type, an SDMI provided TOC-authenticator combination is submitted so a that user can "understand and verify the Oracle." According to SDMI, the result of this query should either be "admit" for a correct pair or "reject" for an incorrect pair. When we attempted this test a SDMI-provided pair, the oracle responded that the submission was "invalid." After verifying that we had indeed submitted a correct pair, we attempted several other submissions using different TOC-authenticator pairs as well as different browsers and operating systems3. We also submitted some pairs that the oracle should have rejected; these submissions were also declared "invalid." Though we alerted SDMI to this problem during the challenge, the oracle was never repaired. For this reason, our analysis of Technology D is incomplete and we lack definitive proof that it is correct. That having been said, we think that what we learned about this technology, even without the benefit of a correctly functioning oracle, is interesting.
____________________
Analyzing the Signal Upon examination of the authenticator audio files, we discovered several patterns. First, the left and right channels contain the same information. The two channels differ by a "noise vector" u, which is a vector of small integer values that range from -8 and 8. Since the magnitude of the noise is so small, the noise vector does not significantly affect the frequency characteristics of the signal. The noise values appear to be random, but the noise vector is the same for each of the 100 provided authenticator files. In other other words, in any authenticator file, the difference between the left and right channels of the ith sample is a constant fixed value u[i]. This implies that the noise vector u does not encode any TOC-specific information.
Second, the signal repeats with a period of 1024 samples. Because the full signal is 2352 samples long, the block repeats approximately 1.3 times. Similarly to the left and right channels of the signal, the first two iterations of the repeating signal differ by a constant noise vector v. The difference between the ith sample of the first iteration and the ith sample of the second iteration differ by a small (and apparently random) integer value v[i] ranging from -15 to 15. In addition, v is the same for each of the provided authenticator files, so v does not encode any TOC-specific information.
Third, the first 100 samples and last 100 samples of the full signal are faded in and faded out, respectively. This is illustrated in Figure 8. The fade-in and fade-out are meaningless, however, because they simply destroy data that is repeated in the middle of the file. We conjecture that this fade-in and fade-out are included so that the audio signal does not sound offensive to a human ear. Fig. 8. In a Technology D Authenticator, the signal fades in, repeats, and fades out.
Extracting the Data Frequency analysis on the 1024 sample block shows that almost all of the signal energy is concentrated in the 16-20kHz range, as shown in Figure 9. We believe this range was chosen because these frequencies are less audible to the human ear. Closer examination shows that this l6-20kHz range is divided up into 80 discrete bins, each of which appears to carry one bit of information. As shown in Figure 10, these bits can be manually counted by a human using a graph of the magnitude of signal in the frequency domain. Fig. 9. Magnitude vs. Frequency of Technology D Authenticator
Fig. 10. Individual Bits From a Technology D Authenticator
Close inspection and pattern matching on these 80 bits of information reveals that there are only 16 bits of information repeated 5 times using different permutations. using the letters A-P to symbolize the 16 bits, these 5 permutations are described in Figure 11. ABCDEFGHIJKLMNOP
OMILANHGPBDCKJFE
PKINHODFMJBCAGLE
FCKLGMEPNOADJBHI
PMGHLECAKDONIFJB Fig. 11. The encoding of the 16 bits of data in Technology D
Because of the malfunctioning oracle, we were unable to determine the function used to map TOCs to authenticators, but given an actual SDMI device, it would be trivial to brute force all 216 possibilities. Likewise, without the oracle, we could not determine if there was any other signal present in the authenticator (e.g., in the phase of the frequency components with nonzero magnitude).
For the moment, let us assume that the hash function used in Technology D has only 16 bits of output. Given the number of distinct CDs available, an attacker should be able to acquire almost, if not all, of the authenticators. We note that at 9 kilobytes each, a collection of 65,536 files would fit nicely on a single CD. Many people have CD collections of 300+ discs, which by the birthday paradox makes it more likely than not that there is a hash collision among their own collection.
Our results indicated that the hash function used in Technology D could be weak or may have less than 16 bits of output. In the 100 authenticator samples provided in the Technology D challenge, there were 2 pairs of 16-bit hash collisions. We will not step through the derivation here, but the probability of two or more collisions occurring in n samples of X equally likely possibilities is:
If the 16-bit hash function output has 16 bits of entropy, the probability of 2 collisions occurring in n = 100 samples of X = 216 possibilities is 0.00254 (by the above 1.5 equation). If X ~ 211.5, the chances of two collisions occurring is about even. This suggests that either 4 bits of the 16-bit hash output may be outputs of functions of the other 12 bits or the hash function used to generate the 16-bit signature is weak. It is also possible that the challenge designers purposefully selected TOCs that yield collisions. The designers could gauge the progress of the contestants by observing whether anyone submits authenticator A with TOC B to the oracle, where authenticator A is equal to authenticator B. Besides the relatively large number of collisions in the provided authenticators, it appears that there are no strong biases in the authenticator bits such as significantly more or less 1's than 0's.
4.2 Technology E
Technology E is designed to fix a specific bug in Technology D: the TOC only mentions the length of each song but says nothing about the contents of that song. As such, an attacker wishing to produce a mix CD would only need to find a TOC approximately the same as the desired mix CD, then copy the TOC and authenticator from that CD onto the mix CD. If the TOC does not perfectly match the CD, the track skipping functionality will still work but will only get "close" to track boundaries rather than reaching them precisely. Likewise, if a TOC specified a track length longer than the track we wished to put there, we could pad the track with digital silence (or properly SDMI-watermarked silence, copied from another valid track). Regardless, a mix CD played from start to end would work perfectly. Technology E is designed to counter this attack, using the audio data itself as part of the authentication process.
The Technology E challenge presented insufficient information to be properly studied. Rather than giving us the original audio tracks (from which we might study the unspecified watermarking scheme), we were instead given the tables of contents for 1000 CDs and a simple scripting language to specify a concatenation of music clips from any of these CDs. 'Me oracle would process one of these scripts and then state whether the resulting CD would be rejected.
While we could have mounted a detailed statistical analysis, submitting hundreds or thousands of queries to the oracle, we believe the challenge was fundamentally flawed. In practice, given a functioning SDMI device and actual SDMI-protected content, we could study the audio tracks in detail and determine the structure of the watermarking scheme.
5 Conclusion
In this paper, we have presented an analysis of the technology challenges issued by the Secure Digital Music Initiative. Each technology challenge described a specific goal (e.g., remove a watermark from an audio track) and offered a Web-based oracle that would confirm whether the challenge was successfully defeated.
We have reverse-engineered and defeated all four of their audio watermarking technologies. We have studied and analyzed both of their "non-watermarking" technologies to the best of our abilities given the lack of information available to us and given a broken oracle in one case.
Some debate remains on whether our attacks damaged the audio beyond standards measured by "golden ear" human listeners. Given a sufficient body of SDMI-protected content using the watermark schemes presented here, we are confident we could refine our attacks to introduce distortion no worse than the watermarks themselves introduce to the the audio. Likewise, debate remains on whether we have truly defeated technologies D and E. Given a functioning implementation of these technologies, we are confident we can defeat them.
Do we believe we can defeat any audio protection scheme? Certainly, the technical details of any scheme will become known publicly through reverse engineering. Using the techniques we have presented here, we believe no public watermark-based scheme intended to thwart copying will succeed. Other techniques may or may not be strong against attacks. For example, the encryption used to protect consumer DVDs was easily defeated. Ultimately, if it is possible for a consumer to hear or see protected content, then it will be technically possible for the consumer to copy that content.
References
1. R. J. ANDERSON, AND F. A. P. PETITCOLAs. On the limits of steganography. IEEE Journal of Selected Areas in Communications 16,4 (May 1998),474-481.
2. R. P. BOGERT, M., AND J. W. TUKEY. The quefrency alanysis of time series for echoes: Cepstrum, pseudo-autocovariance, cross-ceptsrum and saphe-cracking. In Proceedings of the Symposium on Time Series Analysis (Brown University, June 1962), pp. 209-243.
3. R. PETROVIC, J. M. WINOGRAD, K., AND E. METOIS. Apparatus and method for encoding and decoding information in analog signals, Aug. 1999. US Patent No 05940135 http://www.delphion.com/details?pn=US05940135__.
4. SECURE DIGITAL MUSIC INITIATIVE. Call for Proposals for Phase II Screening Technology, Version 1.0, Feb. 2000. http://www.sdmi.org/download/FRWG00022401-Ph2_CFPv 1.0.PDF.
5. SECURE DIGITAL MUSIC INITIATIVE. SDMI public challenge, Sept. 2000. http://www.hacksdmi.org.
>Am I afraid of people with homosexual behaviors?
>Hardly. Am I "afraid" of what homosexualbehavior does to people?
This sounds like homophobia to me.
Homosexual behaviour doesn't "do" anything to people. I happen to be gay and I view it as just another attribute, like having green eyes or black hair.
There are lots of straight AND gay people that do lots of different things not because they are gay or straight but because that's the kind of person they are. Their sexual orientation has nothing to do with that behaviour.
You mean like OpenNap and all the other servers out there that use the napster protocol? Napster was REed yonks ago, and the servers have been around a while to. for a list, check out Napigator
Links is another text browser that does frames and stuff :)
Search freshmeat for it "Links"
>What is going to happen if somebody creates a >mirror of these sites in a server operating >outside the jurorsdiction of a USA court
You mean like this?
I agree with the principle of "punish the crime, not the tool," but it's not that simple here. DVD-CCA developed CSS and licenses it, just like Microsoft developed Windows and licenses it to people. If you reverse engineer their tool and distribute the source code, you're violating their intellectual property
So you're basically saying thatr WINE is violating
Microsoft's "IP"?
Im sorry, it's people like you that seem to think that you can crush the human spirit along with the very idea of curosity. Even if you dont mean it.
The DVDCCA licenses CSS out to people, because it's a (or was) a trade secret. It's no longer secret, so now people can do whatever the hell they want to/with CSS without a license.
No one broke any NDA's or anything like that, so the cat is out of the bag, and you can't stuff it back in.
It's like saying I can't develop my own kind of tyre because I figured out how to put tyres on cars.
My mirror of DeCSS stuff Contains lots of various decss related stuff along with livid/decss + source/mirrors etcetc
I happen to live in NZ, so none of this court crap affects me
Well, all comments are owned by the poster right?
/*
/*
, 0x36,0x2b,0x6e,0x2e,0x66,0x7b,
, 0xd6,0x0b,0x4e,0x0e,0x46,0x9b,
, 0x52,0x8f,0xca,0x8a,0xc2,0x1f,
, 0xd0,0x01,0x48,0x08,0x40,0x91,
, 0x34,0x25,0x6c,0x2c,0x64,0x75,
, 0xd4,0x05,0x4c,0x0c,0x44,0x95,
, 0x50,0x81,0xc8,0x88,0xc0,0x11,
, 0xd2,0x0f,0x4a,0x0a,0x42,0x9f,
, 0x56,0x8b,0xce,0x8e,0xc6,0x1b,
, 0xb6,0xab,0xee,0xae,0xe6,0xfb,
, 0x0b,0x0a,0x0d,0x0c,0x0f,0x0e,
, 0x19,0x18,0x1f,0x1e,0x1d,0x1c,
, 0x2f,0x2e,0x29,0x28,0x2b,0x2a,
, 0x3d,0x3c,0x3b,0x3a,0x39,0x38,
, 0x42,0x43,0x44,0x45,0x46,0x47,
, 0x50,0x51,0x56,0x57,0x54,0x55,
, 0x66,0x67,0x60,0x61,0x62,0x63,
, 0x74,0x75,0x72,0x73,0x70,0x71,
, 0x99,0x98,0x9f,0x9e,0x9d,0x9c,
, 0x8b,0x8a,0x8d,0x8c,0x8f,0x8e,
, 0xbd,0xbc,0xbb,0xba,0xb9,0xb8,
, 0xaf,0xae,0xa9,0xa8,0xab,0xaa,
, 0xd0,0xd1,0xd6,0xd7,0xd4,0xd5,
, 0xc2,0xc3,0xc4,0xc5,0xc6,0xc7,
, 0xf4,0xf5,0xf2,0xf3,0xf0,0xf1,
, 0xe6,0xe7,0xe0,0xe1,0xe2,0xe3
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
2 4,0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff
/* Reverse the order of the bits within a byte.
, 0x50,0xd0,0x30,0xb0,0x70,0xf0,
, 0x58,0xd8,0x38,0xb8,0x78,0xf8,
9 4,0x54,0xd4,0x34,0xb4,0x74,0xf4,
, 0x5c,0xdc,0x3c,0xbc,0x7c,0xfc,
, 0x52,0xd2,0x32,0xb2,0x72,0xf2,
, 0x5a,0xda,0x3a,0xba,0x7a,0xfa,
, 0x56,0xd6,0x36,0xb6,0x76,0xf6,
, 0x5e,0xde,0x3e,0xbe,0x7e,0xfe,
, 0x51,0xd1,0x31,0xb1,0x71,0xf1,
, 0x59,0xd9,0x39,0xb9,0x79,0xf9,
, 0x55,0xd5,0x35,0xb5,0x75,0xf5,
, 0x5d,0xdd,0x3d,0xbd,0x7d,0xfd,
, 0x53,0xd3,0x33,0xb3,0x73,0xf3,
, 0x5b,0xdb,0x3b,0xbb,0x7b,0xfb,
, 0x57,0xd7,0x37,0xb7,0x77,0xf7,
, 0x5f,0xdf,0x3f,0xbf,0x7f,0xff
/*
1 9);*/
;
/*
/*
1 9);*/
;
So the MPAA can come after me, in good old NZ.
I present to you css_descramble.c
(The same file printed on the back of my now illeagl t-shirt) I'll make a note not to ever visit the good ole US of A
/*
* css_descramble.c
*
* Released under the version 2 of the GPL.
*
* Copyright 1999 Derek Fawcus
*
* This file contains functions to descramble CSS encrypted DVD content
*
*/
* Still in progress: Remove the use of the bit_reverse[] table by recoding
* the generation of LFSR1. Finish combining this with
* the css authentication code.
*
*/
#include
#include
#include "css-descramble.h"
typedef unsigned char byte;
*
* some tables used for descrambling sectors and/or decrypting title keys
*
*/
static byte csstab1[256]=
{
0x33,0x73,0x3b,0x26,0x63,0x23,0x6b,0x76,0x3e,0x7e
0xd3,0x93,0xdb,0x06,0x43,0x03,0x4b,0x96,0xde,0x9e
0x57,0x17,0x5f,0x82,0xc7,0x87,0xcf,0x12,0x5a,0x1a
0xd9,0x99,0xd1,0x00,0x49,0x09,0x41,0x90,0xd8,0x98
0x3d,0x7d,0x35,0x24,0x6d,0x2d,0x65,0x74,0x3c,0x7c
0xdd,0x9d,0xd5,0x04,0x4d,0x0d,0x45,0x94,0xdc,0x9c
0x59,0x19,0x51,0x80,0xc9,0x89,0xc1,0x10,0x58,0x18
0xd7,0x97,0xdf,0x02,0x47,0x07,0x4f,0x92,0xda,0x9a
0x53,0x13,0x5b,0x86,0xc3,0x83,0xcb,0x16,0x5e,0x1e
0xb3,0xf3,0xbb,0xa6,0xe3,0xa3,0xeb,0xf6,0xbe,0xfe
static byte lfsr1_bits0[256]=
{
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x09,0x08
0x12,0x13,0x10,0x11,0x16,0x17,0x14,0x15,0x1b,0x1a
0x24,0x25,0x26,0x27,0x20,0x21,0x22,0x23,0x2d,0x2c
0x36,0x37,0x34,0x35,0x32,0x33,0x30,0x31,0x3f,0x3e
0x49,0x48,0x4b,0x4a,0x4d,0x4c,0x4f,0x4e,0x40,0x41
0x5b,0x5a,0x59,0x58,0x5f,0x5e,0x5d,0x5c,0x52,0x53
0x6d,0x6c,0x6f,0x6e,0x69,0x68,0x6b,0x6a,0x64,0x65
0x7f,0x7e,0x7d,0x7c,0x7b,0x7a,0x79,0x78,0x76,0x77
0x92,0x93,0x90,0x91,0x96,0x97,0x94,0x95,0x9b,0x9a
0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x89,0x88
0xb6,0xb7,0xb4,0xb5,0xb2,0xb3,0xb0,0xb1,0xbf,0xbe
0xa4,0xa5,0xa6,0xa7,0xa0,0xa1,0xa2,0xa3,0xad,0xac
0xdb,0xda,0xd9,0xd8,0xdf,0xde,0xdd,0xdc,0xd2,0xd3
0xc9,0xc8,0xcb,0xca,0xcd,0xcc,0xcf,0xce,0xc0,0xc1
0xff,0xfe,0xfd,0xfc,0xfb,0xfa,0xf9,0xf8,0xf6,0xf7
0xed,0xec,0xef,0xee,0xe9,0xe8,0xeb,0xea,0xe4,0xe5
};
static byte lfsr1_bits1[512]=
{
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
};
*/
static byte bit_reverse[256]=
{
0x00,0x80,0x40,0xc0,0x20,0xa0,0x60,0xe0,0x10,0x90
0x08,0x88,0x48,0xc8,0x28,0xa8,0x68,0xe8,0x18,0x98
0x04,0x84,0x44,0xc4,0x24,0xa4,0x64,0xe4,0x14,0x
0x0c,0x8c,0x4c,0xcc,0x2c,0xac,0x6c,0xec,0x1c,0x9c
0x02,0x82,0x42,0xc2,0x22,0xa2,0x62,0xe2,0x12,0x92
0x0a,0x8a,0x4a,0xca,0x2a,0xaa,0x6a,0xea,0x1a,0x9a
0x06,0x86,0x46,0xc6,0x26,0xa6,0x66,0xe6,0x16,0x96
0x0e,0x8e,0x4e,0xce,0x2e,0xae,0x6e,0xee,0x1e,0x9e
0x01,0x81,0x41,0xc1,0x21,0xa1,0x61,0xe1,0x11,0x91
0x09,0x89,0x49,0xc9,0x29,0xa9,0x69,0xe9,0x19,0x99
0x05,0x85,0x45,0xc5,0x25,0xa5,0x65,0xe5,0x15,0x95
0x0d,0x8d,0x4d,0xcd,0x2d,0xad,0x6d,0xed,0x1d,0x9d
0x03,0x83,0x43,0xc3,0x23,0xa3,0x63,0xe3,0x13,0x93
0x0b,0x8b,0x4b,0xcb,0x2b,0xab,0x6b,0xeb,0x1b,0x9b
0x07,0x87,0x47,0xc7,0x27,0xa7,0x67,0xe7,0x17,0x97
0x0f,0x8f,0x4f,0xcf,0x2f,0xaf,0x6f,0xef,0x1f,0x9f
};
*
* this function is only used internally when decrypting title key
*
*/
static void css_titlekey(byte *key, byte *im, byte invert)
{
unsigned int lfsr1_lo,lfsr1_hi,lfsr0,combined;
byte o_lfsr0, o_lfsr1;
byte k[5];
int i;
lfsr1_lo = im[0] | 0x100;
lfsr1_hi = im[1];
lfsr0 = ((im[4] >8)&0xff] >16)&0xff]>24)&0xff];
combined = 0;
for (i = 0; i >1;
lfsr1_lo = ((lfsr1_lo&1)>7)^(lfsr0>>10)^(lfsr0>>11)^(lfsr0>>
o_lfsr0 = (((((((lfsr0>>8)^lfsr0)>>1)^lfsr0)>>3)^lfsr0)>>7)
lfsr0 = (lfsr0>>8)|(o_lfsr0>= 8;
}
key[4]=k[4]^csstab1[key[4]]^key[3];
key[3]=k[3]^csstab1[key[3]]^key[2];
key[2]=k[2]^csstab1[key[2]]^key[1];
key[1]=k[1]^csstab1[key[1]]^key[0];
key[0]=k[0]^csstab1[key[0]]^key[4];
key[4]=k[4]^csstab1[key[4]]^key[3];
key[3]=k[3]^csstab1[key[3]]^key[2];
key[2]=k[2]^csstab1[key[2]]^key[1];
key[1]=k[1]^csstab1[key[1]]^key[0];
key[0]=k[0]^csstab1[key[0]];
}
*
* this function decrypts a title key with the specified disk key
*
* tkey: the unobfuscated title key (XORed with BusKey)
* dkey: the unobfuscated disk key (XORed with BusKey)
* 2048 bytes in length (though only 5 bytes are needed, see below)
* pkey: array of pointers to player keys and disk key offsets
*
*
* use the result returned in tkey with css_descramble
*
*/
int css_decrypttitlekey(byte *tkey, byte *dkey, struct playkey **pkey)
{
byte test[5], pretkey[5];
int i = 0;
for (; *pkey; ++pkey, ++i) {
memcpy(pretkey, dkey + (*pkey)->offset, 5);
css_titlekey(pretkey, (*pkey)->key, 0);
memcpy(test, dkey, 5);
css_titlekey(test, pretkey, 0);
if (memcmp(test, pretkey, 5) == 0) {
fprintf(stderr, "Using Key %d\n", i+1);
break;
}
}
if (!*pkey) {
fprintf(stderr, "Shit - Need Key %d\n", i+1);
return 0;
}
css_titlekey(tkey, pretkey, 0xff);
return 1;
}
*
* this function does the actual descrambling
*
* sec: encrypted sector (2048 bytes)
* key: decrypted title key obtained from css_decrypttitlekey
*
*/
void css_descramble(byte *sec,byte *key)
{
unsigned int lfsr1_lo,lfsr1_hi,lfsr0,combined;
unsigned char o_lfsr0, o_lfsr1;
unsigned char *end = sec + 0x800;
#define SALTED(i) (key[i] ^ sec[0x54 + (i)])
lfsr1_lo = SALTED(0) | 0x100;
lfsr1_hi = SALTED(1);
lfsr0 = ((SALTED(4) >8)&0xff] >16)&0xff]>24)&0xff];
sec+=0x80;
combined = 0;
while (sec != end) {
o_lfsr1 = lfsr1_bits0[lfsr1_hi] ^ lfsr1_bits1[lfsr1_lo];
lfsr1_hi = lfsr1_lo>>1;
lfsr1_lo = ((lfsr1_lo&1)>7)^(lfsr0>>10)^(lfsr0>>11)^(lfsr0>>
o_lfsr0 = (((((((lfsr0>>8)^lfsr0)>>1)^lfsr0)>>3)^lfsr0)>>7)
lfsr0 = (lfsr0>>8)|(o_lfsr0>= 8;
}
}
Errr, there is auctally.
LiViD is one such open source DVD player.
css-auth (which authenticates with the drive) was auctally written by someone on the LiViD team and was used in DeCSS (which is GPLed thus).
It does work, a few months ago I saw the Matrix played off DVD under Linux. So yes, it does work, and there is player (Which, I am in no doubt that if the MPAA wins will be delcared illegal, at least in the US.) Fortunatly, it is GPLed. They can't stop Open Source software, because it will simply be "smuggled" over borders, and the developers will still develop it.
All it will mean is that you will have to get it from foriegn soil.
Also, the MPAA tried to get the injunction modified so that anything that was "unauthorised" (such as LiViD) was also made illegal. I dont think has been granted, because they also wanted the injunction to including linking to the DeCSS bin/source. WHich is funny, because they'd have to shut down their own search engines ;) (Try "DeCSS" in Disney's/Go's search engine. Fun)
Qoute: 1. For an Order, pursuant to Rule 65 of the Federal Rules of Civil Procedure, modifying this Court's preliminary injunction Order, dated January 20, 2000, by adding the following to the indicated paragraphs of said order:
a) add to paragraph 2 the name of additional defendant 2600 Enterprises, Inc., and delete the names of defendants Shawn C. Reimerdes and Roman Kazan,
b) add to paragraphs 2(a) and 2(b), after the words "posting on," the language "or linking to," and insert commas after the words "trafficking in,"
c) revise paragraph 3(b) to read "'CSS' means the Contents Scramble System used to encrypt, scramble or otherwise protect the contents of certain DVDs from unauthorized access or copying,"
d) revise paragraph 3(c) to read " 'DeCSS' means any computer program, file or device that may be used to decrypt or unscramble the contents of DVDs that are protected, or otherwise to circumvent the protection afforded, by CSS and that permits the unauthorized access or copying of the contents or any portion thereof,"
e) add (d) to paragraph 3 as follows: "a 'hyperlink' means software instructions which, when executed, cause a signal to be sent to another location where data or material can be retrieved for viewing, copying or further transmission,"
f) add (e) to paragraph 3 as follows: " 'linking' means provision by the defendants, at their respective websites, of hyperlinks to other websites which are offering to the public, providing, providing hyperlinks to, or otherwise trafficking in DeCSS or any technology, product, service, device, component, or part thereof described in paragraph 2(b),"
Auctally they did have dreams of a DVD player for Linux.
The reason it was written as a windows executable was because linux didn't have UDF support at the time.
If you want proof, read the court transcripts (and depositions) from the MPAAv2600.. Jon Johanson has testified himself.
http://www.eff.org/IP/Video/MPAA_DVD_ca ses/
I just thought of something, inspired by the devil incarinate himself. Since this seems to be the future of propietory software, I figure, why not instead of having to SELL my soul to the devil, I can (while retaining full copyright, trademark rights and everything other prexisting right over it) sell him a LICENSE for the use of my soul. Now, I leave the exact details of this license to the reader, but im sure you can all come up with some nifty EULA's (or DSULA (Devil Soul Usage License Agreements). Email me some ;)
Excuse me, but how do you run an OS ontop of another OS? /. linked to had known what he was talking about, or even elaborated on just HOW they were going to run the next Workbench ontop of Red hat. (and why not just say Linux?)
Not counting things like VMWare, Plex86 and others, running an OS straight ontop of an other is impossible.
Unless they mean compiling things and such?
And no, using a "launcher" doesn't count either (Like the BeOS PE).
It would have been nice if the author of the article that
> 2. If you boot BeOS from an ext2 partition, BeOS will be
/beos/ on my ext2fs partition.
> unable to use virtual memory. BeOS' VM works on FAT, not on
> ext2
*blinks*
I assume you mean if you keep the BeOS image on an ext2fs partition?
I don't think this is right, because both top and ProcessControler under BeOS show apps using virtual memory..
Mem: 48.0/48 Mb (100.0%) Change: -5.2 kb/s Swap In: 5.2 kb/s, 90.7 Mb
Im booting using the bootdisk, with the image in
Auctally, it says
"Unfortunately, BeOS 5 Personal Edition, because of technical
reasons, can only recognize one processor."
Those technical reasons are the fact that your average joe will be using Windows 9x, and just running the bootstrap inside windows.
Windows 9x does not support SMP, it disables any other CPU's.
So in order to get SMP, you have to use the bootdisk.
I beleive www.benews.com has something about it..
ahhh, here..
http://www.benews.com/story/2931.2.html
Ok, I keep seeing people post stuff that isn't true about the BeOS "Personal edition" so here are the _facts_ /beos, use the boot disk and you're off.
BeOS 5 PE is NOT a trial version, crippled or an "evaluation".
It is the entire OS, all of it.. just the same BeOS "Pro Version"
It IS BeOS..
Another thing.
The title of the article is wrong.. The linux "version" just includes a readme, be partition image and a bootdisk image.
Copy the image to
Im guessing it's just for users of OS's other then windows, since they wouldn't be able to run the installer exe that the windows "version" needs.
Also, BeOS "PE" does support SMP, and various other things.
You just have to use the bootdisk, instead of using the windows loader.
(Windows 9x disables all the other CPU's)
Also, you are NOT limited to just the BFS image partition.
Once you have it running, you can use Installer to copy/install BeOS (your current setyp) to any other partition.
So, make some free space, run BeOS from the image and install it there.
Summary: BeOS 5 PE is the entire OS, it has no limitations.
The only thing different between PE and the Pro version is what Be has told you. Realplayer, mp3 encoders (which you can download anyway) etcetc.
Do not let anyone fool you, including Be.
Hmm, this isn't very useful, but amusing for the first few minutes.a l.com/
You can change the characters in that semingly random bunch of chars that they use, such as
http://X199DAASOFTWARE84PATENTS71CBLOW3E.sevenv
*grins*
As long as it remains the same length, you can replace mostly of the garbage with words..
Enjoy.