On 30/04/2020 10:45, Zbych wrote:
> Ostatnio oglądałem fajną prezentację włamania do SoC odpowiedzialnego za
> deszyfrowanie strumienia video. W środku klon prostego 6502, któremu
> wystarczyło wstrzyknąć kod do pamięci RAM i "potrząsnąć" trochę
> zasilaniem, żeby się wykrzaczył i zaczął wykonywać ten kod z RAMu. Ta
> sama sztuczka nawet na Cortexie-M0 ma małą szansę powodzenia, dzięki
> wykrywaniu dostępu do nieistniejących adresów i dużej przestrzeni
> adresowej. Nie wspominając już o większych prockach z MMU.

Przepraszam Cie, ale to jest możliwe w prawie każdym CPU. Nawet w super
wypasionych x86 z super bezpiecznymi mechanizmami chronienia przed
wykonywaniem kodu z ram wymyślono np. obejście o nazwie
return-oriented-programming które jest absurdalnie ale działające i daje
konkretne efekty (jak hacking PS4). Ba, dzięki tej technice można
wykonywac "kod z ramu" majac do czyniena z architekturą która tego nie
potrafi sprzętowo (Harvard). Niezłe jaja nie?

Serio, dajesz wiarę że komplikacja CPU powoduje że coś nie da się
zhackowac? Że większa przestrzeń adresowa przed czymś chroni? Że, w
końcu o to zapytam, w duperelowatej przelotce RS485, której pies z
kulawą nogą nie będzie hackował, to w ogóle POTRZEBNE i jest argumentem
za uzyciem linixa czy Cortexa M500? Urządzenia oparte o Linxua hackuje
się łatwiej tylko dlatego że można wykorzystać znane podatności w
Linuxie, można znaleźć backdoory zostawiane przez idiotów w procesie
produkcji, można znaleźć zabezpieczenia które nia mają sensu itd itp.

W przelotce użyto linuxa bo była zrobiona na odpierdol. Nikomu on tam w
środku potrzebny nie jest, przelotka nie ma adnych zaawansowanych
funkcji poza otwarciem portu TCP i przerzucaniem bajtów z lewa na prawo.

>> I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC.
>> I jakimś trafem fakt że milion instancji Ubuntu do oglądania porno
>> nijak nie poprawia stabilności jajka w SoC Atherosa.
> I oczywiście potrafisz udowodnić, że problemem była ta część linuksa,
> która jest wspólna dla miliona instalacji ubuntu a nie specyficzna dla
> SoC Atherosa?

Tak, to jest ten mały fragment zajmujący się przyjmowaniem przerwań,
implementujący sekcje krytyczne, zajmujący się multitaskingiem,
specyficzny dla każdego rdzenia i bardzo często specyficzny dla
konkretnego SoCa. Do dzisiaj w tym małym, duperelowatym fragmencie kodu
czaiły się błedy, nawet na tej super wypasionej, przetestowanej
pornolami, platformie x86. Dasz wiarę?

>> Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w
>> perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak
>> co dzień.
> To, że ty nie potrzebowałeś, to nie znaczy że producent tych
> przejściówek nie ma klientów, którzy tego nie potrzebują.

Oczywiście, zawsze jest rynek dla dziadowskich rozwiązań, szczgólnie ze
sprawnym marketingiem. Oby to nie był rynek dla rozwiązań w lotnictwie.

do góry

On 30/04/2020 10:58, Grzegorz Niemirowski wrote:
> Nie uważam, żeby możliwość programowania bardziej wypasionego
> mikrokontrolera miała prowadzić do przerośniętego i bardziej
> zabugowanego kodu.

Bierzesz wypasonego ARMa który ma MMU. Na dzien dobry dostajesz w łeb
sporką komplikacją kodu wynikajacą z pamieci wirtualnej. Możesz jej nie
używać, oczywiscie, ale co jesli urządzenia I/O są mapowane przez jakieś
MMUIO? Nagle musisz napisać dużo cholerne skomplikowanego kodu tylko po
to aby to obsługiwać. Coś co dawniej robione jako PORTD |= FOO; dzisiaj
urasta do kilkuset linijek zabawy w dostęp przez MMU, najpewniej z bugami.

Idź teraz i wlacz z przetestowaniem tego invitro.

> Starszy, prostszy mikrokontroler ma różne
> ograniczenia, które utrudniają programowanie, mogą zwiększać ryzyko
> błędu i wydłużają czas tworzenia kodu.

To wszystko zależy ile kodu, boiler plate, niesie ze sobą architektura.
Im większy CPU tym trudniej pisać to co chcesz bez zajmowania się
pierdołami dookoła. W skrajnych przypadkach, jak mikorontrolery na x86,
trzeba było się zajmować całym tym debilizmem jak tryby real, protected,
long, short i h... wie co jeszcze, żeby w końcu po kilku tygodniach
zamigać diodą.

Rozumiesz że każda linijka kodu, kazdy if, każdy zapis do rejestru,
każda akcja globalna to jest nowa ścieżka testowania i generuje coraz
trudniejsze w audytowaniu środowisko?

Jak ktoś miga diodą to pal sześć. Jak to lata samolotem to NIE chcę
skomplikowanego cpu na którym się pisze łatwiej. Bo się cieżej
*testuje*. Dziwne, że wiele osób zapomina o tym, że kod krytyczny
podlega restrykcyjnemu testowaniu a popieprzone architektury nie
usprawniają tego procesu. Wręcz uniemożliwiają w skończonym czasie.

do góry

W dniu 2020-04-30 o 02:28, a...@m...uni.wroc.pl pisze:
> Mozna powiedzic ze technicznie glownym problemem bylo oprogramowanie,
> np. korekta miala byc rzedu 2 stopni a oprogamowanie bez zastanowienia
> walilo 70.

Generalnie Benek uchodził za takiego, co uważa, że decyzje podejmuje
pilot, z kolei Arbuz miał filozofię, że pilot ma jedynie podziwiać
dyskotekę w kokpicie. I wszystko było dobrze, do czasu, aż Benek
postanowił pójść w ślady Arbuza.
No cóż, stara zasada serwisantów mówi: Jeśli coś dobrze działa, to nie
poprawiaj. Coś mi się zdaje, że nie byłby to wielki problem "wyczucie"
nowego samolotu bez tego felernego systemu.

Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE:
moje imie.(kropka)nazwisko, ten_smieszny_znaczek, gmail.com

do góry

On Thu, 30 Apr 2020 11:08:44 +0200, heby <h...@p...onet.pl> wrote:
> return-oriented-programming które jest absurdalnie ale działające i
> daje

Nie rozumiem jak to działa. Na stosie podkładamy adres wybranej i
pasującej instrukcji (gadżet) z istniejącej przestrzeni
(kodu/liba/whatever). Ale co dalej? Przecież CPU zrobi skok tam,
wykona tą instrukcje ALE pójdzie dalej. Jak niby połączyć w sensowną
całość (jeden kontekst) instrukcje które się chce wykonać?

--
Marek

do góry

On 30/04/2020 12:23, Marek wrote:
> On Thu, 30 Apr 2020 11:08:44 +0200, heby <h...@p...onet.pl> wrote:
>> return-oriented-programming które jest absurdalnie ale działające i daje
>
> Nie rozumiem jak to działa. Na stosie podkładamy adres wybranej i
> pasującej instrukcji (gadżet) z istniejącej przestrzeni
> (kodu/liba/whatever). Ale co dalej? Przecież CPU zrobi skok tam, wykona
> tą instrukcje ALE pójdzie dalej. Jak niby połączyć w sensowną całość
> (jeden kontekst) instrukcje które się chce wykonać?
>

Gadżet wygląda tak
[...]
-2. kod
-1. kod
0 adres wejścia
1. kod
2. kod
3. kod
4. return

Na stosie układasz listę adresów wejścia w rózne fragmenty istniejącego
kodu. Powoduje to wykonywanie się kawałków kodu, następnie dzięki return
nastepuje *uzyteczny* skok do innego gadżetu, bo return jest uzywany
jako jump. I tak w kółko, każdy "return" powoduje skok dalej, do
następnego. Wszystko gadety połaczone sa w jeden łańcuch, return
działają jak jump.

do góry

On Thu, 30 Apr 2020 12:47:08 +0200, heby <h...@p...onet.pl> wrote:
> Gadżet wygląda tak
> [...]
> -2. kod
> -1. kod
> 0 adres wejścia
> 1. kod
> 2. kod
> 3. kod
> 4. return

Nie rozumiem, przecież idea mówi o tym, że gadżetem jest JEDNA
instrukcja (pod adresem 0 j.w.) + return a w/w instrukcje 1. 2....
do return to instrukcje w dalszym fragmencie np. liba ALE z innego
kontekstu, które mogą popsuć to co się zrobi "at 0".

--
Marek

do góry

On 30/04/2020 13:05, Marek wrote:
> Nie rozumiem, przecież idea mówi o tym, że gadżetem jest JEDNA
> instrukcja

Nie. gadżetem jest zakończenie funkcji zawierajace użyteczny kod, razem
z return. Może zawierać jedną instrukcję i return, może zawierać kilka
instrukcji (z czego uzyteczna instruckja bądź instrukcje mogą być w
środku bezuzytecznych) i return.

Ogólnie to jest dowolna, przydatna, końcówka funkcji. Nie ma okreslonego
ile zawiera instrucji. Ile potrzebujesz, jeśli jest użyteczna.

Celem zazwyczaj jest przestawienie jakiegoś bitu we właściym miejscu
które pozwoli z normalnego kodu na dostęp gdzieś dalej. Często te
"liniowe" wykonywanie kodu może być wystarczające do tak prostych
zastosowań. Przy odpowiednich gadźetach możesz zrobić wszystko,
zazwyczaj gadżety są turing-complete.

> return to instrukcje w dalszym  fragmencie np. liba ALE z innego
> kontekstu, które mogą popsuć to co się zrobi "at 0".

Dobieranie gadżetów tak by wzajmenie nie niszczyły sobie danych na
których pracujesz jest istotą tej sztuczki. Z tego co słyszalem jest
jakiś dodatek do Ghidra (a może do ida pro? nie pamietam) wspomagający
wyszukiwanie gadżetów w istniejącym kodzie.

Polecam:

https://cturt.github.io/ps4.html

do góry

On 30.04.2020 11:08, heby wrote:

> Serio, dajesz wiarę że komplikacja CPU powoduje że coś nie da się
> zhackowac? Że większa przestrzeń adresowa przed czymś chroni?

Tak, wierzę że dołożenie zabezpieczeń sprzętowych i programowych do CPU
zwiększa szansę na wykrycie błędu i reakcję.

Równie dobrze mógłbyś mnie przekonywać że komplikowanie konstrukcji
windy przez dokładanie hamulców bezpieczeństwa jest bez sensu bo:
1. komplikuje konstrukcję i zwiększa ilość testów
2. hamulce mogą mieć błędy konstrukcyjne
3. hamulce marki Linux używane w windach towarowych to już w ogóle
tragedia, bo można je zablokować śrubokrętem. Co najwyżej można użyć
drewnianego klina wystruganego w garażu, bo pan Mieczysław pokrył go w
100% testami i ma na to papier.

do góry

On 30/04/2020 13:48, Zbych wrote:
>> Serio, dajesz wiarę że komplikacja CPU powoduje że coś nie da się
>> zhackowac? Że większa przestrzeń adresowa przed czymś chroni?
> Tak, wierzę że dołożenie zabezpieczeń sprzętowych i programowych do CPU
> zwiększa szansę na wykrycie błędu i reakcję.

No wiec ma się to nijak do współczesnego świata. Zwiększanie poziomu
komplikacji hardware doprowadza albo do idiotycznych probelmów z
bezpieczeństwem (wyciakenia danych z powodu speculative execution /
cache) albo wręcz uszkadzania danych (row hammer) w tych super
zabezpieczonych kawałkach hardware z masą 3-literowych skrutów. Pomijam
fakt że skompikowany hardware jest skomplikowany z punktu widzenia
programisty i wymaga *znacznie* bardziej bugogennego kodu.

> Równie dobrze mógłbyś mnie przekonywać że komplikowanie konstrukcji
> windy przez dokładanie hamulców bezpieczeństwa jest bez sensu bo:
> 1. komplikuje konstrukcję i zwiększa ilość testów
> 2. hamulce mogą mieć błędy konstrukcyjne
> 3. hamulce marki Linux używane w windach towarowych to już w ogóle
> tragedia, bo można je zablokować śrubokrętem. Co najwyżej można użyć
> drewnianego klina wystruganego w garażu, bo pan Mieczysław pokrył go w
> 100% testami i ma na to papier.

Problem polega na tym że porówniae powinno być pociągnięte dalej:

Pan Mieczysław potrzebuje hamował koło zamachowe w swoim stołowym modelu
silnika parowego.

Ma do wyboru użyć kawałka drewna, co przetestowano już na milion sposóbo
albo
wybrać hamulec brake-on-wire na bazie linuxa na czymś z okolicy Ryzena.

Pan Mieczysław wybiera Ryzena. Bo kto by nie chciał nowocześnie?

Natomiast gdybyś się nieco postarał, to porównanie prawidłwoe jest inne:

Mieczysław LTD od 30 lat produkuje sterowniki hamulców ręcznych do
samolotów. Hamulce są oparte o jakiegoś starego MIPSa z 4kB RAMu, ale za
to są odporne na promieniowanie kosmiczne, zweryfikowane formalnie na
poziomu software i hardware dzieki czemu dopuszczone do latania
stosownymi certyfikatami, w dodatku pracują reduntantnie a ich
konstrukcja umożliwia ekslopatację przez kilkadziesiąt lat bez
sewisowania, a z uwagi na to że kod jest niezmienny, ustalono również że
będzie wypalony w ROMie dzięki czemu nie straszne mu rozbłyski gamma,
pioruny czy nawet toksyczne wydzieliny mniej kontrolowanego końca
przewodu pokarmowego. Dzięki tym prymitywnym urządzeniom każdy samolot
może bez problemu zahamować zaraz po zaciągnięciu mimo że ich moc
obliczeniowa jest milion razy mniejsza niż w smarfonie od oglądania
porno dowolnego pasażera i troche siara.

do góry

On 30/04/2020 14:14, heby wrote:
> skrutów

Łomatko! Przepraszam, jeśli ktoś opluł monitor.

do góry