Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.

And! 09 Lut 2018 18:57 2352 12
  • #1 09 Lut 2018 18:57
    And!
    Admin grupy Projektowanie

    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.
    Poprzedni CTF 01.2018 miał nieco wspólnego ze steganografią. Po licznych wiadomościach od Was, CTF 02.2018 jest związany ze sprzętem. Prawdopodobnie możliwe jest użycie emulatorów i analizy, ale w założeniu użycie sprzętu ma ułatwiać zadanie. Jaki sposób znalezienia flagi będzie optymalny? to się okaże. Sposób wyciągnięcia flagi jak zawsze dowolny. Czas zabawy do 09.03.2018 i jeżeli nie pojawi się odpowiedź to umieszczę rozwiązanie. Możliwe, że będą pojawiać się jakieś podpowiedzi gdy będzie to potrzebne. Jeżeli będziecie potrzebowali konkretnych podpowiedzi napiszcie o tym w temacie.






    W CTF ukryta jest jedna flaga i pierwsza osoba która umieści w temacie post z prawidłową flagą otrzyma niespodziankę od gulson,
    moduł ESP32 z wyświetlaczem OLED.

    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.

    Ponieważ flaga jest jedna i moduł też 1 szt. to będzie jeden wygrany, liczy się szybkość i warto umieścić post w temacie z odkrytą flagą jak najszybciej, liczy się data umieszczenia postu, edytowane posty będą traktowane jako umieszczone z datą ostatniej edycji.

    Zależy mi aby osoba która umieści flagę, później na spokojnie w kolejnym poście opisała jak udało się dotrzeć do ukrytej flagi,
    jakie były trudności, co było ciekawe co można ulepszyć. W materiale poza opisem można umieścić zrzuty ekranu lub nawet film (szczególnie że w tym CTF staramy się odnosić do sprzętu) lub screan cast.

    Flaga jest ciągiem znaków w formacie: CTF-(tutajTrescFlagi) czyli przykładowa flaga mogłaby wyglądać tak:
    CTF-(elektroda.pl)

    W wielu zabawach CTF można wprowadzić flagę do formularza online i sprawdzić czy jest prawidłowa,
    w naszym CTF gdy znajdziecie flagę należy napisać post w tym temacie z treścią flagi oraz w kolejnym poście na spokojnie opisać jak flaga została zdobyta, odpowiem i potwierdzę czy zgłoszona flaga jest prawidłowa czy też nie.

    Zgłaszając flagę koniecznie zachowajcie wielkość liter.
    Gdy będziecie umieszczać post z flagą warto dodać @And! w treści postu, dostanę wtedy powiadomienie abym nie przegapił zgłoszenia i odpowiem czy flaga jest prawidłowa.

    Zapraszam do zabawy, poniżej treść CTF z ukrytą flagą:
    ATmega..hex Download (16.7 kB)

  • #2 11 Lut 2018 03:39
    akrasuski1
    Poziom 7  

    Flaga to: CTF-(JEST-LUTY-PODKUJ-BUTY)
    (w zasadzie CTF-(JEST-LUTY-PODKUJ-BUTY? ze znakiem zapytania na końcu, ale zakładam że to błąd typograficzny)

    Oznaczam @And!

    Dodano po 1 [godziny] 30 [minuty]:

    Większość kodu przeanalizowałem statycznie, wyjątkiem jest tutaj część DTMF - szczegóły niżej. Opowiadać będę jednak głównie z perspektywy tego, co robi atmega, a niekoniecznie tego, co się dzieje "w środku".

    Po załadowaniu ROM-u na Atmegę8, podłączamy się do UART-a. Baud to u mnie nietypowe 4800, ale tylko dlatego, że korzystałem z wewnętrznego oscylatora 8MHz - chip miał działać pod 16MHz. Dlaczego o tym wiem - zaraz. Na konsoli dostajemy:

    Cytat:
    Press enter to continue...


    Naciskamy więc enter, i dalej widzimy kolejno:

    Cytat:
    440Hz tone detected...
    Dialing number...
    Sending login...
    Sending data...
    Enter valid number...


    Wpsiujemy dowolny numer, i odpowiadamy na kilka kolejnych pytań, by ostatecznie dostać:

    Cytat:
    Entered number:
    123456789
    Enter user name...
    Entered user name:
    someone
    Enter user password...
    Entered user password:
    hunter1
    What you get depends on what you give...
    Now the bits are spinning like a crazy!


    Pogrubione słowa to rzeczy wpisane przeze mnie. No dobrze, ale co dalej? No cóż, ATmega8 ma więcej pinów niż tylko dwa odpowiadające za UART, możnaby więc sprawdzić czy coś się na nich dzieje - tym bardziej że jest jakaś sugestia, że coś jest wysyłane.

    Istotnie, patrząc na resztę pinów, widzimy przebiegi - na przykład na oscyloskopie - na dwóch pinach (PB1 i PB3). Po ostatniej wypisanej linijce, dodatkowo zmieniają się piny PD1 do PD7. Oscyloskopu co prawda nie mam, ale dzieje się to na tyle wolno, że można nagrać przebiegi za pomocą gniazda mikrofonu od komputera. Gniazdo to ma u mnie dwa wejścia, więc tym fajniej, bo mogę PB1 i PB3 widzieć naraz.

    Całe nagranie (do momentu przed ostatnią linijką, potem nic ciekawego) umieszczam w załączniku.

    Pierwsza rzecz, to ton 440Hz, zgodnie z treścią. Właśnie po tym poznałem, że moja ATmega chodzi zbyt wolno - dostawałem tu okolice 220Hz. Brawa dla autora za pomyślenie o tym testowym tonie. :) Nagranie zostało sztucznie przyspieszone, więc następne dźwięki są poprawne.

    Dalej słyszymy - chociaż bardziej to widać naocznie na podglądzie fali - impulsy następujące grupami, tak jakby były wybierane telefonem tarczowym, np:
    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.





    Na zdjęciu można naliczyć 6 impulsów. Zbierając w całość 9 podobnych grup, dostajemy pełen numer: 161803398. Na wypadek jakby ktoś chciał faktycznie pod ten numer dzwonić, uprzedzam że jest to przybliżenie rozwinięcia złotego podziału ;)

    Następnie mamy kilkanaście impulsów o różniących się częstotliwościach:
    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.

    Zawsze występują naraz dwa tony, jeden na kanale lewym, drugi na kanale drugim, pierwszy o częstotliwościach rzędu 1300Hz, drugi - rzędu 800Hz. Kto słyszał o kodowaniu DTMF (Dual Tone Multi-Frequency), od razu je rozpozna. Tony te otrzymuje się we współczesnych telefonach po naciśnięciu klawiszy numerycznych. Przepisując częstotliwości, dostajemy takie wartości:

    Code:

    # HIGH | LOW | n
    # -----+-----+---
    # 1520 | 800 | 2
    # 1360 | 880 | 1
    # 1520 | 720 | 2
    # 1230 | 880 | 4
    # 1360 | 800 | 3
    # 1360 | 720 | 1


    Częstotliwości są przybliżone (rozrzut wynika z niedokładności zegaru ATmegi), ale porównując je z wartościami z Wiipedii, wiemy że naciśnięte zostały kolejno klawisze 683752. W tabelce powyżej dodałem także trzecią kolumnę, w której umieściłem ilość powtórzeń danego przycisku. Nasuwa się na myśl klawiatura numeryczna jak na klasycznych komórkach:
    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.
    Traktując ilość naciśnięć klawiszy tak, jakbyśmy pisali SMS-a na starej Nokii, dostajemy: "ntesla", zapewne od Nikoli Tesli. Można się domyślać, że jest to login, o który nas poproszono.

    Kolejna część okazała się dla mnie najtrudniejsza. Ponownie otrzymujemy słyszalny dźwięk - tym razem jest to "ćwierkanie" przeskakujące szybko (co około 22ms) między dwoma częstotliwościami, w przybliżeniu 1450Hz i 1280Hz. Dźwięk ten był dla mnie znajomy, ale nie mogłem sobie w żaden sposób przypomnieć skąd.

    Tym razem moje rozwiązanie wspierało się bezpośrednio na informacji z kodu. Nie wgłębiając się w szczegóły, można tam znaleźć funkcję która generuje ten sygnał, i co ciekawe, wysyła kolejno ton A, pięć bitów danych o różnych tonach, i ton B. Jest to więc jakiś kod pięciobitowy.

    Dalej można iść dwojako: albo przetranskrybować (ręcznie bądź jakimś mądrym skryptem) wspomniane 5-bitowe słowa z nagrania, albo jak to ja zrobiłem, zdumpować odpowiedni ciąg z otrzymanej binarki. Ciąg ten to:

    Code:
    1f181b15150d0d101f181b0d101f101b0c1f161b031f1218181b1501150a1f180e181b0c0a1c0a191f130e0e1b191f131b0d011f161b011f101b0c0d00


    Przyznam się, że trochę czasu mi nad tym zeszło. Popularnych kodów pięciobitowych nie ma tak wiele - w tym wypadku jest to Baudot, stary kod telegraficzny. Zapomniałem jednak że nadaje się w nim od najmłodszego bitu, co powodowało problemy w dekodowaniu. Kod do dekodowania napisałem w Pythonie:

    Kod: python
    Zaloguj się, aby zobaczyć kod


    Wypisany tekst to: "A66003A03E8F9DAA6564ACA84742BCC2B05F5E80@". Oprócz ostatniego znaku, który to jest artefaktem kończenia stringów bajtem zerowym w C, mamy 40 znaków szesnastkowych. Brzmi to jak jakiś hash - i istotnie, po wklejeniu go do internetowych tablic tęczowych, dostajemy słowo, które po zhashowaniu SHA-1 daje właśnie ten ciąg: "widikon". Tematycznie, jest to element starych kamer telewizyjnych. W naszym CTF-ie słowo to pełni funkcję hasła.

    Wpiszmy więc poprawne odpowiedzi na wszystkie trzy pytania:

    Cytat:

    Press enter to continue...
    440Hz tone detected...
    Dialing number...
    Sending login...
    Sending data...
    Enter valid number...
    Entered number:
    161803398
    Enter user name...
    Entered user name:
    ntesla
    Enter user password...
    Entered user password:
    widikon
    What you get depends on what you give...
    Now the bits are spinning like a crazy!


    Jeśli podłączymy jakieś diody pod piny D1-D7, powinny zacząć migać w sposób na pierwszy rzut oka średniolosowy. Pewne zależności widać, ale nie jest to żaden łatwy kod. Mignięć jest przynajmniej kilkadziesiąt, co po przemnożeniu przez 7 bitów oznaczałoby kilkaset bitów do zapisania lub zarejestrowania np. analizatorem logicznym, tudzież portem równoległym. Ja jednak ponownie uciekłem się do analizy statycznej kodu, i przepisałem kod assemblera AVR do Pythona:

    Kod: python
    Zaloguj się, aby zobaczyć kod

    Na wyjściu otrzymujemy:

    Code:

    [
    124, 130, 130, 130, 130, 68, 0, 128, 128, 254, 128, 128, 0, 0, 254,
    144, 144, 144, 128, 0, 0, 0, 48, 48, 48, 48, 48, 0, 0, 0, 56, 68, 130, 0, 0,
    6, 2, 2, 252, 0, 0, 0, 254, 146, 146, 146, 130, 130, 0, 36, 82, 146, 146,
    138, 100, 0, 128, 128, 254, 128, 128, 0, 0, 0, 48, 48, 48, 48, 48, 0,
    254, 2, 2, 2, 2, 0, 0, 252, 2, 2, 2, 252, 0, 0, 128, 128, 254, 128, 128,
    0, 0, 192, 32, 30, 32, 192, 0, 0, 0, 48, 48, 48, 48, 48, 0, 254, 144, 144,
    144, 96, 0, 0, 124, 130, 130, 130, 124, 0, 0, 254, 130, 130, 130, 124,
    0, 0, 254, 24, 40, 68, 130, 0, 0, 252, 2, 2, 2, 252, 0, 0, 6, 2, 2, 252, 0, 0,
    0, 0, 48, 48, 48, 48, 48, 0, 254, 146, 146, 146, 108, 0, 0, 252, 2, 2, 2,
    252, 0, 0, 128, 128, 254, 128, 128, 0, 0, 192, 32, 30, 32, 192, 0, 0, 96,
    128, 138, 144, 96, 0, 0
    ]


    Ponownie, nie jest to żaden rozpoznawalny kod w stylu ASCII (mimo że również 7-bitowy). Po paru chwilach namysłu, dochodzimy do wniosku że wartoby wypisać te liczby bitowo. Od tyłu. I zamiast zer spacje, a jedynek hashe:

    Kod: python
    Zaloguj się, aby zobaczyć kod


    Ostatecznie dostaniemy obróconą o 90 stopni flagę, której początek to:

    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.

    Cała flaga wychodzi tak, jak to napisałem w pierwszym zdaniu postu.

    Przepraszam za brak wcięć w kodzie - elektroda niestety je wycina. Admini - może warto to naprawić, skoro jesteśmy na forum o powiązanej tematyce :P

    Ogólnie, CTF mi się podobał. Fajne wykorzystanie starych technologii. Ciekawy jestem czy autor testował na prawdziwym sprzęcie - na przykład czy miał urządzenie odbierające kod Baudota :). Ostatni etap pewnie dałoby się zrobić na przesuwającym się pasku LED-ów, to byśmy dostali baner z wyświetlającą sie flagą.

  • #3 11 Lut 2018 09:24
    And!
    Admin grupy Projektowanie

    @akrasuski1 bardzo fajna analiza, gratulacje!
    Skontaktuj się z gulson celem wysyłki modułu ESP32+OLED, jeżeli uda się zrealizować coś ciekawego to warto zaprezentować w DIY

    W wolnej chwili jeżeli miałbyś ochotę to można zaprezentować w skrócie w jaki sposób i jakimi narzędziami wykonujesz analizę statyczną kodu,
    myślę że to może zainteresować wiele osób w zastosowaniach także poza CTF. Można to napisać "na luzie" w tym temacie, lub w sposób bardziej profesjonalny w Artykułach i w tym temacie zalinkować.

    Co do kodu w ptyhon, niestety rozsypuje się on w formatowaniu na forum, jest to zgłoszone, można sobie z tym poradzić umieszczając go jako załącznik.

    Co do flagi znak "?" znajduje się na końcu ciągu, jest nieco koślawy ale jest :)

    Numer telefonu (chyba) nie istnieje, ale było by super gdyby kiedyś CTF posiadał jakiś prawdziwy numer telefoniczny lub adres IP z którym należy się połączyć, ale na razie brak na to zasobów. Kiedyś można było kupić prepaid na miesiąc CTF uruchomić urządzenie odbierające rozmowy co byłoby elementem CTF, a później taką kartę SIM zutylizować na koniec zabawy. Niektóre firmy umieszczają takie "hackme" na rzeczywistych adresach IP np. tematyka związana z KNX + stream wideo z tego co dzieje się z urządzeniem podczas prób.

    Ponieważ CTF był sprzętowy to kod był testowany w "rzeczywistych" warunkach i zostało to zlecone "na zewnątrz" a efekty testów załączam w formie filmów.

    Podpowiedzią, którą miałem w zanadrzu był schemat, gdzie rezystor 8om to oczywiście głośnik,
    taki układ wykorzystany był przy testach. Okazało się że podpowiedzi nie były potrzebne :)

    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.

    Wybieranie impulsowe to był dość prosty element CTF i obserwacja przebiegu czasowego wyjaśniała wszystko, liczba impulsów to kolejna cyfra numeru poza "0" któremu przypadało 10 impulsów.



    Etap z DTMF można zdekodować np. aplikacją uruchomioną na smartfonie, później pozostaje wpaść na pomysł i zmapowanie cyfr na klawiaturę telefonu. Przebieg prostokątny ma wiele harmonicznych ale oprogramowanie sobie z tym radzi:



    Do zdekodowania RTTY i kodu Baudot można użyć aplikacji na PC:



    Na koniec pozostaje odczytanie flagi, można wykorzystać 7 LED podłączonych do portu PD i potraktować jako wyświetlacz widmowy, odpowiednio szybko kręcąc płytką. Flagę można wtedy zobaczyć okiem, lub zrobić zdjęcie:



    Dziękuję wszystkim za udział w zabawie!
    Możecie napisać do jakiego etapu i jakimi metodami udało się Wam dotrzeć.

  • #4 11 Lut 2018 19:56
    akrasuski1
    Poziom 7  

    And! napisał:
    W wolnej chwili jeżeli miałbyś ochotę to można zaprezentować w skrócie w jaki sposób i jakimi narzędziami wykonujesz analizę statyczną kodu,
    myślę że to może zainteresować wiele osób w zastosowaniach także poza CTF. Można to napisać "na luzie" w tym temacie, lub w sposób bardziej profesjonalny w Artykułach i w tym temacie zalinkować.


    Co tu dużo mówić, trzeba odpowiednio długo przesiedzieć nad kodem, stopniowo go upraszczając do jak najmniej skomplikowanej formy. Przykładowo biorąc ostatni fragment głównej pętli, odpowiadający za wyświetlanie flagi na LED-ach, oryginalny kod prosto z disassemblera to:

    Kod: avrasm
    Zaloguj się, aby zobaczyć kod


    Poniżej wklejam kilka kolejnych kroków upraszczania:

    Kod: avrasm
    Zaloguj się, aby zobaczyć kod


    Kod: avrasm
    Zaloguj się, aby zobaczyć kod


    Kod: avrasm
    Zaloguj się, aby zobaczyć kod


    Kod: avrasm
    Zaloguj się, aby zobaczyć kod


    I ta ostatnia wersja już jest w zasadzie równoważna mojemu kodowi Pythonowemu (dwóm zagnieżdżonym pętlom for - cały powyższy kod był bowiem w pętli). I tyle, trochę czasu i jakoś to idzie! :)

  • #5 11 Lut 2018 21:54
    And!
    Admin grupy Projektowanie

    Dobre pokazanie krok po kroku.
    Przydałby się jeszcze krótki tutorial jak przełamać barierę pliku .hex i podstawy pracy z wybranym disassemblerem,
    następnym krokiem byłoby właśnie to co opisałeś.

    Które tęczowe tablice złamały hasz ze słowa "widikon" ?
    Sprawdziłem kilka aby zachęcić do użycia np. hascat/john jednocześnie dobierając hasło tak aby liczyło się max 5-15min.

  • #6 11 Lut 2018 22:15
    akrasuski1
    Poziom 7  

    Pierwsze co wyskoczyło w google na "sha1 cracker": https://hashkiller.co.uk/sha1-decrypter.aspx.. Wpisujemy nasz hash, i od razu dostajemy słowo :)

    Co do przejścia hex -> disasm, to można na przykład (pod linuksem, na windowsie pewnie analogicznie):

    Code:

    $ avr-objcopy -I ihex -O elf32-avr ATmega8.hex ATmega8.elf
    $ avr-objdump -D ATmega8.elf > ATmega8.asm
    $ cat ATmega8.asm | grep 161e: -A 8
        161e:   e1 ee          ldi   r30, 0xE1   ; 225
        1620:   f0 e0          ldi   r31, 0x00   ; 0
        1622:   ec 0f          add   r30, r28
        1624:   fd 1f          adc   r31, r29
        1626:   e5 0d          add   r30, r5
        1628:   f1 1d          adc   r31, r1
        162a:   40 81          ld   r20, Z
        162c:   e4 2d          mov   r30, r4
        162e:   f0 e0          ldi   r31, 0x00   ; 0

  • #8 11 Lut 2018 23:43
    akrasuski1
    Poziom 7  

    @miszczo997, na AVR-ach jest o tyle ciekawa sytuacja, że domyślnie stringi są kopiowane z Flasha do RAM-u podczas inicjalizacji. Można więc powiedzieć że tu i tu. RAM-u oczywiście w hexie nie mamy, bo to pamięć ulotna, natomiast na szczęście autor użył funkcji czytających stringi z Flasha, np:

    Kod: avrasm
    Zaloguj się, aby zobaczyć kod


    Jeśli chcemy się dowiedzieć co to za dane tam siedzą, można wykonać następujace operacje:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Dodano po 1 [godziny] 8 [minuty]:

    A ja jeszcze sobie pozwolę dorzucić jeden sposób prawie-rozwiązania, w celu przestrogi przed implementacją szyfrów własnoręcznie. Kolega @And! może niech spróbuje rozgryźć jak działa kod:

    Kod: python
    Zaloguj się, aby zobaczyć kod


    Efekt, może nie jakoś super czytelny, ale od biedy da się coś zauważyć:

    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.

    I to z pominięciem trzech pierwszych etapów!

  • #9 12 Lut 2018 17:46
    And!
    Admin grupy Projektowanie

    @akrasuski1 brawo, byłem ciekawy czy ktoś to zauważy,
    jest to luźne nawiązanie do trybów pracy szyfrów blokowych,
    oraz tego że niewłaściwy tryb pracy np. ECB zamiast CBC może ujawniać treść plaintextu.

    Dość znany przykład z szyfrowaniem bitmapy:
    CTF 02.2018 sekcji projektowanie i tworzenie - hardware rules.
    Mimo że użyjemy silnego algorytmu np. AES to takie same bloki plaintextu zamienią się w identyczne bloki szyfru,
    efektem może ujawnienie zaszyfrowanej informacji lub np. ataki replay.

    Natomiast co do kodu, czy to coś w rodzaju autokorelacji?

  • #10 24 Lut 2018 19:42
    And!
    Admin grupy Projektowanie

    @akrasuski1 czy udało się zrealizować jakiś ciekawy pomysł na ESP32+OLED?
    Przenośny miniaturowy komputerek z WiFi daje sporo możliwości, zarówno w zastosowaniach mobilnych, pentestowych a także codziennych sytuacjach gdzie gadżet z OLED i połączeniem do internetu wniesie coś fajnego.

  • #11 24 Lut 2018 20:55
    akrasuski1
    Poziom 7  

    Byłem ostatnimi dniami za granicą, więc nie bardzo miałem czas - ale coś się wykombinuje!

    Cytat:
    Natomiast co do kodu, czy to coś w rodzaju autokorelacji?


    Autokorelacja to może za dużo powiedziane - bardziej bym tu zauważył pokrewieństwo z szyfrem Vigenere'a, tylko odmianą "binarną", którą można interpretować jako alfabet dwuznakowy zamiast dwudziestosześcioznakowego.

    Tradycyjnie analiza dłuższego tekstu zaszyfrowanego Vigenerem polega na pogrupowaniu znaków na pozycjach [0, k, 2*k, 3*k, ...], [1, k+1, 2*k+1, ...], ..., gdzie k to długość nieznanego klucza. Następnie można przeprowadzić analizę częstotliwościową - w uproszczeniu, najczęściej występująca litera w danej grupie prawdopodobnie odpowiada najczęściej występującej literze w tekście naturalnym - np. E w języku angielskim.

    W naszym przypadku mamy prościej i trudniej zarazem. Prościej, bo alfabet tylko dwuznakowy - częściej występującą "literą" jest zero, czyli niezaświecony LED. Trudniej, bo mamy dość krótki tekst w porównaniu do klucza - "grupy" opisane wyżej mają u nas tylko około 6 elementów, co jest dość kiepską statystyką. Oba te efekty w sumie dają jednak jakiś w miarę sensowny wynik - gdybym musiał, to myślę że dałoby się ręcznie naprawić rezultat tak by dał czytelny obraz.

    W zasadzie da się oszacować prawdopodobieństwo że dany piksel da dobry wynik - we fladze mamy 976 zera i 347 jedynek (odpowiednio LED zgaszony i zapalony). Daje to rozkład 74% zer i 26% jedynek. Mamy teraz próbę sześciu znaków i zgadujemy że ten bardziej popularny to zero (w przypadku remisu strzelamy).

    No to jaka jest szansa że trafimy? Taka jak to, że w tych sześciu znakach wylosowaliśmy cztery lub więcej zer (plus połowa szansy na trzy zera). Można to dość nieźle zamodelować zwykłym rozkładem dwumianowym:

    $$0.5\binom{6}{3}0.74^{3}0.26^{3} + \sum^6_{k=4}\binom{6}{k}0.74^{k}0.26^{6-k}=
    $$$$0.5\binom{6}{3}0.74^{3}0.26^{3} + \binom{6}{4}0.74^40.26^2 + \binom{6}{5}0.74^50.26^1 + \binom{6}{6}0.74^60.26^0=
    $$$$0.071 + 0.304 + 0.346 + 0.164 = 0.885
    $$

    Czyli prawie 90% pikseli średnio mamy poprawnie.

  • #12 24 Lut 2018 22:26
    And!
    Admin grupy Projektowanie

    Gdy pisałem ostatni etap na początku pomyślałem aby wygenerować ciąg danych o długości bufora w flash.
    Ciąg generowany poprzez modyfikację danych wejściowych dla np. algorytmu mieszającego wypluwającego kolejne np. 20 bajtów. Początkowe dane wejściowe zależne od wprowadzonych poprzez UART. Następnie wykonać XOR bufora w flash z wygenerowanym i przesłać na port LED.

    Później pomyślałem aby to uprościć i zrobić coś jak CBC w AES operując na "bloku" o długości jednego bajta.

    Ostatecznie pomyślałem, że zostawię taką lukę. Szczególnie, że liczne zerowe bajty ujawniały kolejne bajty klucza.

    Jeszcze jednym uproszczeniem był brak konwersji 7 bitowych danych dla LED do grup 8 bitowych.

    Zostawiłem jako ciekawostkę, ale nie miałem pojęcia czy jeżeli ktoś to zauważy, to czy uda się to wykorzystać w praktyce do czegokolwiek.
    Teraz wiem że jest to możliwe do wykorzystania!
    Zastanawiam się jedynie czy jest to lepiej widoczne z poziomu "white box", czy też z poziomu "black box" jest to równie dostrzegalne?

    Zauważyłem że przy tworzeniu CTF zawsze jest problem z ustaleniem "środka ciężkości" z jednej strony nie może być zbyt prosty, z drugiej strony nie może być zbyt trudny i zniechęcający. Np. dla mnie ważne jest aby zawierał coś ciekawego dla odbiorcy, a także aby całość w miarę układała się w jakąś tematyczną "historię".
    Tworząc CTF można też bardzo dużo się nauczyć samemu, np. w pierwszym odcinku testowej serii CTF 11.2017 dowiedziałem się coś o SIRDS i chyba pierwszy raz udało mi się go zobaczyć :)
    Bardzo dużo wynika też z komentarzy, czasami więcej niż z samego CTF.

    Jeżeli z modułu uda się uzyskać coś fajnego, lub będziesz miał jakieś ciekawe przemyślenia z pracy z modułem to zapraszam do podzielenia się w:
    DIY lub Artykułach.

    Kiedyś udostępnialiśmy ESP32 bez OLED i co zaskakujące pozwalał on na uruchomienie ułomnego (słabe DAC) radia internetowego:
    Radio internetowe na ESP32
    wbudowany OLED może też wielu osobom ułatwić wizualiację zabawy z DSP (prymitywne ADC i DAC są na płytce):
    FFT na ESP32

  Szukaj w 5mln produktów