<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Scope pr0n</title>
	<atom:link href="http://debugmo.de/2010/07/scope-pr0n/feed/" rel="self" type="application/rss+xml" />
	<link>http://debugmo.de/2010/07/scope-pr0n/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=scope-pr0n</link>
	<description>Projects, hardware fun and everything between it.</description>
	<lastBuildDate>Tue, 14 May 2013 03:46:08 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: WinterMute</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-9159</link>
		<dc:creator>WinterMute</dc:creator>
		<pubDate>Thu, 02 Feb 2012 11:19:36 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-9159</guid>
		<description>That&#039;s one heck of a cliffhanger, we&#039;re on tenterhooks over here. Any plans on doing the follow up to this?</description>
		<content:encoded><![CDATA[<p>That&#8217;s one heck of a cliffhanger, we&#8217;re on tenterhooks over here. Any plans on doing the follow up to this?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tmbinc</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8333</link>
		<dc:creator>tmbinc</dc:creator>
		<pubDate>Mon, 26 Jul 2010 22:28:26 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8333</guid>
		<description>Congratulations toxic, you hit it right on the head!

In fact, the picture above shows:

Green trace: HF data coming from the laser pickup.
Yellow trace: Recovered clock
Blue trace: Recovered data

The data is from a Datel disc (&quot;ultimate cheatcodes&quot;) and shows the &quot;laser mark&quot;; except that it&#039;s not written with an actual laser, but simply embedded in the datastream!

To compare it with the picture from the last post, which showed a real, genuine GC disc. There are subtle differences (like the &quot;noise&quot; in the zeroed region).

So toxic is also right with his assumption that this will be the cliffhanger for the 3rd part of the story.</description>
		<content:encoded><![CDATA[<p>Congratulations toxic, you hit it right on the head!</p>
<p>In fact, the picture above shows:</p>
<p>Green trace: HF data coming from the laser pickup.<br />
Yellow trace: Recovered clock<br />
Blue trace: Recovered data</p>
<p>The data is from a Datel disc (&#8220;ultimate cheatcodes&#8221;) and shows the &#8220;laser mark&#8221;; except that it&#8217;s not written with an actual laser, but simply embedded in the datastream!</p>
<p>To compare it with the picture from the last post, which showed a real, genuine GC disc. There are subtle differences (like the &#8220;noise&#8221; in the zeroed region).</p>
<p>So toxic is also right with his assumption that this will be the cliffhanger for the 3rd part of the story.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: toxic</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8293</link>
		<dc:creator>toxic</dc:creator>
		<pubDate>Sat, 24 Jul 2010 12:27:04 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8293</guid>
		<description>After reading again the post in question it&#039;s very likely that the traces are taken from on of the Datel discs, paving the way for the 3rd part of the story :)</description>
		<content:encoded><![CDATA[<p>After reading again the post in question it&#8217;s very likely that the traces are taken from on of the Datel discs, paving the way for the 3rd part of the story :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: backatyou</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8288</link>
		<dc:creator>backatyou</dc:creator>
		<pubDate>Thu, 22 Jul 2010 21:02:33 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8288</guid>
		<description>I&#039;d guess it&#039;s related to this post:
http://debugmo.de/2008/11/anatomy-of-an-optical-medium-authentication/

Just as toxic stated.</description>
		<content:encoded><![CDATA[<p>I&#8217;d guess it&#8217;s related to this post:<br />
<a href="http://debugmo.de/2008/11/anatomy-of-an-optical-medium-authentication/" rel="nofollow">http://debugmo.de/2008/11/anatomy-of-an-optical-medium-authentication/</a></p>
<p>Just as toxic stated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: toxic</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8276</link>
		<dc:creator>toxic</dc:creator>
		<pubDate>Tue, 20 Jul 2010 18:59:40 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8276</guid>
		<description>After a bit more thought, it is much more likely that the data is in fact analog+efm data from a GC disc, the breakthrough being that someone was able to create one in his kitchen? :) (and maybe burning the corresponding BCA using the same technique?)</description>
		<content:encoded><![CDATA[<p>After a bit more thought, it is much more likely that the data is in fact analog+efm data from a GC disc, the breakthrough being that someone was able to create one in his kitchen? :) (and maybe burning the corresponding BCA using the same technique?)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: toxic</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8265</link>
		<dc:creator>toxic</dc:creator>
		<pubDate>Sun, 18 Jul 2010 21:20:28 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8265</guid>
		<description>I&#039;ll even try the bonus points: The data is unique because that piece takes a break from RLL (as you just said), and it&#039;s a breakthrough because it&#039;s related to PS3 disc protection?</description>
		<content:encoded><![CDATA[<p>I&#8217;ll even try the bonus points: The data is unique because that piece takes a break from RLL (as you just said), and it&#8217;s a breakthrough because it&#8217;s related to PS3 disc protection?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: toxic</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8264</link>
		<dc:creator>toxic</dc:creator>
		<pubDate>Sun, 18 Jul 2010 21:13:16 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8264</guid>
		<description>I&#039;ll try: raw blueray data, analog + digitalized efm ?</description>
		<content:encoded><![CDATA[<p>I&#8217;ll try: raw blueray data, analog + digitalized efm ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tmbinc</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8255</link>
		<dc:creator>tmbinc</dc:creator>
		<pubDate>Sun, 18 Jul 2010 08:57:54 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8255</guid>
		<description>Nice guesses so far! Some of them are closer, some of them not-so-close, but certainly valid based on the available material in this post. Thanks a lot already!

First, the information-density of the green trace is equal to that of the blue trace, as Tyler pointed out. Blue is in fact, as adam pointed out, the digitized, or &quot;sliced&quot;, version of the green one. Yellow is the recovered clock. 

adam is also right when comparing the green signal to an overdriven opamp output; however, no opamp characteristics are involved here. But the waveform distortion can be described as a kind of low-pass filter. In this case, the low-pass effect is caused by the physical proportions of two elements in the system.

You will likely notice the sparseness of the blue signal compared to the clock; that indicates that a special line code has been used, in this case a code to limit the minimum and maximum number of consecutive ones or zeros; this is called an RLL-code, a run-length limited code. The upper bound is set to allow a successful clock recovery, the lower bound to limit the high-frequency components that would get lost due to the &quot;low-pass filter&quot; characteristics. Because of the used code, there is 50% redundancy on top of the payload data. Quite a lot, but that&#039;s life, and also already a 1/17th improvement over the previous generation of this technology.

The long zero sequence, however, is a violation of the RLL rule. And while the data is NRZI encoded, so the data polarity doesn&#039;t matter, the violation will always be low, and never high.</description>
		<content:encoded><![CDATA[<p>Nice guesses so far! Some of them are closer, some of them not-so-close, but certainly valid based on the available material in this post. Thanks a lot already!</p>
<p>First, the information-density of the green trace is equal to that of the blue trace, as Tyler pointed out. Blue is in fact, as adam pointed out, the digitized, or &#8220;sliced&#8221;, version of the green one. Yellow is the recovered clock. </p>
<p>adam is also right when comparing the green signal to an overdriven opamp output; however, no opamp characteristics are involved here. But the waveform distortion can be described as a kind of low-pass filter. In this case, the low-pass effect is caused by the physical proportions of two elements in the system.</p>
<p>You will likely notice the sparseness of the blue signal compared to the clock; that indicates that a special line code has been used, in this case a code to limit the minimum and maximum number of consecutive ones or zeros; this is called an RLL-code, a run-length limited code. The upper bound is set to allow a successful clock recovery, the lower bound to limit the high-frequency components that would get lost due to the &#8220;low-pass filter&#8221; characteristics. Because of the used code, there is 50% redundancy on top of the payload data. Quite a lot, but that&#8217;s life, and also already a 1/17th improvement over the previous generation of this technology.</p>
<p>The long zero sequence, however, is a violation of the RLL rule. And while the data is NRZI encoded, so the data polarity doesn&#8217;t matter, the violation will always be low, and never high.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8250</link>
		<dc:creator>Nate</dc:creator>
		<pubDate>Fri, 16 Jul 2010 22:44:27 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8250</guid>
		<description>This could be I2C or another chip-to-chip protocol. My guess is something to do with the Triforce since 25 Mhz is kinda old.</description>
		<content:encoded><![CDATA[<p>This could be I2C or another chip-to-chip protocol. My guess is something to do with the Triforce since 25 Mhz is kinda old.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: adam</title>
		<link>http://debugmo.de/2010/07/scope-pr0n/comment-page-1/#comment-8249</link>
		<dc:creator>adam</dc:creator>
		<pubDate>Fri, 16 Jul 2010 21:07:23 +0000</pubDate>
		<guid isPermaLink="false">http://debugmo.de/?p=175#comment-8249</guid>
		<description>ok, looking closer at this...

the analog signal seems to be suffering from phase inversion.  notice each &quot;pulse&quot; has an M shape to it.  i mean to say, if you take the &quot;V&quot; part of the &quot;M&quot; shape and folded it over the horizontal, you would have a wider, taller _upside_down_ &quot;V.&quot;

many op-amps tend to do this when you overdrive their inputs.  but i dont think thats whats happening here, because the inversion seems to happen at different voltage levels.  this leads me to think that this some type of phase encoded RF.  the small amplitude also tends to make me think this is upconverted RF.

i also notice the frequency measurements.  the mean frequency is ~25Mhz, with almost perfect STD deviation of 400kHz.  this leads me to think that this is a baseband signal between 0-400kHz, modulated on a 25Mhz carrier.

the clock trace is shown for a reason, im guessing its a recovered clock.  leading me to think this is some kind of NRZ/machester encoded data.

maybe the break through is that the clock has been recovered, and the data is being demodulated correctly, even though the dead-time bursts...

anyway, im driving myself nuts trying to figure this one out, hopefully the answer will show itself soon.

PS - i briefly looked thru the blog posts, nothing jumped out at me :(</description>
		<content:encoded><![CDATA[<p>ok, looking closer at this&#8230;</p>
<p>the analog signal seems to be suffering from phase inversion.  notice each &#8220;pulse&#8221; has an M shape to it.  i mean to say, if you take the &#8220;V&#8221; part of the &#8220;M&#8221; shape and folded it over the horizontal, you would have a wider, taller _upside_down_ &#8220;V.&#8221;</p>
<p>many op-amps tend to do this when you overdrive their inputs.  but i dont think thats whats happening here, because the inversion seems to happen at different voltage levels.  this leads me to think that this some type of phase encoded RF.  the small amplitude also tends to make me think this is upconverted RF.</p>
<p>i also notice the frequency measurements.  the mean frequency is ~25Mhz, with almost perfect STD deviation of 400kHz.  this leads me to think that this is a baseband signal between 0-400kHz, modulated on a 25Mhz carrier.</p>
<p>the clock trace is shown for a reason, im guessing its a recovered clock.  leading me to think this is some kind of NRZ/machester encoded data.</p>
<p>maybe the break through is that the clock has been recovered, and the data is being demodulated correctly, even though the dead-time bursts&#8230;</p>
<p>anyway, im driving myself nuts trying to figure this one out, hopefully the answer will show itself soon.</p>
<p>PS &#8211; i briefly looked thru the blog posts, nothing jumped out at me :(</p>
]]></content:encoded>
	</item>
</channel>
</rss>
