4096 byte sectors don’t solve the analog problem—signals are getting weaker, and noise is getting stronger, and only reduced densities or some breakthrough in recording technology are going to change that—but it helps substantially with the error-correcting problem. Due to the way error correcting codes work, larger sectors require relatively less error correcting data to protect against the same size errors. A 4096 byte sector is equivalent to eight 512 byte sectors. With 40 bytes per sector for finding sector starts and 40 bytes for error correcting, protecting against 50 error bits, 4096 bytes requires (8 x 512 + 8 x 40 + 8 x 40) = 4736 bytes; 4096 of data, 640 of overhead. The total protection is against 400 error bits (50 bits per sector, eight sectors), though they have to be spread evenly among all the sectors.

With 4096 byte sectors, only one spacer start is needed, and to achieve a good level of protection, only 100 bytes of error checking data are required, for a total of (1 x 4096 + 1 x 40 + 1 x 100) = 4236 bytes; 4096 of data, 140 of overhead. 100 bytes per sector can correct up to 1000 consecutive error bits; for the forseeable future, this should be “good enough” to achieve the specified error rates. With an overhead of just 140 bytes per sector, about 96% of the disk’s capacity to be used.

With longer block lengths, the error correction capability generally goes up for the same coding overhead, however, it seems rather more complicated than this. First of all, I don’t think each manufacturer uses the same code or coding structure. (They used to just use Reed-Solomon code, though later they tried concatenating it with LDPC code, and now I hear some are switching to pure LDPC with iterative decoding.) But even if we assume they use some non-exotic block code, and use interleaving for bursts, the math still seems very strange: 40 error correction bytes can only correct 50 consecutive bits currently? I think not.

To my surprise, this driver is still available.

However, I didn’t realize at the time how playing sound through the PC speaker required an interesting hack. You see, the PC speaker could only be put into two states, on and off. So it was easy to make single pitches (which we all did, didn’t we? beep beep) So technically the PC speaker could only generate square waves of various duty cycles. Here’s how the PC speaker is controlled.

Then how was it able to play arbitrary wave files? Well, it turns out 8-bit sound is supposedly generated by pulse code modulation like this, like a light dimmer. The idea is to get “half on” you turn it on half the time. But it really shouldn’t work that way if you think about it, at least not so trivially, since what is being set is the amplitude, not the average power.

Of course the PC speaker, even though it can only be given signals to drive it to two states, doesn’t just make square waves, since it has mechanical impedance. In fact it is a low-pass filter. So the true problem, which any decent PC speaker driver should solve, is given a target signal to be reproduced and an impulse response of the PC speaker, find the input signal (subject to restriction to two values, say, -1 and 1), that when filtered by the PC speaker gives the least error from the target signal. This probably is not given by the simple modulation scheme. On the other hand, is the two-value restriction costly? What is the minimum and maximum amount of error that results?

There must be a paper on this. On the other hand, I’m not sure that any existing PC speaker driver implements anything like this. Here is the code for one of them, but it looks too short to be doing anything sophisticated.

http://en.wikipedia.org/wiki/Noisy-channel_coding_theorem

could have left it at the classical statement of the theorem with bullet #1. Then it goes on to say:

2. If a probability of bit error \(p_b\) is acceptable, rates up to \(R(p_b)\) are achievable, where

\(R(p_b) = \frac{C}{1-H_2(p_b)}\).

3. For any \(p_b\), rates greater than \(R(p_b)\) are not achievable.

I have never seen this before. At first glance, this seems questionable, as Fano’s converse gives \(P_e^{(n)} \ge 1 – \frac{1}{nR} – \frac{C}{R}\), which seems to converge to \(H_b(p_e) \ge p_e\) for \(p_e \in [0,0.5]\). So it must mean whatever is used to code this is not going to be a long block code.

One example where this is true is the binary symmetric channel, with uncoded transmission. But I’m not so sure what is the achievability scheme in general, although I have some ideas — it may involve quantizing the excess codewords to the nearest zero-error codewords. The converse I have no idea.

In terms of the statement, it is really unclear what is meant by “bit error”. In the classical statement, a message from a large alphabet is coded into some \(X^n \in \mathcal{X}^n\) where \(\mathcal{X}\) is the channel input alphabet. After decoding, \(X^n\) is either found correctly, or it is in error. There is no “bit” in here. Even if \(X\) is binary, is the bit error the received (uncooked) bit error? Or is it the decoded (cooked) bit error? Why should the decoded bit error matter, isn’t that a codebook artifact? Or is it the bit error in the original message, if the original message is to be represented by a bit-stream? But that is also entirely arbitrary.

Anyway I’d like a clarification from someone or a reference.

Oh do they? But come… on…, what is this ridiculous demonstration? Okay, okay, it’s the IT Policy School over there, let’s cut them some slack. What they’ve come up with is a way to read seated DRAM under OS lock without specialized hardware, and if they said that, it would be fine.

While I don’t care for their pseudo-slick presentation and shameless self-promotion (with a “blog”?), it is still a curious piece of work. Its unfortunate and regurgitated untechnicality leaves questions, though. DRAM is refreshed in tens of milliseconds, and since DRAM manufacturers are always trying to cut power consumption, I’m going to assume this rate is necessary to ensure reliable read out. There is a 3-order magnitude difference between that and the seconds to minutes reported that DRAM can be without power and still be read, during which time exponential charge decay takes place. Something else has to be going on, no? It just isn’t entirely clear that when the computer is turned off momentarily, on-board capacitors or even on-module capacitors aren’t discharging for long enough to residually power the refresh circuitry [*]. On the other hand, they claim they can remove the RAM completely and (with the help of liquid nitrogen) halt for an hour without power. I have some doubts as they dance around this issue.

As for real implication for security, there isn’t much, if only because this kind of breach isn’t fundamental. We already know that once indefinite hardware access to a running machine is first obtained (a practical requirement for this attack), there are always ways to compromise it. That’s how the Xbox was cracked — I’m talking about in-parallel probes on pins and traces, which can be just as well applied to the scenario here. Unless there are self-destructive mechanisms or other fundamental barriers to hardware access, we are just dealing with a matter of how high is the effort threshold. To fix it, encryption keys should not be stored in RAM in a detectable way, and any TPM modules that are currently being designed should have additional hardware security measures. That’s not hard to do, but in the meantime, let’s sit back and watch an uptick in the cracking of existing software and DRM protection schemes, as protected areas of RAM are opened up to easy hacking — a far more likely and practical fallout.

[*] I just read their full technical documentation, and they seem a little sloppy. They measure (and plot) total module read out error rate, but then fit a curve to it that they justify with MOSFET charge decay characteristics. Isn’t that right? Well, no: error rate should exhibit the typical digitizing water-fall effect of the comparator circuit.

I am interested to know why people in the late 19th century clamored for an income tax. It seems strange. It looks like the farm lobby in the West at that time wanted a graduated tax to redistribute income, so I can understand some states being for an income tax, but three-quarters of the states? It seems difficult even to raise tax rates today, so where were the “tax protestors” back then?

Part 3.

Today I became suspicious of (the ext2ifs driver, the mkfs command, the USB enclosure, and basically) everything

On Christmas morning Santa Claus had not granted my wish: ddrescue was still running, but the image file had not been timestamped any more recently than when I left it, and the damaged drive had spun down by itself. dmesg revealed a syslog message “too many IO errors” or something like that, which had caused Linux to give up on reading from the damaged drive. I was very frustrated because, well let’s see, I had expected the disk imaging to make good progress, but instead… I must suffer a reboot and the induced indefinite re-churning of the drive, with even more data loss! What.

Attempting to reboot, I got impatient and tried the Dell Diagnostic partition again. To my dismay, the Dell Diagnostic partition had become unreadable, a sure sign that the disk’s failures were worsening, adding more urgency to the recovery mission. With no viable second option, I booted Knoppix again and resigned myself to the disk churning. Finally I was in again and started ddrescue back up at about 4000MB, to skip the errors at 3200MB.

This completely goes against the original intention of having a good copy of the data! And at this point I need to fork a sub-project to work on recovering the ext2 volume, because I don’t think I can read all 38GB of the already-recovered data back out of the dead Seagate again. Argh!! I called it a night.

Lessons today:

• I shouldn’t fork the project, I should just bork it altogether. The gods clearly aren’t working with me.
• Of course I should keep working at this. I just need to use proven technology when making a crucial file copy.
• ddrescue is good about skipping over good areas of the disk already scanned, but isn’t intelligent about scanning the bad areas of the disk.
• Dell support is truly useless.

On to Part 4.