 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Darren New schrieb:
>> Orchid XP v8 wrote:
>>> The article suggests that the system *is* supposed to be able to
>>> narrow it down to a specific machine or possibly a small number of
>>> such machines, not just a specific model.
>>
>> No, that's what I'm saying. "Player" in *this* context means a set of
>> keys (obviously).
>
> What's obvious about that?
Because I've read more than just one article on the subject? The point is
to track down the key used to decrypt the content so the key can be added to
the blacklists on future players.
> Hardware players are likely to have a Flash ROM or EEPROM anyway, so
> it's no technical problem to equip each individual player with a unique
> key.
The hardware players are required to have FLASH in them, because they need
to update to new versions of blacklists. They're not (last I read) required
to actually have a separate key per player.
> And as for motivating manufacturers to do that, it might be a
> requirement of the license agreement they had to sign to implement
> BlueRay technology in the first place.
It might. But it isn't.
> Software players, OTOH, typically seem to share a common Device Key for
> all installations of a particular player version.
Typically they often do, but contractually they may be forced to provide a
separate key for each player if the blu-ray licensing folks feel it's
appropriate given the structure of the decoder in the software.
Read up more on how it all works. It's really quite impressively complex.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
>>> No, that's what I'm saying. "Player" in *this* context means a set
>>> of keys (obviously).
>>
>> What's obvious about that?
>
> Because I've read more than just one article on the subject?
Does that make it /obvious/ in this context? It may make it obvious to
/you/, but that's a different story.
> The point
> is to track down the key used to decrypt the content so the key can be
> added to the blacklists on future players.
No. The point is to track down the key (as you say) to add it to the
blacklist on future /discs/.
>> Hardware players are likely to have a Flash ROM or EEPROM anyway, so
>> it's no technical problem to equip each individual player with a
>> unique key.
>
> The hardware players are required to have FLASH in them, because they
> need to update to new versions of blacklists. They're not (last I read)
> required to actually have a separate key per player.
What on earth should the players blacklist?
Unless the security stuff also contains an /additional/ mechanism to
somehow identify pirated copies of movies. But that's not what the
article is talking about.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
>> The article suggests that the system *is* supposed to be able to
>> narrow it down to a specific machine or possibly a small number of
>> such machines, not just a specific model.
>
> No, that's what I'm saying. "Player" in *this* context means a set of
> keys (obviously). Software players can each get a set of keys from the
> manufacturer when you install the machine. But people don't, in general,
> program a unique key into each hardware player.
Not that Wikipedia would be free from error, but they explicitly state
that having a different key for each /individual/ player is the major
difference in key management between CSS (as used on DVD, having one key
per player model) and AACS (having one key per individual player) - the
idea apparently being that keys /can/ be revoked without hurting many
honest consumers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What I suppose they might do is have maybe a 1-frame difference in how
> long a given scene is. Like, on some disks the shot of the ocean is 1362
> frames long, and on others it lasts for 1366 frames. The difference should
> be reliably detectable no matter how you film it.
I think there are lots of possibilities for things they could do. When a
disc is released that actually uses this feature, I'm sure lots of people
will be jumping up and down trying to find the differences.
> Still, it seems like a hell of a lot of work considering that it doesn't
> actually stop illegal copying, it just makes it hypothetically possible to
> find out who did the illegal copying...
You know what they're like, they like to try and scare everyone with their
copy protection schemes, plus they need somone to sue for $76578236597826457
when they find a copy on bitTorrent.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> LOL, I suspect they can do it slightly more subtly than that! They only
>> need to make some tiny changes to some of the pixels to be detectable.
>> In theory they could do what you suggest though, would be fun :-)
>
> Probably a form of steganography, at a guess.
Well, if they're hiding player ID information in the video, then that
would, by definition, be "steganography". That's what steganography
*is*, after all...
The question is which steganographic technique they'll use. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Now I'm thinking... it appears to be a standard Data Matrix barcode, so
>> if I could figure out WTF the data encoded in it is, I could print as
>> many of them as I like, without a fee...
>
> Until you got caught, that is, and fined/put in jail for fraud.... ;-)
Would they actually bother for 21p?
Now, if I wrote an automated program to print these stamps and posted it
on the Internet... *then* they might have a case. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> The impressive thing is, as far as I can tell, almost all barcode
> scanners support almost all kinds of barcodes. Even though each coding
> scheme is utterly unrelated to any of the others. God only knows how
> this is physically possible...
It's actually very simple. As long as the scanner is close enough, and
is at the proper angle, all stripes of a given width will appear the
same to the scanner. Each bar coding system uses a series of different
widths to represent each character. Some systems use only narrow and
wide stripes (double width), while others will have stripes that are
three and four times the size of the narrowest stripe. Generally each
character is comprised of a set of stripes that add up to a constant
width (or else the bar codes would appear to have different widths).
As you can see, once the series of widths is in the scanner,
interpretation becomes a software issues. If the data doesn't make
sense under one coding scheme, the scanner can always run the same set
of width data through another scheme.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/15/2009 3:17 AM, Invisible wrote:
>>> Now I'm thinking... it appears to be a standard Data Matrix barcode, so
>>> if I could figure out WTF the data encoded in it is, I could print as
>>> many of them as I like, without a fee...
>>
>> Until you got caught, that is, and fined/put in jail for fraud.... ;-)
>
> Would they actually bother for 21p?
What would likely happen is the system would detect the stamp was
already used, and kick it back to the sender with "Insufficient Postage"
emblazoned across the stamp.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What would likely happen is the system would detect the stamp was already
> used, and kick it back to the sender with "Insufficient Postage"
> emblazoned across the stamp.
I wonder if they even bother to check them against a database of already
used/issued ones? Maybe they just check the checksum?
There was a story a few years ago where a self-checkout machine in Tesco
didn't do this for some voucher, and a guy just photocopied it hundreds of
times and it worked :-) Oh here I found it:
http://www.timesonline.co.uk/tol/news/uk/crime/article1572721.ece
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott schrieb:
>> What would likely happen is the system would detect the stamp was
>> already used, and kick it back to the sender with "Insufficient
>> Postage" emblazoned across the stamp.
>
> I wonder if they even bother to check them against a database of already
> used/issued ones? Maybe they just check the checksum?
The German "Post" has a similar system, and they /do/ check it against a
database.
BTW, the German 2D "stamp" barcode even encodes the full destination
address information, which has the benefit (for the "Post") of (a)
rendering the stamp fundamentally un-reusable anyway except for mails to
the same addressee, and (b) making the address even easier machine-readable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
