---

hej,

Kan I anbefale et velegnet program til at fjerne alle data fra en mac
(osX). Jeg ved ikke meget om det, men har hørt at en alm
reformattering ikke er tilstrækkelig (det skulle stadig være muligt
at få data frem).

Står over for at skulle sælge et par macs og vil gerne sikre at mine
passwords og andet godt vitterligt er helt væk.

På forhånd tak, hilsen Esther

---

Hej Esther

ufo wrote:
> Kan I anbefale et velegnet program til at fjerne alle data fra en mac
> (osX). Jeg ved ikke meget om det, men har hørt at en alm
> reformattering ikke er tilstrækkelig (det skulle stadig være muligt
> at få data frem).

Brug Diskværktøj... Start fra en system CD fx. Tiger. Vælg 'Diskværktøj'
fra menuen.

Når Diskværktøj har fundet dine diske, vælger du den, der skal slettes
ved at markere den og klik på fanen 'Slet' til højre. Nederst klikker du
på 'Sikkerhedsindstillinger'. Her kan du vælge 'Slet data', som
overskriver med nuller 1 gang eller 'Slet 7 gange', som overskriver med
nuller 7 gange. - Tager selvfølgelig 7x så lang tid, men så er disken
også garanteret 100% ren. Klik så på 'OK' og 'Slet'...

> Står over for at skulle sælge et par macs og vil gerne sikre at mine
> passwords og andet godt vitterligt er helt væk.

Altid en god idé

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

ufo <ufo.danmark@hotmail.com> wrote:
> hej,

> Kan I anbefale et velegnet program til at fjerne alle data fra en mac
> (osX). Jeg ved ikke meget om det, men har hørt at en alm
> reformattering ikke er tilstrækkelig (det skulle stadig være muligt
> at få data frem).

> Står over for at skulle sælge et par macs og vil gerne sikre at mine
> passwords og andet godt vitterligt er helt væk.

> På forhånd tak, hilsen Esther

en hammer + efterfølgende afbrænding kan anbefales hvis du er så
sensitiv... ellers kan du skriver nuller i alle blokke mange gange.

--
Morten Reippuert Knudsen <http://blog.reippuert.dk>

PowerMac G5: 1.6GHz, 1,25GB RAM, 300+300GB SATA, 16xDVD DL, Bluetooth
mus+tastatur, R9600PRO, iSight, eyeTV200 & LaCie Photon18Vision TFT.

---

Morten Reippuert Knudsen wrote:
> ufo <ufo.danmark@hotmail.com> wrote:
>
> en hammer + efterfølgende afbrænding kan anbefales hvis du er så
> sensitiv... ellers kan du skriver nuller i alle blokke mange gange.
>
Det med at skrive nuller er ikke nødvendigvis smart.
Se f.eks. http://www.linux-kurser.dk/secure_del_peter_gutmann.html.

Den intuitive forklaring er at mediet har en vis træghed. Normale
harddiske er designet til at være hurtige, derfor operere de med et
threshold hvor alle signaler under treshold'et bliver opfattet som 0.
Men med specielt udstyr kan data læses alligevel.
Hvis vi for eksemplets skyld antager at det analoge signal fra mediet
ligger mellem 0 og 1.
Hvis signalet x er mindre end 0.5 opfatter vi dette som 0-bit, hvis x >
0.5 opfattes dette som 1-bit.
Da mange medier skal påvirkes et stykke tid for at gå fra 1.0 til 0.0,
så påvirker mange enheder kun mediet i tid nok til at det f.eks. når ned
på 0.4. Hvis vi antager trægheden er lineær, så har vi sparet 40% skrive
tid.
Hvilket under normale omstændigheder gør os glade. Men ved sikker
sletning af data, er dette ikke godt.
Antag vi har følgende data set:
(0.0, 1.0, 1.0, 0.0)
Efter en overskrivning med nuller har vi nu:
(0.0, 0.4, 0.4, 0.0)

Med andre ord, vil man stadig kunne læse data.

Dette vil dog kræve specielt udstyr.

---

Mads <mads@iname.com> wrote:

> Morten Reippuert Knudsen wrote:
> > ufo <ufo.danmark@hotmail.com> wrote:
> >
> > en hammer + efterfølgende afbrænding kan anbefales hvis du er så
> > sensitiv... ellers kan du skriver nuller i alle blokke mange gange.
> >
> Det med at skrive nuller er ikke nødvendigvis smart.
> Se f.eks. http://www.linux-kurser.dk/secure_del_peter_gutmann.html.
>
> Den intuitive forklaring er at mediet har en vis træghed. Normale
> harddiske er designet til at være hurtige, derfor operere de med et
> threshold hvor alle signaler under treshold'et bliver opfattet som 0.
> Men med specielt udstyr kan data læses alligevel.
> Hvis vi for eksemplets skyld antager at det analoge signal fra mediet
> ligger mellem 0 og 1.
> Hvis signalet x er mindre end 0.5 opfatter vi dette som 0-bit, hvis x >
> 0.5 opfattes dette som 1-bit.
> Da mange medier skal påvirkes et stykke tid for at gå fra 1.0 til 0.0,
> så påvirker mange enheder kun mediet i tid nok til at det f.eks. når ned
> på 0.4. Hvis vi antager trægheden er lineær, så har vi sparet 40% skrive
> tid.
> Hvilket under normale omstændigheder gør os glade. Men ved sikker
> sletning af data, er dette ikke godt.
> Antag vi har følgende data set:
> (0.0, 1.0, 1.0, 0.0)
> Efter en overskrivning med nuller har vi nu:
> (0.0, 0.4, 0.4, 0.0)

God pointe. Men hvem siger nu også, at de nuller heri: 0.0, 0.4, 0.4,
0.0, nødvendigvis er 0,0? Hvis de er meget træge, kan det jo være de er
0,38, hvilket så besværliggør det lidt, hvis man nu har det specielle
udstyr til rådighed og vil have indholdet ud.

Bare en tanke, nu vi alligevel har taget det ud på et temmeligt ekstremt
plan, når man tænker på, hvor lidt interessant det er for en normal
køber at aflæse tidligere data på harddisken :)
--
Mvh. Mikkel Westh
Ved direkte mail - fjern fælden.

---

Hej Mikkel

Mikkel Westh [2740] wrote:
>Mads <mads@iname.com> wrote:
>>Morten Reippuert Knudsen wrote:
>>>ufo <ufo.danmark@hotmail.com> wrote:
>>>en hammer + efterfølgende afbrænding kan anbefales hvis du er så
>>>sensitiv... ellers kan du skriver nuller i alle blokke mange gange.
>>
>>Det med at skrive nuller er ikke nødvendigvis smart.
>>Se f.eks. http://www.linux-kurser.dk/secure_del_peter_gutmann.html.
>>
>>Den intuitive forklaring er at mediet har en vis træghed. Normale
>>harddiske er designet til at være hurtige, derfor operere de med et
>>threshold hvor alle signaler under treshold'et bliver opfattet som 0.
>>Men med specielt udstyr kan data læses alligevel.
>>Hvis vi for eksemplets skyld antager at det analoge signal fra mediet
>>ligger mellem 0 og 1.
>>Hvis signalet x er mindre end 0.5 opfatter vi dette som 0-bit, hvis x >
>>0.5 opfattes dette som 1-bit.
>>Da mange medier skal påvirkes et stykke tid for at gå fra 1.0 til 0.0,
>>så påvirker mange enheder kun mediet i tid nok til at det f.eks. når ned
>>på 0.4. Hvis vi antager trægheden er lineær, så har vi sparet 40% skrive
>>tid.
>>Hvilket under normale omstændigheder gør os glade. Men ved sikker
>>sletning af data, er dette ikke godt.
>>Antag vi har følgende data set:
>>(0.0, 1.0, 1.0, 0.0)
>>Efter en overskrivning med nuller har vi nu:
>>(0.0, 0.4, 0.4, 0.0)
>
> God pointe. Men hvem siger nu også, at de nuller heri: 0.0, 0.4, 0.4,
> 0.0, nødvendigvis er 0,0? Hvis de er meget træge, kan det jo være de er
> 0,38, hvilket så besværliggør det lidt, hvis man nu har det specielle
> udstyr til rådighed og vil have indholdet ud.

Svjv. findes der ingen programmer, som almindelige konsumbrugere kan
købe, der vil være istand til at regenerere tidl. data. Det er så
specialiseret et værktøj, og det er hundehamrende dyrt. - Vi snakker i
området af 100.000kr.

Diskværktøj til både OS 9.x og OS X skriver nuller i grupper på 4 altså
i hexa-grupper - '0000 0000 0000 0000' osv.... Og med Diskværktøj til OS
X indstillet til 7x overskrivning, så rykkes hver overskrivning med 1
for hver overskrivning.

- Og ellers kan man jo blot formattere den i FAT 32 først og derefter i
HFS+, så er der garanteret ingen data, der kan regenereres.

> Bare en tanke, nu vi alligevel har taget det ud på et temmeligt ekstremt
> plan, når man tænker på, hvor lidt interessant det er for en normal
> køber at aflæse tidligere data på harddisken :)

Næ, men det troede Danske Bank heller ikke, da de forrige år solgte
deres gamle maskiner inkl. de orig. harddiske. De havde 'kun' valgt
'Slet data' i deres OS2 baserede system, - og et par kvikke hoveder
fandt masser af data med både kundeinfo, bankrådgiver rapporter og div.
Dankort koder... Det var noget af en storm i både radio og TV. Så de
valgte fremover at afmontere harddiske ved salg af gammelt udstyr og
smadre dem med en hammer...

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen wrote:
>
> Svjv. findes der ingen programmer, som almindelige konsumbrugere kan
> købe, der vil være istand til at regenerere tidl. data. Det er så
> specialiseret et værktøj, og det er hundehamrende dyrt. - Vi snakker i
> området af 100.000kr.
>
Du har ret, der kræves specielt hardware. Artiklen nævner US$1400 som
entry pris. Linket til kilden er desværre dødt, så det er svært at
afgøre validiteten af påstanden.

> Diskværktøj til både OS 9.x og OS X skriver nuller i grupper på 4 altså
> i hexa-grupper - '0000 0000 0000 0000' osv.... Og med Diskværktøj til OS
> X indstillet til 7x overskrivning, så rykkes hver overskrivning med 1
> for hver overskrivning.
>
Det skyldes sandsynligvis bare et forsøg på at undgå caching issues, og
evt. mindske effekten af at positionen på disken også er analog.

> - Og ellers kan man jo blot formattere den i FAT 32 først og derefter i
> HFS+, så er der garanteret ingen data, der kan regenereres.
>
En formatering med et givet fil system er i bedste fald at sammenligne
med en enkelt overskrivning.
Mange formateringer overskriver kun helt specifikke dele af disken, og
lader resten forblive uberørt.
Jeg vil mene at en 7x overskrivning alt andet lige giver bedre
beskyttelse, end en formatering.

---

Hej Mads

Mads wrote:
> Erik Richard Sørensen wrote:
>> Svjv. findes der ingen programmer, som almindelige konsumbrugere kan
>> købe, der vil være istand til at regenerere tidl. data. Det er så
>> specialiseret et værktøj, og det er hundehamrende dyrt. - Vi snakker i
>> området af 100.000kr.
>
> Du har ret, der kræves specielt hardware. Artiklen nævner US$1400 som
> entry pris. Linket til kilden er desværre dødt, så det er svært at
> afgøre validiteten af påstanden.

Tja... Jeg véd det fra en kunde, hvor jeg engang skulle forsøge at redde
en disk (IBM DeskStar 180GXP 250gb) med masser af video klip til brug på
en inaktiv CDROM til Undervisningsministeriet til undervisningsbrug. -
Den ville slet ikke spinne op. Vi fik derfor kontakt til et
specialfirma, hvor det lykkedes at redde diskens indhold med undtagelse
af nogle få billeder, som firmaet havde liggende på en anden disk, det
lykkedes mig at redde - faktisk med Norton Utilities + DiskWarrior - i
øvrigt en disk magen til...

Fra en snak med 'redningsfirmaet' fik jeg at vide, at det ville koste i
omegnen af 200.000 i anskaffelse af hardware + ca. 100-150.000kr. i
software. - Jeg overvejede på det tidspunkt at investere i noget
tilsvarende...

>> Diskværktøj til både OS 9.x og OS X skriver nuller i grupper på 4
>> altså i hexa-grupper - '0000 0000 0000 0000' osv.... Og med
>> Diskværktøj til OS X indstillet til 7x overskrivning, så rykkes hver
>> overskrivning med 1 for hver overskrivning.
>
> Det skyldes sandsynligvis bare et forsøg på at undgå caching issues, og
> evt. mindske effekten af at positionen på disken også er analog.

Højst sandsynlig... På OS 9.x bruger jeg altid Norton Wipe Info. - Her
kan jeg selv bestemme tabelstrukturen.

Std. står den til:
0A0E 0A0E 0A0E 0A0E
0A0E 0A0E 0A0E 0A0E
0A0E 0A0E 0A0E 0A0E
0A0E 0A0E 0A0E 0A0E

den har jeg så ændret til:
0000 0000 0000 0000
0 0000 0000 0000 000
00 0000 0000 0000 00
000 0000 0000 0000 0

- eller:
000A 000A 000A 000A
00A0 00A0 00A0 00A0
0A00 0A00 0A00 0A00
A000 A000 A000 A000

Norton DiskEditor til Windows og Norton DiskEditor 3 til Mac bruger
samme hexa struktur.

Jeg fik tippet fra en af 'redningsfirmaets' eksterper, som spurgte mig,
om jeg havde forsøgt at redde disken med Norton DiskEditor + Wipe Info.
For hvis jeg havde det, var data komplet slettede og kunne ikke
gendannes under nogen omstændigheder.

>> - Og ellers kan man jo blot formattere den i FAT 32 først og derefter
>> i HFS+, så er der garanteret ingen data, der kan regenereres.
>
> En formatering med et givet fil system er i bedste fald at sammenligne
> med en enkelt overskrivning.
> Mange formateringer overskriver kun helt specifikke dele af disken, og
> lader resten forblive uberørt.

Med mindre du bruger DiskEditor eller lign. hexa-baseret
sletningsstruktur...

> Jeg vil mene at en 7x overskrivning alt andet lige giver bedre
> beskyttelse, end en formatering.

Enig. For den alm. bruger er det nok.

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen wrote:
>
> Diskværktøj til både OS 9.x og OS X skriver nuller i grupper på 4 altså
> i hexa-grupper - '0000 0000 0000 0000' osv.... Og med Diskværktøj til OS
> X indstillet til 7x overskrivning, så rykkes hver overskrivning med 1
> for hver overskrivning.
>
Er der nogen der har nogle links der beskriver detajlerne i Disk
Utility's secure erase metoder?
Jeg tjekkede lige hjælpe filen. Og den siger bare at den er i compliance
med DoD's 5220.22-M. Men når man læser 5220.22-M så operere den med
flere grader af sikker sletning.
[http://www.usaid.gov/policy/ads/500/d522022m.pdf, s. 57]
Den simple er overskrivning med et bestemt tegn (f.eks. 0x00). Den mere
avancerede kræver mindst 3 overskrivninger hvor første overskrivning
sker med 0x00, anden med 0xFF samt tredje med et tilfældigt tegn.

Det at secure erase vil overskrive et ulige antal gange, kan tyde på at
den laver den sidste løsning. Men det er bare spekulationer.

---

Hej Mads

Mads wrote:
> Erik Richard Sørensen wrote:
>> Diskværktøj til både OS 9.x og OS X skriver nuller i grupper på 4
>> altså i hexa-grupper - '0000 0000 0000 0000' osv.... Og med
>> Diskværktøj til OS X indstillet til 7x overskrivning, så rykkes hver
>> overskrivning med 1 for hver overskrivning.
>
> Er der nogen der har nogle links der beskriver detajlerne i Disk
> Utility's secure erase metoder?
> Jeg tjekkede lige hjælpe filen. Og den siger bare at den er i compliance
> med DoD's 5220.22-M. Men når man læser 5220.22-M så operere den med
> flere grader af sikker sletning.
> [http://www.usaid.gov/policy/ads/500/d522022m.pdf, s. 57]
> Den simple er overskrivning med et bestemt tegn (f.eks. 0x00). Den mere
> avancerede kræver mindst 3 overskrivninger hvor første overskrivning
> sker med 0x00, anden med 0xFF samt tredje med et tilfældigt tegn.

Hovedsagen er, at man bruger hexa angivelser.

> Det at secure erase vil overskrive et ulige antal gange, kan tyde på at
> den laver den sidste løsning. Men det er bare spekulationer.

Hm, Diskværktøj i 10.4.x har udover 1x og 7x også en mere jeg ikke lige
kan huske (korer 10.3.9 lige nu), mens 10.3.x kun har 1x og 8x
overskrivning.

Som du kan se i mit andet svar, så fik jeg fra 'redningsfirmaet' at
vide, at det vigtigste er, at der er 4 grupper i 4 rækker i
hexa-gruppen. Men det kunne da godt tyde på, at der er noget om snakken
med at ændre i gruppering - jvf. den tabelopsætning, jeg viser...

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Hej Erik

Erik Richard Sørensen wrote:
>
> Hovedsagen er, at man bruger hexa angivelser.
>
Hvad mener du med "hexa angivelser"?

>> Det at secure erase vil overskrive et ulige antal gange, kan tyde på
>> at den laver den sidste løsning. Men det er bare spekulationer.
>
> Hm, Diskværktøj i 10.4.x har udover 1x og 7x også en mere jeg ikke lige
> kan huske (korer 10.3.9 lige nu), mens 10.3.x kun har 1x og 8x
> overskrivning.
>
10.4.x Har 1, 7 og 35 overskrivninger.

Venlig hilsen
Mads

---

Mads wrote:
> Erik Richard Sørensen wrote:
>> Hovedsagen er, at man bruger hexa angivelser.
>
> Hvad mener du med "hexa angivelser"?

Det som jeg angiver i grupperne - altså 4 kodetal i 4 grupper i 4
kolonner. - Jeg véd godt, at OS X viser det lidt anderledes, men åbner
du fx. et cocoa eller parbon program i et hexedit værktøj, vil de altid
optræde i 4x4.

>>> Det at secure erase vil overskrive et ulige antal gange, kan tyde på
>>> at den laver den sidste løsning. Men det er bare spekulationer.
>>
>>
>> Hm, Diskværktøj i 10.4.x har udover 1x og 7x også en mere jeg ikke
>> lige kan huske (korer 10.3.9 lige nu), mens 10.3.x kun har 1x og 8x
>> overskrivning.
>
> 10.4.x Har 1, 7 og 35 overskrivninger.

Der var det...
>
> Venlig hilsen
> Mads
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen wrote:
>
>
> Mads wrote:
>> Erik Richard Sørensen wrote:
>>> Hovedsagen er, at man bruger hexa angivelser.
>>
>> Hvad mener du med "hexa angivelser"?
>
> Det som jeg angiver i grupperne - altså 4 kodetal i 4 grupper i 4
> kolonner. - Jeg véd godt, at OS X viser det lidt anderledes, men åbner
> du fx. et cocoa eller parbon program i et hexedit værktøj, vil de altid
> optræde i 4x4.
>
Forstår ikke lige hvor sikkerheden kommer i 4x4 matrix med 16 bit
indgange, som ikke er alle mulige andre matriser?

Venlig hilsen
Mads

---

Hej Mads

Hvis du kun bruger nuller, er det en ganske alm. overskrivning. men hvis
du bruger et bogstav eller tal, rykket 1 trin, vil du i overskrivningen
overskrive alt _forskubbet_

Reelt vil en grafisk tabel så se sådan ud
000A 000A 000A 000A
00A0 00A0 00A0 00A0
0A00 0A00 0A00 0A00
A000 A000 A000 A000

Dvs., at overskrivningen bliver asymetrisk. - Jeg har ingen tabelformel
over hvordan fx. en Linux formattering vil se ud. Tabelformlen har jeg
fra en gammel Norton DiskEditor manual - svjh. en Norton Utilities 2.0.
mvh. Erik Richard

Mads wrote:
> Forstår ikke lige hvor sikkerheden kommer i 4x4 matrix med 16 bit
> indgange, som ikke er alle mulige andre matriser?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen wrote:
> Hej Mads
>
> Hvis du kun bruger nuller, er det en ganske alm. overskrivning. men hvis
> du bruger et bogstav eller tal, rykket 1 trin, vil du i overskrivningen
> overskrive alt _forskubbet_
>
> Reelt vil en grafisk tabel så se sådan ud
> 000A 000A 000A 000A
> 00A0 00A0 00A0 00A0
> 0A00 0A00 0A00 0A00
> A000 A000 A000 A000
>
> Dvs., at overskrivningen bliver asymetrisk.
>

Tror vi har samme grund idé, nemlig at skrive noget forskelligt ved hver
overskrivning.
Vil dog mene at tilfældigt data, og DoD's 5220.22-M's metode med at
overskrive med komplimentet vil være bedre. Din metode, med 0x000A vil
gøre at halvdelen af bits'ene på disken kun overskrives med nul:
0x000A = 0000000000001010.b
0x00A0 = 0000000010100000.b
0x0A00 = 0000101000000000.b
0xA000 = 1010000000000000.b

Komplimentet til 0x000A er derimod 0xFFF5. Som vil gøre at alle bits
bliver flippet mindst én gang:
0x000A = 0000000000001010.b
0xFFF5 = 1111111111110101.b

Man skal dog tage hensyn til at mange harddiske laver forskellige former
for run length encoding eller lignende ting, som gør det hele noget mere
kompliceret.

Venlig hilsen
Mads

---

Hej Mads

Mads wrote:
> Erik Richard Sørensen wrote:
>> Hvis du kun bruger nuller, er det en ganske alm. overskrivning. men
>> hvis du bruger et bogstav eller tal, rykket 1 trin, vil du i
>> overskrivningen overskrive alt _forskubbet_
>>
>> Reelt vil en grafisk tabel så se sådan ud
>> 000A 000A 000A 000A
>> 00A0 00A0 00A0 00A0
>> 0A00 0A00 0A00 0A00
>> A000 A000 A000 A000
>>
>> Dvs., at overskrivningen bliver asymetrisk.
>
> Tror vi har samme grund idé, nemlig at skrive noget forskelligt ved hver
> overskrivning.

Det tror jeg også.

> Vil dog mene at tilfældigt data, og DoD's 5220.22-M's metode med at
> overskrive med komplimentet vil være bedre. Din metode, med 0x000A vil
> gøre at halvdelen af bits'ene på disken kun overskrives med nul:
> 0x000A = 0000000000001010.b
> 0x00A0 = 0000000010100000.b
> 0x0A00 = 0000101000000000.b
> 0xA000 = 1010000000000000.b
>
> Komplimentet til 0x000A er derimod 0xFFF5. Som vil gøre at alle bits
> bliver flippet mindst én gang:
> 0x000A = 0000000000001010.b
> 0xFFF5 = 1111111111110101.b

Nu jeg ser det på tryk igen, kan jeg godt huske, at norton manualen
bruger den som alternativ...

> Man skal dog tage hensyn til at mange harddiske laver forskellige former
> for run length encoding eller lignende ting, som gør det hele noget mere
> kompliceret.

Og det har vel også lidt at gøre med, hvilket format, der formatteres i
- HFS, HFS+, DOS/FAT32, UNIX osv..

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Mikkel Westh [2740] <mikkelw@MUSEFAELDEgmail.com> wrote:

> Mads <mads@iname.com> wrote:
>
> > Morten Reippuert Knudsen wrote:
> > > ufo <ufo.danmark@hotmail.com> wrote:
> > >
> > > en hammer + efterfølgende afbrænding kan anbefales hvis du er så
> > > sensitiv... ellers kan du skriver nuller i alle blokke mange gange.
> > >
> > Det med at skrive nuller er ikke nødvendigvis smart.
> > Se f.eks. http://www.linux-kurser.dk/secure_del_peter_gutmann.html.
> >
> > Den intuitive forklaring er at mediet har en vis træghed. Normale
> > harddiske er designet til at være hurtige, derfor operere de med et
> > threshold hvor alle signaler under treshold'et bliver opfattet som 0.
> > Men med specielt udstyr kan data læses alligevel.
> > Hvis vi for eksemplets skyld antager at det analoge signal fra mediet
> > ligger mellem 0 og 1.
> > Hvis signalet x er mindre end 0.5 opfatter vi dette som 0-bit, hvis x >
> > 0.5 opfattes dette som 1-bit.
> > Da mange medier skal påvirkes et stykke tid for at gå fra 1.0 til 0.0,
> > så påvirker mange enheder kun mediet i tid nok til at det f.eks. når ned
> > på 0.4. Hvis vi antager trægheden er lineær, så har vi sparet 40% skrive
> > tid.
> > Hvilket under normale omstændigheder gør os glade. Men ved sikker
> > sletning af data, er dette ikke godt.
> > Antag vi har følgende data set:
> > (0.0, 1.0, 1.0, 0.0)
> > Efter en overskrivning med nuller har vi nu:
> > (0.0, 0.4, 0.4, 0.0)
>
> God pointe. Men hvem siger nu også, at de nuller heri: 0.0, 0.4, 0.4,
> 0.0, nødvendigvis er 0,0? Hvis de er meget træge, kan det jo være de er
> 0,38, hvilket så besværliggør det lidt, hvis man nu har det specielle
> udstyr til rådighed og vil have indholdet ud.

Diskværktøj har mulighed for sikker sletning.

--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark

---

Mikkel Westh [2740] wrote:
> Mads <mads@iname.com> wrote:
>
>> Morten Reippuert Knudsen wrote:
>>> ufo <ufo.danmark@hotmail.com> wrote:
>>>
>>> en hammer + efterfølgende afbrænding kan anbefales hvis du er så
>>> sensitiv... ellers kan du skriver nuller i alle blokke mange gange.
>>>
>> Det med at skrive nuller er ikke nødvendigvis smart.
>> Se f.eks. http://www.linux-kurser.dk/secure_del_peter_gutmann.html.
>>
>> Den intuitive forklaring er at mediet har en vis træghed. Normale
>> harddiske er designet til at være hurtige, derfor operere de med et
>> threshold hvor alle signaler under treshold'et bliver opfattet som 0.
>> Men med specielt udstyr kan data læses alligevel.
>> Hvis vi for eksemplets skyld antager at det analoge signal fra mediet
>> ligger mellem 0 og 1.
>> Hvis signalet x er mindre end 0.5 opfatter vi dette som 0-bit, hvis x >
>> 0.5 opfattes dette som 1-bit.
>> Da mange medier skal påvirkes et stykke tid for at gå fra 1.0 til 0.0,
>> så påvirker mange enheder kun mediet i tid nok til at det f.eks. når ned
>> på 0.4. Hvis vi antager trægheden er lineær, så har vi sparet 40% skrive
>> tid.
>> Hvilket under normale omstændigheder gør os glade. Men ved sikker
>> sletning af data, er dette ikke godt.
>> Antag vi har følgende data set:
>> (0.0, 1.0, 1.0, 0.0)
>> Efter en overskrivning med nuller har vi nu:
>> (0.0, 0.4, 0.4, 0.0)
>
> God pointe. Men hvem siger nu også, at de nuller heri: 0.0, 0.4, 0.4,
> 0.0, nødvendigvis er 0,0? Hvis de er meget træge, kan det jo være de er
> 0,38, hvilket så besværliggør det lidt, hvis man nu har det specielle
> udstyr til rådighed og vil have indholdet ud.
>
Ja, der sker en sammenblanding af flere "lag" historisk data.
Man kan sammenligne det med en arkæolog der skraber et lag jord væk af
gangen.
Det er derfor at den artikel jeg gav et link til anbefaler at man
overskriver med tilfældigt data, blandet med en række specielt designet
mønstre.

> Bare en tanke, nu vi alligevel har taget det ud på et temmeligt ekstremt
> plan, når man tænker på, hvor lidt interessant det er for en normal
> køber at aflæse tidligere data på harddisken :)
>
Ja, det er nok kun noget man skal tænke på hvis man vil sælge en
harddisk som indeholder Osama bin Laden's adresse el. lign...