In the closing hours of JawnCon 0x2, I was making a final pass of the “Free Stuff for Nerds” table when I noticed a forlorn Kindle that had a piece of paper taped to it. The hand-written note explained that the device was in shambles — not only was its e-ink display visibly broken, but the reader was stuck in some kind of endless boot loop. I might have left it there if it wasn’t for the closing remark: “Have Fun!”

Truth is, the last thing I needed was another Kindle. My family has already managed to build up a collection of the things. But taking a broken one apart and attempting to figure out what was wrong with it did seem like it would be kind of fun, as I’d never really had the opportunity to dig into one before. So I brought it home and promptly forgot about it as Supercon was only a few weeks away and there was plenty to keep me occupied.

The following isn’t really a story about fixing a Kindle, although it might seem like it on the surface. It’s more about the experience of working on the device, and the incredible hacking potential of these unassuming gadgets. Whether you’ve got a clear goal in mind, or just want to get your hands dirty in the world of hardware hacking, you could do far worse than picking a couple of busted Kindles up for cheap on eBay.

If there’s a singular takeaway, it’s that the world’s most popular e-reader just so happens to double as a cheap and impressively capable embedded Linux development environment for anyone who’s willing to crack open the case.

Getting Connected

We start with what’s essentially Hardware Hacking 101: the hidden serial debug port. It’s the sort of thing you learn to look for when taking apart a new gadget, and unsurprisingly, it’s also at the heart of Kindle hacking. While there’s plenty of software modifications you can do depending on the age and version of your particular Kindle, opening up the case and tapping into the serial port is always the most direct way to gain access to the system.

From my research, every Kindle (with the possible exception of the very latest models from the 2020s) have an unpopulated serial port on the board. In the case of this Kindle Paperwhite 2 from 2013, it’s even labeled. I simply soldered on some jumper wires and ran them out to a pin header to make connecting to it a little less fiddly. The only thing to watch out for is the voltage; it seems that the serial port on the majority of Kindles is 1.8 V, and connecting up a higher voltage USB-serial adapter without a level shifter could release the Magic Smoke.

With the hardware connected and my favorite serial communications tool running, it was easy to see what ailed this particular Kindle. As evidenced by the final few lines of the kernel messages, a failure of one of the voltage regulators in the MAX77696 — a power management IC designed specifically for e-ink readers — was preventing the driver module from loading fully. This in turn was triggering a reboot, presumably because some sort of watchdog routine was in place to bail out if any critical hardware issues were detected.

On the Hunt

Coming from the “normal” Linux world, the solution seemed easy enough. Since the screen was toast anyway, all I needed to do to get the Kindle booting was to prevent the kernel module from loading. That way I could at least use it for something, perhaps an energy efficient minimalist server.

But according to the MAX77696 datasheet, the chip was responsible for quite a bit more than simply driving the e-ink panel. If I pulled the kernel module entirely, there was a good chance I’d also lose features like the real-time clock and the ability to read the battery voltage as well. So I decided to change tactics: rather than keeping the driver from loading, I’d take out the watchdog that was forcing the system to reboot. But where was it?

Amazon makes it easy to manually download the latest firmware for each member of the Kindle family, and the aptly named KindleTool lets you manipulate them. In this case I used the extract function to pull out the root filesystem image, which I could then locally mount as a basic EXT3 volume.

That was refreshingly straightforward, but unfortunately didn’t get me where I needed to go. Using grep to search all the files within the filesystem for the string “failed to load eink driver” showed no hits. If the watchdog wasn’t in the root filesystem, then where was it?

Unpacking the firmware update with KindleTool also got me the kernel image, and running Binwalk against it showed there was a compressed filesystem at 0x466C. I reasoned this must be an initramfs — essentially a minimal Linux system that lives in RAM and gives the kernel a place to work as it brings up the rest of the system. If the system has some self-check capability, it’s reasonable to assume that’s where it lives.

After drilling down a few times with Binwalk’s extract function, I was able to get to the contents of the initramfs. Sure enough, another search for the error message revealed our sentinel: /bin/recovery-util.

New Kernel, Who Dis?

I had considered trying to simply remove the recovery-util program from the kernel image, but since I wasn’t 100% sure how the whole watchdog system functioned, there was no guarantee that would have worked without more trial and error. So, emboldened by how well this was all going for me so far, I took the nuclear option and decided to rebuild the kernel with my own initramfs.

It’s here that the Kindle software environment, and the community around it, really started to shine. Once again, Amazon made it ridiculously easy to get the source code for the exact firmware I was working with, and the community provided an actively maintained toolchain to build it with. A little more searching even pulled up some pre-compiled builds that were ready to use.

Actually building the kernel for the Kindle was essentially the same process as doing it on my desktop computer, with the notable addition of supplying the location of the cross compiler into each make command. But if I ever got off track, there were plenty of write-ups online to reference. I even found one that went over building a custom initramfs with BusyBox that doesn’t include any of Amazon’s programs.

But perhaps the best part was that, once I had compiled Amazon’s modified kernel and built my initramfs, installing it on the Kindle was as simple as using a modified version of Android’s fastboot command. There were no cryptographic hoops to jump through, you just give it the new kernel and away it went. It’s my understanding that newer Kindles might not be so understanding, but with at least the hardware of this vintage, there’s nothing stopping you from doing whatever you want.

Pocket Penguin Playground

With the source code, tools, and knowledge floating around out there, I was able to build my own kernel and initramfs that lets me boot into a full Linux environment on what was previously a non-functional Kindle. There are a few things I haven’t gotten to work yet, but I believe that’s largely because I’m still using the root filesystem provided by Amazon.

Now that I know how easy it is to work with Linux on the Kindle, I’m looking to push further and put together my own stripped-down environment without any of Amazon’s frameworks installed. Given how ridiculously cheap early Kindles are on the second hand market — especially if they have a busted screen — there are all sorts of tasks that I could see them performing if I had a solid base to build on.

Make no mistake, I’m greatly appreciative of the fact that we now have mature single-board computers like the Raspberry Pi available for a reasonable cost. But taking what’s essentially consumer e-waste and turning it into a useful platform for learning and experimentation is the true hacker way. So whether you’ve got a Kindle collecting dust somewhere at home, or end up grabbing a few off of eBay for a song, I invite you to bust out the USB-serial adapter and start exploring.

Il lavoro da remoto ha dato libertà ai dipendenti, ma con essa è arrivata anche la sorveglianza digitale.

Ne abbiamo parlato qualche tempo fa in un articolo riportando che tali strumenti di monitoraggio stanno arrivando anche all’interno di Microsoft teams. Pertanto, al posto dello sguardo fisso del capo, questo ruolo verrà sempre più svolto dagli “algoritmi” che monitoreranno per quanto tempo le applicazioni rimangono aperte, quali siti web vengono visitati e con quanta attività viene mosso il mouse e premuto i tasti.

Sistemi avanzati analizzano persino le espressioni facciali e il modo in cui i dipendenti camminano davanti a una webcam. Ma questi strumenti sottolineando al tempo stesso i limiti intrinseci della raccolta di dati personali.

Tuttavia, per molti lavoratori, tale monitoraggio non è visto come una preoccupazione, ma come una sfiducia e una violazione della privacy. Sondaggi e dati dell’American Psychological Association collegano la sorveglianza costante a un aumento dello stress, a un peggioramento del benessere psico-emotivo e al desiderio di lasciare il lavoro.

La necessità di trasmettere immagini da webcam o informazioni mediche sensibili è particolarmente pressante. Le persone chiedono spiegazioni chiare sul motivo per cui i dati vengono raccolti e con chi possono essere condivisi.

Lo sguardo gelido degli algoritmi non è meno pericoloso. I programmi mancano di contesto e scambiano facilmente telefonate o documenti per inattività. Questo porta i dipendenti a fingere un’attività frenetica per il bene degli indicatori di performance, e gli esperti del National Employment Law Project degli Stati Uniti hanno documentato casi di sanzioni ingiustificate e difficili da contestare quando la decisione viene effettivamente presa dal sistema.

Nei magazzini e nella logistica, dove ogni movimento è digitalizzato, la pressione è particolarmente intensa: la fretta di rispettare gli standard si traduce in dolore fisico, affaticamento e burnout. Secondo NELP, la sorveglianza digitale ha anche un impatto sui diritti dei lavoratori, ostacolando l’organizzazione dei lavoratori e fornendo alle aziende uno strumento per la rilevazione precoce dell’attività sindacale, con il pretesto di analizzare altri parametri.

Le regole del gioco stanno cambiando lentamente. Negli Stati Uniti, i datori di lavoro sono tenuti a fornire un avviso sulla raccolta dei dati, ma questi requisiti sono limitati, quindi gli stati stanno cercando di introdurre misure di salvaguardia proprie. La California sta discutendo di vietare i sistemi che riconoscono emozioni, andatura o espressioni facciali e trasmettono dati a terzi.

Nel frattempo, il Massachusetts sta promuovendo una legislazione che proteggerebbe i lavoratori dall’abuso della sorveglianza digitale. Nel frattempo, le autorità federali stanno cercando un approccio unificato alla regolamentazione dell’intelligenza artificiale, il che potrebbe indebolire le iniziative locali. Pertanto, l’interesse per la contrattazione collettiva come mezzo valido per combattere la sorveglianza eccessiva sta crescendo.

I sostenitori di un approccio più cauto insistono sul fatto che tali strumenti siano significativi solo quando aiutano a identificare le tendenze generali e a migliorare i processi, piuttosto che trasformare le persone in parametri. Dove rispetto, autonomia e condizioni di lavoro sicure permangono, la produttività emerge in modo naturale, senza una telecamera onnipresente che controlla ogni mossa.

L'articolo La Sorveglianza Digitale sui Lavoratori sta Arrivando: Muovi il Mouse più Veloce! proviene da Red Hot Cyber.

Una vulnerabilità recentemente corretta nei servizi di aggiornamento di Windows Server di Microsoft ha portato a una serie di attacchi utilizzando uno degli strumenti di spionaggio più noti degli ultimi anni.

Gli incidenti dimostrano la rapidità con cui gli aggressori possono passare dallo studio di un exploit pubblicato allo sfruttamento attivo della vulnerabilità per penetrare nell’infrastruttura.

Secondo l’azienda sudcoreana AhnLab, un gruppo sconosciuto ha ottenuto l’accesso ai server Windows che eseguivano WSUS sfruttando la vulnerabilità CVE-2025-59287. Questa vulnerabilità è stata sfruttata per eseguire utilità di sistema standard, consentendo agli aggressori di contattare un server esterno e scaricare codice dannoso.

Prima di installare lo strumento principale, è stata utilizzata l’utilità PowerCat, che ha fornito agli aggressori un prompt dei comandi remoto. Quindi, utilizzando certutil e curl, è stato installato ShadowPad sul sistema.

Questo programma è considerato uno sviluppo di PlugX ed è da tempo utilizzato da entità collegate alla Cina. La sua architettura è modulare e viene avviato tramite sostituzione di libreria.

Un file DLL, situato in memoria e responsabile dell’esecuzione del contenuto principale, viene caricato nel file legittimo ETDCtrlHelper.exe. Al suo interno viene implementato un modulo che carica componenti aggiuntivi e utilizza meccanismi stealth e di persistenza.

Microsoft ha corretto CVE-2025-59287 un mese fa. Il bug è classificato come critico perché consente l’esecuzione di codice arbitrario con privilegi di sistema. Dopo il rilascio di un exploit dimostrativo, molti gruppi hanno iniziato a scansionare in massa i server WSUS accessibili, ottenendo l’accesso iniziale, effettuando ricognizioni e scaricando sia file dannosi che strumenti di amministrazione legittimi. Secondo AhnLab, è in questo modo che ShadowPad è stato distribuito sui server.

L’incidente ha chiaramente dimostrato che ogni vulnerabilità diventa una minaccia reale se la sua risoluzione viene ritardata. Quanto più rapidamente vengono affrontati i problemi identificati, tanto minore è la probabilità che gli aggressori riescano a infiltrarsi nell’infrastruttura e a trasformare un guasto in una crisi conclamata.

L'articolo Microsoft corregge il bug su WSUS, ma gli hacker Cinesi arrivano prima proviene da Red Hot Cyber.

La crescente fuga di dati dall’ecosistema Salesforce ha preso una nuova piega dopo che il gruppo ShinyHuntersha annunciato il suo coinvolgimento nell’incidente. Gli eventi sono in corso da diversi mesi, interessando diversi servizi correlati alle piattaforme CRM, e la portata dell’impatto continua a crescere.

ShinyHunters afferma di aver ottenuto l’accesso a Gainsight diversi mesi fa, sfruttando le funzionalità acquisite tramite un hack dell’integrazione di Salesloft Drift. All’epoca, individui sconosciuti si erano infiltrati nell’account GitHub di Salesloft ed estraevano i token OAuth utilizzati dal servizio di terze parti Drift con Salesforce. Questi token hanno permesso loro di accedere furtivamente ai dati di un gran numero di clienti aziendali.

Secondo quanto riferito, la stessa campagna ha compromesso anche Gainsight. Questo servizio opera come piattaforma di gestione dei processi dei clienti ed è connesso a Salesforce, HubSpot e sistemi di supporto come Zendesk.

L’incidente ha spinto l’azienda a contattare gli specialisti di Google Mandiant per indagare sulla natura dell’attività e sull’origine del problema. Gainsight sostiene che l’attività indesiderata si sia verificata tramite connessioni ad applicazioni esterne, non a causa di un bug nella piattaforma Salesforce stessa.

In risposta, Salesforce ha revocato tutte le chiavi di accesso attive per le app Gainsight e le ha temporaneamente rimosse da AppExchange. Zendesk e HubSpot hanno adottato misure simili, limitando la funzionalità dei rispettivi connettori in attesa di una revisione interna. I rappresentanti di Salesforce hanno rifiutato di commentare nei dettagli, ma hanno sottolineato che le misure sono state adottate immediatamente.

Secondo il Google Threat Intelligence Group, l’attacco è collegato al gruppo UNC6240, noto anche come ShinyHunters. L’azienda ha identificato oltre duecento istanze Salesforce interessate. Si ritiene che la fonte della compromissione siano i token OAuth rubati, che hanno consentito agli aggressori di accedere a servizi di terze parti e alle relative integrazioni.

I membri di ShinyHunters affermano di aver verificato il livello di monitoraggio nei sistemi di Gainsight e che l’attività illegale è stata rilevata circa una o due settimane dopo l’inizio delle intrusioni. Il gruppo afferma inoltre di cercare complici all’interno di grandi aziende. Salesforce aveva precedentemente dichiarato che non avrebbe acconsentito alle richieste degli estorsori e non avrebbe negoziato.

L'articolo ShinyHunters cerca impiegati infedeli mentre il caso Gainsight Salesforce si estende proviene da Red Hot Cyber.

Partono le prenotazioni della campagna “Arance di natale arance per la vita” 2025. C’e’ tempo fino al 3 dicembre!

La finalita’ e’ la ripresa dei lavori per il completamento dell’ospedale di Duhla, lavori che attualmente sono fermi per mancanza di fondi.
IBAN dell’Associazione Verso il Kurdistan: IT17 Q030 6909 6061 0000 0111 185 Causale: Campagna arance 2025

Prenotazioni entro il 3 dicembre.

Per info: Antonio 335 7564743 – Lucia 333 5627137

Per chi volesse dare un contributo liberale, la causale è: contributo volontario.

Associazione Verso il Kurdistan Odv

L'articolo Campagna “Arance di Natale, arance per la vita” proviene da Retekurdistan.it.