To update an old saying for the modern day, one man’s e-waste is another man’s bill of materials. Upcycling has always been in the hacker’s toolkit, and cellphones provide a wealth of resources for those bold enough to seize them. [Huy Vector] was bold enough, and transformed an old smartphone into a portable pico projector and an ASMR-style video. That’s what we call efficiency!

Kidding aside, the speech-free video embedded below absolutely gives enough info to copy along with [Huy Vector] even though he doesn’t say a word the whole time. You’ll need deft hands and a phone you really don’t care about, because one of the early steps is pulling the LCD apart to remove the back layers to shine an LED through. You’ll absolutely need an old phone for that, since that trick doesn’t apply to the OLED displays that most flagships have been rocking the past few years.

It looks like he’s specifying a 20 W LED (the bill of materials is in the description of the video on YouTube), so this projector won’t be super bright, but it will certainly be usable in darkened rooms. At least that lower wattage also means the batteries salvaged from an old power bank should give enough runtime to finish a movie… as long as it’s not the director’s cut, anyway. A heatsink and fan keep the LED from cooking itself and what’s left of the cell phone inside the foam board case.

The projected image looks surprisingly good considering the only optics in this thing are the LCD and the lens from a 5x magnifying glass from AliExpress. The foam board case, too, ends up looking surprisingly good once the textured vinyl wrap is applied. That’s a quick and easy way to get a nice looking prototype, if you don’t particularly need durability.

It’s not the brightest screen you can build, nor the highest resolution projector we’ve seen– but it might just be the easiest such build we’ve featured. As long as you handle the tricky LCD disassembly step, this is absolutely something we could see doing with children, which isn’t always the case on Hackaday.

youtube.com/embed/hx1keLrcFGw?…

hackaday.com/2025/09/11/old-ph…

We’ll admit it. We have access to great debugging tools and, yes, sometimes they are invaluable. But most of the time, we’ll just throw a few print statements in whatever program we’re running to better understand what’s going on inside of it. [Loop Invariant] wants to point out to us that there are things a proper debugger can do that you can’t do with print statements.

So what are these magical things? Well, some of them depend on the debugger, of course. But, in general, debuggers will catch exceptions when they occur. That can be a big help, especially if you have a lot of them and don’t want to write print statements on every one. Semi-related is the fact that when a debugger stops for an exception or even a breakpoint, you can walk the call stack to see the flow of code before you got there.

In fact, some debuggers can back step, although not all of them do that. Another advantage is that you can evaluate expressions on the fly. Even better, you should be able to alter program flow, jumping over some code, for example.

So we get it. There is more to debugging than just crude print statements. Then again, there are plenty of Python libraries to make debug printing nicer (including IceCream). Or write your own debugger. If gdb’s user interface puts you off, there are alternatives.

hackaday.com/2025/09/11/debugg…

Milioni di persone e aziende si affidano a Google Drive per archiviare contratti, report, foto e documenti di lavoro, utilizzando il client desktop di Windows per sincronizzare i file tra cartelle locali e cloud. Ma è stata proprio questa applicazione a rivelarsi vulnerabile: è stato scoperto un grave bug che consente a chiunque, su un computer condiviso, di ottenere l’accesso completo ai contenuti dell’account Google Drive di qualcun altro senza dover richiedere una nuova autorizzazione.

I ricercatori hanno scoperto che il programma salva copie dei dati sincronizzati in una cartella DriveFS nascosta all’interno del profilo di Windows. Questa directory dovrebbe essere accessibile solo al proprietario, ma l’applicazione non verifica i diritti di accesso quando si connette alla cache. È sufficiente copiare il contenuto della cartella DriveFS di un altro utente sul proprio profilo, dopodiché il client caricherà i dati di qualcun altro come se fossero propri. All’avvio, Google Drive Desktop percepisce la cache trasferita come legittima, aggirando i controlli di autenticazione e consentendo l’accesso ai file personali e aziendali.

Un test pratico ha dimostrato che su Windows 10 e 11 con versione client 112.0.3.0 la procedura è elementare: l’aggressore accede a Google Drive con il proprio account, chiude l’applicazione, copia la directory DriveFS della vittima (C:/Users/[vittima]/AppData/Local/Google/DriveFS/[ID]) nella propria directory (C:/Users/[attaccante]/AppData/Local/Google/DriveFS/[ID]) e riavvia il programma. Di conseguenza, ottiene pieno accesso all’unità principale della vittima, nonché a tutte le unità condivise, senza password o notifiche.

Codici sorgente, bilanci finanziari, foto personali e qualsiasi altro documento sono in formato aperto.

Questo meccanismo viola i principi fondamentali di Zero Trust, che richiedono la verifica obbligatoria dell’identità a ogni accesso, e compromette anche la protezione associata alla crittografia dei dati. I file nella cache vengono archiviati in chiaro e possono essere utilizzati da chiunque abbia accesso al sistema. Ciò è in contrasto con gli standard e le normative NIST, ISO 27001, GDPR e HIPAA, che prevedono un rigoroso isolamento e una verifica periodica delle credenziali.

Fino al rilascio di una correzione, si consiglia alle organizzazioni di interrompere l’utilizzo di Google Drive Desktop su computer con più utenti. Le misure temporanee includono la cancellazione della cache quando si cambia account, l’utilizzo di profili Windows separati con diritti di accesso rigorosi e la limitazione dell’esecuzione del client solo su dispositivi attendibili. Per risolvere definitivamente il problema, Google dovrebbe implementare la crittografia individuale dei dati memorizzati nella cache, un nuovo accesso obbligatorio quando si monta una cartella e autorizzazioni rigorose a livello di file system.

Dato che una percentuale significativa di perdite è causata da personale interno, affidarsi a una cache non protetta diventa una minaccia diretta. Finché l’azienda non colma questa lacuna, utenti e reparti IT corrono il rischio di accesso non autorizzato ai dati più critici .

L'articolo Un bug in Google Drive consente l’accesso ai file di altre persone su desktop condivisi proviene da il blog della sicurezza informatica.

Nella giornata di ieri, su un noto forum underground frequentato da cyber criminali, è apparso un post che riguarda direttamente il Comune di Canegrate (Milano, Italia).

L’annuncio è stato pubblicato da un utente con nickname “krek1i”, attivo dal mese di aprile 2025 e con una reputazione di 81 punti, indice di una certa affidabilità all’interno della community underground. Lo stesso utente vanta decine di post e thread aperti, fattori che lo rendono un profilo consolidato nell’ambiente.

Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.

Nel messaggio, il criminale informatico sostiene di essere in possesso di un database e degli accessi ai sistemi del Comune di Canegrate, offrendo il tutto in vendita per la cifra di 500 dollari.

A corredo dell’annuncio sono stati pubblicati alcuni sample per dimostrare l’autenticità del materiale. Dall’analisi di tali sample emergono i seguenti elementi potenzialmente sensibili:

• dati personali di cittadini e utenti;
• account e password associati ai sistemi compromessi;
• schemi di database con numerose tabelle, a conferma di un’ampia quantità di informazioni potenzialmente esfiltrate.

Al momento, sul sito ufficiale del Comune di Canegrate non sono presenti comunicazioni in merito alla presunta violazione. Non si hanno quindi conferme ufficiali su quanto dichiarato dal criminale informatico.

Se confermata, la compromissione rappresenterebbe un grave incidente di sicurezza informatica ai danni di un ente pubblico locale, con possibili ripercussioni sulla protezione dei dati personali dei cittadini.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione dell’organizzazione qualora voglia darci degli aggiornamenti su questa vicenda e saremo lieti di pubblicarla con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono accedere utilizzare la mail crittografata del whistleblower.

L'articolo Comune di Canegrate: presunta violazione e vendita di database e accessi proviene da il blog della sicurezza informatica.

Attaullah Baig, che avrebbe guidato il team di sicurezza di WhatsApp dal 2021 al 2025, ha intentato una causa contro la società madre Meta. Baig sostiene di essere stato licenziato per aver ripetutamente tentato di risolvere i gravi problemi di sicurezza informatica dell’app di messaggistica.

Baig ha intentato una causa ai sensi del Sarbanes-Oxley Act per aver presumibilmente occultato problemi di sicurezza che avrebbero potuto portare a potenziali frodi da parte degli azionisti, nonché potenziali violazioni delle norme della Securities and Exchange Commission (SEC) degli Stati Uniti in materia di controlli interni delle informazioni.

Nella causa, l’ex dipendente di WhatsApp (che in precedenza aveva ricoperto posizioni legate alla sicurezza informatica presso PayPal e Capital One) sostiene che la dirigenza di WhatsApp lo ha ingiustamente licenziato, travisando la sua valutazione delle prestazioni e usandola come pretesto per rescindere il suo contratto.

I documenti affermano che poco dopo essersi unito a WhatsApp nel 2021, Baig “ha scoperto problemi sistemici di sicurezza informatica che creavano gravi rischi per i dati degli utenti e violavano gli obblighi legali di Meta ai sensi della Risoluzione sulla privacy del 2020 e delle leggi federali sui titoli”.

Baig sostiene che circa 1.500 ingegneri di WhatsApp avevano accesso illimitato ai dati personali sensibili degli utenti e sono stati in grado di copiarli e rubarli senza essere scoperti o sottoposti a controlli.

L’8 settembre 2022, Baig avrebbe sollevato le seguenti violazioni durante una riunione di lavoro:

• impossibilità di inventariare i dati degli utenti;
• incapacità di localizzare ed elencare i repository di dati;
• accesso illimitato ai dati degli utenti, a disposizione di 1.500 ingegneri informatici;
• mancanza di controllo sull’accesso ai dati degli utenti;
• incapacità di rilevare perdite di dati;
• incapacità di proteggere gli account utente da eventuali furti (si stima che si verifichino circa 100.000 casi di questo tipo al giorno).

Nell’ottobre 2022, Baig avrebbe informato dieci dirigenti senior di WhatsApp, tra cui l’amministratore delegato Will Cathcart e l’ingegnere capo Nitin Gupta, dei problemi, avvertendo che l’azienda avrebbe potuto affrontare conseguenze legali.

Baig afferma di aver tentato di sollevare le sue preoccupazioni nel 2023, ma di aver incontrato la resistenza dei dirigenti. Poi, all’inizio del 2024, avrebbe inviato una lettera al CEO di Meta Mark Zuckerberg e al consulente legale Jennifer Newstead, informandoli delle potenziali violazioni, delle resistenze che stavano affrontando e delle “prove che il team di sicurezza stava falsificando i report per nascondere le proprie decisioni e non affrontare i rischi di furto di dati”.

Nel febbraio 2025, Baig venne licenziato dall’azienda, presumibilmente diversi mesi dopo aver personalmente segnalato alla Securities and Exchange Commission degli Stati Uniti presunte violazioni della sicurezza informatica presso Meta.

Ora Baig chiede un processo con giuria e vuole che Meta lo reintegrasse, oltre a rimborsargli gli stipendi arretrati, le spese legali, i danni emotivi e le sofferenze. Tuttavia, Meta ha dichiarato ai media che Baig non ricopriva affatto il ruolo di “responsabile della sicurezza” di WhatsApp, ma piuttosto quello di responsabile dello sviluppo software, con diversi dirigenti senior al di sopra di lui. Secondo l’azienda, diversi ingegneri senior hanno stabilito in modo indipendente che le sue prestazioni non soddisfacevano le aspettative dell’azienda, il che ha portato al suo licenziamento.

“Purtroppo, è uno scenario familiare quello in cui un dipendente viene licenziato per scarse prestazioni e poi rilascia dichiarazioni distorte che sminuiscono l’essenza del duro lavoro del nostro team”, ha affermato Andy Stone, direttore delle comunicazioni di Meta.

Inoltre, secondo i documenti forniti dall’azienda a SecurityWeek, il Dipartimento del Lavoro degli Stati Uniti aveva precedentemente respinto il reclamo di Baig. L’OSHA ha concluso che Meta non aveva attuato ritorsioni nei confronti di un dipendente che aveva cercato di sollevare problemi di sicurezza. I documenti mostrano inoltre che il Dipartimento del Lavoro ha stabilito che le azioni di Baig non erano giustificate ai sensi del Sarbanes-Oxley Act.

L'articolo Ex dipendente di WhatsApp: “1500 ingegneri hanno accesso ai dati riservati degli utenti” proviene da il blog della sicurezza informatica.

Every Thursday of the week, Bastian’s Night is broadcast from 21:30 CEST (new time).

Bastian’s Night is a live talk show in German with lots of music, a weekly round-up of news from around the world, and a glimpse into the host’s crazy week in the pirate movement.

If you want to read more about @BastianBB: –> This way

piratesonair.net/bastians-nigh…

Does the in 65F02 “F” stand for “fast” or “FPGA”? [Jurgen] doesn’t know, but his drop-in replacement board for the 6502 and 65c02 is out there and open source, whatever you want it to stand for.

The “f” could easily be both, since at 100 MHz, the 65f02 is blazing fast by 6502 standards–literally 100 times the speed of the first chips from MOS. That speed comes from the use of a Spartan 6 FPGA core to implement the 6502 logic; making the “f” stand for “FPGA” makes sense, given that the CMOS version of the chip was dubbed the 65c02. The 65f02 is a tiny PCB containing the FPGA and all associated hardware that shares the footprint of a DIP-40 package, making it a drop-in replacement. A really fast drop-in replacement.

You might be thinking that that’s insane, and that (for example) the memory on an Apple ][ could never run at 100 MHz and so you won’t get the gains. This is both true, and accounted for: the 65F02 has an internal RAM “cache” that it mirrors to external memory at a rate the bus can handle. When memory addresses known to interact with peripherals change, the 65f02 slows down to match for “real time” operations.
The USB adapter board for programming is a great touch.
Because of this the memory map of the external machine matters; [Jurgen] has tested the Commodore PET and Apple ][, along with a plethora of German chess computers, but, alas, this chip is not currently compatible with the Commodore 64, Atari 400/800 or BBC Micro (or at least not tested). The project is open source, however, so you might be able to help [Jurgen] change that.

We admit this project isn’t totally new– indeed, it looks like [Jurgen]’s last update was in 2024– but a fast 6502 is just as obsolete today as it was when [Jurgen] started work in 2020. That’s why when [Stephen Walters] sent us the tip (via electronics-lab), we just had to cover it, especially considering the 6502’s golden jubilee.

We also recently featured a 32-bit version of the venerable chip that may be of interest, also on FPGA.

hackaday.com/2025/09/10/65f02-…

E’ stato analizzato che gli inviti del Calendario iCloud sono stati utilizzati per inviare email di phishing camuffate da notifiche di acquisto direttamente dai server di posta di Apple. Questa tattica aumenta le probabilità di bypassare i filtri antispam.

Bleeping Computer ha segnalato che all’inizio di questo mese un lettore ha condiviso un’e-mail dannosa che si spacciava per una ricevuta di 599 dollari, presumibilmente addebitata sul suo conto PayPal. L’e-mail includeva un numero di telefono nel caso in cui il destinatario volesse contrassegnare il pagamento o apportare modifiche.

Lo scopo di queste email è indurre gli utenti a credere che il loro account PayPal sia stato hackerato e che il denaro venga utilizzato da truffatori per effettuare acquisti. I truffatori cercano di spaventare il destinatario dell’email in modo che venga chiamato il falso numero di “assistenza”.

Durante la chiamata, i truffatori continuano a intimidire le vittime, convincendole che l’account è stato effettivamente violato. Gli aggressori si offrono quindi di connettersi da remoto al computer della vittima (presumibilmente per restituire i fondi) o chiedono di scaricare ed eseguire un software. Naturalmente, gli aggressori alla fine utilizzano l’accesso remoto ottenuto per rubare denaro dai conti bancari dell’utente, distribuire malware o rubare dati dal computer compromesso.

Tuttavia, la cosa strana in questo caso era che l’email fraudolenta proveniva da noreply@email.apple.com, superando tutti i controlli di sicurezza SPF, DMARC e DKIM. In altre parole, il messaggio proveniva effettivamente dal server di posta di Apple.

I giornalisti spiegano che l’email era in realtà un invito al Calendario iCloud. Gli aggressori hanno semplicemente aggiunto del testo di phishing al campo Note e poi hanno inviato l’invito a un indirizzo Microsoft 365 da loro controllato. Quando si crea un evento nel Calendario iCloud e si invitano persone esterne, un’email di invito viene inviata dai server Apple a (email.apple.com) per conto del proprietario del Calendario iCloud. Questa email proviene da noreply@email.apple.com.

I ricercatori ritengono che questa campagna sia simile a un’altra truffa scoperta nella primavera del 2025. Questo perché in entrambi i casi l’indirizzo Microsoft 365 a cui viene inviato l’invito è in realtà una mail che inoltra automaticamente tutte le email ricevute a tutti gli altri membri del gruppo.

Poiché l’e-mail dannosa proveniva originariamente dai server di posta di Apple, non avrebbe superato i controlli SPF se inoltrata a Microsoft 365. Per evitare che ciò accada, Microsoft 365 utilizza lo schema di riscrittura del mittente (SRS) per riscrivere il percorso di ritorno a un indirizzo correlato a Microsoft, consentendo al messaggio di superare i controlli.

Sebbene l’e-mail di phishing in sé non fosse nulla di speciale, l’abuso della legittima funzionalità di invito del Calendario iCloud e dei server di posta elettronica di Apple aiuta gli aggressori a eludere i filtri antispam perché le e-mail sembrano provenire da una fonte attendibile.

L'articolo Truffa phishing via Calendario iCloud: come funziona e come difendersi proviene da il blog della sicurezza informatica.