[Youtube] Wylut modułu SMD i zmiana firmware BK7231 w lampce LED RGBCW

Miło się słucha damskiego lektora . Jednak trochę dziwnie brzmi "ArGeeBee" jako określenie diod RGB, lepiej by brzmiało po naszemu R-G-B. Film bardzo fajny, pokazuje iż nie trzeba super-hiper wypasionego sprzętu lutowniczego do takich prac.

p.kaczmarek2 napisał:

Czy podoba się Wam taka forma prezentacji? Video przyśpieszone + komentarz + napisy na filmie? Dajcie znać, a może jeszcze coś dla Was nagramy.

Jak najbardziej!

Tani sprzęt lutowniczy jak najbardziej daje radę, jedynie trzeba starać się pamiętać o higienie grotu lutownicy, no i niezbędny też jest topnik i plecionka. No i koniecznie spoiwo ołowiowe do metody z filmu... (niby jest do tego jeszcze coś lepszego - jakiś niskotemperaturowy "Chip Quik PbBiln" który widziałem recenzowany m. in. przez Dave Jonesa, ale nie korzystałem z tego nigdy i do prostszych sytuacji jak ta na filmie zwykłe Pb daje radę)

"ArGeeBee" może z rozpędu, bo też pracujemy nad wersją angielską dla kolegów zza granicy. Tj. już ta wersja ma angielskie napisy (uznaliśmy kompromisowo, że można dać po angielsku), ale też chcemy spróbować nagrać wersję 100% angielski lektor + angielski Windows (bo na filmiku jest polski).

p.kaczmarek2 napisał:

Tani sprzęt lutowniczy jak najbardziej daje radę, jedynie trzeba starać się pamiętać o higienie grotu lutownicy, no i niezbędny też jest topnik i plecionka.

Sam używam nie najwyższych lotów sprzętu i nawet z jedną sprawną ręką daje radę. "Higiena" grotu to podstawa a dodatkowo dopasowanie grotu do wykonywanych czynności. Lut Pb to chyba podstawa, kilka razy użyłem PbFree przy naprawach sprzętu medycznego i jest to masakra technologiczna niestety. Zmieniłem komputer na trochę nowszy, właśnie ze względu na @TechEkspert. W końcu namówił mnie do nagrania podcastu, problemy ze sterownikami oraz rozkładająca mnie grypa trochę temat "odwlokły" w czasie. Nie mniej coś się pokaże w najbliższym czasie . Co do zwrotów w języku angielskim, są pewne tzw. nieprzetłumaczalne i wtedy należałoby oprócz nazwy oryginalnej podać przybliżone oddające sens tłumaczenie.

W komentarzach na YT pojawiło się pytanie jaki jest cel takiej modyfikacji, wygląda na to, że temat uwolnienia sprzętu od dostarczonej przez producenta aplikacji i ekosystemu jest ciągle nowy.

@p.kaczmarek2 pojawiło się także pytanie czy możliwe jest skopiowanie oryginalnego firmware, na potrzeby zmiany jednak chyba nie jest to konieczne?

Jeżeli możesz prośba o rozwinięcie tematu, poniżej oryginalne pytanie:
"...zastanawia mnie tylko kwestia zgrania oryginalnego firmware jak to możliwe ? Czy mikrokontroler nie miał ustawionej ochrony przed odczytem, czy wykorzystaliście jakiś bug po przez zresetowanie mikrokontrolera po przez odłączanie na ułamek sekundy zasilania? czy te mikrokontrolery które są montowane w lampkach nie mają żadnych zabezpieczeń przed odczytaniem wsadu?"

@ArturAVS w nagraniu podcastu przeszkodziły nam losowe zdarzenie, nie zdradzajmy tematu odcinka, a na PW spróbujmy ponownie uzgodnić termin nagrania.

TechEkspert napisał:

nie zdradzajmy tematu odcinka

Dlatego o tym nawet nie wspomniałem .

TechEkspert napisał:

@p.kaczmarek2 pojawiło się także pytanie czy możliwe jest skopiowanie oryginalnego firmware, na potrzeby zmiany jednak chyba nie jest to konieczne?

W sensie użytkownik pyta czemu na filmie robimy kopię zapasową wsadu? Dobrze rozumiem?
Nie jest to konieczne, można wgrać nowy firmware bez tego, ale robimy to z dwóch powodów:
1. Warto jest zrobić kopię zapasową całego 2MB firmware (najlepiej po parowaniu z testowym SSID - nie jakimś naszym prywatnym - gdyż dump zawiera nasze SSID i hasło) gdyż wtedy można je wysłać do projektu tuya-cloudcutter:
https://github.com/tuya-cloudcutter/tuya-cloudcutter/issues
który potem pozwoli na programowanie kolejnych produktów z tej samej serii (z tą samą wersją firmware) zdalnie, przez WiFi (to taki tuya-convert dla Beken, z tym że wsparcie oferuje per-device)
2. kopię zapasową należy wykonać też na wypadek ewentualnych problemów po zmianie firmware i by móc w razie czego wrócić do poprzedniego

Chyba, że pytanie zrozumiałem źle i user pyta czy można by zmodyfikować stare firmware Tuya tak by dopiąć np. Home Assistant - jeśli tak, to odpowiem że jest to wręcz niewykonalne, skompilowanego programu już łatwo nie zmodyfikujesz i nie odzyskasz tym bardziej z niego kodu C. Nawet jak zgrasz firmware to możesz co najwyżej obejrzeć je w dissamblerze takim jak Ghidra, ale to nie będzie już to samo co kod C.

Mimo to warto pamiętać, że są też innego rodzaju rozwiązania - jest np. LocalTuya jako plugin do HA (tylko że one nie modyfikują istniejącego wsadu Tuya...).

TechEkspert napisał:

Jeżeli możesz prośba o rozwinięcie tematu, poniżej oryginalne pytanie:
"...zastanawia mnie tylko kwestia zgrania oryginalnego firmware jak to możliwe ? Czy mikrokontroler nie miał ustawionej ochrony przed odczytem, czy wykorzystaliście jakiś bug po przez zresetowanie mikrokontrolera po przez odłączanie na ułamek sekundy zasilania? czy te mikrokontrolery które są montowane w lampkach nie mają żadnych zabezpieczeń przed odczytaniem wsadu?"

Te układy nie mają żadnych zabezpieczeń wsadu, a przynajmniej nic mi o tym nie wiadomo.
Ciekawostka: można też do nich połączyć się w trybie SPI (bez bootloadera UART) i wtedy identyfikują się jako kość SPI i też można wszystko odczytać.
Szczegóły: https://github.com/OpenBekenIOT/hid_download_py/blob/master/SPIFlash.md

TechEkspert napisał:

czy wykorzystaliście jakiś bug po przez zresetowanie mikrokontrolera po przez odłączanie na ułamek sekundy zasilania

Jak wyżej - to żaden bug, po prostu ich bootloader tak działa że "melduje się" tylko chwilkę po odcięciu zasilania/reboocie (drugi sposób to zamiast odcięcia zasilania jest zresetowanie pinem CEN).
Inne układy mają inaczej - np. BL602 ma osobny pin "BOOT" i albo jak się go zewrze do masy to jest w trybie bootloadera cały czas, albo normalnie startuje program. I nie trzeba "łapać" bootloadera. A te BK7231 mają tak, że nie ma pinu "BOOT" tylko bootloader "melduje się" przy reboocie i czeka krótki moment na odpowiedź z TX/RX i jak jej nie ma, to uruchamia normalnie program.

Z tego powodu do programowania wystarczają 4 sygnały - zasilanie (masa+3.3V) oraz RX i TX. Nic więcej.

Taki kolejny przykład-ciekwoastka, fotki z dzisiaj z programowania kolejnego BK7231N, nowy moduł, EB01-B (nie znalazłem o nim niczego w sieci), na zdjęciach widać gdzie jest RX i TX:


Przylutowane 3.3V:

Przylutowane GND:

RX i TX są tu:

RX i TX i cały układ:

i jak napisałem wyżej - jeśli zgramy 2MB flash i wyślemy do tuya-cloudcutter i autorom tego projektu uda się zrobić "hack" do programowania tej danej wersji wsadu/urządzenia przez WiFi, to przy następnych produktach nawet nie trzeba otwierać obudowy by wgrać nowy wsad. Jedyny problem jest taki, że jak Tuya zaktualizuje wsad (i np. mamy urządzenie z inną wersją niż ta w tuya-cloudcutter) to trzeba proces powtórzyć, czyli znów lutujemy kabelki (bo np. nowa lampka jest z nowszej serii)

Dzięki za wyjaśnienie tematu, chodziło właśnie o możliwość kopiowania oryginalnego oprogramowania i zabezpieczeń przed zapisem/odczytem pamięci modułu.

p.kaczmarek2 napisał:

1. Warto jest zrobić kopię zapasową całego 2MB firmware (najlepiej po parowaniu z testowym SSID - nie jakimś naszym prywatnym - gdyż dump zawiera nasze SSID i hasło) gdyż wtedy można je wysłać do projektu tuya-cloudcutter

To mnie zastanawia, gdyż może to być najsłabszy punkt systemu. Jeżeli chcemy ingerować w sieć IoT obsługującą takie żarówki to czy wystarczy wykręcić jedną i zastąpić ją nową lub uszkodzoną aby nie wzbudzać podejrzeń a następnie odczytać zawartość pamięci i już mamy dostęp do WiFi obsługującego żarówki a być może inne urządzenia?

W przypadku "żarówki" zbudowanej na ESP8266 z firmware Tuya (innych nie testowałem osobiście) wystarczy zgrać jego pamięć (starczy zwykły UART na USB konwerter i esptool.py; ew. bezpośrednio z kości) i uzyskujemy dostęp do SSID i hasła w plaintexcie - testowane wiele razy, też na forum to umieszczałem.
(trochę dziwne, bo co to za problem, chociażby jakimś prostym XORem zmienić bajty, a samo to by utrudniło wielu osobom odzyskanie hasła)

W przypadku "żarówki" z BK7231T/BK7231N oprócz zgrania pamięci flash trzeba jeszcze dokonać jej odszyfrowania, ale to niestety jest w tej chwili bardzo łatwe, gdyż są do tego narzędzia (a Tuya udostępniła sama SDK, więc wiadomo co i jak działa):

dump.bin to zgrany plik binarny metodami z filmiku z pierwszego postu.

Fun fact: nie pamiętam już tego dokładnie, ale któreś z urządzeń testowanych przeze mnie na forum (chyba któreś oparte na ESP8266), ale nie ze wsadem Tuya, tylko jakimś innym (może Magic Home? który o dziwo nie był przeróbką Tuya) działało w ten sposób, że przy uruchomieniu na UART w ogóle drukowało razem z boot logiem i wszystkim SSID i hasło naszej sieci...

więc z tymi zabezpieczeniami jest bardzo źle. Chyba jedynym bezpiecznym sposobem utylizacji sprzętu IoT Tuya jest takie jego zniszczenie, by sam moduł WiFi też uległ zniszczeniu (chyba, że umiemy zrobić erase flash dla danego układu).


EDIT: Aha, wiem już gdzie widziałem w debug logu na UART moje hasło i SSID, To było na BL602, ten temat:
https://www.elektroda.pl/rtvforum/topic3881416.html#19944184

W sumie słuszna uwaga z tym pogrubieniem, podkreślę tam, że była mowa głównie o "żarówkach" Tuya (ew. poszerzyłbym to ogólnie na produkty Tuya) na ESP8266 i BK7231. Tuya (oraz ewentualni mniejsi producenci - bodajże ten Magic Home wspomniany - z logu wynika, że nie jest on malowanką Tuya i nie korzysta z ich SDK) nie dokonały absolutnie żadnych starań by zabezpieczyć ich produkty, nawet tego prostego XOR na bajtach nie puścili. Z RTL pewnie jest podobnie, tym bardziej, że tam można odlutować kość Flash z płytki.

Co do samego ESP32 się nie wypowiem, gdyż choć testuję produkty IoT od kilku lat to jakoś ani razu mi się on jeszcze chyba nie trafił (a produkty raczej kupuję losowo, nie dobieram ich specjalnie pod tezę, choć faktem jest że testuję te popularne i budżetowe z Ali/Ale/Eba).

Ogromny plus za całość prac, i za dokumentację filmową. Przyspieszone video jest spoko
Jedno drobne zastrzeżenie - instruktaż na filmie od 3:11 do 3:22 jest troszkę ryzykowny zwłaszcza dla niedoświadczonych, kiedy ktoś dopiero zaczyna przygodę z SMD. Warto zaznaczyć żeby wówczas przy takim czyszczeniu z kleksa cyny grzać tylko jeden pad elementu, i krótko. W przeciwnym razie odlutowanie rezystora/kondensatora SMD gwarantowane. Albo przesunięcie i złączenie z tymi obok. Chyba że są tam klejone, to tylko wtedy można szaleć.
Nie żebym się czepiał, wskazuję drobiazgi do poprawy jakości merytorycznej takich materiałów.
Dla starych wyjadaczy jest to oczywista czynność, więc się nawet nie wspomina. Początkujący powinni się skądś dowiedzieć. Zwykle uczą się "na własnej skórze"