Uidentificeret Programmeret Object

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.

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

Kommentarer (57)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

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.

Allan Høiberg

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.

Poul-Henning Kamp Blogger

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.

Gunnar Hedin Heinesen

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

Peter Lind

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.

Per Gøtterup

"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.

Peter Lind

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.

Allan Høiberg

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. :-)

Gunnar Hedin Heinesen

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

#! /usr/bin/env python  
   
import binascii  
   
d = dict()  
f = open('uco_image.bin', 'r')  
content = f.read()  
f.close()  
for c in content:  
    key = binascii.hexlify(c)  
    if key not in d:  
    d[key] = 1  
    else:  
        d[key] += 1   
skeys = sorted(d.keys())  
for k in skeys:  
    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.

Finn Christensen

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..

Anonym

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.

Niels Danielsen

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.

Rune Broberg

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.

Martin Zacho

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.

Per Michael Jensen

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.

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

Lars Skovlund

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.

Lars Skovlund

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.txt
http://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.

Martin Zacho

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.

<edit> 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.

Martin Zacho

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

Martin Zacho

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:

0000  c8 37 84 98 LD 0x3784, 0x98  
0004  c8 31 80 10 LD 0x3180, 0x10  
0008  c8 32 80 14 LD 0x3280, 0x14  
000c  c8 33 80 18 LD 0x3380, 0x18  
0010  c8 34 80 0a LD 0x3490, 0x0a  
0014  c8 35 80 16 LD 0x3580, 0x16  
0018  c8 36 80 1c LD 0x3680, 0x1c  
001c  c8 37 80 08 LD 0x3780, 0x08  
0020  c8 37 85 78 LD 0x3785, 0x78  
0024  c8 31 86 f9 LD 0x3186, 0xf9  
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.

Per Michael Jensen

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.

Log ind eller Opret konto for at kommentere