Dette indlæg er alene udtryk for skribentens egen holdning.

Uidentificeret Programmeret Object

57 kommentarer.  Hop til debatten
Blogindlæg13. januar 2012 kl. 09:14
errorÆldre end 30 dage

Når man sådan går rundt ude i arkivet i datamuseum.dk, kan man godt få sjove ideer.

En af dem jeg fik var inspireret af nyheden om at i fremtiden skal piloter have alt flyets dokumentation på en iPad, frem for i store besværlige ringbind.

Det er jo et på alle måder fornuftigt og logisk tiltag.

Men præmissen for noget af vores bedste Science Fiction er jo netop at en flyvende tallerken lander og at vi gennemskuer "Faster Than Light" transport fra deres teknologi.

Artiklen fortsætter efter annoncen

Hvor nemt er det lige hvis alle manualerne til UFO'en ligger på en iPad, beskyttet af DRM ?

Men hvad med computerne i UFO'en, kan vi lære noget af dem ?

Vis hvad i duer til...

phk

57 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
57
18. januar 2012 kl. 00:13

Kan nogen ikke snart få løst den kode. Nu har manden rodet med den tre aftener i træk :)

56
17. januar 2012 kl. 21:19

Per: Sikker på det er jumps? Jeg kunne godt have det mistænkt for at være moves. Hvis vi ser på de bytes der følger efter 0xc8, får jeg følgende lister:

Set ikke sikker. Det ligner moves, og initialisering vil også give mening her. Martin er også langt foran nu.

Memory-mapped I/O og banking af memory og ROM var ikke ualmindeligt før PC'en, som regel fordi man var klemt på adressebussen. Men havde man plads nok på adressebussen, så kunne man bruge A14 og A15 til direkte at vælge chip, og derved spare gates til deodning af adressen.

8-bits ROM på en 16-bits maskine var også almindeligt (hvis jeg husker rigtigt). Så blev et word læst en byte ad gangen.

Det er alt for længe siden jeg har rodet med kode på dette niveau, så jeg håber mest på at inspirere jer andre.

46
16. januar 2012 kl. 21:23

Per: Sikker på det er jumps? Jeg kunne godt have det mistænkt for at være moves. Hvis vi ser på de bytes der følger efter 0xc8, får jeg følgende lister:

http://www.sprogklog.dk/uco/move_second_byte.txthttp://www.sprogklog.dk/uco/move_four_bytes.txt

Givet at vi har c81x, c82x og c83x, med x fra 0 op til 8 ligner det, at der gemmer sig et registernummer i nederste del af anden byte og måske noget af tredje... tør nogen gætte på antallet af registre? 8, 16, 32?

Værre er det med resten af kombinationerne, altså c8yx hvor y>3.

44
16. januar 2012 kl. 19:50

Björn: Inden du fordyber dig alt for meget, så skriver PHK i sin engelske artikel at Google er "absolutely clueless" mht den pågældende maskine. Så det er nok ikke en PIC fra 2002...

Martin Zacho: Du skal nok til at pille med bitfelter... hvis du kun samler 14 bits op, så bliver tallene naturligvis ikke større end 16383!

Jeg har skrevet nogle småprogrammer til at søge efter 14-bit strenge (eller strenge af vilkårlig længde for så vidt):

http://www.sprogklog.dk/uco/uco_buf.py

Den kræver et library, bitarray - hvis du kører Debian Linux er det nok at sige apt-get install python-bitarray. Ved hjælp af værktøjet har jeg prøvet at søge efter instruktioner, der refererer til bufferområderne:

http://www.sprogklog.dk/uco/search_buffers.txt

Den skal læses sådan at tallet inden skråstregen er byte-offset for et match, dernæst følger den bit (læst fra venstre) hvor bitfeltet starter. Jeg bemærker nogle gengangere... men modtager gerne hjælp til at dekode instruktionsformatet. Anyway, jeg roder videre.

41
16. januar 2012 kl. 18:44

Tænk jer ordentligt om...

Hvis det havde været BIOS-ROM'en fra en PC, ville den have haft ca. 20 addressebits, hvad siger det om CPU'ens antal af addressebits ?

45
16. januar 2012 kl. 21:05

At adresser fra 0x0000 til 0x3fff er mulige, når der er 14.

I ROM'en. Men CPU'en kan godt have 16 eller mange flere adressebits.

Der er tilsyneladende en jump for hver 4 bytes. Det kunne være et hint om 16 eller måske endda 32 bit data.

50
16. januar 2012 kl. 21:47

Det kunne jo være at man også havde memory-mapped RAM og I/O enheder ?

53
16. januar 2012 kl. 22:19

...men hvorfor skal 0xC8 være en jmp ? Dette er ikke en applikation som loades af et OS, denne kode kan i teorien starte på 0000 og køre lige ud ad landevejen og så er 0xC8 sandsynligvis en MOV.

54
16. januar 2012 kl. 22:29

Maciej - Korrekt. Har set på det samme - og 0x3184 og deromkring ligner også noget ram eller lign. 0x5f, så det kunne fint være opsætning, initialisering eller lign.

Krævede lige en editor med to kopier, så man lettere kunne se opcoden og det pågældende adresseområde på en gang.

Martin

55
16. januar 2012 kl. 23:12

Desuden behøver dekodningen jo ikke være fuldstændig, så spejlinger kan forekomme... Noget af et puslespil ;-)

Antager vi 0xc8 er en LD (gammel z80 haj ;-), så ser den første del ud som følger:

  1. 0000 c8 37 84 98 LD 0x3784, 0x98
  2. 0004 c8 31 80 10 LD 0x3180, 0x10
  3. 0008 c8 32 80 14 LD 0x3280, 0x14
  4. 000c c8 33 80 18 LD 0x3380, 0x18
  5. 0010 c8 34 80 0a LD 0x3490, 0x0a
  6. 0014 c8 35 80 16 LD 0x3580, 0x16
  7. 0018 c8 36 80 1c LD 0x3680, 0x1c
  8. 001c c8 37 80 08 LD 0x3780, 0x08
  9. 0020 c8 37 85 78 LD 0x3785, 0x78
  10. 0024 c8 31 86 f9 LD 0x3186, 0xf9
  11. 0028 c8 20 c9 a3 LD 0x20c9, 0xa3
Det virker lidt påfaldende de spring i adresserne. Måske der er tale om lsb msb, hvor adressen så er 0bxyaa aaaa og x og måske y bruges til i/o eller RAM adressering. Understøttes måske lidt af de mange c8 xx c9 sekvenser... En masse gætværk GG og så har vi ikke engang taget hul på indirekte adressering.

Sengen kalder - hygge, Martin.

37
16. januar 2012 kl. 09:57

14 bit adressebus og 16k ROM levner ikke plads til RAM. Så enten kan UPO'en klare sig uden RAM eller den har RAM (eller nok registre) på CPUen. Harvard arkitektur?

34
15. januar 2012 kl. 20:33

Det faldt mig ind senere: Det er vel de der bufferområder (0x5F), der fremtræder sådan når man betragter dem i grupper á 14 bits. Så passer det med, at der er 8 forskellige steder at starte inde i en byte (bit 0-7) og så 14 bits frem.

32
15. januar 2012 kl. 13:13

Jeg har forsøgt at lave en frekvensanalyse på 14-bit strenge i ROM'en: http://pastebin.com/Zsz10UwbDer er relativt få topscorere: 3ebe, 3afa, 3d7d, 35f5, 2beb, 2faf, 17d7, 1f5f har hver især cirka 2800 forekomster. Derefter har de næste 300 forekomster eller mindre.

28
Indsendt af Thomas Hansen (ikke efterprøvet) den lør, 01/14/2012 - 14:26

Det ER ikke muligt at bevæge sig hurtigere end lyset ! Hvis man bevæger sig hurtigere end lyset, så opstår den situation, som kan observeres i forbindelse ed sorte huller.

Men lad mig holde mig til hypotesen, om man kan lære noget ud af Alien Teknik. Hvis der skulle ske en nedstyrtning af en UFO, vil det betyde at deres tekniske formåen vil overgå vores, langt ud over hvad vi kan forestille os.

De analyser vi kan foretage, vil skulle beskrive noget vi ikke forstår, altså skal analysemetoderne først udvikles, som interface mellem den fremmede teknik og vores opfattelse. Her er det vigtigt at forstå, at begrænsningen ligger i vores opfattelse af det vi omgiver os med. Vores hjerne, skal omkodes til at forstå hvad det er vi observerer. Det er der foretaget nogen interessante antropologiske eksperimenter med, hvor man har ladet mennesker beskrive ting, som befinder sig på afstand, selv om de mennesker aldrig har set noget længere end nogen få hundrede meter væk. Så bliver en ko på afstand til et lille dyr, for ellers passer det ikke ind i personens verdensbillede. ( En person der altid har levet i tæt jungle )

Alene, at vi normalt opfatter et punkt i universet som et geometrisk stedpunkt, beskrevet ved mindst 3 koordinater, selv om vi tilsvarende ved at denne opfattelse er forkert, da tid ikke indgår men skal indgå, kan beskrive hvor svært vi vil have ved at forstå Alien teknik. IT i vores forstand, vil sandsynligvis ikke indgå i en alien teknik, nødvendigvis må vi anse IT som et skridt på vejen i en udviklingsproces, helt som alle andre store tekniske fremstød.

24
14. januar 2012 kl. 10:53

...som er meget forsk. fra nutidens maskiner ellers ville det ikke være en "alien"-teknologi. 36-bit, 18-bit eller 12-bit måske, der var mange "sære" maskiner i 60'erne og de overlevede forbavsende længe.

26
14. januar 2012 kl. 12:13

Givet at det totale antal bits er 2^17 og at frekvensanalysen af 8 bit sekvenser giver en stærkt heterogen fordeling er jeg nu ret overbevist om at vi har med en maskine at gøre som arbejder med 4 eller 8 bit blokke.

27
14. januar 2012 kl. 12:33

Det går op for mig at jeg ikke explicit har skrevet noget om hvorledes ROM'en er organiseret, det burde jeg naturligvis have gjort, for det kan man jo se når man roder med det fysiske artifakt.

Databussen er 8 bits. Addressebussen er 14 bits.

36
15. januar 2012 kl. 22:58

Det ræsonement minder mere om Lestrade end om Holmes og strider imod en hel del af de informationer jeg har givet.

38
16. januar 2012 kl. 16:19

Det ræsonement minder mere om Lestrade end om Holmes og strider imod en hel del af de informationer jeg har givet.

Vil finde piben og hatten frem ;-)

Havde ikke læst din udenlanske artikkel - I så fald havde jeg ikke kommet til den konklusion.

Læser den første del som en jump blok, hvor 0xc8 kunne være en JMP instruktion og den næste to bytes en adresse. Det hænger dog ikke helt sammen med data senere i "teksten", da adresserne bliver højere end 0x3fff.

Hmmm.... nærmere studier nødvendige :)

Martin.

39
16. januar 2012 kl. 18:11

Læser den første del som en jump blok, hvor 0xc8 kunne være en JMP instruktion og den næste to bytes en adresse. Det hænger dog ikke helt sammen med data senere i "teksten", da adresserne bliver højere end 0x3fff.

Med mindre at ROM'en bliver kopieret højere op i RAM. (Det ville også gøre bufferområderne anvendelige.)

0000  c8 37 84 98 må så pege på boot-loaderen.

De næste adresser i jump-tabellen må så give et hint om hvorhen koden bliver kopieret.

49
16. januar 2012 kl. 21:41

Med mindre at ROM'en bliver kopieret højere op i RAM. (Det ville også gøre bufferområderne anvendelige.)</p>
<p>0000 c8 37 84 98 må så pege på boot-loaderen.</p>
<p> De næste adresser i jump-tabellen må så give et hint om hvorhen koden bliver kopieret.

Synes ikke det giver mening, da der er steder hvor 0xc8 efterfølges af aa bb, hvor aa > 0x03 (antager at det er msb først). Kan selvfølgelig ikke antage noget som helst mht. msb/lsb little/big endian.

Martin.

23
14. januar 2012 kl. 09:35

Er du sikker på at du har regnet rigtigt ?

Jeg kan f.eks ikke finde sekvensen "caca" et eneste sted ?

21
14. januar 2012 kl. 02:07

vi er havnet mere end 20 år tilbage i tiden og det her ligner nu 16-bit...

Måske noget fra CP/M perioden eller begyndelsen af DOS. Kunne være fra en af de utallige maskiner fra den tid, hvor lagerplads var kostbar og en rom kunne indeholde både boot, programmer, fortolker og andet godt.

Jeg kan genkende dele af strukturen, og de her data ligner faktisk inddelingen (sektor ?) af en HD fra den periode..

20
14. januar 2012 kl. 00:34

Editoren her på v2.dk ødelægger indrykningen af koden, ser det ud til.

Linjen:

d[key] = 1

skal selvfølgelig indrykkes

19
14. januar 2012 kl. 00:17

Mens resten af Danmark har siddet og set X-factor, lavede jeg det første spæde forsøg på at lave en frekvensanalyse...

  1. #! /usr/bin/env python
  2.  
  3. import binascii
  4.  
  5. d = dict()
  6. f = open('uco_image.bin', 'r')
  7. content = f.read()
  8. f.close()
  9. for c in content:
  10. key = binascii.hexlify(c)
  11. if key not in d:
  12. d[key] = 1
  13. else:
  14. d[key] += 1
  15. skeys = sorted(d.keys())
  16. for k in skeys:
  17. print(k, d[k])

Hvis ovenforstående python-script køres i en mappe, hvor PHKs uco_image.bin ligger, bliver resultatet en liste over bytes => antal forekomster, sorteret på bytes. Listen kan ses her:

http://pastebin.com/BKtF1ud0

Vi ser, at samtlige 256 "ord" i det mulige alfabet er til stede, og at frekvensen af de enkelte "ord", som forventet, svinger en del.

17
13. januar 2012 kl. 16:38

Måske er jeg helt på vildspor her, men det virker som om der er en masse kinesiske person navne?

Noget siger mig en liste over kinesiske husgeråd eller en kinesisk addressebog?

15
13. januar 2012 kl. 15:39

Til inspiration kunne man jo prøve at se Terminator filmene :)

14
13. januar 2012 kl. 14:56

"Any sufficiently advanced technology is indistinguishable from magic." (Arthur C. Clarke, "Profiles of The Future", 1961) - Også kendt som "Clarke's third law"

Han har selvfølgelig ret, og jeg vil derfor vove påstanden, at hvis en UFO dumper ned her på Jorden så er sandsynligheden for at deres teknologi kun er lidt mere avanceret end vores - så vi har en chance for at forstå den - stort set nul.

Derfor vil vi med stor sandsynlighed ikke kunne afgøre om vi står med 'overlysmotoren', en selvdestruktionsdims, en dommedagsbombe, navigationscomputeren eller måske bare Alien Playboy eller toilettet... måske er UFO'en i virkeligheden multidimensional og vi derfor kun kan se den del som stikker ind i vores 3 dimensioner (ligesom Doctor Who's Tardis)... måske er UFO'en helt tom og alt udstyr ren energi eller formindsket til atom-størrelse og placeret mellem molekylerne i skroget?

Nej, det er nok sandsynligt at vi ikke engang vil kunne identificere det styrtede fartøj til at begynde med. Det ligner måske bare en sten, vand eller noget vi slet ikke formår at se med vores nuværende biologi og/eller teknologi.

16
13. januar 2012 kl. 16:02

Han har selvfølgelig ret, og jeg vil derfor vove påstanden, at hvis en UFO dumper ned her på Jorden så er sandsynligheden for at deres teknologi kun er lidt mere avanceret end vores - så vi har en chance for at forstå den - stort set nul.

Det er grundlæggende ligegyldigt i konteksten. Blogposten går ud fra at vi faktisk har fundet et eller andet og skal prøve at finde ud af hvad det er. In casu: et computerprogram.

Eller sagt med andre ord: vi er flintrende ligeglade med alle de teknologier vi ikke ville kunne indse er teknologier, netop af den årsag - og fokuserer derfor udelukkende på det vi faktisk kan have en chance for at finde noget ud af om.

13
13. januar 2012 kl. 14:55

5F blokkene ligner ikke data, de ligner buffers. De er næsten alle sammen aligned til en word-boundary.

Derudover ville jeg nok gå statistisk til værks: 1. tjek hvilke strukturer, der går igen. 2. prøv at tilskrive dem mulige funktionaliteter baseret på vores egen viden om maskinkode samt arkitektur-optimisering. Dvs. noget i retning af en primitiv kryptografi-tilgang.

12
13. januar 2012 kl. 14:35

Det øverste af ROM'en kunne være jump-instruktioner (=reset- og interrupt-vektorer) - men det forudsætter selvfølgelig 32-bit instruktioner

29
14. januar 2012 kl. 20:55

Det øverste af ROM'en kunne være jump-instruktioner (=reset- og interrupt-vektorer) - men deke noget mening)
Men hvis C8 er en jump inst forudsætter selvfølgelig 32-bit instruktioner

Det var også mit første gæt (Jeg chekkede op mod instruktion sættet på I3031, men det gav ikke nogen mening. Hvis C8 er en jump instruktion, og de to næste bytes er en 16 bit adresse, så peger peger den første vektor ud i nogle fyld bytes. Det virker som om at starten på ROM'en er en tabel af en art, måske mikrokode ?. Denne sekvens virker ikke helt tilfældigt: C8 31 80 xx C8 32 80 xx C8 33 80 xx C8 34 80 xx C8 35 80 xx C8 36 80 xx Der er en ligende tabeler ved 0x1010 0x2010, 0x2810, 0x3030, 0x3800.

Måske er det noget fra sidst i 60'erne med bit slice kredse som 74181.

30
14. januar 2012 kl. 23:06

Hmm, det virker som nogle interessante instruktioner i starten - og nok det bedste sted at starte. Ja, det er jo i alt fald svært at gætte bredden på instruktionerne ved at starte midt i ;-)

Det ligner umiddelbart, at et "c8" oftest er fuldt af noget "3X" for X=0..7.

Hvis man kun kigger på de steder, der er en sådan form i dumpet, og på hvad der så kan komme efter, ser det sådan her ud:

61: 1 64: 3 69: 1 80: 36 81: 94 82: 32 83: 36 84: 12 85: 23 86: 43 87: 9 90: 1 c9: 102 cf: 2

Der er i alt fald noget struktur at angribe. Jeg kan ikke helt beslutte mig for bredden på instruktionerne - jeg synes måske det kunne ligne at nogle af dem er 8 bit + 8 bit adresse/data; nogle af dem måske kun 2 bit + 14 bit adresse... men det stammer nok af at ROMen angives til at have 14 bit adressebus.

10
13. januar 2012 kl. 14:12

Kører man:

hexdump -C uco_image.bin

får man ingen tekststrenge ud af det; men ET bruger nok heller ikke ASCII som kodetabel...! - I det konkrete eksempel (hvor vi har med en menneskeskabt maskine at gøre) kunne man overveje, hvorvidt vi er ovre i noget eksotisk, orientalsk tegnsæt, der ikke mapper til ASCII.

Via:

http://en.wikipedia.org/wiki/Character_encoding

finder man f.eks.:

http://en.wikipedia.org/wiki/JIS_X_0208

4
13. januar 2012 kl. 10:29

Spørgsmålet er om vi overhovedet ville opdage at der var noget at komme efter (med eller uden DRM) hvis en UFO styrtede ned.

Methinks det er relativt passende at sammenligne med, hvordan moderne teknologi ville blive betragtet af én fra f.eks. 1700-tallet. Ville han kunne gennemskue funktionaliteten af en benzinmotor fra sidste årtusind? Sandsynligvis er der en god chance, selvom brændstoffet måtte være fordampet. En moderne motorcontroller med sensorer der vel ikke en gang er synlige med det blotte øje, ville det måske ikke en gang falde ham ind, kunne have en funktion, hvis ikke han var enormt meget out-of-the-box-tænkende.

Hvis der så var en iPad med fuld dokumentation med... Jow, hvis den virkede endnu og ikke krævede password, skulle den nok være til at bruge - men selvom han så havde diagrammerne til motorcontrolleren, mangler der nok et par kapitler om, hvordan man fremstiller kredsløb på nanometerskala med smedejernsredskaber. :-)

Hvis så batteriet er løbet tørt på iPad'en, vil jeg tro, alt er tabt - hvem ville bare for 75 år siden være i stand til at genkende sådan én som et elektronisk apparat? Hvis man var, hvem kunne så regne sig frem til hvordan den skal oplades uden at blive ødelagt? Dét, der tit har slået mig når jeg læste sci-fi om eksotisk teknologi, er at meget elektronik allerede i dag er så kompakt at man dårligt kan åbne det uden at ødelægge det - og hvis vi så taler krystalteknologi eller whatever, som vi knapt nok ved er teknologi før vi har lavet hvad der i bedste fald svarer til et forsøg på at adskille lagene i et displaypanel med et koben, skal vi være temmelig heldige for at have noget at analysere bagefter. Hvis vi altså har fantasi nok til at forestille os, hvad det hele går ud på når vi ser det.

Derfor tror jeg ikke, vores ven fra 1700-tallet ville have nogen som helst chance for at hive data ud fra en iPad, der ikke havde mere batteri, og selvom vi i givet fald kunne genkende en computer, ville det undre mig hvis ikke der var så fundamentale teknologiske forskelle i virkemåden at vi ville ødelægge det hele i forsøget på at gennemskue, hvordan den fungerede.

6
13. januar 2012 kl. 10:44

Jeg synes ikke sammenligningen med 1700 tallet er relevant, hvis du skal bruge den tidsforskel skal du kigge på en bil i stedet: Man havde den samme fundamentale teknologi.

Hvis UFO'en er baseret på en teknologi vi ikke kender, har vi et problem, også med i det hele taget at genkende teknologien.

Men i denne udfordring ved vi det er en teknologi vi fundamentalt set kender.

18
13. januar 2012 kl. 19:13

Jeg fulgte ikke linket oprindeligt - ellers havde jeg selvfølgelig opdaget at opgaven var afgrænset til teknologi, vi tror vi forstår. Ups! :-)

Det er vel så på sin plads at acceptere at vi "opdager", vi har at gøre med teknologi, der ligner vores egen og ikke er på "UFO-niveau" som sådan - f.eks. at vi kan antage at adresse- og databen er blevet sorteret korrekt af dem, der har trukket indholdet ud, der er tale om traditionel arkitektur og ikke et lager, der indirekte adresserer ét, vi ikke har fået med, at alle bytes er beregnet til at blive behandlet sekventielt og så videre.

Naaaa.... Det virker nu lidt som et for fantastisk tilfælde for en sci fi-nørd - så jeg hælder mest til den antagelse at der har været tale om et hjørne af en chip fra en kinesisk spionsatellit, vores grå venner har kapret inden de styrtede ned. :-)

2
13. januar 2012 kl. 10:18

Der er meget redundans, så jeg tror, at meget af det er data, evt. uinitialiserede tabeller. Der er f.eks. lange sekvenser af 5f, som kunne være en en variant af "deadbeef". Der er også forholdsvis lange sekvenser af firebytes kombinationer af formen c8 3. 8. .., hvor "." står for vilkårlige hexadecimale tal, så noget tyder på, at maskinord eller instruktioner er 32 bit. Mit umiddelbare gæt er, at der er tale om instruktioner. Der er ikke noget, der tyder på ASCII data.

3
13. januar 2012 kl. 10:22

Det er instruktioner, men selvfølgelig må der forventes at der er nogle data imellem, det er som sagt et "real-world" program.

Du har overset et meget vigtigt clue.

9
13. januar 2012 kl. 13:43

Du får ikke nogen hjælp Torben, men jeg kan næsten høre at du allerede gør dig tanker om maskinkode du ikke har gjort dig før :-)

1
13. januar 2012 kl. 09:42

Enhver, der har fået et indblik i alien computer-teknologi fra denne perle: http://www.imdb.com/title/tt0116629/ vil nok mene, at det ikke er besværet værd ;-)

(Beklager, kunne bare ikke la' vær')

5
13. januar 2012 kl. 10:30

Jeg har tit ledt efter kommandoen 'Upload Virus' i morderne systemer.