Gli esperti hanno identificato gravi vulnerabilità in SMBClient per macOS che interessano sia lo spazio utente che il kernel del sistema operativo. Queste vulnerabilità consentono potenzialmente l’esecuzione remota di codice arbitrario e l’interruzione di processi di sistema critici. Durante l’analisi, è emerso chiaramente che un’ampia gamma di utenti è a rischio, dato che a partire da macOS Big Sur, il protocollo SMB è diventato il metodo preferito per organizzare la condivisione di file in rete.

SMBClient è un insieme di componenti, che include sia processi utente che driver del kernel, progettati per funzionare con file system accessibili tramite risorse di rete. Una parte significativa del codice client SMB interagisce direttamente con il kernel del sistema, il che apre ulteriori vettori di attacco. Inoltre, è possibile sfruttare le vulnerabilità con un intervento minimo dell’utente: è sufficiente costringere una persona a seguire un collegamento appositamente predisposto del tipo smb://.

La prima delle vulnerabilità scoperte è il CVE-2025-24269 (punteggio CVSS: 9,8) ed è correlata al componente smbfs.kext, il driver del kernel macOS per l’utilizzo di SMB. Il problema risiede nella funzione di elaborazione dei dati compressi smb2_rq_decompress_read, dove in alcuni casi la lunghezza dei dati in ingresso viene verificata in modo errato. Se viene utilizzato uno degli algoritmi di compressione supportati – LZNT1, LZ77 o LZ77_Huffman – il campo speciale compress_len viene letto dal pacchetto di rete, ma il suo valore non viene convalidato in alcun modo prima di copiare i dati nel buffer compress_startp. Allo stesso tempo, la macro SMB_MALLOC_DATA, utilizzata per allocare la memoria, consente a un aggressore di controllare la dimensione del blocco allocato, che può raggiungere fino a 16 megabyte.

Di conseguenza, si verifica un overflow di memoria dinamica all’interno dell’heap dati xnu, un’area della memoria del kernel in cui la presenza di puntatori di controllo è limitata da meccanismi di protezione aggiuntivi, ma è impossibile escludere completamente la possibilità di sfruttare tale difetto. Gli esperti sottolineano che, per un attacco riuscito, è sufficiente convincere l’utente a cliccare su un collegamento smb:// dannoso, che consentirà all’attaccante di avviare l’interazione con il server vulnerabile e attivare la trasmissione di pacchetti appositamente preparati.

La seconda vulnerabilità, identificata come CVE-2025-24235 (punteggio CVSS: 5,5), riguarda la libreria Kerberos Helper utilizzata per stabilire una sessione SMB. Qui è stato rilevato un classico errore di sicurezza: la liberazione di una variabile di stack non inizializzata. Durante l’analisi dei token di autenticazione nella funzione _KRBDecodeNegTokenInit, potrebbe verificarsi una situazione in cui la chiamata interna a _gss_decapsulate_token fallisce. Tuttavia, anche in questo caso, il controllo viene trasferito al blocco di rilascio della memoria, dove la funzione _free_NegotiationToken opera con un’area di stack non inizializzata.

Un’analisi più approfondita ha mostrato che il processo di liberazione della memoria richiama la funzione _asn1_free della libreria Heimdal, progettata per analizzare e cancellare le strutture ASN.1. Poiché la struttura da liberare non è stata inizializzata, sussiste il rischio di un accesso incontrollato alla memoria, che potrebbe potenzialmente portare all’esecuzione di codice arbitrario sul dispositivo della vittima. Per un attacco riuscito, è sufficiente utilizzare meccanismi di connessione standard, ad esempio seguendo un collegamento smb:// o montando una risorsa tramite mount_smbfs.

La terza vulnerabilità, sebbene non abbia ricevuto un identificativo CVE ufficiale, è comunque considerata critica. È correlata a un’implementazione errata del meccanismo di registrazione del processo mc_notifier nel modulo smbfs. Questo servizio è responsabile delle notifiche quando le risorse di rete vengono smontate. Un utente con qualsiasi livello di privilegio può registrare un identificativo di processo arbitrario utilizzando la richiesta ioctl SMBIOC_UPDATE_NOTIFIER_PID. Se la risorsa viene quindi smontata, il kernel di sistema invierà al processo registrato un segnale SIGTERM, ovvero la terminazione standard.

Il problema è che il kernel non verifica i permessi del processo chiamante né la correttezza dell’identificatore specificato. Ciò consente a un aggressore di terminare quasi tutti i processi del sistema, incluso il processo critico launchd, responsabile dell’avvio e della gestione di tutti i servizi utente e di sistema. Di conseguenza, il sistema si trova in uno stato inoperativo e richiede un riavvio. Allo stesso tempo, per sfruttare questa vulnerabilità, è sufficiente avere accesso al dispositivo e la possibilità di aprire il dispositivo /dev/nsmb, operazione possibile nella maggior parte degli scenari anche senza uscire dall’isolamento utente (sandbox).

Apple ha già risolto tutte e tre le vulnerabilità. In particolare, è stato aggiunto un controllo della lunghezza del blocco di dati compressi alla funzione di elaborazione dei pacchetti SMB per prevenire la possibilità di un overflow di memoria. Inoltre, la libreria Kerberos Helper ora pulisce preventivamente la struttura NegotiationToken prima di utilizzarla e liberarla, impedendo così lo sfruttamento del difetto. Per il meccanismo di registrazione mc_notifier, è stato implementato un controllo dei permessi dell’utente che richiama l’ioctl SMBIOC_UPDATE_NOTIFIER_PID, che elimina la possibilità di terminazione incontrollata di processi arbitrari.

L'articolo Vulnerabilità critiche in SMBClient per macOS. 9.8 su 10 per una efficace RCE proviene da il blog della sicurezza informatica.

😁😁😁

#Musk #Tesla #teslashares

Aside from GPUs, you don’t hear much about co-processors these days. [bitluni] perhaps missed those days, because he found a way to squeeze a 160 core RISC V supercluster onto a single m.2 board,and shared it all on GitHub.

OK, sure, each core isn’t impressive– he’s using CH32V003, so each core is only running at 48 MHz, but with 160 of them, surely it can do something? This is a supercomputer by mid-80s standards, after all. Well, like anyone else with massive parallelism, [bitluni] decided to try a raymarcher. It’s not going to replace RTX anytime soon, but it makes for a good demo.

Like his previous m.2 project, an LED matrix, the cluster is communicating over PCIe via a WCH CH382 serial interface. Unlike that project, blinkenlights weren’t possible: the tiny, hair-thin traces couldn’t carry enough power to run the cores and indicator LEDs at once. With the power issue sorted, the serial interface is the big bottleneck. It turns out this cluster can crunch numbers much faster than it can communicate. That might be a software issue, however, as the cluster isn’t using all of the CH382’s bandwidth at the moment. While that gets sorted there are low-bandwidth, compute-heavy tasks he can set for the cluster. [bitluni] won’t have trouble thinking of them; he has a certain amount of experience with RISCV microcontroller clusters.

We were tipped off to this video by [Steven Walters], who is truly a prince among men. If you are equally valorous, please consider dropping informational alms into ourever-present tip line.

youtube.com/embed/HRfbQJ6FdF0?…

hackaday.com/2025/07/07/160-co…

Introduction

Since early March 2025, our systems have recorded an increase in detections of similar files with names like договор-2025-5.vbe, приложение.vbe, and dogovor.vbe (translation: contract, attachment) among employees at various Russian organizations. The targeted attack begins with bait emails containing malicious links, sent under the pretext of signing a contract. The campaign began in July 2024 and is still ongoing at the time of publication. The main goal of the attack is to infect organizations with the previously unknown Batavia spyware, which then proceeds to steal internal documents. The malware consists of the following malicious components: a VBA script and two executable files, which we will describe in this article. Kaspersky solutions detect these components as HEUR:Trojan.VBS.Batavia.gen and HEUR:Trojan-Spy.Win32.Batavia.gen.

First stage of infection: VBS script

As an example, we examined one of the emails users received in February. According to our research, the theme of these emails has remained largely unchanged since the start of the campaign.

Example of an email with a malicious link

In this email, the employee is asked to download a contract file supposedly attached to the message. In reality, the attached file is actually a malicious link: https://oblast-ru[.]com/oblast_download/?file=hc1-[redacted].

Notably, the sender’s address belongs to the same domain – oblast-ru[.]com, which is owned by the attackers. We also observed that the file=hc1-[redacted] argument is unique for each email and is used in subsequent stages of the infection, which we’ll discuss in more detail below.

When the link is clicked, an archive is downloaded to the user’s device, containing just one file: the script Договор-2025-2.vbe, encrypted using Microsoft’s proprietary algorithm (MD5: 2963FB4980127ADB7E045A0F743EAD05).

Snippet of the malicious script after decryption

The script is a downloader that retrieves a specially crafted string of 12 comma-separated parameters from the hardcoded URL [strong]https://oblast-ru[.]com/oblast_download/?file=hc1-[redacted][/strong]&vput2. These parameters are arguments for various malicious functions. For example, the script identifies the OS version of the infected device and sends it to the attackers’ C2 server.

By accessing the address [strong]https://oblast-ru[.]com/oblast_download/?file=hc1-[redacted][/strong]&dd=d, the script downloads the file WebView.exe (MD5: 5CFA142D1B912F31C9F761DDEFB3C288) and saves it to the %TEMP% directory, then executes it. If the OS version cannot be retrieved or does not match the one obtained from the C2 server, the downloader uses the Navigate() method; otherwise, it uses Run().

Second stage of infection: WebView.exe

WebView.exe is an executable file written in Delphi, with a size of 3,235,328 bytes. When launched, the malware downloads content from the link [strong]https://oblast-ru[.]com/oblast_download/?file=[/strong]1[strong]hc1-[redacted]&view[/strong] and saves it to the directory C:\Users[username]\AppData\Local\Temp\WebView, after which it displays the downloaded content in its window. At the time of analysis, the link was no longer active, but we assume it originally hosted the fake contract mentioned in the malicious email.

At the same time as displaying the window, the malware begins collecting information from the infected computer and sends it to an address with a different domain, but the same infection ID: [strong]https://ru-exchange[.]com/mexchange/?file=[/strong]1[strong]hc1-[redacted][/strong]. The only difference from the ID used in the VBS script is the addition of the digit 1 at the beginning of the argument, which may indicate the next stage of infection.

The spyware collects several types of files, including various system logs and office documents found on the computer and removable media. Additionally, the malicious module periodically takes screenshots, which are also sent to the C2 server. To avoid sending the same files repeatedly, the malware creates a file named h12 in the %TEMP% directory and writes a 4-byte FNV-1a_32 hash of the first 40,000 bytes of each uploaded file. If the hash of any subsequent file matches a value in h12, that file is not sent again.

In addition, WebView.exe downloads the next-stage executable from [strong]https://oblast-ru[.]com/oblast_download/?file=[/strong]1[strong]hc1-[redacted][/strong]&de and saves it to %PROGRAMDATA%\jre_22.3\javav.exe. To execute this file, the malware creates a shortcut in the system startup folder: %APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\Jre22.3.lnk. This shortcut is triggered upon the first device reboot after infection, initiating the next stage of malicious activity.

Third stage of infection: javav.exe

The executable file javav.exe (MD5: 03B728A6F6AAB25A65F189857580E0BD) is written in C++, unlike WebView.exe. The malicious capabilities of the two files are largely similar; however, javav.exe includes several new functions.

For example, javav.exe collects files using the same masks as WebView.exe, but the list of targeted file extensions is expanded to include these formats:

• Image and vector graphic: *.jpeg, *.jpg, *.cdr
• Spreadsheets: *.csv
• Emails: *.eml
• Presentations: *.ppt, *.pptx, *.odp
• Archives: *.rar, *.zip
• Other text documents: *.rtf, *.txt

Like its predecessor, the third-stage module compares the hash sums of the obtained files to the contents of the h12 file. The newly collected data is sent to [strong]https://ru-exchange[.]com/mexchange/?file=[/strong]2[strong]hc1-[redacted][/strong].
Note that at this stage, the digit 2 has been added to the infection ID.

Additionally, two new commands appear in the malware’s code: set to change the C2 server and exa/exb to download and execute additional files.

In a separate thread, the malware regularly sends requests to [strong]https://ru-exchange[.]com/mexchange/?[/strong]set[strong]&file=[/strong]2[strong]hc1-[redacted]&data=[xxxx][/strong], where [xxxx] is a randomly generated 4-character string. In response, javav.exe receives a new C2 address, encrypted with a 232-byte XOR key, which is saved to a file named settrn.txt.

In another thread, the malware periodically connects to [strong]https://ru-exchange[.]com/mexchange/?[/strong]exa[strong]&file=[/strong]2[strong]hc1-[redacted]&data=[xxxx][/strong] (where [xxxx] is also a string of four random characters). The server responds with a binary executable file, encrypted using a one-byte XOR key 7A and encoded using Base64. After decoding and decryption, the file is saved as %TEMP%\windowsmsg.exe. In addition to this, javav.exe sends requests to [strong]https://ru-exchange[.]com/mexchange/?[/strong]exb[strong]&file=[/strong]2[strong]hc1-[redacted]&data=[xxxx][/strong], asking for a command-line argument to pass to windowsmsg.exe.

To launch windowsmsg.exe, the malware uses a UAC bypass technique (T1548.002) involving the built-in Windows utility computerdefaults.exe, along with modification of two registry keys using the reg.exe utility.
add HKCU\Software\Classes\ms-settings\Shell\Open\command /v DelegateExecute /t REG_SZ /d "" /f

add HKCU\Software\Classes\ms-settings\Shell\Open\command /f /ve /t REG_SZ /d "%temp%\windowsmsg.exe <arg>"
At the time of analysis, downloading windowsmsg.exe from the C2 server was no longer possible. However, we assume that this file serves as the payload for the next stage – most likely containing additional malicious functionality.

Victims

The victims of the Batavia spyware campaign were Russian industrial enterprises. According to our telemetry data, more than 100 users across several dozen organizations received the bait emails.

Number of infections via VBS scripts, August 2024 – June 2025 (download)

Conclusion

Batavia is a new spyware that emerged in July 2024, targeting organizations in Russia. It spreads through malicious emails: by clicking a link disguised as an official document, unsuspecting users download a script that initiates a three-stage infection process on their device. As a result of the attack, Batavia exfiltrates the victim’s documents, as well as information such as a list of installed programs, drivers, and operating system components.

To avoid falling victim to such attacks, organizations must take a comprehensive approach to infrastructure protection, employing a suite of security tools that include threat hunting, incident detection, and response capabilities. Kaspersky Next XDR Expert is a solution for organizations of all sizes that enables flexible, effective workplace security. It’s also worth noting that the initial infection vector in this campaign is bait emails. This highlights the importance of regular employee training and raising awareness of corporate cybersecurity practices. We recommend specialized courses available on the Kaspersky Automated Security Awareness Platform, which help reduce employees’ susceptibility to email-based cyberattacks.

Indicators of compromise

Hashes of malicious files
Договор-2025-2.vbe
2963FB4980127ADB7E045A0F743EAD05
webview.exe
5CFA142D1B912F31C9F761DDEFB3C288
javav.exe
03B728A6F6AAB25A65F189857580E0BD

C2 addresses
oblast-ru[.]com
ru-exchange[.]com

securelist.com/batavia-spyware…

X-ray crystallography, like mass spectroscopy and nuclear spectroscopy, is an extremely useful material characterization technique that is unfortunately hard for amateurs to perform. The physical operation isn’t too complicated, however, and as [Farben-X] shows, it’s entirely possible to build an X-ray diffractometer if you’re willing to deal with high voltages, ancient X-ray tubes, and soft X-rays.

[Farben-X] based his diffractometer around an old Soviet BSV-29 structural analysis X-ray tube, which emits X-rays through four beryllium windows. Two ZVS drivers power the tube: one to drive the electron gun’s filament, and one to feed a flyback transformer and Cockroft-Walton voltage multiplier which generate a potential across the tube. The most important part of the imaging system is the X-ray collimator, which [Farben-X] made out of a lead disk with a copper tube mounted in it. A 3D printer nozzle screws into each end of the tube, creating a very narrow path for X-rays, and thus a thin, mostly collimated beam.

To get good diffraction patterns from a crystal, it needed to be a single crystal, and to actually let the X-ray beam pass through, it needed to be a thin crystal. For this, [Farben-X] selected a sodium chloride crystal, a menthol crystal, and a thin sheet of mica. To grow large salt crystals, he used solvent vapor diffusion, which slowly dissolves a suitable solvent vapor in a salt solution, which decreases the salt’s solubility, leading to very slow, fine crystal growth. Afterwards, he redissolved portions of the resulting crystal to make it thinner.
The diffraction pattern generated by a sodium chloride crystal.
For the actual experiment, [Farben-X] passed the X-ray beam through the crystals, then recorded the diffraction patterns formed on a slide of X-ray sensitive film. This created a pattern of dots around the central beam, indicating diffracted beams. The mathematics for reverse-engineering the crystal structure from this is rather complicated, and [Farben-X] hadn’t gotten to it yet, but it should be possible.

We would recommend a great deal of caution to anyone considering replicating this – a few clips of X-rays inducing flashes in the camera sensor made us particularly concerned – but we do have to admire any hack that coaxed such impressive results out of such a rudimentary setup. If you’re interested in further reading, we’ve covered the basics of X-ray crystallography before. We’ve also seen a few X-ray machines.

youtube.com/embed/EKCt-dHuzS4?…

hackaday.com/2025/07/07/buildi…

E’ stato sviluppato un proof-of-concept (PoC) di un exploit per una falla critica che consente l’escalation dei privilegi locali, interessando varie distribuzioni Linux principali, come Fedora e SUSE. La vulnerabilità, monitorata con il codice CVE-2025-6019, consente agli utenti non privilegiati di ottenere l’accesso root sfruttando il demone udisksd e la sua libreria backend libblockdev, creando significativi rischi per la sicurezza dei sistemi multiutente e degli ambienti condivisi.

La vulnerabilità sfrutta una vulnerabilità fondamentale nel modo in cui il demone udisksd elabora le richieste di comunicazione D-Bus dagli utenti del gruppo allow_active. Quando i sistemi correttamente configurati ricevono operazioni relative al disco tramite chiamate D-Bus, il demone presuppone erroneamente che la sola appartenenza al gruppo fornisca un’autorizzazione sufficiente per operazioni sensibili.

Ricordiamo che il demone udisksd è un componente di sistema su Linux responsabile della gestione dei dispositivi di archiviazione (dischi rigidi, SSD, chiavette USB, CD/DVD, ecc.). Questo PoC consente agli aggressori di aggirare i controlli di sicurezza previsti ed eseguire operazioni privilegiate con permessi di root.

Il vettore di attacco si concentra sulla gestione impropria dell’autorità dell’utente durante le comunicazioni interprocesso tramite D-Bus. I ricercatori di sicurezza hanno scoperto che il demone udisksd non riesce a convalidare adeguatamente il contesto dell’utente che effettua l’invocazione, affidandosi invece esclusivamente a controlli dei privilegi basati sul gruppo.

Secondo l’analisi di SecureLayer7, questo difetto di progettazione crea un percorso sfruttabile in cui le chiamate D-Bus possono essere manipolate per innescare operazioni privilegiate non autorizzate. L’analisi statica del codice sorgente di udisks2 e libblockdev ha rivelato diversi pattern preoccupanti nel percorso di escalation dei privilegi. Il flusso di esecuzione vulnerabile segue il seguente schema: udisks_daemon_handle_mount → polkit_check → blkdev_mount.
Immagine dell’esecuzione dell’exploit dal blog di securelayer7.net
Questa sequenza consente agli utenti non privilegiati di far sì che udisksd esegua operazioni di montaggio con permessi di root, aggirando di fatto il modello di sicurezza previsto. Il processo di exploit richiede una sofisticazione tecnica minima, il che lo rende particolarmente pericoloso. Gli aggressori necessitano solo dell’appartenenza al gruppo allow_active e della capacità di eseguire comandi udisksctl.

La prova di concetto dimostra che un semplice comando come udisksctl mount -b /dev/loop0 può causare operazioni di montaggio controllate da root da parte di utenti non root, portando potenzialmente alla compromissione dell’intero sistema. La vulnerabilità interessa un’ampia gamma di distribuzioni Linux che implementano udisks2 e libblockdev nei loro ambienti desktop. I sistemi Fedora e SUSE sono particolarmente vulnerabili a causa delle loro configurazioni predefinite, che spesso includono utenti nel gruppo allow_active per le funzionalità desktop.

Il problema della sicurezza è particolarmente preoccupante per gli ambienti di elaborazione condivisi, i sistemi multiutente e qualsiasi distribuzione in cui la separazione dei privilegi è fondamentale. I responsabili della distribuzione hanno risposto con aggiornamenti di sicurezza che risolvono la vulnerabilità principale attraverso diversi meccanismi. La correzione principale prevede una verifica basata sull’UID più rigorosa, anziché basarsi esclusivamente sull’appartenenza al gruppo. Il codice aggiornato ora richiede sia l’appartenenza al gruppo che un contesto UID appropriato prima di consentire operazioni privilegiate.

Gli amministratori di sistema dovrebbero aggiornare immediatamente i pacchetti udisks2 e libblockdev alle versioni corrette. Le organizzazioni dovrebbero inoltre verificare le autorizzazioni basate sui gruppi e implementare regole polkit più rigorose per prevenire vulnerabilità simili.

L'articolo Un nuovo Exploit Poc consente Privilege Excalation su Linux utilizzando il demone udisksd proviene da il blog della sicurezza informatica.

CHIUSURA STAGIONE 9 - I LLM sono il sogno di manager e stakeholder: il lavoro (o almeno la sua parte vendibile) senza i lavoratori. Il solo vero caso d'uso è la svalutazione del lavoro e delle competenze. Da qui tutti i discorsi sulla prossima inutilità di psicologi, medici, programmatori. Gli utili idioti che abboccano sono solo quelli che credono di avere il simulacro, lo spettacolo della competenza, senza la competenza, sia un gioco vincente.

spreaker.com/episode/dk-9x36-i…

A San Francisco, chiunque abbia mai partecipato a un hackathon lo conosce. René Turcios non è un programmatore, non è un ingegnere e non si è laureato in un’università prestigiosa. Non scrive nemmeno codice. Ma dal 2023, questo ragazzo ha vinto più di duecento hackathon, portando a casa premi, rispetto e bonus piuttosto consistenti. Il suo segreto è semplice: la “programmazione a vibrazioni”.

Il termine “vibe coding” è stato coniato dal ricercatore di intelligenza artificiale Andrej Karpathy per descrivere il processo in cui un essere umano spiega un compito a parole e un’intelligenza artificiale lo trasforma in codice funzionante. Inizialmente disprezzato, questo approccio è ora utilizzato sia da startup che da grandi aziende IT, e strumenti come Cursor e Claude stanno diventando la norma.

Turcios iniziò a usare questo metodo molto prima di avere un nome. Al suo primo hackathon, inseriva semplicemente un’idea in ChatGPT: creare un convertitore di qualsiasi canzone in una versione lo-fi. E – senza scrivere nulla a mano – si aggiudicò il secondo posto. Quando i risultati furono annunciati, urlò di gioia. Nessuno lo conosceva allora, ma fu allora che capì di poter competere con laureati di Stanford e ingegneri di grandi aziende.

René ha 29 anni. È originario del Missouri ed è cresciuto in una famiglia di artisti circensi che domavano leoni e orsi. Invece di andare all’università, è diventato un giocatore professionista di Yu-Gi-Oh! e ha viaggiato per diversi anni negli Stati Uniti, partecipando a tornei e dormendo a casa di amici. A un certo punto, si è stancato e si è trasferito a San Francisco con la sua ragazza. Ha provato diversi lavori part-time e in seguito ha lanciato una startup per creare infrastrutture per il metaverso. Ma il progetto è stato presto chiuso: gli ingegneri si sono rifiutati di lavorare con l’intelligenza artificiale.

Uno di loro ha persino affermato che si sarebbe licenziato se gli avessero chiesto di nuovo di usare una rete neurale. In risposta, Turcios ha chiuso l’azienda e si è messo a studiare per conto proprio. Ha iniziato a presentarsi a quasi tutti gli hackathon della città, dall’AGI House alla Frontier Tower. Non scriveva codice, sapeva solo come formulare correttamente una richiesta e sfruttare al meglio l’intelligenza artificiale. E sapeva come vincere.
Una immagine di René Turcios dal suo profilo di Instagram
Organizzatori e partecipanti agli hackathon si sono già abituati alla sua voce potente, all’immagine cyberpunk da strada e alla sua frase distintiva “Non ho scritto una sola riga di codice”. Le vittorie sono arrivate una dopo l’altra. Le startup hanno iniziato a commissionargli lo sviluppo di MVP e prototipi, che richiedevano settimane di lavoro a team di programmatori. Lui li ha realizzati in poche ore. Ora conduce personalmente workshop, insegnando sia a principianti che a sviluppatori esperti come lavorare con l’intelligenza artificiale.

Ora Turcios ha rallentato un po’. Si concentra sul suo progetto personale: creare agenti di intelligenza artificiale. Nessun team, nessun investitore, nessun sviluppatore. Fa tutto da solo, o meglio, insieme a una rete neurale. Durante una delle riunioni, ha aperto il suo portatile e ha chiesto: cosa dovremmo costruire? La conversazione verteva sui suoi personaggi preferiti di Labubus, che conserva in scatole a casa. In 15 minuti, un sito web per la rivendita di bambole era pronto.

A René non importano lauree, linguaggi di programmazione o ruoli aziendali. Ha semplicemente capito come funziona il nuovo mondo e ha imparato a giocare secondo le sue regole. O meglio, le ha riscritte.

L'articolo Non so programmare, ma ha vinto 200 hackathon! René Turcios, la leggenda del “vibe coder” proviene da il blog della sicurezza informatica.