Nytro

Salut, probabil practica. Ideea e ca nu o sa stii sa le rezolvi. Dar incercand sa le faci, o sa inveti multe lucruri. Asta e beneficiul principal al CTF-urilor din partea mea. De asemenea, dar numai dupa ce incerci, cauta write-ups si reprodu-le. Gasesti o multime de resurse.

Ai trecut de la schimbat chei publice, la furat chei private. Hotaraste-te. Nu am zis ca nu se poate, am zis ca daca se face crypto corect, nu poate face nimic NSA. Si imi dai dreptate cu acele aplicatii care fac crypto corect si probabil de aceea sunt "date jos". Pup ca sa nu mai fi supy Vorbim de lucruri diferite, nu am zis ca nu ai dreptate cu capacitatile generale ale unor astfel de agentii, as fi vrut ca discutia sa fie mai tehnica. Atat s-a putut.

Nu ai inteles, dar incepe sa se lege treaba. 1. Partea de criptare se realizeaza prin criptare simetrica unde cheile se schimba folosind cheia asimetrica 2. Partea de trust, de verificare, se realizeaza prin certificate sau semnaturi digitale Criptografie nu inseamna doar AES ci ai: criptare simetrica, asimetrica, semnaturi, hashuri, hmac-uri, certificate, authorities etc. De aceea procesul, normal, nu e doar cum am mentionat eu, doar am dat un exemplu basic. Asa cum pentru a obtine un certificat pentru "rstforums.com" a trebuit sa demonstrez ca am acces la rstforums.com (verificarile unui Root CA pentru a oferi un server certificate), asa aplicatiile precum WhatsApp sau altele au mecanismul lor de verificare prin SMS (de exemplu). Stiu ca era o aplicatie la care scanai un cod QR de la cealalta persoana pentru aceasta relatie de trust. Acest trust e un certificat - adica legatura intre o cheie publica si un utilizator, o identitate. Cum se intampla in browser, desigur, ai la baza acele Root CAs si intr-adevar, unele pot sa fie controlate de catre autoritatile americane, ruse, chineze sau orice altceva. Dar sunt si mecanism in place, inclusiv in browsere. Daca se schimba un certtificat, browser-ul nu permite accesul. Ce putin temporar. Revenind la WhatsApp, sau alte aplicatii desktop, modul de implementare nu e acelasi. Nu ai un Root CA care genereaza acele chei publice si private. Cheile sunt generate local, de catre telefon. Iar daca relatia de trust se face intr-un mod sigur (e.g. cum vezi cheia publica GPG a unuia pe Twitter-ul lui, sau ti-o da pe hartie), atunci totul o sa fie in regula, nimeni nu o sa poata face nimic. Se pare ca public key fingerprints sunt ceea ce foloseste Signal Protocol de exemplu. Tu pierzi din vedere tot acest proces si vezi lucrile la modul simplu in care se schimba niste chei publice, faci MiTM si kaboom, ai acces. Nu esti singura persoana care s-a gandit la asa ceva. Revenind la partea de monitorizare in cazul in care NSA are acces la root CAs, exista solutii simple: own PKI. Se pot genera usor root CAs, se pot verifica certificate emise si tot asa. Daca vrei sa comunica "secure" cu un server, o poti face, trecand peste orice paranoia, folosind aceasta metoda (de exemplu). Adica tu consideri trusted doar acel root CA. Criptografia ajuta mult, trebuie doar inteleasa si facuta corect. Si nu te mai supara atat ca nu are sens.

Da, complet de acord, peste tot se intampla asa. Dar asta doar cu datele pe care le au firmele. Daca firmele nu au date, nu au ce sa ofere. Cam asta e baza pe care ar trebui sa mearga persoanele ca Gigel de mai sus, PhD in cryptography. Sau, solutia cea mai simpla: nu face mizerii si nu ai de ce sa iti faci griji. Daca toate datele mele de pe Internet ar ajunge publice, probabil ar fi maxim 2-3 zile de mici caterinci si asta ar fi tot.

Sunt destul de sigur ca intercepteaza date. Dar din cate se pare, daca partea de crypto e facuta bine, nu pare sa se poata face ceva in privinta asta. Desigur, mai degraba au niste 0day-uri in whatsapp, dar inca cred ca pe partea de crypto nu pot face mare lucru. Cel putin nu fara un quantum computer.

Verificarile astea sunt o alta discutie. Bitcoin si Signal/Whatsapp sunt doua scenarii total diferite si fara legatura intre ele. Compari mere cu pere. Nici macar nu stii ce inseamna ECDSA si arunci cuvinte pe aici.

Am inteles. In primul rand exista conceptul de certificate, adica legatura dintre o cheie publica si o identitate. Se poate folosi acest mecanism. Ar trebui sa mai lucrezi la acel doctorat pentru ca asta e la baza criptografiei. Daca datele nu sunt criptate cu cheia publica, acestea nu se pot decripta (cu cheia privata). In practica, schimbul de chei simetrice se realizeaza prin criptare asimetrica. Diffie Hellman de exemplu. Ai conceptele de Key Exchange vs Key Agreement. Ce am mentionat eu mai sus nu e folosit in practica. E un proces mai complicat care e necesar atat pentru security cat si pentru features (e.g. E2E group chats). Era doar o idee. Dar poti citi singur acel protocol Daca mergem pe principiul tau, NSA poate sa faca MiTM si pe TLS nu? De fapt nu doar NSA, chiar si tu. Cu un mic Man in The Middle poti face asta nu? De ce nu o faci? Mai ales ca ai doctoratul in cryptografie. Acum serios, pune mana pe carte. Edit: Uite mai simpu: https://requestly.com/blog/how-whatsapp-ensures-chat-security-with-end-to-end-encryption/

Bune venit pe Internet, mare hacker. Am inteles nivelul de cunostiinte tehnice. E OK, pentru asta e forumul, sa invatam impreuna ❤️ Iti recomand aceasta carte: https://gnanavelrec.wordpress.com/wp-content/uploads/2019/06/2.understanding-cryptography-by-christof-paar-.pdf Eu am terminat-o de citit zilele trecute. Desi o parte dintre explicatii necesita cunostiinte de matematica, nu sunt atat de avansate pe cat par denumirile, se poate intelege cu o matematica de clasa a VIII-a (a 8-a pentru altii). E asa: 1. Telefonul 0711111111 genereaza o pereche de cheie publica - cheie privata (criptare asimetrica) 2. Telefonul 072222222 genereaza o alta pereche de chei publica - privata 3. Se face schimbul de chei publice 4. Telefonul 0711111111 crypteaza datele cu cheia publica a lui 0722222222 si i le trimite 5. Telefonul 0722222222 decrypteaza datele folosind cheia sa privata (deoarece au fost cryptate cu cheia publica) 6. Se intampla la fel si pentru comunicarea inversa, acelasi principiu Bine, aici e cea mai simpla versiune posibila. In practica, cryptarea se face folosind chei simetrice deoarece e mult mai rapida. Acestea sunt schimbate intre device-uri prin mai multe metode. De exemplu Signal are documentatie: https://signal.org/docs/specifications/pqxdh/ dar si altele au. Problema e ca e mai greu de inteles pentru cineva care zice ca lucreaza de ani de zile ascunzandu-se de NSA, dar nu are basic skills de crypto(graphy).

Nu si daca ai E2E encryption. Telefonul genereaza cheile. Traficul nu e accesibil lor.

As sugera sa lasam la o parte teoriile conspirationiste care nu au dovezi si sa ne axam pe partea tehnica. De exemplu: Oricine are aceste aplicatii si poate intelege cum functioneaza. Sunt persoane care au facut research public pe ele, dar poate face oricine. Nu am vazut pe nimeni sa descopere ceva serios in ele. De fapt, mai apar vulnerabilitati, raportate de Google Project Zero de exemplu. Dar niciuna nu avea legatura cu Man in The Middle. Asa putem banui orice, de exemplu daca unul dintre voi e Donald Trump, celalalt Putin si vreti sa aflati mai multe despre forum?

Windows BitLocker: Screwed without a Screwdriver th0mas We are aware of audio issues, especially during talks of day 1 (2024-12-27). Some talks have been released in a preview-version, but are still being worked on behind the scenes. Ever wondered how Cellebrite and law enforcement gain access to encrypted devices without knowing the password? In this talk, we’ll demonstrate how to bypass BitLocker encryption on a fully up-to-date Windows 11 system using Secure Boot. We’ll leverage a little-known software vulnerability that Microsoft has been unable to patch since 2022: bitpixie (CVE-2023-21563). We'll live-demo the exploit, and will walk through the entire process—from the prerequisites and inner workings of the exploit to why Microsoft has struggled to address this flaw. We'll also discuss how to protect yourself from this and similar vulnerabilities. BitLocker is Microsoft’s implementation of full-volume encryption. It offers several modes of operation, but the most widely used is Secure Boot-based encryption. Many consumer and corporate clients use it, and it’s starting to be enabled by default under "Device Encryption" on newer Windows 11 installations. In this mode, the harddrive is encrypted at rest but is automatically unsealed when a legit windows boots, meaning users don't need a separate decryption password. They just have to sign in with their usual user account. Unfortunately, this configuration has been broken for quite a while. Hardware attacks against a dTPM are widely known, but software attacks are possible as well, at least since 2022, when Rairii discovered the bitpixie bug (CVE-2023-21563). While this bug is 'fixed' since Nov. 2022 and publically known since 2023, we can still use it today with a downgrade attack to decrypt BitLocker. In this talk, we'll dive into: - How does Secure Boot work, and what role does the TPM play? - How can Bitlocker leverage the TPM? - How does the bitpixie exploit work? What are PXE boot and BCD? - What are the prerequisites for running this exploit? - How can you protect yourself against it? - Why is it so challenging for Microsoft to fully fix this? - How does this affect Linux secure boot? Licensed to the public under http://creativecommons.org/licenses/by/4.0 URL: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-without-a-screwdriver

Nop, e doar vorba de bani, daca nu ar da salarii de 5000 RON ar avea si ei oameni buni. Utilizatorii sunt serviciul. Banii nu se fac doar vanzand direct catre consumatori (e.g. iti cumperi o masina). Utilizatorii sunt cei care aduc banii, cum e Facebook sau Instagram, dau click pe reclame. Google Maps si celelalte servicii Google aduc multi bani indirect, strangand informatii despre utilizatori astfel incat la ei sa ajunga cele mai relevante reclame. Dap, cei care vor sa faca bani vanzand mizerii catre oamenii simpli. Produse idioate, nenatatoase sau mai stiu eu ce. Asa functioneaza economia. E doar un exemplu, dar uite ceva concret, cu acel United Healthcare - big pharma american. Banii se duc "unde trebuie", la actionari si la cine trebuie sa scoata sute de milioane din profiturile facute de corporatii. Dar asta nu are legatura cu serviciile. Da, dar am plecat de la servicii secrete si am ajuns la altele. Inteleg ca esti de acord cu mine ca nu e vorba doar despre servicii secrete, ca ele controleaza tot sau mai stiu eu ce teorii conform carora pamantul era plat iar ei l-au rotunjit. Daca mergi pe ideea asta, mai schimba de pe Realitatea Plus televizorul. Teoria ta duce catre rusi. Ce sa inteleg din asta? Ca ei sunt cei de treaba? PS: Imi plac discutiile de genul acesta dar ne-am deplasat putin de la scopul topicului.

Parca ti-a disparut toata paranoia Cei care fac treburile "murdare" sunt acolo nu? Nu cred ca NSA are un echivalent la noi. Chiar citeam zilele astea o carte de crypto (Understanding Cryptography) in care erau mentionate cateva lucruri interesante, precum faptul ca DES e safe impotriva differential analysis care a fost descoperit public prin anii 90, in timp ce algoritmul e cu 20 de ani mai vechi. Si mai erau cateva astfel de mentiuni. Nu era specificat cine le descoperise initial, dar erau mentionate lucruri gen NSA sau GCHQ. Si astea sunt informatii publice. Daca tu crezi ca aceia sunt angajatii NSA sau ca sunt toti, ma dezamagesti, dupa discutiile de mai sus. Edit: Ca tot vorbeam la inceput despre hackeri, aici e hacking adevarat conform standardelor mele: https://media.ccc.de/v/38c3-blinkencity-radio-controlling-street-lamps-and-power-plants

A significant portion of Europe's renewable energy production can be remotely controlled via longwave radio. While this system is intended to stabilize the grid, it can potentially also be abused to destabilize it by remotely toggling energy loads and power plants. In this talk, we will dive into radio ripple control technology, analyze the protocols in use, and discuss whether its weaknesses could potentially be leveraged to cause a blackout, or – more positively – to create a city-wide Blinkenlights-inspired art installation. With three broadcasting towers and over 1.3 million receivers, the radio ripple control system by *EFR (Europäische Funk-Rundsteuerung) GmbH* is responsible for controlling various types of loads (street lamps, heating systems, wall boxes, …) as well as multiple gigawatts of renewable power generation (solar, wind, biogas, …) in Germany, Austria, Czechia, Hungary and Slovakia. The used radio protocols Versacom and Semagyr, which carry time and control signals, are partially proprietary but completely unencrypted and unauthenticated, leaving the door open for abuse. This talk will cover: - An introduction to radio ripple control - Detailed analysis of transmitted radio messages, protocols, addressing schemes, and their inherent weaknesses - Hardware hacking and reversing - Implementation of sending devices and attack PoCs - (Live) demonstrations of attacks - Evaluation of the abuse potential - The way forward Licensed to the public under http://creativecommons.org/licenses/by/4.0 URL: https://media.ccc.de/v/38c3-blinkencity-radio-controlling-street-lamps-and-power-plants

Ai cateva exemple? De persoane publice care ar lucra la NSA sau similare? Poate face asta daca are ceva de castigat. La companii precum Google sau Apple are sens, dar la altele mai mici, nu prea. Ce se intampla pe device-uri poate analiza oricine. Se poate afla, dureaza procesul de reverse engineering pentru aplicatii dar nu e deloc imposibil. Exista oricum alternative sau se pot crea oricand alte aplicatii. Oricum, nici corporatiile astea nu se arunca cu capul inainte deoarece daca sunt prinse, ceea ce se poate cum ziceam prin reverse engineering, e foarte nasol: pierd multi utilizatori, scade stockul si smecherii (aia cu adevarat smecheri, actionari cu mult stock) pierd multi bani.

Eu cred ca cei care lucreaza pentru NSA nu sunt persoane publice. Nu apar pe Twitter, pe la conferinte si prin alte locuri. Majoritatea lucreaza pe bani frumosi pentru multinationale / corporatii. Unele companii investesc in persoane a caror munca de zi cu zi nu e sa faca pentest, ci sa faca research, sa descopere lucruri noi. Cel mai cunoscut exemplu e Google Project Zero, dar multe companii au astfel de oameni. Ceea ce e ideal, omul se dezvolta, compania e ajutata. Mai greu de argumentat cu managementul despre ROI (Return of Investment). Acum, fiecare intelege ce vrea prin hacker. Eu am o parere, ca sunt cei care fac research, descopera si publica lucruri interesante, tu poate esti de parere ca singurul lucru care conteaza sunt banii. Poate e cate putin din fiecare.

Recent: PS: Tipa e smechera. E top.

Prima regula care nu se aplica doar in security, ci si in multe alte lucruri, inclusiv fotbal sau mai stiu eu ce e urmatorul: sa iti placa ceea ce faci. Daca o faci pentru bani, slabe sanse sa ai succes. Daca iti place o sa pui si osul la treaba care e urmatorul pas. Sa inveti. Mai intai cate putin din fiecare, apoi extinzi ceea ce stii in functie de necesitati.

Banii se fac muncind, legal. Sau inseland, furand sau efectuand alte activitati - ilegal. Grupurile la care te referi probabil sunt niste mizerii piramidale din care nu o sa faci bani, o sa pierzi inutil mult timp.

O sa ma uit pe 8 ian cand ma intorc la treaba.

How I Also Hacked my Car 2024-01-30T22:14:07+00:00 • goncalomb • hacking,car,dacia,rpi This blog post is kind of inspired by another that I saw on HN some time ago, "How I Hacked my Car". After praising the infotainment system of the car, a Hyundai IONIQ, the author ends up hacking it and running custom software on the head unit. Well, my much cheaper 2023 Dacia Sandero also has a decent infotainment system with navigation and wireless Android Auto. Even before I got the car, I searched around to see if the system was hackable. I was not surprised to find that a simple USB drive with an autorun.sh script gets run as root. A classic. Various forums around the web use this method to change skins and side-load navigation maps. I was not interested in that, my goal was also to run some custom software. Well, there is more to the story, otherwise, I would just that autorun.sh "feature". The Infotainment System The system is a MediaNav Evolution from Renault (which Dacia is a subsidiary of), built by LG (FCC ID: BEJLAN5900WR). It's a Linux box. Over the years there have been various iterations of this system, the older devices used WinCE. The navigation part of the software is by a company called NNG (iGO?). Apparently, they provide navigation software for many other devices. MediaNav Evolution (unofficially called MediaNav 4) The autorun.sh Just by looking around on various forums, I knew of 3 special files that when placed on a USB drive would trigger some debug functions: autorun_bavn/autorun.sh: a script that gets run as root logfiles_bavn: a directory that gathers various system logs and files usb_logging: a directory where the system continually dumps dlt files (proprietary log system) One good thing about the log files is that they contain the Wi-Fi password for the AP. This password can be reset on the UI, but it's never visible. Knowing the password allows other devices to connect to it (e.g. PC). When using wireless Android Auto it connects automatically, I think it bootstraps using Bluetooth. I was most interested in the autorun.sh... But it was not working, I couldn't get the script to run. The Firmware At this point, I decided to start inspecting the firmware to see what was wrong, and if there was another way in. My device came with version 6.0.9.9. I wanted a recent update file, but the official website doesn't provide a direct download. It requires installing a desktop application, "Toolbox", which I ended up doing. The application can be used to buy map updates or download firmware/OS updates for free. The procedure starts with collecting some information about the system/car to a USB drive. After connecting it to a PC, the "Toolbox" software detects a new update and puts the new update file on the drive. I didn't update it, I just wanted the file, it was version 6.0.10.2: >: file upgrade.lgu upgrade.lgu: POSIX tar archive (GNU) I also had an older update file, version 6.0.9.7, that I found in some random forum. Sometimes even grep can be a great analysis tool. Just by running grep -RF autorun.sh on the contents of both the new and old firmware, I could see that the new one had no matches. Time to load Ghidra and see what's going on... Version 6.0.9.7 has the autorun.sh feature, but it is not present on version 6.0.10.2 Comparing the 2 files it was evident that they had removed the autorun.sh backdoor. Even though I didn't have the specific firmware for my installed version (6.0.9.9), it was clear that mine didn't have it and that's why I could never get it to work. This miscmanager file is also responsible for the other USB debug features, these are all still there. The core OS appears to be from GENIVI/COVESA (GitHub: GENIVI/COVESA). I'm not familiar with these systems at all. They have a fair bit of open-source stuff that will probably explore in the future. I decompiled other binaries to try to look for some other interesting stuff. Found a lot of D-Bus stuff, that will be useful for getting vehicle information when I can run my own software. But my goal was to get root access first. One way would be to craft a new update file with a backdoor, which would require reverse engineering the whole upgrade procedure, and as expected the update files do have some signature hashes that presumably need to match. Getting root access directly would be the preferred way. The Android Update App Something I noticed on the official website was that they were promoting a new way to update the maps, using an Android phone app. Could this be my way in? The description on Google Play promises to "Eliminate the Sneaker Network", an expression that I had never heard, in reference to not requiring a USB drive. Of course I didn't install it, there is no point in that. I just searched the id com.nng.pbmu.dacia on Google to find one of the many sites that offer the .apk file for download. I'm not an Android developer, I just know that deep inside there is some bytecode that traces its root back to Java, and I know Java. I don't care about Dalvik, ART, Zygote, or whatever. Just give me those Java classes. Over the years I've decompiled a few Android apps, my preferred way is just to unpack the .apk as a .zip (that's all it is), get the .dex bytecode files, run them through dex2jar to get some .jar files and open them with good old JD-GUI. Recently I've discovered jadx which provides a better experience for decompiling apps. To my surprise the app was quite complex, it appears to include some sort of native bindings, and most of the functionality is implemented in some kind of proprietary .xs scripts (similar to JavaScript). These are found on the app's resources. Android APIs are exported as modules to be used in the .xs scripts Several native libraries and .xs scripts It appears that the liblib_nng_sdk.so library is responsible for running these scripts, but I didn't explore it further. My goal was just to focus on what kind of protocol was used to update the maps on the device. And I found it in the file nftp.xs. NFTP!? Is it standard FTP? No, it's not standard FTP or any other known protocol that I could find. It's a new binary protocol for transferring files, implemented on these .xs scripts. The app then uses Android Open Accessory (AOA) as the transport layer for the protocol. AOA was totally new to me, but after some reading, it was clear that it is just a way of establishing a standard for an accessory to talk USB with an Android device. The names are confusing, the "accessory" is actually the USB host (in this case, the head unit) and the Android device is the USB peripheral. The Other Side The new update file that I had was version 6.0.10.2, which, according to the website, was the version required for the new update app to work. That naturally means that there is some specific service/code on that file to handle the update on the head unit side. After some digging, I found it. It's another set of .xs scripts, these run on a native interpreter. There is also a native binary, aoa2sock, that bridges the gap between USB (AOA) and the .xs scripts by providing a pipe for the transfer protocol. It's clear that this phone update feature is an afterthought, the binaries/scripts are not part of the standard upgrade filesystem, they are installed separately from a .ipk package file (yellowtool.ipk) when the system is updated. The internal name they use is YellowTool / YellowBox. And this is the only part of the entire system that is coded with these .xs scripts, everything else is just native binaries. Most of the system uses native binaries and Qt applications The mobile update app feature uses .xs scripts Being plain text scripts, it was relatively easy to understand what the protocol does and what kind of access it provides, even though the coding style is atrocious. Constructing The Backdoor At this point, just by reading the code, I was pretty sure that it was possible to write arbitrary files under the /navi directory, and that would give me full access if I carefully modified some files. I just needed to create a fake Android update app and connect using AOA. Well, as I said before, I'm not an Android developer, so I went with the next best thing, the Linux Kernel. As it turns out I'm also not a kernel developer... But I knew that it has something called gadget mode, where a device running Linux can act as a USB peripheral (instead of a host). Could I make a Raspberry Pi act as an Android device in AOA mode? Gadget mode can be configured from userspace using configfs (just by writing specific /sys/kernel/config/ files), this way does not require writing any kernel code, but it's limited to specific "functions" already implemented in the kernel (e.g. serial port, mass storage, ethernet adapter etc). Not unsurprisingly, that's how the guys at Google implemented AOA, they added a new "accessory" function to the kernel. They even tried to push it upstream, but it went nowhere, currently, it's not part of the Linux Kernel. I don't think it will ever be, it's probably too specific, and it's kind of a weird protocol. After reading more about AOA, it was clear that it involved a kind of handshake where the accessory asks the Android device for AOA, and after that, the device just acts like a serial port (a "raw" data pipe), and it's up to the developer to do the rest (this is a simplification, and there are other modes, read more). So maybe I could use the serial gadget function to fake an Android device already in accessory mode, without implementing the handshake. I also found the talk where they first announced AOA, back in 2011. It's a nice talk if you are into USB stuff: The Testing Setup The system is something like this: Android side: Update App / "nftp" (.xs scripts) <=> AOA <=> USB Head unit side: USB (host) <=> aoa2sock <=> "nftp" (.xs scripts) <=> [reads/writes system files] For testing, I used 2 Raspberry Pies. Because the head unit is ARM-based as is the Raspberry Pi, I was able to run the aoa2sock binary and .xs interpreter from the firmware, this simulated the head unit and acted like a USB host. The other RPi was the USB peripheral (using the On-The-Go, OTG port), which when configured correctly using the gadget mode, acted like an Android device in AOA mode. The smaller Raspberry Pi Zero 2 W can be powered from the OTG port and will act as the Android device After messing about with multiple gadget configurations, I was seeing some promising debug messages from aoa2sock, that's the binary extracted from the firmware that creates a pipe between the USB AOA and the weird "nftp" protocol (.xs scripts), on the head unit side. But it was not working... "No AOA endpoint was found": My fake head unit was not recognizing my fake Android device >: file aoa2sock aoa2sock: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=XXXXXXXX, with debug_info, not stripped After inspecting the aoa2sock binary in Ghidra (thanks for the debug info) and reading the kernel code, I finally found the issue. The kernel serial port gadget uses a different USB subclass from the one used by AOA, and it can't be changed from userspace. Is this a bug? I think AOA is correct in using USB_SUBCLASS_VENDOR_SPEC for a generic interface OK... Let's patch the kernel I ended up having to download the kernel source and patch the f_serial.c gadget function to change the USB subclass. After compiling the kernel module and loading it using modprobe, it finally worked and the aoa2sock binary recognized the device. My fake Android device was finally connected to my fake head unit Can I call myself a kernel developer now? All that was left to do was to somehow recreate that "nftp" protocol. I didn't really want to use the proprietary .xs files implementation, so I wrote my own in Python. At this point, I had all the pieces and the Raspberry Pi now replaced the Android app: Raspberry Pi side: Python Script ("nftp" implementation) <=> USB Gadget Mode (emulates AOA) Head unit side (same as before): USB (host) <=> aoa2sock <=> "nftp" (.xs scripts) <=> [reads/writes system files] Creating the backdoor involved issuing "nftp" commands to edit a specific file under the /navi directory and inject a call to a bash script, this bash script (also uploaded using "nftp") contains the payload that runs as root. H4cking Time After much testing with my dual RPi setup, I was confident that it was going to work... Raspberry Pi Zero 2 W (OTG port) connected to the infotainment head unit Setting up for an update... Ready to "Update with Phone", that option is only available after version 6.0.10.2 Waiting for a phone Time to put the RPi in gadget mode (I was connected to it using SSH)... Sorry, it's not a phone and we are not sending any maps Sending and running the payload... Got it! Success! I had root access. That payload is just call to a specific D-Bus method that I found while analyzing the firmware, it shows a popup with custom text and title. The text is the output of the id command. Finally, after replacing the payload with something more useful, a simple socat bind shell and connecting back to it using Wi-Fi, I had full access. Give me that root shell If you didn't follow it all the way, here's a summary: I used a Raspberry Pi in USB gadget mode to simulate an Android device connected to the head unit. The head unit thinks it's accepting a navigation maps update from the "phone", but because the update protocol allows for arbitrary file changes, I can issue commands to modify a specific file and inject a call to a bash script that gets run as root. Code Please Everything is on GitHub with more detailed instructions (it contains no proprietary code). The key pieces are my implementation of the "nftp" protocol and the gadget configuration. What's Next? This is just the beginning, now it's time to really explore the system. First, I'll probably end up restoring the autorun.sh functionality, with a custom service, because I think that's the easiest way to load software. That way I can keep all the new stuff on the drive and make as few changes to the system as possible. One of the main things I would like to do is record car parameters, stuff like speed, fuel, location etc. It remains to be seen if I can easily access that information through D-Bus, or if I need to go deeper. I'm not interested in adding anything that requires my attention while driving. But that's for another time... Some Extras (Could I have used SSH?) Two ports are open by default on the head unit, an SSH server, and some Apple service, probably related to CarPlay (Server: AirTunes/320.17.6), I didn't really explore that. But I tried cracking the /etc/shadow root password from the update file using hashcat / john with some rules and password lists. I'm not an expert doing this at all, I don't even know if I was doing it right, and was not successful. Not that it matters now, I could just change the root password or add a new user. SSH on port 22 / AirTunes/320.17.6 on port 7000 Sursa: https://goncalomb.com/blog/2024/01/30/f57cf19b-how-i-also-hacked-my-car

E un forum de security, simte-te liber sa postezi mai multe detalii. Mie cel putin imi plac lucrurile tehnice de orice fel, atat "attack" cat si "defense". Eu ma refeream ca pe placa de baza poti avea componente in plus, implanturi, care pot face destul de multe lucruri, cel mai simplu ar fi nu accesul la procesor (ca nu are sens), ci la memorie, sau la datele care se plimba pe acolo. Astfel de lucruri nu sunt imposibil de prins dar foarte dificil. Si nu cred ca sunt multi care isi fac custom hardware. Uite doar un exemplu, desigur mai mult teoretic, la care ma refeream: https://cs-people.bu.edu/tromer/acoustic/ - This is hacking.

Inventezi masina timpului, mergi 5-10 ani in trecut, cumperi cryptocurrencies (crypto == CRYPTOGRAPHY, sunteti pe un forum de security, bha), profit.

Side-channel attacks. Trebuie sa invatati hardware ca cine stie ce face acel mic chip de pe placa, cine stie cum WiFi trimite date. Snowden leaks au aratat multe lucruri misto. Inclusiv monitorizare "remote" (de la mica distanta) folosind undele electromagnetica de la cablu VGA. V-am zis mai sus care e singura solutie.

Inteleg idee, oricum, pana la urma, daca cineva e destul de motivat, poate afla orice bit de pe orice tip de hardware. Dar care ar fi scopul? In primul rand inteleg paranoia, dar atunci cand e cazul. Daca sunteti presedinti sau persoane importante, daca faceti infractiuni de milioane de dolari, daca controlati corporatii de miliarde de dolari sau mai stiu eu ce, da, aveti grija. Dar... chiar e cazul? Un lucru pe care il puteti face e sa monitorizati traficul, paranoic vorbind, la un alt layer, nu de pe hardware-ul care il genereaza. Sunt destul de sigur ca nu o sa vedeti mare lucru. Exista reverse engineering la orice fel de software, iar cu niste skill-uri bune de hardware... Ca sa nu mai zic ca probabil nu compilati voi acele sisteme de operare si toate programele care ruleaza. Asta, desigur, dupa ce faceti code review la cateva sute de milioane de linii de cod. Solutia mai simpla si care functioneaza 100% e sa nu mai folositi deloc tehnologia.