Uidentificeret Programmeret Object

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

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.

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.

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.

Det var forkert af mig.

Kigger lige på PIC16F747 der kan adressere 2^14 bytes, altså har 14 adressebits :)

http://ww1.microchip.com/downloads/en/devicedoc/30325b.pdf

Der røg aftenen med familien :)

/björn

Er mit gæt.

Er doven og træt så jeg har ikke lavet nogen analyse. Men 14 bit wordlængde og 8 bit adressebus lyder som en PIC16F84.

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

Held og lykke :)

/björn

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?

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.

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.

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.

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

...kan ses her: http://pastebin.com/trJigXHr

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

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

Linjen:

d[key] = 1

skal selvfølgelig indrykkes

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.

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?

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

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

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.

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

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

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.

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.

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')