The arrival of cheap thermal printer mechanisms over the last few years has led to a burst of printer hacking in our community, and we’re sure many of you will like us have one knocking around somewhere. There are a variety of different models on the market, and since they often appear in discount stores we frequently see new ones requiring their own reverse engineering effort. [Mel] has done some work on just such a model, the Core Innovation CTP-500, which can be found at Walmart.

The write-up is a tale of Bluetooth reverse engineering as much as it is one about the device itself, as he sniffs the protocol it uses, and finds inspiration from the work of others on similar peripherals. The resulting Python app can be found in his GitHub repository, and includes a TK GUI for ease of use. We like this work and since there’s an analogous printer from a European store sitting on the Hackaday bench as we write this, it’s likely we’ll be giving it a very close look.

Meanwhile if [Mel] sounds a little familiar it might be because of their print-in-place PCB holder we featured recently.

hackaday.com/2025/11/11/anothe…

Siamo ossessionati da firewall e crittografia. Investiamo miliardi in fortezze digitali, ma le statistiche sono inesorabili: la maggior parte degli attacchi cyber non inizia con un difetto nel codice, ma con un difetto nel carattere umano.

La verità è questa: l’unica vulnerabilità che conta davvero è quella psicologica.

Faremo un viaggio radicale. Prenderemo il manuale di istruzioni più efficace che esista per la nostra difesa personale: il capolavoro animato della Pixar, Inside Out (2015).

Come psicologo, filosofo e coach, mostrerò come le dinamiche interiori del film non siano solo una metafora della mente, ma una dottrina di resilienza cibernetica che affonda le radici in Aristotele, Freud e nelle scienze cognitive.

La nostra mente è la nostra ultima e più complessa linea di difesa.

La Console Emotiva: il quartier generale

Nel film, le cinque emozioni (Gioia, Tristezza, Rabbia, Paura, Disgusto) sono gli operatori che lottano per il controllo della console, il nostro interfaccia decisionale.

In termini psicoanalitici, questo quartier generale corrisponde all’Io (Ego) di Sigmund Freud, l’istanza che media tra gli impulsi dell’Es e le richieste del Super-Io e della realtà esterna.

Il social engineering è il tentativo di hackerare questo Ego digitale, sfruttando le sue debolezze.

La console è il luogo della Phronesis (Prudenza) aristotelica, la virtù intellettuale che ci permette di deliberare bene su ciò che è buono e vantaggioso non solo in generale, ma in situazioni specifiche.

Quando le emozioni prendono il sopravvento, la Phronesis viene bypassata.

L’arma a doppio taglio delle emozioni (Paura, Rabbia, Gioia)

I cybercriminali non disattivano le nostre difese emotive; le manipolano per creare un cortocircuito cognitivo.

1. La Paura (IDS)

È il nostro Sistema di Rilevamento delle Intrusioni (IDS).

La sua funzione, riconosciuta anche da Aristotele come elemento essenziale della prudenza (eulabeia), è la prevenzione del danno. Tuttavia, quando i phishing attivano la paura della perdita (“Il tuo account verrà bloccato!”), essa paralizza il giudizio critico.

La Paura è un ottimo sensore, ma un pessimo decisore.

Strategia del Coach: eseguire il “Protocollo 3 Secondi”.

Mettiamo in pausa e respiriamo: inspiriamo lentamente, espiriamo lentamente. Questo attiva la corteccia prefrontale, l’area del cervello responsabile del ragionamento esecutivo, e disinnesca l’amigdala, il centro della paura. Riconoscere l’emozione ci aiuta a prendere le distanze.

2. Rabbia e Gioia (Impulso)

Queste emozioni sono i driver dell’impulsività.

La promessa esagerata di un guadagno facile (sfruttando la Gioia e la FOMO – Fear of Missing Out) o la comunicazione aggressiva che innesca la rabbia (il “breve delirio” condannato da Seneca) bypassano il filtro critico.

In termini di scienze cognitive, il cyberattacco mira a costringere la mente a operare in Sistema 1 (pensiero veloce, intuitivo, emotivo), eludendo il Sistema 2 (pensiero lento, logico, analitico).

Strategia del Coach: allenare il nostro “disgusto cognitivo”.

Ogni volta che proviamo un picco emotivo intenso (Gioia eccessiva, Rabbia improvvisa, Paura paralizzante) in risposta a un’interazione digitale, rifiutiamo di ingerire l’informazione o l’offerta sospetta e sospendiamo l’azione analizzando il contesto.

Nel momento in cui ci costringiamo a fare la verifica (Sistema 2) su un’informazione sospetta, stiamo rafforzando la nostra disciplina mentale contro la manipolazione.

L’Integrazione Emotiva: la potenza della Tristezza

La crisi di Riley inizia quando Gioia tenta di escludere la Tristezza.

Questo tentativo di negazione emotiva è, nel mondo digitale, il rifiuto della vulnerabilità.

• La Tristezza: non è un bug, ma una feature. Segnala la necessità di supporto dopo un errore. L’utente che, per negazione della Tristezza (paura del giudizio), non ammette l’errore digitale (“Ho cliccato sul link sbagliato”), mette a rischio l’intero sistema.
• Resilienza: l’accettazione della Tristezza è l’accettazione della vulnerabilità. La sicurezza, deriva dall’integrazione sinergica di tutte le emozioni: trasformare l’errore (Tristezza) in apprendimento (la complessa Memoria Centrale di Riley).

L’integrazione delle emozioni è la chiave per la maturità emotiva!

In conclusione

La nostra missione finale, come professionisti e individui, è superare la “tirannia della Gioia”: la convinzione ossessiva che si debba essere sempre impeccabili, sempre on-line e mai in errore.

La sicurezza non è perfezione; è resilienza!

L’autenticità emotiva, la capacità di sentire e integrare la Tristezza (l’errore) e la Paura (il rischio) è la nostra forma di self-ware più avanzata.

Solo imparando a fare debugging delle nostre reazioni emotive possiamo raggiungere l’eudaimonia digitale: uno stato di benessere in cui tutte le emozioni coesistono, producendo una vera armonia psicofisica.

La maturità cibernetica, proprio come per Riley, sta nell’integrare la Tristezza (l’ammissione dell’errore) per trasformare ogni fallimento in apprendimento e resilienza.

Il Cyber Coaching in 3 Passi

1. Mappiamo la nostra Console Emotiva: dopo un’interazione digitale stressante o sospetta (un’email di phishing, un messaggio aggressivo), chiediamoci: “Chi è al comando della console in questo momento?” (Gioia, Paura, Rabbia, Disgusto?). La consapevolezza è la prima linea di difesa contro la manipolazione.
2. Trasformiamoci in Supervisori: insegniamo al nostro Ego (l’Io) a non agire immediatamente quando una singola emozione urla. Il nostro ruolo non è eliminare Paura o Rabbia, ma dare loro un posto al tavolo decisionale, gestito dalla Phronesis (Prudenza).
3. Abbracciamo il Growth Mindset: quando si verifica un errore (abbiamo cliccato, siamo stati truffati, abbiamo dubbi), non neghiamo la Tristezza o la Vergogna. Riconosciamole e trasformiamo la memoria centrale da “errore inconfessabile” a “lezione appresa e condivisa”. Il nostro errore diventa un firewall per gli altri!

Coach’s Challenge

1. Chi è al comando della nostra Console Emotiva in questo momento?”
2. In che modo la Paura e il Disgusto possono essere re-ingegnerizzati dopo un data breach oppure dopo un phishing ?
3. In che modo il raggiungimento della “maturità emotiva” di Riley si traduce concretamente in un comportamento digitale più sicuro e resiliente?

L'articolo Inside Out: perché la Tristezza è il tuo miglior firewall proviene da Red Hot Cyber.

Vi sono momenti nella Storia in cui grandi anime che appartengono a mondi e universi apparentemente incomunicabili, per le circostanze della sorte o di quell’intenzione amorevole che noi cristiani chiamiamo «Provvidenza», entrano in contatto e dialogano tra loro. Appare così, come un rivolo nascosto tra i grandi eventi della Storia, un pensiero divergente, paradossale, al tempo stesso ingenuo e dirompente.

È ciò che è avvenuto tra il 1909 e il 1910, quando Lev Tolstoj e Gandhi – l’uno a Jasnaja Poljana, nella Russia europea, l’altro nel Transvaal sudafricano, colonia inglese – si scambiarono alcune lettere. Il futuro mahatma liberatore dell’India, all’epoca quarantenne, aveva letto il testo che l’autore di Guerra e Pace, Anna Karenina e Resurrezione aveva scritto per il giornale The Free Hindustan, su sollecitazione del suo direttore. Tale scritto, oggi conosciuto come Lettera a un indù, non venne pubblicato, forse perché il giornalista indiano, che pur l’aveva sollecitato, sperava in una risposta dai toni diversi, ma giunse tramite un amico nelle mani di Gandhi, che ne rimase molto colpito. In questa lettera Tolstoj teorizzò la lotta non violenta come via di liberazione non solo interiore, ma anche sociale e politica, e contribuì, a detta dello stesso Gandhi, a far maturare in lui la riflessione sul satyagraha, ossia sulla resistenza all’oppressione (coloniale inglese) tramite la disobbedienza civile.

Sono gli ultimi mesi di vita di Tolstoj, che morirà il 20 novembre 1910. Gandhi gli scrive per manifestargli la sua gratitudine. Contestualmente gli chiede se la versione inglese del testo, inizialmente composto in russo, corrisponde alle idee del suo autore, se vada integrato e se sia possibile pubblicarlo nel giornale fondato da Gandhi stesso, Indian opinion.

Tolstoj è divenuto un punto di riferimento intellettuale a livello internazionale. La sua opzione religiosa e per la pace è diventata irreversibile, e per le sue posizioni eterodosse è già stato scomunicato dalla Chiesa ortodossa. Egli sostiene che la legge dell’amore, affermata da Cristo, risponde alla natura profonda del cuore dell’uomo e si ritrova in ogni tradizione religiosa. Questa norma è stata tradita, schiacciata o elusa, manipolata o avvelenata sia dai «religiosi» sia dai pensatori del socialismo «scientifico», che la vogliono far valere nell’ambito della vita personale, ma la ritengono inadatta a quello delle relazioni politiche istituzionali e negli ambiti sociali.

La condanna da parte di Tolstoj è netta, e l’invito a non partecipare ad alcuna forma di violenza irriducibile. Il male si vince con il bene e con l’amore, mai con il male. Chi teorizza la sospensione della legge dell’amore, proponendo il ricorso alla violenza come inevitabile «in alcuni casi», lo fa per paura inconsapevole o consapevole ambizione di potere. D’altra parte, come spiegare che pochi possano dominare su moltitudini, se non per la complicità di queste ultime, che ritengono la violenza architrave dolorosa e necessaria del vivere comune?

Voce isolata, profetica o ingenua, Tolstoj chiede che l’India – come la Cina – non rinunci alla sua tradizione spirituale, di «pazienza» e mitezza, per abbracciare il modello economico e politico occidentale, considerato fallimentare e nel lungo periodo distruttivo. Nello slancio ideale dello scrittore, colpisce verificare l’acume di alcune sue considerazioni, che possiamo trovare applicabili in filigrana ai nodi ancora irrisolti delle tensioni dei nostri giorni, in termini militari e di sviluppo economico.

Lettera a un indù, Lettera a un cinese e Karma, insieme alla breve ma luminosa corrispondenza tra Gandhi e Tolstoj, sono contenute in questo piccolo e prezioso libro. Come ha scritto nell’Introduzione Davide Brullo, con questo testo ci si muove nell’ambito rarefatto delle parole ultime di una vita lunga, carica di parole, eventi e riflessioni.

The post Buddha first appeared on La Civiltà Cattolica.

Over on YouTube, [Ben Eater] pursues that classic 8-bit sound. In this video, [Ben] integrates the MOS Technology 6581 Sound Interface Device (SID) with his homegrown 6502. The 6581 SID was famously used in the Commodore line of computers, perhaps most notably in the Commodore 64.

The 6581 SID supports three independent voices, each consisting of a tone oscillator/waveform generator, an envelope generator, and an amplitude modulator. These voices are combined into an output filter along with a volume control. [Ben] goes into detail concerning how to configure each of these voices using the available facilities on the available pins, referencing the datasheet for the details.

[Ben]’s video finishes with an 8-bit hit from all the way back in October 1985: Monty on the Run by Rob Hubbard. We first heard about [Ben’s] musical explorations back in June. If you missed it, be sure to check it out. It seems hard to imagine that demand for these chips has been strong for decades and shows little sign of subsiding.

youtube.com/embed/LSMQ3U1Thzw?…

hackaday.com/2025/11/10/progra…

Era il 20 aprile 1998. Microsoft rimase così imbarazzata dall’iconica schermata blu di errore di Windows 98 sul palco decise di cambiare i piani per la costruzione di una nuova sede nel suo campus di Redmond. L’obiettivo era garantire che un incidente del genere non si ripeta mai più durante le presentazioni pubbliche.

Questo momento memorabile si verificò alla grande fiera COMDEX, diversi mesi prima del rilascio ufficiale di Windows 98. Bill Gates stava tenendo la presentazione principale e il dipendente Microsoft Chris Caposselastava illustrando una nuova funzionalità: il supporto plug-and-play per i dispositivi USB.

Mentre collegava uno scanner, che avrebbe dovuto scaricare automaticamente i driver, il sistema mostrò una schermata blu della morte BSOD (Blue Screen Of Death), proprio di fronte al pubblico. Gates reagì con umorismo, scherzando sul fatto che questo spiegasse perché Windows 98 non fosse ancora stato rilasciato, ma all’interno dell’azienda l’incidente ebbe un impatto molto più grave.

Il veterano di Microsoft Raymond Chen ha recentemente scritto sul suo blog che i Microsoft Production Studios dedicati “erano stati progettati proprio all’epoca della schermata blu che compariva quando si collegava un cavo USB a Windows 98“.

In seguito all’incidente, la planimetria dell’edificio è stata modificata, aggiungendo una stanza accanto allo studio principale per preparare e testare tutte le apparecchiature informatiche prima delle trasmissioni in diretta. Le apparecchiature sono state quindi configurate e testate prima di essere consegnate ai conduttori del programma.

Chen ha anche spiegato la ragione tecnica del problema. Il team di sviluppo di Windows aveva testato lo scanner in laboratorio e ne aveva confermato la funzionalità, ma il team che preparava la demo utilizzava un dispositivo diverso: aveva semplicemente acquistato lo scanner in un negozio di elettronica locale.

Questo particolare scanner tentava di assorbire più energia dalla porta USB di quanto consentito dalle specifiche e il team di sviluppo non aveva ancora gestito questo errore. Il risultato è stata una schermata blu di errore di fronte all’intero pubblico.

L’aggiunta di una sala prove ai Microsoft Production Studios fu una conseguenza diretta di questo incidente.

L’azienda non voleva che si ripetesse il disastro della schermata blu durante una diretta streaming e, secondo Chen, la strategia funzionò: incidenti del genere non si sono mai più verificati. Per quanto riguarda lo sfortunato scanner, secondo un ex dipendente Microsoft, il dispositivo venne poi collegato a un elmetto da fante della Seconda Guerra Mondiale, indossato da Brad Carpenter nelle sale operative di Windows per il resto del ciclo di sviluppo del prodotto.

L'articolo La schermata blu della morte di Windows 98 che cambiò i piani di Microsoft proviene da Red Hot Cyber.

Immaginiamo una metropolitana notturna in cui le richieste sono vagoni che scorrono uno dopo l’altro. Il front end fa da bigliettaio e smista i vagoni, il back end è il deposito che li riceve e li lavora. Se il bigliettaio e il deposito non sono d’accordo su dove finisce un vagone e inizia quello successivo, si apre una fessura che qualcuno può sfruttare per infilare un vagone nascosto. Quel vagone nascosto è il contrabbando di richieste HTTP.

Nel mondo reale la cosa prende forma quando componenti diversi della catena di comunicazione interpretano in modo diverso la lunghezza del corpo di una richiesta. In HTTP versione uno ci sono due modi per dichiarare la lunghezza del corpo, uno è il content length e l’altro è la transfer encoding in modalità chunked. Quando i nodi intermedi o i server finali non concordano su quale metodo utilizzare, la stessa sequenza di byte può essere letta da un elemento come parte della richiesta corrente e da un altro come l’inizio della richiesta successiva.

Questo disaccordo non è una sottigliezza teorica ma una vera leva d’attacco. Le varianti che si incontrano più spesso sono quelle in cui il front end prende come riferimento il valore di lunghezza mentre il back end interpreta la codifica a blocchi, oppure il contrario, oppure ancora situazioni in cui entrambi supportano la codifica a blocchi ma uno dei due ignora l’intestazione perché leggermente deformata con spazi, tabulazioni o formattazioni non standard. In tutti i casi il risultato effettivo è lo stesso, una parte di dati che si ritrova dove non doveva essere e che può alterare il comportamento di richieste legittime successive.

Le conseguenze pratiche possono diventare molto serie. Una richiesta prepended può cambiare il contesto di una transazione e far credere al server che una chiamata autenticata appartenga a un utente diverso. Si possono rubare sessioni, bypassare filtri, avvelenare cache o inserire comandi nella sequenza di richieste che colpisce utenti successivi sulla stessa connessione. In ambienti moderni il rischio aumenta quando c’è il downgrade da HTTP due a HTTP uno perché la riscrittura o la traduzione dei messaggi introduce ulteriori punti di ambiguità, e quando le connessioni backend vengono riutilizzate per inviare più richieste una dopo l’altra perché il riuso moltiplica le possibilità che dati residui vengano interpretati come nuova richiesta.

Per capire dove guardare basta osservare i comportamenti divergenti tra front end e back end, le intestazioni duplicate o non conformi che emergono nei log e i casi in cui i log mostrano mismatch tra la lunghezza dichiarata e il contenuto reale. Questi segnali non sono la prova definitiva di una vulnerabilità ma sono la traccia che indica che la catena di elaborazione non è allineata e che vale la pena investigare. Dal punto di vista di chi progetta e mantiene l’infrastruttura la soluzione più robusta è eliminare l’ambiguità alla fonte.

La comunicazione end to end su HTTP due risolve il problema alla radice perché quel protocollo fornisce un unico, solido meccanismo per definire le dimensioni delle richieste. Quando non è possibile mantenere HTTP due su tutta la filiera la fase di traduzione verso HTTP uno deve essere trattata come un punto critico: la richiesta riscritta va verificata rispetto alla specifica e gli elementi della catena non devono tollerare deviazioni formattative che possano essere interpretate in modo diverso. Nei pezzi dell’infrastruttura che si occupano di accettare e inoltrare traffico è utile normalizzare le richieste e rilevare le ambiguità invece di tentare di correggerle in modo silente. Il back end, di norma, dovrebbe chiudere la connessione quando non è possibile risolvere un’ambiguità in modo certo, perché mantenere aperte connessioni impure è ciò che permette al contrabbando di propagarsi.

Limitare o controllare il riutilizzo delle connessioni backend riduce la finestra d’attacco anche se non la elimina del tutto. È importante anche uniformare la gestione delle intestazioni che determinano la lunghezza del corpo e non accettare varianti non standard che possono essere sfruttate per mascherare la codifica. A complemento di queste scelte architetturali, test specifici che replicano scenari di desincronizzazione e monitoraggio attento dei log aiutano a individuare regressioni e incidenti reali.

Da ultimo, vale la pena ricordare che le tecniche che permettono di generare desincronizzazione sono potenti e pericolose se usate senza autorizzazione, quindi la loro esplorazione va sempre confinata ad ambienti controllati e autorizzati e qualsiasi scoperta in sistemi di terzi va gestita con responsabilità e disclosure appropriata. Capire il meccanismo del contrabbando di richieste significa riconoscere che non stiamo parlando di bug isolati ma di disallineamenti di protocollo che emergono nelle catene complesse di servizi, ed è proprio per questo che la difesa efficace nasce dall’allineamento dei protocolli, dalla standardizzazione dei comportamenti e dalla capacità di osservare e reagire quando le cose non tornano.

L'articolo Alla scoperta dell’HTTP Request Smuggling: cos’è e come difendersi proviene da Red Hot Cyber.