Re: Floppy recovery
On Tue, 5 Jan 2016, Fred Cisin wrote: 1) if the alignment of the head of the original recording and of the overwrite head are not a perfect match, then there can be some residual data somewhat off axis. At a first thought I don't see how there can be residual data because there is the tunnel erase head after the R/W head. The drives must be very misaligned (i.e. more than the width of one erase half) to still have residual data. 2) if the data was overwritten once, with a known pattern, then somebody with sufficient resources and motivation can attempt to analyze the noise, and determine "what, overwritten by a 0 could produce the noise that we have here." Accordingly, there are guvmint standards of MULTIPLE patterns to That is why you don't take /dev/zero but /dev/[u]random for overwriting data. Christian
Front panel update
Hi Guys Just got back from the silk screeners. Panels everywhere!! Final layers (Amber and white ) going on. Customising insets for type A and B ready Front is now matt black as per requests. They are sourcing some ready made packaging and plastic cloth. Its that soft stuff you get round hifi's and TV's etc. I have some pictures I took on the wifes iPad. If I can get them off on to my PC I can send then out. I'm working on a Web server as focal point for everything panel. In addition to DEC Straight 8, 8/e (A or B), 8/f and 8/m, I also have artwork for IBM 360 and Burroughs 3500 PDP 11/40 (PDP10) thru 11/70 are under way. Regards Rod
PDP-8 core memory for sale (_not_ from me)
So there's this item: http://www.ebay.com/itm/262217954449 I'm not an -8 person, so maybe there's some reason nobody's biting, but if not, I thought I'd point it out. Noel
Re: PDP-8 core memory for sale (_not_ from me)
On 07/01/2016 14:03, Noel Chiappa wrote: So there's this item: http://www.ebay.com/itm/262217954449 I'm not an -8 person, so maybe there's some reason nobody's biting, but if not, I thought I'd point it out. Noel Core is quite delicate stuff. I'd want to see a good long printout of a repeated core test. Rod
Re: PDP-8 core memory for sale (_not_ from me)
> On Jan 7, 2016, at 6:03 AM, Noel Chiappa wrote: > > So there's this item: > > http://www.ebay.com/itm/262217954449 > > I'm not an -8 person, so maybe there's some reason nobody's biting, > but if not, I thought I'd point it out. > > Noel It could be because there is no core plane shown in any of the photo’s. :-) The H219A control board needs an H220 core stack. This is only of use if you have a bad control board. Zane
Re: Conservation issue - shrink-wrapped manual
On 1/6/16 9:42 AM, Noel Chiappa wrote: I have a DEC manual (actually a Products Guide) still in its original shrink-wrap, and I'm interested in hearing opinions/rationales on whether or not I should keep it like that The CHM archivists tell me shrink wrap will continue to shrink, and it should be removed. We also don't keep vinyl binders, because they outgas and get sticky over time.
Re: Floppy recovery
1) if the alignment of the head of the original recording and of the overwrite head are not a perfect match, then there can be some residual data somewhat off axis. On Thu, 7 Jan 2016, Christian Corti wrote: At a first thought I don't see how there can be residual data because there is the tunnel erase head after the R/W head. The drives must be very misaligned (i.e. more than the width of one erase half) to still have residual data. Yes, that makes sense. But, the erase head probably doesn't scramble the weak residual flux transitions as much as overwriting does. 2) if the data was overwritten once, with a known pattern, then somebody with sufficient resources and motivation can attempt to analyze the noise, and determine "what, overwritten by a 0 could produce the noise that we have here." Accordingly, there are guvmint standards of MULTIPLE patterns to That is why you don't take /dev/zero but /dev/[u]random for overwriting data. Even then, since the s'posedly random data that was used for overwrite is still readable, leading to, "OK, here's what's currently on it, what prior recording would generate THIS background noise?", thus, a scond overwrite of a different pattern would render it past any "reasonable" efforts. I've heard that there are "standards" for a number of overwrites, and what patterns to use, . . . But, as I mentioned before, the most thorough protection of all, is to be too boring for it to be worth any effort at all. 'Course extremely violent total destruction of the drive has its own emotional benefit! I suspect that most of the stuff that impresses the hell out of outsiders to the field is really nothing more than patching DIRectories to "UNERASE" files that haven't even been overwritten.
Re: Floppy recovery
On 01/07/2016 09:36 AM, Fred Cisin wrote: I've heard that there are "standards" for a number of overwrites, and what patterns to use, . . . The paper that got the most notice was from Peter Gutmann from the early 90s. https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html --Chuck
Re: Floppy recovery
I've heard that there are "standards" for a number of overwrites, and what patterns to use, . . . On Thu, 7 Jan 2016, Chuck Guzis wrote: The paper that got the most notice was from Peter Gutmann from the early 90s. https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Thank you! That answers most of our ignorant questions. I wonder what the cost is to do those techniques.
RE: Free HP 3000 Equipment for removal (Denver Craigslist)
From: ben Sent: Wednesday, January 06, 2016 10:30 PM > On 1/6/2016 8:27 PM, Ethan Dicks wrote: >> On Wed, Jan 6, 2016 at 9:14 PM, ben wrote: >>> But where do you get the 2016 Line Printer Calender? >> jp2a --width=76 snoopy.jpg | lpr >> cal 2016 | lpr > As the printer chugs away, on second thought I want the NUDE. You'll have to be more specific. Which one? Rich
Re: Floppy recovery
- Original Message - From: "Fred Cisin" To: "General Discussion: On-Topic and Off-Topic Posts" Sent: Thursday, January 07, 2016 1:58 PM Subject: Re: Floppy recovery >>> I've heard that there are "standards" for a number of overwrites, and >>> what patterns to use, . . . > > On Thu, 7 Jan 2016, Chuck Guzis wrote: >> The paper that got the most notice was from Peter Gutmann from the early 90s. >> https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > Thank you! > > That answers most of our ignorant questions. > > > I wonder what the cost is to do those techniques. > Well, if you don't have access to thermite or even a large sledgehammer then this recommendation of his might be a cost-effective solution: http://www.diskstroyer.com/Home.html Even if you do have that sledgehammer this might be useful as a preprocessing step before final treatment with the aforementioned hammer. I'm fortunate in already having some of the tools in this kit and some experience in their use and I can highly recommend this technique, not only for data destruction but also for relaxation and a source of various unique parts. I wonder how many of those clocks made from HD platters contain sensitive information; definitely something else to worry about... ;-)
s100
hello everyone , first am 1 on the correct channel?? I have several S100 boards , found 25 years ago, kept in my cellar and forgottenfortunately they are still in good conditions , all circuits are standard ttl (only a few proms) ,and all circuits are on sockets so all is easy to repair. I cleaned and repaired the power supply (only one capacitor exploded ) , I have the correct voltages +- 19v ,+9V on the backplane , now the power supply works . I have very few documentations only a few booklets with configuration data on some of the boards , no schematic. The maker was a french company named ADD-X ,located near Toulouse south west of France . Machines ran cpm/mpm . I have boards of several configurations : *cpu boards with Z80,64k of dynamic rams and 2708 . There are configuration switches around the eprom socket to use 2708 or 2716 . I wonder how it is possible to address more than 64K (rams+eprom)with a Z80 . I need documentation about it . On Ebay I found a Z64 board that is identical , I cannot contact the seller , I tried to get informations ... he does not accept emails. Does anyone know that Z64 ? *boards with 4 rs232+1 ppi *boards with 2 rs232+1ppi+1 fdc configurable for 8 inches or 5 inches floppys. *hdc controllers with one hard disk I also have disquettes,and backplanes . I need informations on the S100/cpm systems , how are boards addressed , it is something like qbus/unibus : fixed address for each category of board,is the console at a fixed address???etc . Since that epoch I have all the classic books from R.Zaks about microprocessors and cpm , there are very few informations on the S100 bus. I built a system with a cpu and a board with RS232 and fdc,I connected the terminal to the port labeled 'con0'(console 0??) ,nothing happened on the terminal. It may be lots of thing from a dead cpu or eprom to rs232 driver . I did not test more for today. I want to build a small system with a monitor in rom to examine/modify ram , registers just to learn Z80 . What monitor can be used ? I have what is necessary to compile and burn eproms . Thanks for your help . I have lots of questions.I can send photos to identify boards . Best regards Alain Nierveze
Re: Floppy recovery
> On Jan 7, 2016, at 1:13 PM, Chuck Guzis wrote:
>
> On 01/07/2016 09:36 AM, Fred Cisin wrote:
>
>> I've heard that there are "standards" for a number of overwrites, and
>> what patterns to use, . . .
>
> The paper that got the most notice was from Peter Gutmann from the early 90s.
>
> https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
Oh yes, one of my favorite topics. I get a lot of questions where people refer
to "the DoD wiping standard". Unfortunately, there isn't one. There are some
very old documents that give suggestions, but those seem to have expired long
ago. Gutmann's document is similarly old. Any decade-old rule suffers from
the fact that drive technology has changed drastically, and considerations that
were valid then are no longer valid. Gutmann did great work at the time, and
his contribution deserves to be honored, but it has very much been superseded
by technology change. Tracks are so much smaller and margins so tiny that
multiple erasures don't add much if anything.
On the other hand, block replacement, and especially the write remapping done
by SSDs, can leave stuff in places you can't even see until you take the device
apart. In fact, hard drives are not much of an issue, but SSDs should make you
worry.
Incineration should work, but use enough heat. Shredding is questionable,
unless the particles are very small. I think high end shredders are required
to produce particles less than 1/32 inch in size.
Much more recent work on erase was done by Gordon Hughes at UCSD. See
http://cmrr.ucsd.edu/people/Hughes/secure-erase.html for more.
If you want data security and don't like destroying your hardware, SED
("self-encrypting drives") are a solution. Those encrypt all data, and "erase"
by discarding and replacing the data encryption key. So all your sectors
instantly turn to random noise. SSD versions of those are starting to appear,
which addresses the invisible old copies problem that regular SSDs have. The
great thing of an SED is not just the security of its erase function, but in
particular the speed: it takes only seconds to destroy all the data on the
drive.
paul
Re: I COULD JUST KICK MYSELF IN THE BUTT!!! commodore pet . . .
> I don't know if > any of you remember when they switched over to the unlimited monthly > plan but as for in Oregon AOL Servers crashed for about 3 months from > such a heavy load of members dialing up and connecting quick question > here _*<--- Did this happen in your area if so where were you?*_ Yes, I remember those times. I was everywhere. -- Will, ex will...@ans.net
Re: Floppy recovery
On Thu, Jan 7, 2016 at 1:17 PM, Paul Koning wrote:
> If you want data security and don't like destroying your hardware, SED
> ("self-encrypting drives") are a solution. Those encrypt all data, and
> "erase" by discarding and replacing the data encryption key. So all your
> sectors instantly turn to random noise. SSD versions of those are starting
> to appear, which addresses the invisible old copies problem that regular SSDs
> have. The great thing of an SED is not just the security of its erase
> function, but in particular the speed: it takes only seconds to destroy all
> the data on the drive.
You're assuming that the SED doesn't store an extra copy of the
decryption key in NVM or on the medium. IMO, that's a very naive
assumption. Also, reverse-engineering has shown that at least some
SEDs have very bad crypto implementations.
Even if your SED doesn't have a back door or badly implemented crypto,
you also have to worry about whether someone has managed to install
compromised firmware on it. People once thought that hacked drive
firmware was too difficult or expensive to develop for anyone other
than three-letter agencies, but that's been proven false.
I'm OK with an SED being a component of the data security solution,
but I'm not willing to count on it exclusively. I'll still run
software disk encryption. Preferably open-source software disk
encryption, so that the source code can be audited, though that's not
a guarantee either.
One might expect that simple security measures would be enough as long
as the threat model you're concerned with isn't three-letter agencies.
Unfortunately any back doors or badly implemented crypto, whether
installed by TLAs or just through incompetence, are likely to be
exploited by many miscreants, not just TLAs.
If your threat model IS three-letter agencies, you're basically doomed
from the outset.
Re: Floppy recovery
> On Jan 7, 2016, at 3:33 PM, Eric Smith wrote:
>
> On Thu, Jan 7, 2016 at 1:17 PM, Paul Koning wrote:
>> If you want data security and don't like destroying your hardware, SED
>> ("self-encrypting drives") are a solution. Those encrypt all data, and
>> "erase" by discarding and replacing the data encryption key. So all your
>> sectors instantly turn to random noise. SSD versions of those are starting
>> to appear, which addresses the invisible old copies problem that regular
>> SSDs have. The great thing of an SED is not just the security of its erase
>> function, but in particular the speed: it takes only seconds to destroy all
>> the data on the drive.
>
> You're assuming that the SED doesn't store an extra copy of the
> decryption key in NVM or on the medium. IMO, that's a very naive
> assumption. Also, reverse-engineering has shown that at least some
> SEDs have very bad crypto implementations.
True. I know of at least one first generation SED that uses ECB mode. Anyone
who has looked at IEEE 802.11 knows that cryptographic competence is not
common, and that some of the people designing cryptosystems are not only
unqualified to do so, but sufficiently ignorant that the aren't even aware that
they aren't qualified.
With SEDs as with any other security tool, one has to be sceptical and ask very
pointed questions. For example, with the SSD kind, I probed deeply into how
the key is replaced in a "crypto erase" operation, down to the level of the
flash memory primitives involved. The particular implementation I looked at
had the correct answers.
> Even if your SED doesn't have a back door or badly implemented crypto,
> you also have to worry about whether someone has managed to install
> compromised firmware on it. People once thought that hacked drive
> firmware was too difficult or expensive to develop for anyone other
> than three-letter agencies, but that's been proven false.
The key here is the use of signed firmware, which I believe is the normal
practice. With that, it's not just a matter of reverse engineering, the
attacker would also have to steal the firmware signing key.
> I'm OK with an SED being a component of the data security solution,
> but I'm not willing to count on it exclusively. I'll still run
> software disk encryption. Preferably open-source software disk
> encryption, so that the source code can be audited, though that's not
> a guarantee either.
Agreed. I've been a TrueCrypt user ever since DriveCrypt went off track.
> One might expect that simple security measures would be enough as long
> as the threat model you're concerned with isn't three-letter agencies.
> Unfortunately any back doors or badly implemented crypto, whether
> installed by TLAs or just through incompetence, are likely to be
> exploited by many miscreants, not just TLAs.
>
> If your threat model IS three-letter agencies, you're basically doomed
> from the outset.
Maybe so. But you can definitely make things much harder, which is worth doing.
paul
Cloning a PCB
Any suggestions/hints/experience/links regarding the best/easiest way to clone a (two-sided) PCB, i.e. create a Gerber or equivalent file from a PCB layout instead of a schematic? TIA, m
Re: s100
On 2016-Jan-07, at 11:13 AM, nierveze wrote: > first am 1 on the correct channel?? > I have several S100 boards , found 25 years ago, > ... > I wonder how it is possible to address more than 64K (rams+eprom)with a Z80 . S100 memory boards often incorporated a bank-switching scheme to allow for multiple 64K banks in the system. The convention was a dedicated I/O port number (0x40?) to which one writes a bit pattern to select the desired bank. Such memory boards have configuration switches to set their bank ID/number. For a system to use this scheme, all the memory boards in the system are to be listening on that same port, waiting to recognise their ID. There's also the PHANTOM line on the bus, used to allow a bootstrap ROM to take precedence over some address space at reset/power-on, thus overlaying some RAM during boot. The ROM is switched out at some point to allow access to full RAM. > I need documentation about it . Best sourcess for S100 board docs are: http://www.s100computers.com/Hardware%20Index%20Page.htm and http://maben.homeip.net/static/S100/ Seems to be a lot of duplication between the two, I'm not sure which site the (duplicate) material originated on (who's copying whom). There's also this site, although I'm not as familiar with it: http://www.hartetechnologies.com/manuals/
Re: Cloning a PCB
On Thu, Jan 7, 2016 at 1:33 PM, Mike Stein wrote: > Any suggestions/hints/experience/links regarding the best/easiest way to > clone a (two-sided) PCB, i.e. create a Gerber or equivalent file from a PCB > layout instead of a schematic? > Easiest? Throw some money at having someone do the work for you. Grant at http://altairkit.com says that he used these people to scan and replicate some vintage PCBs: http://www.mhtest.com/scanning.shtml No idea how much that costs. Probably in the if you have to ask you can't afford it range.
Re: Cloning a PCB
I reverse engineer boards as a hobby i produce full schematics and can also replicate PC boards I have the boards produced in china. should be cheaper now that china is crashing and burning just takes time and money On 1/7/2016 3:11 PM, Glen Slick wrote: > On Thu, Jan 7, 2016 at 1:33 PM, Mike Stein wrote: >> Any suggestions/hints/experience/links regarding the best/easiest way to >> clone a (two-sided) PCB, i.e. create a Gerber or equivalent file from a PCB >> layout instead of a schematic? >> > Easiest? Throw some money at having someone do the work for you. > > Grant at http://altairkit.com says that he used these people to scan > and replicate some vintage PCBs: http://www.mhtest.com/scanning.shtml > > No idea how much that costs. Probably in the if you have to ask you > can't afford it range. > -- The contents of this e-mail and any attachments are intended solely for the use of the named addressee(s) and may contain confidential and/or privileged information. Any unauthorized use, copying, disclosure, or distribution of the contents of this e-mail is strictly prohibited by the sender and may be unlawful. If you are not the intended recipient, please notify the sender immediately and delete this e-mail.
Re: Secure disk destruction [was Re: Floppy recovery]
tor 2016-01-07 klockan 15:08 -0500 skrev Mouse: > > Well, if you don't have access to thermite [...] > > Actually, red heat is well above the Curie temperature for most media, > isn't it? You could chuck the platters into the coals of a bonfire, > let them get up to a nice cherry red. Depending on what the platters > are made of, this might even melt them, which should effectively > destroy any organization in the material that once formed a thin film > on them. If not, it should demagnetize the coating Unhealthy. I would expect that to generate a fair amount of sulphuric and hydrochloric acid. A fair bit of the shit inside the HD also would end up in the nearby soil.
Re: Floppy recovery
>>> If you want data security and don't like destroying your hardware,
>>> SED ("sel$
>> You're assuming that the SED doesn't store an extra copy of the
>> decryption key in NVM or on the medium.
That was my initial reaction too!
>> Also, reverse-engineering has shown that at least some SEDs have
>> very bad crypto implementations.
I was not aware of that, but (and this is a depressing commentary on
_something_) it does not surprise me in the least.
>> Even if your SED doesn't have a back door or badly implemented
>> crypto, you also have to worry about whether someone has managed to
>> install compromised firmware on it.
> The key here is the use of signed firmware, which I believe is the normal pr$
That's hardly a fix; all it does is somewhat reduce the pool of people
who can create the compromised firmware. I don't trust the vendor's
internal security to keep the key from leaking and I don't trust the
vendor's HR security to prevent malware authors from making it to the
inside, and I *sure* don't trust the vendor to resist a request from
law enforcement for an easy-to-access backdoor (which will, of course,
promptly get abused, either by others or for other purposes).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Floppy recovery
> On Jan 7, 2016, at 3:52 PM, Mouse wrote: > > >>> Even if your SED doesn't have a back door or badly implemented >>> crypto, you also have to worry about whether someone has managed to >>> install compromised firmware on it. >> The key here is the use of signed firmware, which I believe is the normal pr$ > > That's hardly a fix; all it does is somewhat reduce the pool of people > who can create the compromised firmware. I don't trust the vendor's > internal security to keep the key from leaking and I don't trust the > vendor's HR security to prevent malware authors from making it to the > inside, and I *sure* don't trust the vendor to resist a request from > law enforcement for an easy-to-access backdoor (which will, of course, > promptly get abused, either by others or for other purposes). > I don’t know if it’s typical or not, but every company that I’ve worked for that has managed crypto-keys has taken key security *very* seriously. For example, the key generating system (usually something custom) is kept in an “air gapped” vault (and I *do* mean vault). The vault can only be opened when two authorized individuals are present (ie neither one can get into the vault without the other). Everything is tracked and audited on a regular basis. One big semi-conductor company does it this way (I have personal knowledge). I also helped set up this type of crypo-key management for one of the startups I worked for once upon a time (even to the point where they crypto-key hardware would “self destruct” if tampered with…sorry no sparks, smoke or other visual aids…it just erased itself). TTFN - Guy
Re: Floppy recovery
>> I don't trust the vendor's internal security to keep the key from >> leaking and I don't trust the vendor's HR security to prevent >> malware authors from making it to the inside, and I *sure* don't >> trust the vendor to resist a request from law enforcement [...] > I donâ¿¿t know if itâ¿¿s typical or not, but every company that > Iâ¿¿ve worked for that has managed crypto-keys has taken key security > *very* seriously. I find that easy to believe. However: (1) "[E]very company [you]'ve worked for" is almost certainly a heavily biased sample; if you have a tenth the clue you appear to, you would stay away from the dodgier ones. (2) Taking key security seriously is a very different thing from being good at key security. (They probably correlate positively, but not nearly as strongly as one might wish.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Floppy recovery
> On Jan 7, 2016, at 4:13 PM, Mouse wrote: > >>> I don't trust the vendor's internal security to keep the key from >>> leaking and I don't trust the vendor's HR security to prevent >>> malware authors from making it to the inside, and I *sure* don't >>> trust the vendor to resist a request from law enforcement [...] >> I donâ¿¿t know if itâ¿¿s typical or not, but every company that >> Iâ¿¿ve worked for that has managed crypto-keys has taken key security >> *very* seriously. > > I find that easy to believe. However: > > (1) "[E]very company [you]'ve worked for" is almost certainly a heavily >biased sample; if you have a tenth the clue you appear to, you >would stay away from the dodgier ones. Probably. ;-) > > (2) Taking key security seriously is a very different thing from being >good at key security. (They probably correlate positively, but not >nearly as strongly as one might wish.) > Agree. In the cases I’m aware of they do both. ;-) TTFN - Guy
Re: Secure disk destruction [was Re: Floppy recovery]
What's wrong with the "disassemble and rend with heavy hammer" approach? Doesn't that render the platters un-readable, if done with sufficient ardor? On Thu, Jan 7, 2016 at 5:09 PM, Stefan Skoglund (lokal < stefan.skogl...@agj.net> wrote: > tor 2016-01-07 klockan 15:08 -0500 skrev Mouse: > > > Well, if you don't have access to thermite [...] > > > > Actually, red heat is well above the Curie temperature for most media, > > isn't it? You could chuck the platters into the coals of a bonfire, > > let them get up to a nice cherry red. Depending on what the platters > > are made of, this might even melt them, which should effectively > > destroy any organization in the material that once formed a thin film > > on them. If not, it should demagnetize the coating > > Unhealthy. > > I would expect that to generate a fair amount of sulphuric and > hydrochloric acid. > A fair bit of the shit inside the HD also would end up in the nearby > soil. > >
Re: Secure disk destruction [was Re: Floppy recovery]
On 2016-01-07 9:06 PM, drlegendre . wrote: What's wrong with the "disassemble and rend with heavy hammer" approach? Doesn't that render the platters un-readable, if done with sufficient ardor? Or spin the disk and scrape off the oxide, I have seen disk drive do that all by themselves, but as I said earlier modern disks mostly use glass platters so you do not even have to disassemble them to smash the platters. Paul.
Re: Secure disk destruction [was Re: Floppy recovery]
On Thu, 7 Jan 2016, drlegendre . wrote: What's wrong with the "disassemble and rend with heavy hammer" approach? Doesn't that render the platters un-readable, if done with sufficient ardor? Bending the platters will keep them from turning and being usable in the drive, but does NOT prevent various other imaging methods. Breaking a platter in half doesn't prevent those techniques. Shattering a glass platter into dozens of pieces doesn't prevent those techniques. breaking it into tiny bits may or may not depending on how much effort somebody is willing to put into identifying where each piece came from in the platter. High heat should work. Sanding all of the rust off of the platter should work. Mailing the drive to a government office, with a note saying, "please help me recover the pictures of my grandmother's birthday party", and having it lost in their mailroom might work.
Re: Secure disk destruction [was Re: Floppy recovery]
On Thu, Jan 7, 2016 at 6:20 PM, Fred Cisin wrote: > On Thu, 7 Jan 2016, drlegendre . wrote: > >> What's wrong with the "disassemble and rend with heavy hammer" approach? >> Doesn't that render the platters un-readable, if done with sufficient >> ardor? >> > > Bending the platters will keep them from turning and being usable in the > drive, but does NOT prevent various other imaging methods. > > Breaking a platter in half doesn't prevent those techniques. > > Shattering a glass platter into dozens of pieces doesn't prevent those > techniques. > > breaking it into tiny bits may or may not depending on how much effort > somebody is willing to put into identifying where each piece came from in > the platter. > > High heat should work. > > Sanding all of the rust off of the platter should work. > > Mailing the drive to a government office, with a note saying, "please help > me recover the pictures of my grandmother's birthday party", and having it > lost in their mailroom might work. > > > Putting it a crate with a few hundred other drives... -- Charles
Re: Secure disk destruction [was Re: Floppy recovery]
On 1/7/2016 6:20 PM, Fred Cisin wrote: On Thu, 7 Jan 2016, drlegendre . wrote: What's wrong with the "disassemble and rend with heavy hammer" approach? Doesn't that render the platters un-readable, if done with sufficient ardor? Bending the platters will keep them from turning and being usable in the drive, but does NOT prevent various other imaging methods. Breaking a platter in half doesn't prevent those techniques. There are machines sold to machine document destruction folks that will shred the entire drive into pieces the size of large grains of sand. They are deployable on trucks with on site document destruction services, and I know of two friends here in Orange Country who have bought them. They are also useful if you are also doing your own high-grade gold refining pass, for preparation of material. The two recycling operators I know are probably doing this process as well. Most gold recover folks are not trusted. thanks jim
Re: Secure disk destruction [was Re: Floppy recovery]
On 01/07/2016 08:17 PM, jwsmobile wrote: They are also useful if you are also doing your own high-grade gold refining pass, for preparation of material. The two recycling operators I know are probably doing this process as well. Most gold recover folks are not trusted. There are several Youtube clips of these things in operation, including one that's being fed vintage Macs. --Chuck
Re: Open VMS System Mgt Guide Scripts Avail.
On Sun, Jan 3, 2016 at 2:31 PM, william degnan wrote: > I've uploaded the contents of the disk that accompanis the book "OpenVMS > System Management Guide" by Lawrence Baldwin here: > > http://www.vintagecomputer.net/digital/OpenVMS/ There are a lot of files there. Can you post them zipped up as well? j
