Re: [eff-austin] Antispam Bills: Worse Than Spam?
On Tue, 5 Aug 2003, Sunder wrote: That is not upto you to decide. That is upto Bob. Since you haven't entered any business agreement with AOL, you cannot make such claims against them. Sometimes you don't have an effective choice. According to a friend, there are still areas (especially rural) in the US where AOL is the virtually only game in town. The 1st ammended prevents CONGRESS from limiting the freedom of speech. More precisely from creating laws that do so. It does not limit private or public companies from doing so. The 1st has nothing to do with this. You're clueless. There is an emerging potential problem linked to continuing privatization of virtually everything, and - the most important - to consolidation of owners. You can easily end up with the situation when everything around is owned by one of a handful of Big Corps, all with virtually the same restrictions, if the Market allows them that (eg, there will be enough consumers that won't care, and the rest will be the commercially uninteresting fringe). Then - tough luck. While I have gotten all but one friend and all family members to drop their AOL/Earthlink services, this still remains an issue for users whome I don't know personally. And you have no contract with either AOL or that friend. Like I said, you have no right to interfere in AOL's business. If you can convince their subscribers that AOL sucks, and they chose to cancel their service, that's fine, that's wonderful - though if AOL finds out, they may sue you for loss of business. Now this is an interesting question. Can AOL really sue the one who tells their customers the truth about the drawbacks of AOL's service? Isn't the existence of those drawbacks - including their refusal to correct them - ultimately THEIR OWN fault?
Re: MRAM, persistance of memory
On Wed, 9 Jul 2003, Eric Murray wrote: I doubt it as well. DRAM also has power-off memory persistence and nearly everyone in security ignores that as well. But not the spooks : The FEI-374i-DRS is a data recovery system that captures and preserved digital data, in its original format, directly from the Dynamic Random Access Memory (DRAM) of Digital Telephone Answering Machines (DTAMs) .. The FEI-374i-DRS is an indispensable tool for forensic investigators required to evaluate residual audio and tag information retained in today's DRAM-based DTAMs. http://www.nomadics.com/374idrs.htm The system doesn't seem to be able to recover data from powered-off DRAM. The specs say it can recover files that were erased. The DRAM-based DTAMs use the DRAM as a RAM disk. For some reason unknown to us (may be conspiracy with TLA, but Occam's razor says it's mere negligence/laziness) the designers don't overwrite the memory region that pertains to an erased file, only deallocate it, leaving the data there. I suppose the DRAM refresh circuits are backed up with a small battery to cover brief blackouts. It is impossible to get access to the voltage on the DRAM cell capacitors (at least if the chip is in its case and we can access only its pins). We can only see if it is in the range for H or L. And after a power-down (or even a sufficiently long period without a refresh of the given cell) the cell capacitor loses voltage steadily, reaching the level of L (or maybe H?) within at most couple seconds. Seems the device is nothing more than a logic analyzer connected to the DRAM pins. This is a nice illustration of the problem with comercial vendors and closed-architecture devices they peddle. If we'd have access to the firmware of the DTAMs, writing extensions for storing data in (at least somehow) encrypted format and their overwriting after deletion won't be a big problem. Hope the price of embeddable computer cores will continue to fall. (Apropos, whats the current cost of the cheapest cores able to run stripped-down Linux? Maybe something based on ARM or MIPS architecture?)
Idea: The ultimate CD/DVD auditing tool
Pondering. Vast majority of the CD/DVD protection methods is based on various deviations from the standards, or more accurately, how such deviations are (or aren't) handled by the drive firmware. However, we can sidestep the firmware. The drive contains the moving part with the head assembly. There is an important output signal there: the raw analog signal bounced from the disk and amplified. We can tap it and connect it to a highspeed digital oscilloscope card. And sample obscene amount of data from it. In comparison with fast-enough ADCs, disk space is cheap. The problem can be in bandwidth, but for the drive speed set up to possible minimum (or for normal players) the contemporary machines should be sufficient. Real-time operating system (maybe RTOS-Linux) may be necessary. We get the record of the signal captured from the drive's head - raw, with everything - dirt, drop-outs, sector headers, ECC bits. The low-level format is fairly well documented; now we have to postprocess the signal. Conversion from analog to digital data and then from the CD representation to 8-bit-per-byte should be fairly straightforward (at least for someone skilled with digital signal processing). Now we can identify the individual sectors on the disc and extract them to a disc image file that we can handle later by normal means. We can push the idea a step further, making a stripped-down CD/DVD drive that would be able basically just to follow the spiral track with its head in constant linear velocity (easier to analyze than CAV) mode, with the ability to control the speed in accordance with how fast (and expensive) ADC, bus, and disks we have, and the possibility to interrupt/resume scanning anytimes in accordance with how much disk space we have (or to scan just a small area of the disc). As a welcomed side effect, not only we'd get a device for circumvention of just about any contemporary (and possibly a good deal of the future ones) optical media protections, but we would also get a powerful tool for retrieving data from even very grossly damaged discs, for audit of behavior of CD/DVD writers and CD vendors (eg, if they don't attempt to sneak in something like a hidden serial number of the writer), and for access to all areas of the discs - including the eventual ones unreachable through the drive's own firmware. If we'd fill this idea with water, would it leak? Where? Why?
Re: [Brinworld] Car's data recorder convicts driver
On Tue, 17 Jun 2003, Tim May wrote: Unlikely. Getting juice into the innards of a box in a way so as to overwrite data is not nearly so simply as applying sparky things to the outside of the box. Lots of reasons for this. The idea wasn't about overwriting the data. The idea was about frying the chip with the data inside (and if all the other chips inside the box become a collateral damage, let's that be so). As long as it is outside the technological abilities of the given adversary to retrieve the data from the fried chip, the objective is reached. The idea also wasn't about the outside of the box, I thought rather disconnecting the power leads and blasting the spark into the power-GND pair, or into the (disconnected, we don't want to kill the entire car electronics) data bus. With a bit of luck, the spark could get through the filters and into the Vcc pins of the chips.
Re: [Brinworld] Car's data recorder convicts driver
On Wed, 18 Jun 2003, jburnes wrote: Why go to all that trouble. Just take it out of circuit. Cut the printed circuit board leads and disable it or if its in an inaccessible black box, cut the leads to the box. Easy enough. Works very nicely. :) Problem: leaves evidence, and takes time. The main advantage of electric shock is that the fried chip looks for the naked eye exactly the same way as a non-fried chip. The only difference could be found with a scanning electron microscope on the chip itself, which is something nobody is likely to bother with. Especially in harsh environments (cars classify) chips tend to die, so its death could look as natural enough to not be suspicious. If I am wrong, please tell me where and why. :)
