Leaderboard

Nop, nu e pentru astfel de persoane. Pentru tine exista Tiktok.

Aici sunt. A fost busit forumul si nu se mai putea posta, plus ca am fost prins cu munca mea de corporatist sarac care nu am macar un Urus amarat in garajul plin de teancuri de cryptomonede Muie Pax. Se stie. P.S. Voi va dati seama ca @paxxx a schimbat prefixul de la 2 la 3? Atat de batrani suntem, in plm.

Sursa: https://doi.org/10.5281/zenodo.15761894 ✅ Un atacator care utilizează inteligență artificială (AI) pentru a compromite un sistem CBDC (Central Bank Digital Currency) nu va acționa ca un hacker clasic. În schimb, el va folosi AI pentru a detecta slăbiciuni comportamentale, arhitecturale și sociale ale sistemului și pentru a automatiza și scala atacurile. 🎯 Obiectivul final: Să submineze funcționarea CBDC sau să obțină acces/control asupra fondurilor, logicii programabile sau identităților utilizatorilor prin exploatare inteligentă, în masă sau subtilă. 🔐 10 MECANISME DE ATAC CU AI ÎMPOTRIVA CBDC Reconstrucția modelelor comportamentale (Shadow AI) • Ce face: AI-ul atacatorului urmărește și imită algoritmii oficiali de fraudă/monitorizare. • Cum: Colectează date despre tranzacții, frecvențe, comportamente și detectează ce tipare declanșează alerte. • Rezultat: Poate construi tranzacții care sunt „invizibile” pentru AI-ul oficial al sistemului CBDC. Replay inteligent și imitație tranzacțională • Ce face: Creează modele care simulează perfect comportamentul unui utilizator legitim. • Cum: AI-ul învață secvențe de plăți recurente, orare, locații, și le reproduce fără declanșare de alarmă. • Rezultat: Transferuri frauduloase nedetectabile până la analiză umană post-factum. Manipularea programabilității banilor • Ce face: AI detectează și exploatează logica „smart money” (ex: bani valabili doar pentru anumite produse sau până la o dată). • Cum: Caută versiuni de firmware, reguli de cheltuire și încalcă condițiile de utilizare fără declanșarea mecanismelor de blocare. • Rezultat: Permite tranzacții interzise, cum ar fi achiziții neautorizate. Poisoning de modele predictive (Data Poisoning) • Ce face: Atacă AI-ul oficial al băncii centrale. • Cum: Introduce în mod deliberat date false (mii de portofele controlate care simulează activitate legitimă sau frauduloasă). • Rezultat: Slăbește acuratețea detecției și creează „orbi” statistici în motorul AI de fraudă. Clonare biometrică prin AI • Ce face: Folosește AI pentru a crea falsuri vocale, faciale sau de amprente. • Cum: Prin deepfake și voice synthesis, AI poate imita în mod credibil un utilizator pentru a trece verificările. • Rezultat: Acces fraudulos la fonduri CBDC fără niciun exploit tehnic tradițional. Crearea de AI honeypots (portofele-capcană) • Ce face: Creează portofele false ce atrag AI-ul de detecție al sistemului CBDC. • Cum: Simulează comportamente „aproape” ilegale pentru a deturna sau învăța AI-ul oficial. • Rezultat: Dezactivează temporar sau păcălește sistemul AI de control. Exfiltrare prin API folosind NLP adversarial • Ce face: Folosește AI pentru a interacționa cu interfețele guvernamentale în mod subtil. • Cum: Trimite cereri „valide” dar ambigue (scrise special pentru a păcăli filtrarea NLP) în API-uri de suport, audit, sau reclamații. • Rezultat: Obține acces indirect la date sensibile sau controlează fluxuri fără a sparge sisteme. Răspândire de haos financiar prin simulare AI • Ce face: AI creează rețele sociale false care diseminează panica („CBDC blocat!”, „Portofele sterse!”). • Cum: Utilizează bots și NLP generativ pentru a crea iluzia unei crize. • Rezultat: Crize de încredere, retrageri masive, destabilizarea economică a unei zone. Scoruri sociale false și manipulare comportamentală • Ce face: AI poate învăța cum sunt calculate scorurile sociale (unde sunt integrate în CBDC). • Cum: Se comportă într-un mod optimizat pentru a obține beneficii, reducând penalizările și păcălind sistemul. • Rezultat: Obține acces preferențial la fonduri, bonusuri, sau reduceri în mod fraudulos. Inginerie socială AI la scară națională • Ce face: Creează mii de profile AI care simulează autorități, bănci sau servicii oficiale. • Cum: Apelează utilizatori, trimite notificări frauduloase de tip „verifica urgent soldul CBDC”. • Rezultat: Sute de mii de victime redirectioneaza fonduri voluntar spre portofele controlate. 🔚 Concluzie Atacurile cu AI asupra CBDC nu vor fi brute-force, ci strategice, comportamentale si scalabile. 🧠 AI-ul atacatorului: • Nu sparge servere. • Imita, invata, distorsioneaza si corupe comportamentul sistemului. • Exploateaza logica, nu codul. 🛡️ Iar cum CBDC nu poate renunta la centralizare, supraveghere si programabilitate, aceste atacuri nu vor putea fi niciodata complet eliminate — doar limitate temporar. Odată cu apariția CBDC (monede digitale emise de băncile centrale), unele dintre tehnicile tradiționale folosite în atacurile asupra Bitcoin, cum ar fi RBF, Double Spend, sau 0-conf, nu mai pot fi aplicate direct — dar hackerii le pot regândi în moduri similare, adaptate la specificul CBDC: centralizare, programabilitate și supraveghere digitală totală. 🔁 Regândirea celor 5 tehnici clasice Bitcoin pentru CBDC Atac BTC Echivalent în CBDC Cum funcționează atacul asupra CBDC RBF (Replace-By-Fee) 🔁 "Replace-by-Justification" Hackerul trimite o tranzacție CBDC, apoi o retrage sau modifică motivând eroare tehnică, medicală, etc. Sistemul CBDC cu intervenție umană permite „corecția” dacă ai motive acceptate. Finney Attack ⏱️ "Pre-validare falsă de portofel" Hackerul preînregistrează o tranzacție dar nu o finalizează, iar între timp o folosește ca dovadă de plată falsă în fața unei entități. Poate funcționa în portofele CBDC interconectate cu aplicații comerciale. 0-conf (Zero Confirmation) ⚡ "Zero Clearance Delay Attack" Tranzacția este trimisă, iar comerciantul o acceptă instant (ex: NFC). Hackerul exploatează un bug sau delay intern în procesarea serverului. Dacă retrage sau schimbă starea portofelului imediat, poate anula tranzacția. Race Attack 🧠 "Race of Transaction Conditions" Hackerul trimite două cereri simultane către rețele CBDC diferite (ex: două regiuni, două aplicații) și doar una se procesează complet. Cealaltă rămâne pending și poate fi anulată. Vector76 Attack 🛰️ "Node De-Sync Attack (CBDC Proxy)" Creează o aplicație clonă sau server proxy ce intermediază interacțiunile cu sistemul oficial, dar injectează modificări subtile (ex: schimbă beneficiarul în backend). 🔐 Alte atacuri similare pe care AI sau hackeri le-ar putea folosi în CBDC 🧬 Simulare de portofel fantomă (Shadow Wallet) • Hackerul creează un portofel sincronizat cu interfața reală, dar care redirecționează fondurile în fundal. • Se poate face prin aplicații modificate, wallet-uri customizate. 🎭 Redenumirea tranzacțiilor în jurnal • Tranzacțiile pot avea tag-uri (ex: "asistență medicală", "alimente"). • Hackerul le trimite ca "tranzacție aprobată" dar le redenumește vizual pentru a păcăli comerciantul sau utilizatorul. 📲 Atac pe aplicație cu dublă vizualizare • Aplicația de portofel arată o tranzacție "aprobată" pe ecran, dar nu este validată în rețeaua CBDC oficială. • Hackerul menține sincronizarea locală, dar deturnează starea reală. 🧠 Atac comportamental asupra sistemului de scor/identitate • Hackerul introduce sute/mii de comportamente „perfecte” care învață cum funcționează sistemul de scor social sau prioritate. • Obține statut preferențial în sistem și execută fraude pe baza încrederii câștigate. 🔃 Reverse-execution attack • Hackerul simulează un rollback al contului bazat pe o eroare (medicală, juridică, identitate), iar sistemul centralizat acceptă modificarea balanței. 🎯 Esența atacurilor în CBDC: Spre deosebire de Bitcoin unde atacurile sunt tehnice și criptografice, în CBDC ele vor fi: • Comportamentale • Sociale și psihologice • Exploituri în interfață și decizii umane • Manipularea regulilor programabile 🔚 Concluzie CBDC poate bloca anumite tipuri de atacuri brute, dar deschide ușa la: • Manipulare de logică • Atacuri prin inginerie socială și AI • Fraudă pe niveluri soft (UX/API/trust layer) Phishing-ul și manipularea socială (social engineering) nu doar că se pot aplica la CBDC (Central Bank Digital Currency), ci vor deveni probabil unele dintre cele mai frecvente și eficiente metode de atac împotriva utilizatorilor sistemului. Mai mult decât în cazul criptomonedelor clasice, deoarece CBDC: • Este interconectat cu identitatea ta oficială (KYC) • Este accesibil prin aplicații guvernamentale sau bancare • Poate include funcții programabile și controlate la distanță 🎣 Cum funcționează phishing-ul în cazul CBDC? Metodă de atac Cum este aplicată la CBDC Email/SMS spoofing Mesaje false de la „Banca Națională” sau „Aplicația CBDC” care cer să-ți confirmi datele sau să accesezi un link Portofel fals Aplicații CBDC clone (cu design oficial) distribuite pe site-uri sau magazine neoficiale Link-uri frauduloase Pagini de login care imită interfața guvernamentală, unde introduci datele tale reale Update-uri false Notificări de tip „actualizează-ți portofelul CBDC pentru funcționalitate completă” – dar de fapt descarci un spyware 🧠 Cum funcționează social engineering cu CBDC? Tehnică Descriere aplicată în contextul CBDC Autoritate falsă Apeluri/mesaje de la „funcționar bancar” care solicită verificarea contului, sub pretextul unei erori Panică/urgenta „Contul tău CBDC este blocat!” sau „Ai primit fonduri suspecte, confirmă identitatea în 5 minute” Falsuri biometrice Se cere să trimiți selfie/video/voce pentru „confirmare rapidă”, dar hackerul folosește aceste date pentru acces Atac asupra rudelor Hackerul contactează o rudă în vârstă spunând că trebuie să transfere urgent fonduri din CBDC „pentru a evita penalități” 🔓 De ce aceste atacuri sunt greu de prevenit? • CBDC este conectat la infrastructură națională, iar oamenii au încredere în autorități – ceea ce face ca phishing-ul să pară mai legitim. • Majoritatea utilizatorilor nu cunosc cum funcționează criptografia sau portofelele digitale. • Atacatorii pot folosi AI (deepfake, voice cloning) pentru a păcăli și mai ușor victimele. 🔐 Exemple realiste: SMS fals: "Aplicația eLEU: contul tău a fost suspendat temporar. Accesează imediat www.cbdc-verificare.net pentru reactivare." Email oficial fals: "Banca Centrală Europeană actualizează sistemul CBDC. Te rugăm să îți reconfirmi identitatea." Aplicație Android falsă: Numită „Portofel CBDC România” – apare pe forumuri, trimite datele la un server extern. ✅ Cum te protejezi (utilizator simplu)? • Nu dai niciodată date personale prin SMS/email. • Instalează doar aplicații de pe site-ul oficial sau magazinul verificat (Google Play, App Store). • Activează autentificare 2FA unde este posibil. • Verifică adresa site-urilor (HTTPS, domenii oficiale). • Fii sceptic la urgențe sau apeluri nesolicitate. 🛡️ Cum se pot proteja și guvernele? • Monitorizare constantă a campaniilor de phishing și site-uri false • Educație digitală în masă • Introducerea unor mecanisme hardware (ex: token fizic, semnătură biometrică locală) pentru autentificare

Cam da. Exista o explicatie pertinenta in advertorialul asta https://www.searchenginejournal.com/ai-mode-playbook-visibility-marketbrew-spa/548187/

i-ar ti-ai luat teapa , eu ti-am scris , nu m-ai bagat in seama

Pai as fii vrut sa incerci tu daca tot ai instalat , sa nu ma chinui degeaba , vreau sa stiu daca merge , atat. nu am un laptop performant , asa daca stiu ca merge ma duc si imi iau unul

ce naiba sa inveti ma de la astia. pana si builder.ai care au angajat 700 sa mimeze AI au dat faliment .

retete culinare bre si reviewuri la filme

Know Your Customer Ma gandesc ca sunt frameworks sau companii care ofera acest serviciu. Le trimiti selfie si se ocupa ei. Procesul pare similar la mai multe aplicatii, banuiesc ca in spate au acelasi provider. Nu am idee care e, dar probabil e ceva "cunoscut".

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

Cu putina inginerie sociala afli unde sta si de unde si cumpara electronice si alte chestii. Ii trimiti din partea acelui magazin un cadou cu ceva pentru pc care contine si un super mic programel care modifica hosts file . Poti sa i faci si un Evil Twin Attack. Vezi daca cel ce ti a furat contul se mai ocupa cu asa ceva sau alte prostii informatice. Poti sa creezi honeypoturi. Insa eu iti recomand sa vorbesti cu cei de la CERT. Ei se ocupa cu facebookuri furate.

Du-te sa te culci

https://github.com/zxo2004/DarkComet-RAT-5.3.1 https://github.com/simalei/njRAT Maybe next time you will search yourself not be so lazy. good luck to caught your girlfriend cheating on you :)))

Caut pe cineva care poate sparge un cont de fb

Hahaha

Hahaha. Nu inteleg pentru ce e acest forum, cine imi spune si mie? 🤔