Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Czy da się odczytać zabezpieczony mikrokontroler?

tmf 08 Jan 2023 11:06 3510 29
  • Witam Was w kolejnej odsłonie moich miniporadników. Ponieważ nie ma tygodnia, aby nie padło pytanie jak w tytule – czy da się odczytać mikrokontroler, ew. to samo inaczej sformułowane – jak skopiować zawartość MCU, więc postanowiłem o tym trochę opowiedzieć.
    W tym odcinku będzie o tym jak odczytać zawartość MCU, co uzyskamy, jeśli będzie on zabezpieczony i jak poznać, że MCU jest zabezpieczony. Oczywiście przy okazji nie sposób nie wspomnieć o lockbitach.



    Miłego oglądania!

    Cool? Ranking DIY
    About Author
    tmf
    Moderator of Microcontroller designs
    Offline 
  • #2
    silvvester
    Level 25  
    To zróbcie w końcu na elektrodzie zrzutkę i dajcie dowód na możliwość odczytania zabezpieczonego flash`a. Na razie widzę próbę wyłudzenia kasy i reklamę tego procederu.
  • #3
    tmf
    Moderator of Microcontroller designs
    silvvester wrote:
    o zróbcie w końcu na elektrodzie zrzutkę i dajcie dowód na możliwość odczytania zabezpieczonego flash`a. Na razie widzę próbę wyłudzenia kasy i reklamę tego procederu.

    Na razie to widzę, że nawet nie przeglądnąłeś materiału, ale musiałeś się wypowiedzieć. Proponuję jednak najpierw zobaczyć, potem się wypowiadać.
  • #4
    krzbor
    Level 24  
    Na EP był cykl artykułów o zabezpieczeniach. Tekst ma już 20 lat, ale można się dowiedzieć kilku ciekawych rzeczy:
    Część 1
    Część 2
    Część 3
  • #5
    tmf
    Moderator of Microcontroller designs
    krzbor wrote:
    Na EP był cykl artykułów o zabezpieczeniach. Tekst ma już 20 lat, ale można się dowiedzieć kilku ciekawych rzeczy:

    Pewne rzeczy, pomimo upływu lat się aż tak bardzo nie zmieniają. Ciekawa i wartościowa seria artykułów. Co ciekawe, jeśli mówimy o łamaniu zabezpieczeń, to dzięki postępowi technologii i temu, że dzisiaj w "garażu" możemy mieć sprzęt, który 20 lat temu było może w jakiś laboratoriach, albo był piekielnie drogi, także łamanie zabezpieczeń wydaje się być bardziej dostępne dla chcących.
  • #6
    krzbor
    Level 24  
    Zaciekawił mnie opis zabezpieczenia w trzeciej części polegającego na elektrycznym uszkodzeniu wejść procesora koniecznych do odczytania zawartości. Wówczas odczyt jest możliwy tylko w sposób inwazyjny. Oczywiście uszkodzone wejścia nie mogą być używane w układzie. Ciekawe, czy w ten sposób można zabezpieczyć ESP8285?
  • #7
    khoam
    Level 41  
    krzbor wrote:
    Ciekawe, czy w ten sposób można zabezpieczyć ESP8285?

    Nie. W ESP8266 (czyli też ESP8285) nie ma żadnych mechanizmów zabezpieczenia flash przed odczytem. Takie mechanizmy występują w rodzinie ESP32. Link
  • #8
    krzbor
    Level 24  
    khoam wrote:
    krzbor wrote:
    Ciekawe, czy w ten sposób można zabezpieczyć ESP8285?

    Nie. W ESP8266 (czyli też ESP8285) nie ma żadnych mechanizmów zabezpieczenia flash przed odczytem. Takie mechanizmy występują w rodzinie ESP32. Link

    ESP8285 ma flash wbudowany. Jeśli uszkodzimy Rx lub Tx to chyba nie można nic odczytać?
    Link, który podałeś zawiera ciekawe informacje.
  • #9
    khoam
    Level 41  
    krzbor wrote:
    Jeśli uszkodzimy Rx lub Tx to chyba nie można nic odczytać?

    Po co uszkadzać, wystarczy w bootloaderze przekierować te piny na nieistniejące :)
  • #10
    krzbor
    Level 24  
    khoam wrote:
    krzbor wrote:
    Jeśli uszkodzimy Rx lub Tx to chyba nie można nic odczytać?

    Po co uszkadzać, wystarczy w bootloaderze przekierować te piny na nieistniejące :)

    Moje rozważania są czysto teoretyczne, ale fizyczne uszkodzenie jednego z pinów oznacza brak możliwości odczytu nawet przy sztuczkach typu skoki napięcia, zmiana taktowania. Nawet znajdując jakikolwiek błąd w projekcie procesora nie można się dostać do zawartości flash inaczej jak metodami inwazyjnymi. Oczywiście myślę o ESP8285 z wbudowanym flash.
  • #11
    khoam
    Level 41  
    krzbor wrote:
    Oczywiście myślę o ESP8285 z wbudowanym flash.

    Ale ten flash jest tylko wbudowany w obudowę i komunikuję się po SPI z MCU. Te linie są dostępne na zewnątrz jako piny SDIO_CMD, SDIO_CLK, SDIO_DATA_0 oraz SDIO_DATA_1, więc jak ktoś się uprze może odczytać "wewnętrzny" flash bez uruchamiania MCU. Problemem jest brak możliwości zaszyfrowania zawartości flash w ESP8266.
  • #12
    silvvester
    Level 25  
    tmf wrote:
    Na razie to widzę, że nawet nie przeglądnąłeś materiału, ale musiałeś się wypowiedzieć. Proponuję jednak najpierw zobaczyć, potem się wypowiadać.


    Obejrzałem jak najbardziej z czystej ciekawości, aby się dowiedzieć czegoś czego jeszcze nie wiem. Powiem tak, mamy więcej dowodów na istnienie ufo niż dowodów na wyciągnięcie pamięci z dzisiejszych kontrolerów. Jeżeli jestem w błędzie, na pewno w całych internetach znajdzie się jeden człowiek który z błędu mnie wyprowadzi i da w końcu dowód na wyciągnięcie flasha z zabezpieczonego kontrolera.

    Przez ostatnie 2 lata mamy niedobór półprzewodników, wyrosły dziesiątki firmy które "mają" na magazynie wszystko, pierwsza z brzegu.
    https://www.trustpilot.com/review/micro-semiconductor.com


    I wg. mnie firmy które oferują usługę wyłuskania flasha z kontrolera działają tak samo. 95% z nich kradnie, być może 5% oferuje taka usługę. Ciężko powiedzieć, bo dowodów brak.
  • #13
    konrad92
    Level 15  
    silvvester wrote:
    To zróbcie w końcu na elektrodzie zrzutkę i dajcie dowód na możliwość odczytania zabezpieczonego flash`a. Na razie widzę próbę wyłudzenia kasy i reklamę tego procederu.


    Otóż da się. Trzy lata temu miałem okazję sprawdzić to na własnym przykładzie. Sytuacja była dość prosta - uszkodził się dysk twardy na którym trzymałem firmware do procków (bez backupu), które były częścią większego modułu. Sytuacja była dość paląca i powtórne napisanie firmware było niemożliwe ze względu na czas.
    Trochę poszperałem i pokazało się kilka firm w chinach które odczytują flash i eeprom z MCU, ceny takich usług są uzależnione od typu procka. Wtedy dla megi32 płaciłem ok. 200USD + wysyłka 1 sztuki procka. Po tygodniu od doręczenia dostałem hexy na maila.
  • #14
    Seba_smd
    Level 16  
    konrad92 wrote:
    silvvester wrote:
    To zróbcie w końcu na elektrodzie zrzutkę i dajcie dowód na możliwość odczytania zabezpieczonego flash`a. Na razie widzę próbę wyłudzenia kasy i reklamę tego procederu.


    Otóż da się. Trzy lata temu miałem okazję sprawdzić to na własnym przykładzie. Sytuacja była dość prosta - uszkodził się dysk twardy na którym trzymałem firmware do procków (bez backupu), które były częścią większego modułu. Sytuacja była dość paląca i powtórne napisanie firmware było niemożliwe ze względu na czas.
    Trochę poszperałem i pokazało się kilka firm w chinach które odczytują flash i eeprom z MCU, ceny takich usług są uzależnione od typu procka. Wtedy dla megi32 płaciłem ok. 200USD + wysyłka 1 sztuki procka. Po tygodniu od doręczenia dostałem hexy na maila.


    Możesz podać strony ??
  • #15
    acctr
    Level 26  
    silvvester wrote:
    znajdzie się jeden człowiek który z błędu mnie wyprowadzi i da w końcu dowód na wyciągnięcie flasha z zabezpieczonego kontrolera

    Ale wiesz, że taki dowód ma swoją cenę?
  • #16
    neo_84
    Level 15  
    silvvester wrote:
    To zróbcie w końcu na elektrodzie zrzutkę i dajcie dowód na możliwość odczytania zabezpieczonego flash`a. Na razie widzę próbę wyłudzenia kasy i reklamę tego procederu.

    Oj niewierny Tomasz z Ciebie :D
    Ten gość wyciaga flasza i to na raz Czy da się odczytać zabezpieczony mikrokontroler?
    Notabene co tu jest nie do uwierzenia ? Ludzie włamują się do najnowszych aut podrabiają karty bankomatowe potrafią wyciągać zawartość pamięci z uszkodzonych kart pamięci dysków itp łamanie szyfrów (enigma) . Ba człowiek był nawet na księżycu :lol: A ty uważasz ze np z jakiegoś AVR nie da się wyciągnąć wsadu...
  • #17
    LightOfWinter
    Level 35  
    silvvester wrote:
    To zróbcie w końcu na elektrodzie zrzutkę i dajcie dowód na możliwość odczytania zabezpieczonego flash`a. Na razie widzę próbę wyłudzenia kasy i reklamę tego procederu.


    Witam
    Przecież ta kwestia jest całkiem nieźle opisana. Po co wyważać otwarte drzwi?

    Zobacz np. cykl artykułów "Atak na mikrokontrolery" w EP.
    Cz1.
    https://ep.com.pl/files/8088.pdf
    Cz2.
    https://ep.com.pl/files/8110.pdf

    W cz2. Masz opisane - nieinwazyjne metody ataku.
  • #18
    kekon
    Level 19  
    neo_84 wrote:
    Ludzie włamują się do najnowszych aut podrabiają karty bankomatowe potrafią wyciągać zawartość pamięci z uszkodzonych kart pamięci dysków itp łamanie szyfrów (enigma) .


    Nie ma 100% zabezpieczeń; można co najwyżej zrobić je tak, aby wymagały ogromnej ilości czasu do złamania i sporych kosztów co sprawia, że jest to nieopłacalne.

    W mojej firmie używamy m.in. mikrokontrolerów firmy Renesas rodziny RL78. Gdy już jakoś je "ogarnąłem" (nauka kolejnego mikrokontrolera jest już po prostu nudna) szukałem w dokumentacji jak zabezpieczyć flash przed odczytem. I ku mojemu zdziwieniu okazało się, że nie ma takich zabezpieczeń bo po prostu nie ma możliwości odczytu pamięci. Nie można tego zrobić nawet oryginalnym programatorem. Programowanie odbywa się przez zwykły UART (tyle że 1 przewodowy) i w protokole transmisji nie ma komend do odczytu.
  • #19
    acctr
    Level 26  
    kekon wrote:
    Nie można tego zrobić nawet oryginalnym programatorem.

    Protokół programowania tego procka uwzględnia weryfikację kodu. A nuż można z tego wykombinować jakiś wyłuskiwacz kodu.
    Albo nadpisać swoim kodem, który sczytuje flasha i podaje na seriala.
  • #20
    kekon
    Level 19  
    acctr wrote:
    Protokół programowania tego procka uwzględnia weryfikację kodu. A nuż można z tego wykombinować jakiś wyłuskiwacz kodu.


    Zgadza się, jednak z tego nie da się "wyłuskać" kodu.

    Teoretycznie lepsza jest druga opcja - nadpisać swoim kodem i podać na seriala. Problem w tym, że ten kod trzeba jakoś uruchomić (sprawić aby oryginalny program skoczył do naszego kodu i zaczął go wykonywać i to pod warunkiem że zmieści się wszystko w pamięci)

    Warto jeszcze wspomnieć o znacznie skuteczniejszej metodzie zabezpieczenia - unikalnym numerze fabrycznym, który zawierają niektóre mikrokontrolery. Program sprawdza swój numer fabryczny z tym ukrytym gdzieś w kodzie firmware i jeśli się różnią - dalsza praca jest wstrzymywana. Skopiowanie pamięci flash i próba uruchomienia na nowym mikrokontrolerze nie uda się.
  • #21
    tmf
    Moderator of Microcontroller designs
    kekon wrote:
    Zgadza się, jednak z tego nie da się "wyłuskać" kodu.

    A tam się nie da. Decapping i odczyt pamięci mikroelektrodami lub laserem. Obecnie to żadne rocket science.
    kekon wrote:
    roblem w tym, że ten kod trzeba jakoś uruchomić (sprawić aby oryginalny program skoczył do naszego kodu i zaczął go wykonywać i to pod warunkiem że zmieści się wszystko w pamięci)

    Glitche na zasilaniu zapewniają taki efekt.
    kekon wrote:
    Warto jeszcze wspomnieć o znacznie skuteczniejszej metodzie zabezpieczenia - unikalnym numerze fabrycznym, który zawierają niektóre mikrokontrolery. Program sprawdza swój numer fabryczny z tym ukrytym gdzieś w kodzie firmware i jeśli się różnią - dalsza praca jest wstrzymywana. Skopiowanie pamięci flash i próba uruchomienia na nowym mikrokontrolerze nie uda się.

    A jak trudne jest odnalezienie w kilku-kilkunastu kB kodzie odwołania do rejestru zawierającego ID? 10 minut pracy jeśli ktoś to zakamuflował, parę sekund jeśli dosyć jawnie ktoś odczytuje ID/nr seryjny.
    To wszystko są utrudnienia, ale jeśli jest fizyczny dostęp do urządzenia to zawsze znajdzie się metoda złamania zabezpieczenia.
    Jakieś rozwiązania typu zabezpieczenie na silikonie wrażliwych obszarów nawet ułatwiło zadanie, bo wiadomo gdzie szukać zabezpieczenia. Jeden z producentów zrobił takie zabezpieczenie poprzez naniesienie dodatkowej metalizacji na fusebity - efekt - metalizację szybko można usunąć, a dzięi temu było wiadomo, gdzie są odpowiednie bezpieczniki.
  • #22
    kekon
    Level 19  
    tmf wrote:
    kekon wrote:
    Zgadza się, jednak z tego nie da się "wyłuskać" kodu.

    A tam się nie da. Decapping i odczyt pamięci mikroelektrodami lub laserem. Obecnie to żadne rocket science.


    Nie doczytałeś. Nie chodziło o wyłuskanie kodu metodą "brute force" tylko na podstawie weryfikacji zaprogramowania.

    tmf wrote:
    A jak trudne jest odnalezienie w kilku-kilkunastu kB kodzie odwołania do rejestru zawierającego ID? 10 minut pracy jeśli ktoś to zakamuflował, parę sekund jeśli dosyć jawnie ktoś odczytuje ID/nr seryjny.


    Może jakieś konkretne przykłady ?
    Zwykle nie robi się to w sposób jawny, tylko znacznie bardziej zakamuflowany. Wątpię w to aby przeciętny programista zrobił to w 10 minut czy nawet parę sekund. Znalezienie odwołania do rejestru to jedno a wykrycie sposobu zaszyfrowania tego kodu w firmware to drugie. Nawet jeśli się uda nam to zrobić to co dalej ? Można zdeasemblować program, wykryć gdzie są funkcje sprawdzające i usunąć je (bądź odpowiednio zmodyfikować) ale to jest żmudna robota.

    Quote:
    Glitche na zasilaniu zapewniają taki efekt


    W każdym układzie ? W jaki sposób ?
  • #23
    tmf
    Moderator of Microcontroller designs
    kekon wrote:
    Nie doczytałeś. Nie chodziło o wyłuskanie kodu metodą "brute force" tylko na podstawie weryfikacji zaprogramowania.

    To żadne brute force, zresztąn ieistotne -ważne jest, że oprogramowanie da się odczytać z MCU w ten sposób.
    kekon wrote:
    Może jakieś konkretne przykłady ?
    Zwykle nie robi się to w sposób jawny, tylko znacznie bardziej zakamuflowany. Wątpię w to aby przeciętny programista zrobił to w 10 minut czy nawet parę sekund. Znalezienie odwołania do rejestru to jedno a wykrycie sposobu zaszyfrowania tego kodu w firmware to drugie. Nawet jeśli się uda nam to zrobić to co dalej ? Można zdeasemblować program, wykryć gdzie są funkcje sprawdzające i usunąć je (bądź odpowiednio zmodyfikować) ale to jest żmudna robota.

    Żmudna, ale weź pod uwagę, że dla osoby, która w tym siedzi robota jest do zrobienia. Oczywiście dla kogoś kto na codzień się takimi problemami nie zajmuje to będzie długie doświadczenie. Jednak pamiętaj, że w latach 80-tych i 90-tych zabezpieczano gry i programy na różne sposoby i jakoś zawsze to łamano, raczej prędzej niż później. Jak wprowadzono bardziej wyrafinowane zabezpieczenia, to też na końcu się okazuje, że jest jakieś podejście. Takie gmatwanie kodu jest jakimś rozwiązaniem,, nawet są programy, które to wspomagają, ale to też jest uciążliwe dla programisty i czasami prowadzi do błędnego działania programu. No i kod dla MCU, to też nie są setki MB, a raczej kilka-kilkadziesiąt kB, więc jego rozpracowanie, jakokolwiek może być uciążliwe, nie jest jakimś niemożliwym wyzwaniem. Oczywiście, to znowu jest jakaś kolejna warstwa zabezpieczeń, z której warto skorzystać, szczególnie jeśli koszty są niewielkie.
    kekon wrote:
    W każdym układzie ? W jaki sposób ?

    Wiele jest podatnych na takie ataki. Nie chcę tu podawać linków do konkretnych miejsc i urządzeń, bo to nie temat o hackowaniu, ale da się odpowiednie urządzeni8a i opisy łatwo wygooglać.
  • #24
    kekon
    Level 19  
    tmf wrote:
    Żmudna, ale weź pod uwagę, że dla osoby, która w tym siedzi robota jest do zrobienia.


    No właśnie żmudna - mogę dać Ci przykładowy plik hex do konkretnego mikrokontrolera i wątpię czy znajdziesz w skompilowanym kodzie np. wywołanie rejestru ID w 10 minut (np. adres fizyczny funkcji która odczytuje ID). Łatwiej będzie to zapewne zrobić to debuggerem.
    Łatwo i szybko jest powiedzieć że coś jest proste do wykonania ale potem zaczynają się schody i już tak łatwo nie jest.

    Quote:
    kekon napisał:
    W każdym układzie ? W jaki sposób ?

    Wiele jest podatnych na takie ataki. Nie chcę tu podawać linków do konkretnych miejsc i urządzeń, bo to nie temat o hackowaniu, ale da się odpowiednie urządzeni8a i opisy łatwo wygooglać.


    Jasne... jak trzeba przejść do praktyki to jest z tym problem.

    Pewnie że nie ma idealnych zabezpieczeń; pisałem o tym na początku. Wszystko można złamać. Nie jest to jednak kwestia kilku minut, przynajmniej w znakomitej większości przypadków.
    Niektóre firmy oferują popularne mikrokontrolery umieszczone w obudowach o zupełnie innych oznaczeniach i innym układzie wyprowadzeń. Takie rozwiązanie jest dostępne, jeśli jest dość duża liczba zamówień. Dokumentacja jest udostępniana tylko dla zamawiającej firmy. To też utrudnia złamanie zabezpieczeń.

    Quote:
    Jednak pamiętaj, że w latach 80-tych i 90-tych zabezpieczano gry i programy na różne sposoby i jakoś zawsze to łamano, raczej prędzej niż później.


    Pamiętam te czasy; gry były też np. na kasetach magnetofonowych bez żadnych zabezpieczeń i wystarczyło je po prostu przegrać i już. Były też proste konsole do gier na cardridge, ale tego nie dało się skopiować tak łatwo (przynajmniej w realiach PRL)
  • #25
    adam white
    Level 27  
    W usuwaniu (omijaniu) zabezpieczeń często pomagają błędy programistów (lub celowo zostawiane backdoor - y).

    Z mojej dawnej branży radio code - radia Visteona do Forda. Zabezpieczenie - (na 2006 rok potężne) - kod szyfrowany w procesorze TMS 470 (nie było czym czytać), zewnętrzna pamięć 24c16 ale w nietypowej (niespotykanej) wtedy obudowie. Dodatkowo korelacja wsadów procesora i pamięci. I wystarczyło w tej zewnętrznej pamięci zmienić wartość jednego adresu. Radio uruchamiał każdy, dowolny kod. Bez żadnego cięcia, bajpasów itp. Radia z pierwszych serii (z 2006) ruszały nawet bez kodu.
  • #26
    kekon
    Level 19  
    Przypomina mi się inna historia - trochę odbiega od tematu ale to też temat zabezpieczeń. Gdy pojawiły się w Polsce pierwsze "niekopiowalne" płyty CD audio bodajże jedną z pierwszych takich płyt CD była wydana przez Budkę Suflera. Piraci poradzili sobie w banalny sposób - przegrali płytę na taśmę a z taśmy na CD. To oczywiście pogarszało jakość ale było zupełnie akceptowalne dla większości słuchaczy.
  • #27
    silvvester
    Level 25  
    acctr wrote:
    Ale wiesz, że taki dowód ma swoją cenę?


    Wiem że firmy reklamujące takie usługi plotą bez sensu.
    https://www.ic-cracker.com/crack-mcu-attiny25-heximal/

    Ktoś kto się nie zna kupi wszystko. Ktoś kto się zna widzi zdjęcie mosfeta, a nie attiny. Do tego na stronie jest przeplatanka angielskiego, rosyjskiego, tureckiego i znów zapala się czerwona lampka. Wygląda na ctrl+c wraz ctrl+v w wersji na rympał. Całość jest reklamą jednej z firm. I to jest weryfikowalne.
  • #28
    acctr
    Level 26  
    silvvester wrote:
    Wiem że firmy reklamujące takie usługi plotą bez sensu.

    Wyciąganie wniosków w temacie łamania zabezpieczeń na podstawie jakiejś niedopracowanej strony internetowej to nieporozumienie.
    Nie od dzisiaj wiadomo, że większość treści w internecie jest warta tyle co nic.
    Przy nieco większym wysiłku na pewno znajdziesz wartościowe materiały, nawet takie, gdzie krok po kroku pokazują jak łamać zabezpieczenia przykładowo AVR. Gdy będziesz zdeterminowany możesz potraktować to jako instrukcje dla własnych doświadczeń, poprzez które sam sobie udowodnisz, że jednak da się.
  • #29
    LightOfWinter
    Level 35  
    acctr wrote:
    Nie od dzisiaj wiadomo, że większość treści w internecie jest warta tyle co nic.


    Witam
    Nic takiego nie wiadomo. Sądzę że jest to raczej stwierdzenie oparte o przekonanie niż poparte jakimiś badaniami. Jeśli jest inaczej proszę o podanie jakiegoś badania na poparcie tej hipotezy?

    acctr wrote:

    Przy nieco większym wysiłku na pewno znajdziesz wartościowe materiały, nawet takie, gdzie krok po kroku pokazują jak łamać zabezpieczenia przykładowo AVR. Gdy będziesz zdeterminowany możesz potraktować to jako instrukcje dla własnych doświadczeń, poprzez które sam sobie udowodnisz, że jednak da się.


    Dokładnie tak. Przy pewnym poziomie determinacji można znaleźć użyteczne informacje będące punktem wyjścia do dalszych badań i dociekań.
    Temat ten w pewien sposób łączy się z popularnym teraz tematem cyber security. Choć ten drugi jest szerszym zagadnieniem.

    Tu jest dyskusja na podobny temat:
    https://www.elektroda.pl/rtvforum/topic1628283.html
  • #30
    silvvester
    Level 25  
    LightOfWinter wrote:
    Tu jest dyskusja na podobny temat:
    https://www.elektroda.pl/rtvforum/topic1628283.html


    Zajrzałem na stronę wymienioną w linku. http://www.chip-explorer.de/ Wszystkie zdjęcia na stronie mają "stock`owe", ale że strona nie zniknęła przez 12 lat, wnioskuję jakiś outsourcing. Przyjmują zlecenia, wysyłają układ na wschód i za całość biorą prowizję 100-400%. Tak widzę całość. Jakaś istniejąca firma w niemczech zwyczajnie dorabia sobie.