UNIX-haj-Fu

Her er en lille drilleopgave til UNIX hajerne:

Antag et UNIX system på niveau med UNIX v7

Opgaven er at lave en sektor-for-sektor sikkerhedskopi af en 20MB harddisk, der kun er tilgængelig som raw-device.

Du har kun de programmer der ligger på en installationsdiskette: cat, cmp, cp, dd, echo, ed, grep, od, sh, i særdeleshed har du ingen C-compiler.

Du har en seriel konsol, max 9600 bps, der kan sættes i raw mode.

Du har en parallel printer port der kan overføre ca. 1700 bytes per sekund, men den oversætter NL til CRNL og TAB til spaces.

Desuden kan printerporten kun åbnes en gang, bagefter kræver det et reboot (= 1 minut)

I den anden ende af serielport og printerporten har du en laptop med en moderne UNIX.

Det tager ca. 2 sekunder at starte en kommando fordi det hele kører på floppydisk.

Pipes er langsomme, fordi de bruger disketten som mellemlager (har ikke målt hastigheden, men "dd ... | od -x" er klart langsommere end serielporten).

od(1) programmet læser 16 bytes af gangen og kan derfor ikke direkte læse en raw-device.

Hvad gør en rigtig UNIX haj ?

phk

Kommentarer (53)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Klaus Ellegaard

Jeg har fornøjelsen af at have en go', gammel Commodore Amiga 3000UX, der kommer med AmigaUNIX (aka AMIX). Og som stadig virker - og fint kan snakke IPv4... omend den næppe er sikkerhedsmæssig forsvarlig at hælde direkte på nettet.

At rode med den er rigeligt til mig, men ja, man bliver vældig god til at finde kreative løsninger med et begrænset kommandoapparat til rådighed. Det minder mig næsten om de gode, gamle SunOS 4.1-dage. Som i øvrigt ikke var SÅ vældigt gode igen :-)

Det er i øvrigt fantastisk at se, hvor meget UNIX der egentlig virker på sådan en fin 25 MHz 68030 med 18 MB RAM. Og endda ganske hurtigt.

Held og lykke med dit gamle hardware :-)

  • 1
  • 0
#4 Peter Makholm Blogger

Spørgsmålet er vel hvor du vil cat'e dit rawdevice hen og det er nok her hunden ligger begravet. Min første indskyldede var at det da bare var at dd'e harddisken til seriel porten. Men når begynder Poul-Henning at snakke om 'dd ... | od -x' er det nok ikke så let.

Så hvis pointen er at vores kommunikation skal være 7bit ren og vi ikke må bruge pipes, så rækker min unix-fu ikke længere. Så jeg er holdt op med at gætte. (Efter at jeg tjekkede dd(1) for om conv argumented kunne hjælpe os på magisk vis)

  • 0
  • 0
#6 Poul-Henning Kamp Blogger

@Kristian: "cat /dev/rawdevice" virker ikke, cat på denne UNIX læser tilsyneladende et tegn ad gangen. Du er velkommen til manualsider hvis du kan finde dem: Coherent 0.7.3

@Thomas: Kabelproblemer er løst, men vi ved ikke om vi har flowcontrol på serielporten.

@Peter: dd til konsolporten er den direkte vej, men der mangler en eller anden form for fejldetektering synes jeg.

@Ole: Det er ikke en mulighed, formatet er tilsyneladende unikt for denne maskine (CBM900)

  • 0
  • 0
#9 Peter Makholm Blogger

@Peter: dd til konsolporten er den direkte vej, men der mangler en eller anden form for fejldetektering synes jeg.

Og du vil også helst begrænse antallet af læsninger, så harddisken ikke dør yderligere?

Ellers ville jeg nok overveje om der ikke er fejldetektering nok i bare at gøre det tre gange og så sammenligne. Det tager 2 timer, hvis jeg lige regner rigtigt. Så en Rigtig(tm) løsning skal være hurtigere at implementere end det.

Men jeg har ingen praktisk erfaring med den slags begrænsede miljøer.

  • 0
  • 0
#11 Jan Gundtofte-Bruun

Som jeg læser artiklen og kommentarer var jeg først ude i en Ole-løsning, dernæst en Steffen-løsning, som vel nærmest er en Chris Fenton-løsning.

Det springende punkt er, hvor meget vil I gøre for at tilgå disse data? Hvad er data værd? Hvad er hardware værd? (På sin vis ubetaleligt, I know...) Med "værd" mener jeg naturligvis ikke "rede penge" men snarere tid, hacking, og for hardwarens del evt. indgriben a la teknisk forandring.

Links: http://chrisfenton.com/cray-1-digital-archeology/ http://www.archive.org/details/2011-cdc-disk-archaeology-fenton Disse forudsætter naturligvis en vis portion mod, tid, og ikke mindst kendskab til diskens bit-allokering, filsystem, etc.

  • 1
  • 0
#14 Jan Gundtofte-Bruun

Men de par timer er vel ikke afgørende; så vidt jeg har forstået er det mere et spørgsmål om tvivlsom fejldetektering (ECC)?

...så du risikerer at der ikke ligger andet end en gammel Space War hi-score liste? Det gør det sværere at estimere "passende" indsats...

  • 0
  • 0
#15 Casper Bang

Hvad fylder hver sektor og hvor mange er der? Kan du dumpe x antal sektorer på floppy og kopiere disse ind via diskettedrev/station? Det lyder næsten som om du har forsøgt dette, men at det er for langsommelig en process?

  • 0
  • 0
#24 Olav M.j. Christiansen Blogger

Er det slet ikke muligt at lave et hex dump og så køre det ud via den serielle konsol eller til printeren? Godt tager det længere tid, men det er nok lettere at fejlsikre og så gør det ikke så meget med f.eks. linjeskift. Ellers må du igang med at fremskaffe/-stille en c-compiler eller en assembler.

  • 0
  • 0
#26 Palle Simonsen

Noget Coherent source og en manual kan stadig findes

http://unixarchive.tliquest.net/Other/Coherent/kernelsource/

http://www.tenox.tc/docs/coherent_manual.pdf

dd virker som en standard dd inklusive stop på IO fejl.

Coherent brugte COFF format, men kan I få CBM 900 op at køre og har I mulighed for selv at lave disketter? (og så er der lige den med COFF kompatibilitet og held)

Man kan finde Allan Cornish' navn nogle steder i kernesovsen (og i manualen), så han kan måske findes?

  • 2
  • 0
#29 Christian E. Lysel

Er der forskel på nedestående? (rtty referere til raw tty, hvis en sådan findes ... skulle gerne starte med bogstavet r):

cat /dev/rawdisk

cat /dev/rawdisk > /dev/rtty

cat -u /dev/rawdisk

cp /dev/rawdisk /dev/tty

ar rv /terminal /rawdisk

tar c /terminal /rawdisk

compress < /rawdevice

uuencode < /rawdevice

kermit sa /dev/rawdisk diskkopi

Hvad siger stty?

Hvor slemt medtaget er diskene? /etc/badscan -v /rawdisk size /etc/badscan -v /rawdisk /ikkerawdiskx (kan være destruktivt, manualen bruger termologien "scans a disk for bad blocks" ... jeg antager den ikke laver skrivninger)

Er der for mange fejl, kan awk parse uddata fra badscan, og kalde dd så fejl læsninger undgåes.

lpskip, kan den ikke bruges til at genskrive til printeren uden genstart?

  • 0
  • 0
#31 Poul-Henning Kamp Blogger

Se grunden til det her blogindlæg var en ide jeg havde fået, men desværre holdt den kun 15/16 vand.

Bo er inde på samme ide med "dd conv=ascii", men istedet for "ascii" ville jeg bruge "swab" (= swap bytes).

Det virker perfekt i 15/16 del af de mulige tilfælde, hvis man gider skrive den sindsygt komplexe kode til at sammenligne de to dumps og gennemskue hvor der var TABs og hvor mange spaces de var lavet om til.

Men det virker jo selvsagt ikke i den 1/16 hvor en TAB bliver til en enkelt SP i både den ene og den anden kopi.

Æv Bæv, tilbage til start, uden at indkassere 20MB.

Det siger naturligvis sig selv at jeg først opdagede denne svaghed, da jeg havde dumpet hele disken med conv=swab.

For ikke at spilde aftenen totalt startede jeg en dd if=/dev/rhdall0 | od -x > /dev/lp og til min store glæde opdagede jeg at jeg fik ca. 1400 Bps igennem, fordi alle de sektorer på floppyen der blev brugt til pipen havnede i samme cylinder.

Men ingen glæde varer som bekendt ved.

Der kom læsefejl på floppyen, men efter nogle retries kom den videre. Problemet er bare at jeg ved at checksummen på det der skod-format de bruger på floppyen er en simpel en-byte sum, så jeg stoler ikke synderligt på at de 3MB jeg fik hevet igennem er OK.

Man kan ikke sige andet om den CBM900 end at den gør brav modstand.

Ideen med at sniffe med på harddisk-controlleren har jeg overvejet, data passerer, meget bekvemt, en 8-bit parallel bus, men desværre kender jeg ikke handshake på den bus i alle detaljer og da hastigheden er omkring 500kB/s er det heller ikke helt trivielt at fange og få experedet data videre, når man ikke har muligheden for at lave flow-control.

Det med at få lagt et program på floppyen ville kræve at jeg skrev en simulator der kunne køre C-compileren. Formodentlig kunne man nøjes med at simulere userland og emulere systemkaldene, men det er stadig en bid mere arbejde end jeg har lyst til lige nu.

Endelig er der muligheden for at fylde et maskinkodeprogram i RAM via boot-rom'ens debugger og det er nok den vej jeg hælder mest lige for tiden.

  • 1
  • 0
#34 Bo Normann Jensen

Men i tilfældet med to på hinanden følgende TABS eller LF vil conv=swab ikke virke. EBCDIC -> ASCII vil konvertere 0x09 -> 0x8d og 0x0a -> 0x8e.

!/bin/bash

echo -ne "0123456789\n\t\t\t " > diskdatsim.txt echo -ne "Raw :" od -t x1 diskdatsim.txt dd if=diskdatsim.txt of=ascii_dump.txt conv=ascii echo -ne "Ascii:" od -t x1 ascii_dump.txt dd if=diskdatsim.txt of=swap_dump.txt conv=swab echo -ne "Swap :" od -t x1 swap_dump.txt

Raw :0000000 30 31 32 33 34 35 36 37 38 39 0a 09 09 09 20 20 0000020 20 20 20 20 20 20 0000026 0+1 records in 0+1 records out 22 bytes (22 B) copied, 5.7184e-05 s, 385 kB/s Ascii:0000000 90 91 16 93 94 95 96 04 98 99 8e 8d 8d 8d 80 80 0000020 80 80 80 80 80 80 0000026 0+1 records in 0+1 records out 22 bytes (22 B) copied, 5.6859e-05 s, 387 kB/s Swap :0000000 31 30 33 32 35 34 37 36 39 38 09 0a 09 09 20 20 0000020 20 20 20 20 20 20 0000026

  • 0
  • 0
#37 Casper Bang

Ideen med at sniffe med på harddisk-controlleren har jeg overvejet, data passerer, meget bekvemt, en 8-bit parallel bus, men desværre kender jeg ikke handshake på den bus i alle detaljer og da hastigheden er omkring 500kB/s er det heller ikke helt trivielt at fange og få experedet data videre, når man ikke har muligheden for at lave flow-control.

Moderne oscilloskoper med logik probes, har dog mulighed for at logge over tid og til en fil. 500Kb/s på en 8bit bus, svarer så til 64KHz. Med lidt god vilje kan man så benytte rising/lowering edges til at aligne efter i et post-processing job. Det er nok ikke nemmeste løsning, men tilgængæld kan du vælge at crowdsource post-processing jobbet.

  • 1
  • 0
#38 Jacob Pind

Commodore har nok brugt 100tpi drev i dem som i de senere 8050,8250 drev som blev brugt på 8000 serien, de ligger tidmæssig op ad hinanden. Er ikke så mange maskiner som brugt de 100tpi drev, så det bliver ikke meget nemmer af at få det ud på disketter, og med en anden sector size end commodore dos i de drev, tvivler jeg på mine drev kunne læse dem, andet man smed ny kode i et par roms til dem.

  • 0
  • 0
#39 Lasse Makholm

hexdump en klump af disken til konsol, webcam på laptop knipser et billede og kører det en tur gennem OCR og gemmer. Synkronisering af skærm-dump og kamera gennem seriel port. Doable?

  • 2
  • 1
#45 Poul-Henning Kamp Blogger

Men i tilfældet med to på hinanden følgende TABS eller LF vil conv=swab ikke virke. EBCDIC -> ASCII vil konvertere 0x09 -> 0x8d og 0x0a -> 0x8e.

Så vidt jeg husker taber de "gamle" conv={ascii,ebcdic} information, ingen af dem er 1:1 mapninger, men du har ret at man burde kunne identificere TAB karakterne på den måde. (CR er ikke noget problem, s/CRNL/NL/ klarer dem.)

  • 0
  • 0
#46 Casper Bang

hexdump en klump af disken til konsol, webcam på laptop knipser et billede og kører det en tur gennem OCR og gemmer. Synkronisering af skærm-dump og kamera gennem seriel port. Doable?

Hvis PHK alligevel har tænkt over en maskinekode løsning, så kunne han måske generere ascii QR koder på skærmen. Med 21 vertikale linier til rådighed, vil han med 7% redundans, AFAIK kunne gemme ca. 16byte. på en monokron skærm. Ved at benytte rotation af QR markørene som flow kontrol, og med 10 billeder i sekundet, vil det tage ca. 1½ døgn at få de 20MB ud.

Om det kan gøres i realtid er nok tvivlsomt, selv om det bestemt vil være nemmere og mere fejl-frit end ASCII/HEX OCR post-processing.

  • 3
  • 0
#47 Eskild Nielsen

I gamle dage, når man skulle overføre binære filer over serrielporten, så brugte man at uuencode en fil en mapning, som konverterede 2 oktetter til tre printable ascii tegn

Døde, da alle fik mail med 8 bit integrity

(der fandtes vistnok også en version der kunne overføres på 6 bit teletype)

  • 0
  • 0
Log ind eller Opret konto for at kommentere