Joulusta 2021 alkaa hakkerointia ja viestintätekniikkaa sivuava kilpailu.
Joulupukki tekee digiloikan: tuhmia lapsia valvoo jatkossa armoton Sähkötonttu™, ja olet joutunut sen koehenkilöksi. Toimiiko laite tarpeeksi luotettavasti pukin tarpeisiin vai onko sitä mahdollista huijata?
Lue koko tarina kilpailusivulta. Itse tehtävä paljastuu jouluaamuna, ja lisää vihjeitä tulee vähitellen kisan kuluessa. Tällä kertaa kisataan ajasta ja tarkkuudesta: kuka selvittää ratkaisun ensimmäisenä ja vähimmillä virheyrityksillä?
Tehtävään tarvittavat tiedot on nyt julkaistu kilpailusivulla. Hakkerointi voi alkaa!
Tässä voi keskustella ideoista ja ratkaisun vaiheista sitten, kun kyseiset tiedot on julkaistu vihjeinä tehtäväsivulla. Viimeiset vihjeet tulevat tammikuun lopussa, ja sen jälkeen saa vaihtaa tietoja aivan vapaasti. Yleisellä tasolla työvälineitä ja omaa edistymistä voi tietysti kommentoida aiemminkin.
Tämän päivän datapaketti on siivotussa muodossa, josta pääsee helpommin alkuun. Vastauslomake on myös avattu, nimittäin tämän päivän datatiedostossa näkyvä muoto kelpaa jo vastauksen lähettämiseen. Onkohan joku jo päässyt alkuun tehtävässä?
Nyt yksi viesti mahtuu jo yhdelle riville ja viestien vertailu helpottuu entisestään. Miltä näyttää, onko toivoa? Seuraavissa vihjeissä puretaan viestistä vielä yksi taso...
Itselläni on vaikeuksia hahmottaa tehtävää, kun ei ole kokemusta mikrokontrollereista tai siitä, miten ne käsittelevät dataa ja missä muodossa yleensäkin data kulkee. Eli olen ihan "kuutamolla" tehtävän suhteen.
Mikrokontrolleri käsittelee dataa ihan samalla tavalla kuin muutkin tietokoneet.
TapaniS kirjoitti:
Itselläni on vaikeuksia hahmottaa tehtävää, kun ei ole kokemusta mikrokontrollereista
Voi ei, olet hämääntynyt tehtävän teknisestä taustasta! Onneksi ei tarvitse tietää mitään mikrokontrollereista, vaan datan käsittelyn puolesta tämän pitäisi olla jo helpompaa kuin AoC-joulukalenterin bittitehtävä. Data on siis yksinkertaisesti jono bittejä, jotka on tässä esitetty heksadesimaalimuodossa.
Tärkein osa ratkaisusta on viestien tutkiminen ihan omin silmin, jotta selviää, mitä kannattaisi ohjelmoida. Käytännössä ohjelmointia voi käyttää tässä datan muokkaukseen, paloitteluun, tilastointiin jne. mutta ratkaisun idea pitää löytää tutkimalla ja päättelemällä.
Datan liikkumista tarvitsi miettiä vain tehtävän ensimmäisessä vaiheessa, ja sehän on yksinkertaista: datan bitit vain lähetetään peräkkäin (big-endian, tai näin tehtävässä ainakin on oletettu), ja vastaanottajan vastuulla on tunnistaa, mistä viesti alkaa ja loppuu. Toiseen datatiedostoon on korjattu radiolähetyksen kohinaa ja kolmanteen on muutettu 00 = 0 ja ff = 1 ja tämän muunnoksen tulos vielä bittijonosta uudelleen heksamuotoon. Vihjetekstien mukaisesti data on nyt muodossa, jossa sitä pystyy myös suoraan lähettämään ja vastaanottomaan korjaamalla lähettimen nopeuden oikeaksi.
Nyt kolmannen datatiedoston myötä tarvitsee ymmärtää datan liikkumista enää siitä näkökulmasta, että tiedoston data on heksadesimaalimuodossa ja tämän voi muuttaa binäärimuotoon (kaksi merkkiä on yksi 8-bittinen tavu 00–ff eli 10-järjestelmässä 0–255), joka taas muodostuu lopulta ykkösistä ja nollista (eli tavut 00, 01, 02, ff ovat bitteinä 00000000, 00000001, 00000010, 11111111). Harjoituksena voi tehdä vaikka muuntimen, jolla merkkijono 0123456789abcdef muuttuu tavuiksi 1, 35, 69, 103, 137, 171, 205, 239 ja päinvastoin.
Tehtävässä mainitun radiolähettimen (tai vastaavan; itselläni on CC110L, jolla ohjailen Nexan langattomia pistorasioita) voi kytkeä esimerkiksi Raspberry Pi -koneeseen, jossa toimii tavallinen Linux. Dataa saa laitteesta sisään ja ulos 8-bittisinä tavuina valmiilla funktioilla.
Heksadesimaaleista lyhyesti
Tavu (byte, uint8) on luku väliltä 0–255 eli heksadesimaalina 00–ff. Yksi tavu vastaa siis kahta heksadesimaalimerkkiä. Heksadesimaalimuotoisen datan saa takaisin tavuiksi, kun katkaisee datan 2 merkin paloihin ja muuttaa nämä luvuiksi taulukkoon. Jos kielessä ei ole valmiiksi 8-bittisiä lukuja, laskutoimitusten tulokset saa pidettyä oikealla lukuvälillä tekemällä luvun 255 kanssa binäärisen ja-operaation (usein &-merkki tai and-sana). Luvut saa takaisin toivottuun heksamuotoon, kun muuttaa jokaisen luvun kaksimerkkiseksi heksadesimaaliluvuksi ja laittaa nämä sitten peräkkäin.
Heksadesimaaliluvun muuntamiseen on monissa kielissä valmis funktio.
// C++
int luku = stoi(hex, 0, 16);
int uusiluku = luku & 255; // Voisi olla pidempikin laskutoimitus.
printf("%02x", luku);// JavaScript let luku = parseInt(hex, 16); let uusiluku = luku & 255; // Voisi olla pidempikin laskutoimitus. let hex2 = luku.toString(16).padStart(2, "0");
Aloittelin tehtävän ratkaisua ensimmäisen vihjeen avulla. Sain dekoodattua lähetteen ja selvitettyä sen vaihtuvasta osasta suurimman osan. Ratkaisu tuntuu olevan muutamasta bitistä kiinni. Luulin keksineeni niiden merkityksen, mutta tarkastussivu hylkäsi ideani perusteella generoidun viestisarjan liian pitkänä.
-tossu- kirjoitti:
Tarkastussivu hylkäsi ideani perusteella generoidun viestisarjan liian pitkänä.
Suurensin nyt lähetyksen maksimikokoa ja rivimäärää, joten voit kokeilla vielä uudestaan. (Jos ratkaisu ei edelleenkään mahdu, mieti vielä.) Ratkaisu voi olla oikea, vaikka se olisikin tarpeettoman pitkä; kyseessä on toistettava viestisykli, joten vastauksessa voi olla esimerkiksi useampi kelvollinen sykli peräkkäin.
Toisaalta ratkaisua voi miettiä siltä kannalta, että dataakin on annettu vain 1564 riviä...
Sehän meni läpi ensimmäisellä. Yritin selvästi hakea ratkaisua aivan liian kaukaa.
-tossu- kirjoitti:
Sehän meni läpi ensimmäisellä.
Onneksi olkoon ensimmäisestä toimivasta ratkaisusta!
Ratkaisusi rivimäärä on aika erikoinen. Tammikuun lopussa tulevat viimeiset vihjeet, joten helmikuussa voisit ehkä lisävihjeenä paljastaa, miten päädyit kyseiseen rivimäärään. Sitä odotellessa: Saatko rivejä vähennettyä?
Oletettavasti tiedät datalle lyhyemmät muodot (datatiedoston 3 ja vielä tätä seuraavankin muodon), joissa voit myös lähettää ratkaisuja. Eli ei tarvitse muuttaa viestejä takaisin alkuperäiseen pitkään muotoon. (Tai muuten olisi erityisen jännä kuulla, miten sitten olet saanut uutta dataa generoitua.)
Lisätehtävä on julkaistu! Kaveri on nimittäin saanut samanlaisen rannekkeen ja kaipaa apua. Kaverilla on kuitenkin tiedossa vain yksi kaapattu viesti. Onnistutko tekemään myös kaverille sopivat viestit?
Lähetin lyhyet ratkaisut molempiin tehtäviin. Kerron toki kilpailun päätyttyä, miten päädyin alkuperäiseen ratkaisuun.
Olen selvitännyt kyllä datan lyhyemmät muodot. Minulla on valmiina pitkää muotoa käyttävät työkalut datan parsimiseen, visualisointiin, tarkastamiseen sekä luomiseen. Halusin tarkistaa vastauksen syöttämällä sen koko ketjun läpi, joten generoin sen suoraan pitkään muotoon.
Kiitokset mielenkiintoisen kilpailun järjestämisestä! Sitä pähkiessä kului joulun välipäivät rattoisasti.
-tossu- kirjoitti:
Minulla on valmiina pitkää muotoa käyttävät työkalut datan parsimiseen, visualisointiin, tarkastamiseen sekä luomiseen.
Oletko itse tehnyt nämä työkalut tai voitko antaa vinkin, millaisia työkaluja on käytössä ja voiko niitä ladata jostakin?
TapaniS kirjoitti:
Oletko itse tehnyt nämä työkalut tai voitko antaa vinkin, millaisia työkaluja on käytössä ja voiko niitä ladata jostakin?
Tein työkalut itse tätä tehtävää varten.
Ensimmäisen vihjeen avulla ykkösiksi ja nolliksi muunnetuista signaaleista kannattaa piirtää kuvaaja. Tehtävässä mainitun radiolähettimen datalehdestä löytyy pari esimerkkiä.
Tehtävään teknisesti riittäviä työkaluja ovat merkkijono, for-silmukka ja muunnostaulukko 0-f = 0000-1111. Näillä välineillä onnistuu nopeasti esimerkiksi jo vihjeissä kerrottu muunnos 2.-3. datatiedoston välillä. (Ihan ensimmäisen tiedoston dataa ei kannata turhaan enää itse siivota, se on vaikein ohjelmoitava.)
Kannattaa koodata erilaiset datan muunnokset aina molempiin suuntiin. Silloin voi helposti testata, että takaisin(muuta(x)) on edelleen x.
Se on makuasia, katsooko tietoa mieluummin heksamuodossa, bitteinä vai graafisena esityksenä, kun miettii seuraavaa mahdollista askelta.
Ei ole tarkoitus nyt spoilata kisaa ja poistettakoon viesti, jos se katsotaan ratkaisun kannalta jotenkin helpottavan liikaa tms.
Lähettimen data -lehdeltä löytyy oheinen teksti:
CC1050 kirjoitti:
CC1050 can be configured for the data rates 0.3, 0.6, 1.2, 2.4, 4.8, 9.6, 19.2 or 38.4 kbit/s.
Eli kysyisin onko tarkoitus laitetasolla tarkastella mahdollisia bittivirtojen pituuksia? Tässä esim. 256/38.4 antaa suhdeluvuksi 6,666.. Nyt tuohon kolmanteen datatiedostoon oli ilmeisesti lyhennetty aina 8 bitin setti kerralla. Ja jatkokysymyksenä sitten olisi, että miten noita virtoja sitten käsitellään, jos ei mene suhde tasan vaan välillä saadaan esim. 6, 7 tai 7 bittiä yhden sijaan?
Ja sanoisin, että ei tämä ihan "perinteiseltä ohjelmointikisalta" vaikuta. Aikaisemmin on alkanut lähes heti pukkaamaan koodia, jota on paranneltu kisan kuluessa. Nyt ei ole vielä kovin montaa riviä syntynyt. :)
TapaniS kirjoitti:
Eli kysyisin onko tarkoitus laitetasolla tarkastella mahdollisia bittivirtojen pituuksia? ... Miten noita virtoja sitten käsitellään, jos ei mene suhde tasan vaan välillä saadaan esim. 6, 7 tai 7 bittiä yhden sijaan?
Kyllä, ensimmäisen tiedoston idea oli juuri se, että se ei ole tasan 8:lla jaollinen ja seassa on myös häiriöitä. Siivottu data on jo annettu eikä siis tätä asiaa enää ole pakko ratkaista, joten voin kertoa keinot tämän ratkaisuun. Saa jättää lukematta, jos haluaa myöhemmin miettiä tätä välivaihetta.
Ensin ajatusharjoitus. Voit simuloida tätä datan väärää nopeutta, kun katsot kelloa (tai ruudulla sekunnin välein vaihtuvaa yhtä bittiä) ja räpytät silmiä. Jos räpytät nopeasti, ehdit nähdä saman aina monta kertaa ja voit päätellä, missä sekunti vaihtui ja montako räpäystä on yksi sekunti (eli yksi bitti). Välttämättä ei ole aina yhtä monta, vaan voi olla välillä 3 ja välillä 4 räpäystä, jos räpytysnopeus on siitä välistä. Jos taas räpytät aivan liian hitaasti, osa jää näkemättä. Jos räpytät melkein oikein, välillä saattaa jäädä välistä tai näkyä sama kahdesti. Tasan oikein räpytellessä näkyy jokainen sekunti tasan kerran. Selvästi näistä toimivia vaihtoehtoja ovat täsmälleen oikea tai sitten niin nopea, että oikean tuloksen pystyy päättelemään.
Spoileri. Virhebitit saa enimmäkseen pois blurrin tyyppisesti eli vaikka laskemalla viiden peräkkäisen bitin keskiarvoa, jolloin yksinäinen väärä bitti "tasoittuu" pois. Tämän jälkeen voi laskea samaa bittiä olevien palojen pituudet, joista näkee, että ne osuvat noin 8 bitin sarjoihin. Nämä pituudet voi yksinkertaisesti pyöristää, eli esimerkiksi 13 saman bitin jono on lähempänä 16:ta kuin 8:aa. Toiseen tiedostoon oli tehty juurikin tuon tyyppiset korjaukset, tuloksena virheetöntä dataa 8 bitin jaolla.
Tosielämässä kannattaa ensimmäisestä viestistä vain tunnistaa oikea nopeus ja äkkiä säätää vastaanotin uusiksi, niin saa datan suoraan oikeassa eli kolmannen datatiedoston muodossa. Ja tätä vastaten, kun nyt data on annettu jo uudemmassa muodossa, kannattaa unohtaa tehtävän alkuvaiheet ja jatkaa suoraan viimeisestä annetusta tiedostosta. Alkuun voi palata sitten myöhemmin lisäharjoituksena.
TapaniS kirjoitti:
Lähettimen data -lehdeltä löytyy oheinen teksti: ...
CC1050:lle voi syöttää dataa ilman synkronointia (teknisen PDF:n tekstissä kolmas moodi, asynkroninen), jolloin se ei ole sidoksissa noihin nopeuksiin vaan lähettää ikään kuin reaaliajassa sen, mitä johdosta syötetään. Lisäksi aina voi olla jokin virhe konfiguraatiossa. Yksi syy tuohon alun epäselvään dataan on se, että käyttämäni vastaanotin yrittää synkronoida nopeuden tunnistamiinsa bitteihin ja sen takia nopeus seilaa.
Mutta olet kyllä oikeassa siinä, että 32 ja 256 ovat törkeän epärealistiset luvut ja 38,4 kbps olisi todennäköisempi valinta. Korjaan tekstin joskus. (Muutan molemmat luvut, niin data pysyy samana. :D)
TapaniS kirjoitti:
Ja sanoisin, että ei tämä ihan "perinteiseltä ohjelmointikisalta" vaikuta.
:) :) :)
TapaniS kirjoitti:
Ja sanoisin, että ei tämä ihan "perinteiseltä ohjelmointikisalta" vaikuta.
Tämähän onkin hakkerointikilpailu
Tänään data on purettu kaikkein selvimpään muotoon, eli nyt voi unohtaa kaikki tiedonsiirtoon ja mikropiireihin liittyvät huolet. Ratkaistavana on vain, millä perusteella viestit hyväksytään tai hylätään. Ratkaisun saa lähettää tässä täysin puretussa muodossa.
Edelleen on vain yksi hyväksytty lähetys eikä edes yrityksiä. Viimeisimmissä vihjeissä katsotaan viestien todennäköistä rakennetta ja oivalletaan, että kerätyt viestit ovat tietenkin olleet kelvollisia eli samoja viestejä lähettämällä voisi saada lisävinkkiä oikeaan ratkaisuun.
29.1. tulee viimeinen etukäteen suunniteltu vihje, ja sen jälkeen saa täällä keskustella oman harkinnan mukaan, mitä on saanut selville ja missä kohdissa on ongelmia. Katsotaan sitten, löytyykö pienellä avulla lisää ratkaisijoita.
Onko tehtävä todella näin vaikea tai vieras? Heittikö TapaniS pyyhkeen kehään, entä jalski? Saadaanko voittajalta tässä vaiheessa lisävinkkejä tai kertomusta, miten oma ratkaisu löytyi? Onko joku selvittänyt tehtävään liittymättömiä asioita kuvaillusta laitteesta?
TapaniS:n aiempaan nopeuskommenttiin on nyt vastaus: Havaintojen mukaan nopeus olisi todella 31700 bps, tai sitten käytetyssä koodissa on jokin virhe asetusten laskemisessa. (Laitteen asetusten säätämisessä on monta virheen mahdollisuutta, koska niitä ei anneta suoraan tuollaisena lukuna.) Eli pidetään tehtävässä vanhat lukemat 32 kbps ja 256 kbps, jotka vastaavat saamiani tietoja.
No joo, vihjeet ovat olleet hyviä ja jos vielä jotakin paljastetaan, niin ratkaisu varmaan on jo sitten edessä. Tässä on hiukan sellainen ongelma, että yleensä ei kannata arvailla mitään, vaan ratkaisu lähetetään, kun omasta mielestä looginen ratkaisu on löytynyt.
Eli tuossa näyttäisi viimeinen tavu olevan varmaan tarkistus. Tämän laskentaan googlettamalla löytyi käytäntö, jota pitäisi vielä testailla.
Toiseksi viimeinen tavu aina muuttuu jonkin kaavan mukaan. Sama tavu toistuu aina n. 250 rivin jälkeen. Eli tuon tavun muuttumisjärjestyksen lähtötiedoista varmaan saa kaivettua, mutta jokin kaava tuossa olisi parempi kuin manuaalinen excel-menetelmä. Joka toinen tavu on aina 4 pienempi kuin edellisessä viestissä. Pitäisi varmaan laittaa binäärimuodossa muutama rivi allekkain, niin ehkä tuosta jotakin voisi selvitä.
Kolmanneksi viimeisen tavun arvoista ei ole vielä oikein käsitystä. Maksiarvo näyttäisi olevan 100 ja yöaikaan 0 tai 8. Ehkä se vain aina on jotakin tuolta väliltä. Lisäksi näyttäisi olevan aina jaollinen 8:lla (paitsi 100).
Vihjasinkin jo aiemmin, että viestejä kannattaa tutkia graafisessa muodossa. Viimeisessä datatiedostossa muuttuva osa on 6 heksamerkkiä eli 24 bittiä. Niistä voi piirtää 24 pikseliä korkean kuvan, jossa viestit ovat esitettynä vierekkäin ja yksi pikseli vastaa yhtä bittiä. Kuvasta saa aika helposti ratkaistua ainakin yhden tavun merkityksen.
Selvitin viestien logiikan lähes kokokaan kuvaa tutkimalla. Tarkistussummassa on useampi bitti, joista ratkaisin ensin kuvasta pari helpointa ja lopuille hain vastaavat ratkaisut ohjelmallisesti.
Tehtävän vaikein vaihe oli ehdottomasti viestien sisällön selvittäminen. Mielestäni signaalin suodatus ja dekoodaus oli paljon helpompaa, ja vihjeet oli jaettu turhankin pieniin paloihin. Datatiedosto 2:n dekoodaus bittijonoiksi vaatii vain pari riviä koodia eikä vihjeissä mainituille välimuodoille ole välttämättä tarvetta.
Oletin alussa virheellisesti, että tukiasema tarkistaa viestien sisällön järkevyyden pidemmältä ajalta jollain hienolla heuristiikalla. Yritin lähettää ratkaisua, joka oli mahdollisimman aidon näköinen, mutta tarkistussivu ei ottanut pitkää tiedostoa vastaan. Tehtävässä ei siis selvästikään haeta liian monimutkaista ratkaisua.
Viimeisten vihjeiden mukaan kerättyjä viestejä voisi koittaa hyödyntää sellaisenaan. En edes yrittänyt niin triviaalia ratkaisua. Oletin, että tukiasema hyväksyy vastauksen, vaikka osa viesteistä puuttuisi välistä. Todellisuudessahan yksisuuntaista radioliikennettä käyttävän järjestelmän olisi hyväksyttävä se, että osa viesteistä ei mene perille. Silloin ratkaisuksi riittäisi sopiva pala datatiedostosta.
TapaniS kirjoitti:
Toiseksi viimeinen tavu – – jokin kaava tuossa olisi parempi kuin manuaalinen excel-menetelmä
Mitä vikaa on Excel-menetelmässä? Kaavan voi kyllä tehdä, mutta siitä saatava ilo jää aika pieneksi. Jos joku ymmärtää, mitä järkeä kyseisessä kaavassa on, tämä olisi minuakin kiinnostava tieto.
-tossu- kirjoitti:
Tehtävän vaikein vaihe oli ehdottomasti viestien sisällön selvittäminen. Mielestäni signaalin suodatus ja dekoodaus oli paljon helpompaa, ja vihjeet oli jaettu turhankin pieniin paloihin.
Tätä oli vaikea ennakoida. En tiennyt tällaisista laitteista ennen mitään, joten ratkaisin dekoodauksen ”kantapään kautta” suunnilleen vihjeiden mukaisesti, ja siihen meni kohtalaisesti aikaa. Sopivilla välineillä koodimäärä on kyllä pieni, itse käytin PHP:tä ja GMP-kirjastoa.
Vihjeistä huolimatta ilmeisesti tehtävä ei ole ollut turhan helppo.
-tossu- kirjoitti:
Oletin alussa virheellisesti, että tukiasema tarkistaa viestien sisällön järkevyyden pidemmältä ajalta jollain hienolla heuristiikalla.
En tiedä, kiinnostaako asia tonttuja ja minkälainen hieno heuristiikka huomioisi riittävän hyvin kaikenlaiset käyttäjät ja tilanteet. Mutta sen verran olisi kai voinut tarkastaa, että datassa on jotain elämää.
-tossu- kirjoitti:
Viimeisten vihjeiden mukaan kerättyjä viestejä voisi koittaa hyödyntää sellaisenaan. En edes yrittänyt niin triviaalia ratkaisua.
Toisaalta kun nyt tiedät viesteistä kaiken, tiedät myös mahdollisten viestien lukumäärän, joka on yllättävän pieni. Jo tuossa annetussa datassa näkyy sen verran toistuvia viestejä, että ehkäpä joku ratkaisee asian tätä kautta.
-tossu- kirjoitti:
Oletin, että tukiasema hyväksyy vastauksen, vaikka osa viesteistä puuttuisi välistä.
Tukiasema reagoi jo yhteen puuttuvaan tai virheelliseen viestiin. Ehkä virhetoleranssi on tonttujen valvomon ohjelmissa, tai ehkä tontuilla on vain sopimus, missä vaiheessa virheisiin reagoidaan.
Puuttuvien viestien tunnistusta (erotuksena väärästä viestistä) ei nyt tässä implementoitu, tämä vaatisi ratkaisussa myös aikaleimojen tarkastusta.
-tossu- kirjoitti:
Tarkistussummassa on useampi bitti, joista ratkaisin ensin kuvasta pari helpointa ja lopuille hain vastaavat ratkaisut ohjelmallisesti.
Löysitkö ihan algoritmin (nimen tai kaavan), vai perustuuko ratkaisu vain datasta kaivettuihin bitteihin?
Metabolix kirjoitti:
Onko tehtävä todella näin vaikea tai vieras?
Itse en osallistunut koska on vaikeuksia löytää aikaa kaikkiin kiinnostaviin projekteihin. Oli siis tietoinen valinta, että en käytä aikaa tähän. Tehtävä vaikuttaa hauskalta ja jos olisi enemmän aikaa niin siihen olisi ollut kiva osallistua.
Vaikka tämä ei ole vaikuttanut erityisen vaikealta, niin olen huomannut että "helppoihinkin" tehtäviin saattaa palaa tunteja. (kommentoin nyt kuitenkin kun tiedän että siihen ei mene yli 5 minuuttia :D)
-tossu- kirjoitti:
Todellisuudessahan yksisuuntaista radioliikennettä käyttävän järjestelmän olisi hyväksyttävä se, että osa viesteistä ei mene perille.
Mielestäni tehtävänannossa oli aika selvästi rivien välistä annettu ymmärtää että kyseessä on jonkinlainen räpellys ja vieläpä sellaisen betaversio, ei kyvykkäiden insinöörien taidonnäyte.
Grez kirjoitti:
Mielestäni tehtävänannossa oli aika selvästi rivien välistä annettu ymmärtää että kyseessä on jonkinlainen räpellys ja vieläpä sellaisen betaversio, ei kyvykkäiden insinöörien taidonnäyte.
Joulupukin rannekkeeseen liittyviä dokumentteja on luvatusti Yhdysvaltain telehallintoviraston sivuilla ja satunnaisissa muissa lähteissä. Uskon, että mahdollinen virhetoleranssi on toteutettu pukin järjestelmässä vasta korkeammalla tasolla. Ainakin nuo dokumentit antavat ymmärtää, että virheistä ilmoitetaan välittömästi vaaratilanteiden välttämiseksi.
Oletteko päässeet eteenpäin tehtävässä?
Alla olevassa kuvassa näkyy viimeisen datatiedoston 80 ensimmäistä viestiä dekoodattuna. Jokainen rivi vastaa viestien yhtä bittiä ja sarake yhtä viestiä. Ykköset esittävät ykkösbittejä ja välit nollabittejä. Ainakin bitit 11-15 näyttävät toistuvan jonkin kaavan mukaan.
0: 1: 11 11 1 1 11111 1 11 1111 1 1 11 111 1 1 1 11 11 1 2: 1111 11 1 1 11 11 1 11 111 1 1 1 1 1 1 1 1 1 11 3: 111 11 1 1 11111 1 1 1 1 11 111 1111 1 11 1 11 11 1 11 1 4: 1 1 11 11 1 1 111 1 1 11 11 11 1 11 11 1 1 1 1 1 1 11 1 1 1 11 5: 1 1 1 6: 7: 8: 1111111111111111111111 9: 1111111111111111111111 11111111111111111111111111 10: 1111111111111111111111111111111111111111111111111111111111 11: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 1 11 11 11 11 12: 111111 1111111111111111 111111111111111 13: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 14: 11111111 11111111 11111111 11111111 11111111 15: 11 1111 1111 1111 1111 1111 1111 1111 111 1111 111 16: 11 11 111 1 11 1 1 1 111 11 1 1 1 11 1 1 1 1 11 11 111111 17: 111 11 11 11 111 1111 111 1 11 1111 1 11 11 1 1 1 11 1 1 1 1 11 18: 1 11 11 1 1 1 1 11 1 11 1 1111 1111 11 111 1 1 1 1111 1 11 1 19: 1 1 111 11 111 111 11 1 1 1 1 1 11 1 11 1 1 1 1111 11111 1 20: 1 1 1111 1 1 111 11 111 1 1111111 111 111 1 1 11 11 1 1 11 1 11 1 21: 111 111 11 1 11 111111 1111111 1111 11 1 1 1 111 11 11 11 11 22: 1 1 1 1 11 11 1 1 1 1 1111 11 1 1 1 1 11 1 1 1 1 11 1 23: 1 1 11 11 11111 11 11 1 1 11 11 11 1 11 1 1 111 1 1 1111
Tarkistussumma on ratkaistavissa kuvasta, jossa näkyy kaikki viestit. Käytin merkkigrafiikan sijaan pikselikuvaa, koska sitä on paljon helpompi lukea. Kuvankäsittelyohjelmalla saa tehtyä merkintöjä kuvan päälle sekä mitattua bittijonojen pituuksia.
Keskustelussa on tullut myös esiin idea käyttää kaapattuja viestejä ratkaisussa. Viesteissä on jo valmiiksi tarkiste, joten ehkä sitä ei tarvitsekaan murtaa.
Metabolix kirjoitti:
Löysitkö ihan algoritmin (nimen tai kaavan), vai perustuuko ratkaisu vain datasta kaivettuihin bitteihin?
Löysin kaavan, jolla tarkistussumman saa laskettua biteittäin viestin muuttuvasta osasta. Ratkaisin ainakin kolme bittiä käsin, jonka jälkeen hain osittain algoritmillisesti ja osittain valistuneella arvauksella kaavan lopuille. En ole siistinyt kavaa tai selvittänyt, vastaako se jotain tunnettua algoritmia.
Nyt on Ukrainan tilanteen takia ihan lamaantunut olo. Aivosolu on ihan hyytynyt. Tehtävä on kyllä hyvin laadittu, mutta omat eväät eivät nyt riittäneet löytämään ratkaisua.
Vain -tossu- ratkaisi tehtävän ennen kesää – jo hyvissä ajoin, 4.1.2022 eli vain 10 päivää datan ilmestymisen jälkeen. Poistan nyt kisan mainoksen sivupalkista, joten näin kisan ”päättyessä” onneksi olkoon voittajalle vielä kerran! ;)
Halukkaat voivat edelleen yrittää tehtävää, ohjeet ja vihjeet pysyvät, ja tuloslista näkyy automaattisesti lähetyssivulla.
Muutama viimeinen lisätieto: Viestissä on tosiaan kiinteä alkuosa, sitten jonkinlaisen liikesensorin lukema (0–100 mutta pyöristettynä 8:n välein, paitsi se 100), tiettyjä arvoja kiertävä ”laskuri” ja muutaman viimeisen tavun CRC-tarkastussumma (CRC-8-Dallas/Maxim, polynomi 0x31). Ratkaisun avain on siis se, miten saa selville laskurin oikean kierroksen ja miten tarkastussumma lasketaan (tai voiko laskemisen jotenkin välttää).
Tehtävä pohjautuu saamiini tietoihin todellisesta pannasta, jota myös Suomessa käytetään valvontarangaistukseen.
Aihe on jo aika vanha, joten et voi enää vastata siihen.