Kirjautuminen

Haku

Tehtävät

Kilpailu

Murra koodi!
Lue ja osallistu!
Seuraava vihje 29.1.
Voittajia 1 + yrittäjiä 1

Keskustelu: Ohjelmointiputka: Hakkerointikilpailu alkaa!

Sivun loppuun

Metabolix [24.12.2021 19:00:00]

#

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ä?

Metabolix [25.12.2021 09:00:00]

#

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.

Metabolix [28.12.2021 08:40:45]

#

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ä?

Metabolix [31.12.2021 10:23:53]

#

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

TapaniS [03.01.2022 14:18:28]

#

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.

Grez [03.01.2022 15:01:03]

#

Mikrokontrolleri käsittelee dataa ihan samalla tavalla kuin muutkin tietokoneet.

Metabolix [03.01.2022 15:37:39]

#

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");

-tossu- [04.01.2022 20:48:16]

#

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

Metabolix [04.01.2022 22:00:00]

#

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

-tossu- [04.01.2022 22:09:52]

#

Sehän meni läpi ensimmäisellä. Yritin selvästi hakea ratkaisua aivan liian kaukaa.

Metabolix [05.01.2022 00:01:46]

#

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

-tossu- [05.01.2022 02:08:54]

#

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.

TapaniS [09.01.2022 17:36:55]

#

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

-tossu- [09.01.2022 23:12:59]

#

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

Metabolix [10.01.2022 00:28:24]

#

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.

TapaniS [10.01.2022 15:40:07]

#

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

Metabolix [10.01.2022 22:11:23]

#

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.

:) :) :)

Grez [11.01.2022 13:30:13]

#

TapaniS kirjoitti:

Ja sanoisin, että ei tämä ihan "perinteiseltä ohjelmointikisalta" vaikuta.

Tämähän onkin hakkerointikilpailu

Metabolix [15.01.2022 13:59:10]

#

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.

Metabolix [26.01.2022 08:15:05]

#

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.


Sivun alkuun

Vastaus

Muista lukea kirjoitusohjeet.
Tietoa sivustosta