The e-paper “dashboard” is something we’ve seen plenty of times here at Hackaday. Use it to show your daily schedule, the news, weather, maybe the latest posts from your favorite hardware hacking website. Any information source that doesn’t need to be updated more than every hour or so is a perfect candidate. All you’ve got to do is write the necessary code to pull down said data and turn it into a visually attractive display.

Well, that last part isn’t always so easy. There are plenty of folks who have no problem cobbling together a Raspberry Pi and one of the commercially available e-paper modules, but writing the software to turn it into a useful information center is another story entirely. Luckily, Inkycal is here to help.

This open source project uses Python to pull information from a wide variety of sources and turns it into an e-paper friendly dashboard. It works with Waveshare displays ranging from 4.2 inches all the way up to the massive 12 inch tricolor panels. While it could theoretically be deployed on any operating system running a modern version of Python, it’s primarily developed to be run under Linux and on the Raspberry Pi. All of the versions of the Pi are supported, so no need to spring for the latest and greatest model. In fact, the notoriously pokey Raspberry Pi Zero is their recommended platform thanks to its low power consumption.

With Inkycal on the Pi — they even provide a pre-configured SD card image — and the e-paper display hooked up, all you need to do is pick which sources you want to use from the web-based configuration page. Look ma, no code!

Not feeling like putting the hardware together either? Well, we might wonder how you’ve found yourself on Hackaday if that’s the case. But if you really would rather buy then build, you can get a pre-built Inkcal display right now on Tindie.

hackaday.com/2024/09/12/inkyca…

Diventare un white hat hacker è il sogno di molti. Ma come superare un colloquio e dimostrare la propria professionalità? Ecco a voi 15 domande che ti aiuteranno a prepararti efficacemente per superare con successo un colloquio di assunzione per una posizione di penetration tester.

1. Cos’è il test di penetrazione e in cosa differisce dalla scansione delle vulnerabilità?

Il penetration test (pentest) è un tentativo ordinato, mirato e autorizzato di attaccare un’infrastruttura IT per testarne la sicurezza. Si differenzia dalla scansione delle vulnerabilità in quanto un pentest implica il tentativo attivo di sfruttare le vulnerabilità rilevate, mentre la scansione delle vulnerabilità è il processo automatizzato di scoperta delle stesse, solitamente per scopi di conformità normativa. Il penetration test permette di concatenare delle vulnerabilità per creare un “vettore di attacco” capace di compromettere un sistema dal punto di vista della Riservatezza, Integrità e Disponibilità (RID).

2. Qual è la differenza tra analisi del rischio e test di penetrazione?

L’analisi del rischio è il processo di identificazione delle potenziali minacce e vulnerabilità che influiscono sulla sicurezza di un sistema. Il penetration test è un tentativo reale ma controllato di sfruttare le vulnerabilità per testare la funzionalità delle attuali misure di sicurezza.

3. Descrivi le fasi di un penetration test

Le fasi di un pentest possono variare a seconda dell’azienda o del professionista che le esegue, ma generalmente seguono la seguente sequenza:

Preparazione al test : durante questa fase vengono discussi i dettagli e le aspettative del test. Questo processo può sembrare noioso, ma è molto importante per stabilire obiettivi chiari e regole di impegno tra committente e penetration tester. Vengono discussi i tempi del test, gli obiettivi e ciò che è accettabile svolgere all’interno del test.

Raccolta delle informazioni : questo è il momento in cui inizia il test vero e proprio. Generalmente si eseguono attività di Open Source Intelligence (OSINT), esaminando gli host, la rete e i servizi disponibili per analizzarli in modo passivo. In questa fase si cercano reti IP insolite, segreti sparsi in qualche repository aperto come su GitHub, attività dei dipendenti sui social network che possono rivelare informazioni sulle tecnologie dell’azienda. Si può abbinare alla fase di information gathering anche attività di Cyber Threat Intelligence mirate ad analizzare tracce del sistema all’interno delle underground, come ad esempio log provenienti da infostealer. Alla fine si crea una una mappa visiva della rete e si definisce una “Metodologia di assessment” che riporta come avverrà il test e cosa ci si aspetta dal test stesso.

Valutazione delle vulnerabilità : dopo aver raccolto le informazioni, si iniziano a valutare se esistono vulnerabilità che possono essere sfruttate. Si cercano vulnerabilità note in base alle versioni del software e del servizio e si isolano le CVE (vulnerabilità ed esposizioni comuni) verificando la presenza di exploit pubblici. Questa attività può essere svolta con scanner automatizzati ma anche attraverso una ricognizione manuale. È importante pianificare attentamente gli attacchi per ridurre al minimo il rischio di disservizio dei sistemi.

Sfruttamento delle vulnerabilità : in questa fase, si inizia ad effettuare attacchi attivi sulle vulnerabilità identificate sfruttando gli exploit rilevati. Se è richiesto il test sia da rete esterna che da quella interna, generalmente si inizia ad hackerare il sistema esterno vulnerabile per comprendere se si riesce ad utilizzare tali falle per accedere all’infrastruttura interna dell’azienda. Si può lavorare anche all’interno della rete del cliente, accedendo da remoto tramite VPN o macchina virtuale fornita per il test.

Post-sfruttamento : una volta entrato nel sistema, si iniziano a controllarne i privilegi. Ad esempio, se si tratta di un sistema Windows, si eseguono dei comandi per raccogliere informazioni, trovare file ed effettuare delle “privilege escalation”.

Movimenti laterale : utilizzando le informazioni raccolte, si prova a muoversi all’interno della rete, passando da un sistema all’altro. Ciò potrebbe includere l’utilizzo di credenziali rubate o l’elusione della sicurezza di altri sistemi interni.

Reportistica : una volta completati tutti i test, e compresi gli impatti che il sistema potrebbe avere a seguito di un attacco da parte di un malintenzionato, viene preparato un rapporto con una descrizione dettagliata delle vulnerabilità e proposte per eliminarle. Vengono quindi discussi i risultati con il cliente per garantire che comprenda tutte le minacce identificate e sappia come eliminarle.

4. Quali fattori rendono un sistema vulnerabile?

I sistemi possono essere vulnerabili per diversi motivi, solitamente legati alla gestione delle patch, alla gestione delle vulnerabilità e alla configurazione. Ecco alcuni esempi:

• Utilizzo di versioni obsolete di servizi o applicazioni con vulnerabilità note per le quali esistono già exploit pubblici.
• Configurazione errata dei servizi, come l’utilizzo di password standard o deboli, mancanza di diritti di accesso adeguati, mancanza di autenticazione.
• Applicazioni Web vulnerabili ad attacchi comuni come quelli descritti nella OWASP Top 10.
• Sistemi che fanno parte di domini Active Directory vulnerabili ad attacchi alle credenziali o ad altri attacchi mirati all’infrastruttura AD.

5. Come gestisci i dati sensibili che incontri durante i penetration test?

Ogni vulnerabilità scoperta nella rete di un cliente può tecnicamente essere considerata un’informazione sensibile. Il lavoro di pentester è aiutare i clienti a migliorare la loro sicurezza. Occorre essere responsabili lavorando con i dati dei clienti e documentare tutti i risultati. Ad esempio, se si sta conducendo un test per un’azienda sanitaria, l’obiettivo non è esaminare un database di informazioni mediche sensibili, ma trovare una vulnerabilità che possa essere sfruttata per accedere a tali dati. È importante documentare la vulnerabilità e valutarne l’impatto senza violare i diritti dei clienti. Se ci si imbatte in contenuti illegali, si interrompe immediatamente i test e si segnala il tutto al management. Successivamente i decide assieme come proseguire adeguatamente i lavori, eventualmente con il coinvolgimento dei legali.

6. Spiegare la differenza tra crittografia simmetrica e asimmetrica.

La crittografia simmetrica utilizza una singola chiave per crittografare e decrittografare i dati, mentre la crittografia asimmetrica utilizza una coppia di chiavi pubblica e privata. Il primo è più veloce e il secondo viene utilizzato per trasferire in modo sicuro chiavi e firme digitali. Nella crittografia asimmetrica, la chiave pubblica può essere distribuita a tutti per cifrare i dati mentre la chiave privata deve essere conservata gelosamente in quanto sarà quella che permetterà di decifrarli.

7. Come mantieni le tue conoscenze sulla sicurezza informatica?

Utilizzo sia metodi di apprendimento passivo (leggendo notizie su redhotcyber.com, iscrivendomi a blog e podcast) che attivi (praticando attività di Capture The Flag o svolgendo percorsi formativi tramite Hack The Box ed esperimenti nel mio laboratorio di casa).

8. Qual è la differenza tra Windows e Linux nelle attività di pentest?

I sistemi operativi Windows e Linux presentano i propri vantaggi e svantaggi nel contesto del test delle applicazioni web. Windows è considerato più amichevole per gli utenti inesperti, mentre Linux è più affidabile e sicuro. La maggior parte degli strumenti di test vengono eseguiti su Linux in quanto questo sistema operativo offre più opzioni di personalizzazione. Tuttavia, Windows è più comune negli ambienti aziendali, quindi i test su questa piattaforma possono simulare più da vicino le condizioni del mondo reale che incontrerai durante il test delle applicazioni aziendali. Preferisco combinare entrambi i sistemi, il che mi consente di sfruttare i vantaggi di ciascuno.

9. Quali tre strumenti utilizzi per svolgere pentest di Active Directory e perché?

I miei 3 strumenti principali per testare Active Directory sono:

BloodHound : questo è un potente strumento per visualizzare le relazioni tra oggetti Active Directory come domini, trust, policy e autorizzazioni. Aiuta a identificare visivamente i possibili vettori di attacco.

PowerShell : questo è uno strumento integrato in Windows che può essere utilizzato per eseguire comandi relativi ad AD. Se si riesce ad accedere a un account amministratore utilizzando PowerShell, è possibile usarlo per ottenere l’accesso remoto al controller di dominio.

PowerView.ps1 : fa parte del progetto PowerSploit e fornisce una varietà di funzionalità per la raccolta di dati sugli oggetti AD, la ricerca di risorse di rete e il furto di ticket TGS per eseguire un attacco Kerberoasting.

10. Quali vulnerabilità potrebbe avere lo scambio di chiavi Diffie-Hellman?

Lo scambio di chiavi Diffie-Hellman (DH) può essere vulnerabile a diversi tipi di attacchi se non configurato correttamente. Tra i più comuni ci sono:

Attacco Man-in-the-middle (MitM) : se le parti non si autenticano a vicenda, un utente malintenzionato può inserirsi tra di loro e acquisire la capacità di decrittografare e modificare i dati.

Attacco Logjam : questo attacco utilizza parametri chiave deboli per forzare un downgrade della sicurezza della sessione.

Attacchi di forza bruta e canali laterali : se i parametri chiave sono deboli, sono possibili tentativi di forza bruta o attacchi che utilizzano dati di terze parti (ad esempio, il tempo di esecuzione dell’operazione).

11. Cos’è l’SQL injection basata sull’operatore UNION?

L’SQL injection basata su UNION è un tipo di SQL injection in cui un utente malintenzionato utilizza l’operatore UNION per combinare i risultati di più query, ottenendo così l’accesso a dati che non avrebbero dovuto essere esposti. Ad esempio, un utente malintenzionato potrebbe aggiungere una query UNION SELECT alla query originale per ottenere l’accesso a un’altra tabella di database che non faceva originariamente parte della query.

12. Che cos’è l’escalation dei privilegi e come affrontarla?

L’escalation dei privilegi è il processo che consente di ottenere l’accesso non autorizzato alle risorse di sistema con diritti più elevati. Una volta che un utente malintenzionato ottiene l’accesso a un sistema, inizia a cercare le vulnerabilità che gli consentiranno di aumentare i privilegi al livello di amministratore o ottenere l’accesso a dati sensibili. Ad esempio, se un sistema utilizza un componente software obsoleto, un utente malintenzionato potrebbe tentare di sfruttarlo per aumentare i diritti di accesso.

13. Qual è la vulnerabilità XXE?

XXE (XML External Entity) è una vulnerabilità che si verifica quando il server elabora input XML non sicuri. Un utente malintenzionato potrebbe inserire entità esterne nell’input XML che verrebbe elaborato dal server, il che potrebbe comportare la divulgazione di informazioni sensibili, l’esecuzione di codice arbitrario o l’invio di richieste dannose a risorse esterne per conto del server.

14. Cos’è l’intercettazione dei pacchetti di rete?

Lo sniffing dei pacchetti di rete è il processo di acquisizione dei dati trasmessi su una rete. Viene utilizzato per diagnosticare, monitorare e analizzare il traffico e può anche essere utilizzato per identificare vulnerabilità e ottenere informazioni sensibili.

15. Come spieghi la vulnerabilità XSS a qualcuno senza conoscenze tecniche?

XSS è una vulnerabilità in cui un utente malintenzionato può inserire codice dannoso in un sito Web. Questo codice verrà eseguito nel browser dell’utente, il che può portare al furto di dati, al dirottamento della sessione o alla modifica delle impostazioni dell’utente a sua insaputa.

Il ruolo di un hacker white hat richiede un costante sviluppo personale e un adattamento al panorama delle minacce informatiche in rapida evoluzione.

Un colloquio di successo dipende non solo dalle competenze tecniche, ma anche dalla capacità del candidato di dimostrare passione per l’apprendimento di nuove tecnologie, volontà di risolvere problemi complessi e capacità di lavorare in gruppo.

L'articolo Le 15 Risposte che ti faranno Assumere ad un Colloquio Tecnico per un Ruolo da Pen Tester proviene da il blog della sicurezza informatica.

Google ha sostenuto l’implementazione di Rust nel firmware di basso livello, promuovendo la traduzione del codice legacy come mezzo per combattere i bug che minacciano la sicurezza dell’accesso alla memoria.

In un nuovo post sul blog, il team di Android sostiene che il passaggio da C o C++ a Rust nel firmware esistente fornirà garanzie di sicurezza della memoria a livelli inferiori al sistema operativo che non dispone di standard di sicurezza.

Secondo gli esperti, la perdita di produttività in questo caso è trascurabile, anche la dimensione dei codici Rust è comparabile, l’importante è sostituire i codici base per gradi, iniziando con quelli nuovi e più critici. Il processo non richiederà molti sforzi e nel tempo il numero di vulnerabilità di accesso alla memoria sarà significativamente ridotto.

Riscrivere gradualmente il codice delle librerie utilizzando la logica Shim

Per facilitare la transizione, è possibile ad esempio, creare un sottile strato Rust, il preloader Shim , che copierà l’API C ed esporterà per la base di codice esistente. “Shim funge da wrapper attorno all’API della libreria Rust, collegando l’API C esistente e l’API Rust”, spiegano gli esperti. “Questo è quello che si fa di solito, riscrivendo le librerie o sostituendole con un’alternativa a Rust.”

Secondo Google, fino a poco tempo fa, i bug di sicurezza nella memoria erano la principale fonte di vulnerabilità in Chrome e Android. Grazie all’implementazione di linguaggi di programmazione in grado di liberare i prodotti da questa piaga, tra il 2019 e il 2022 il numero annuo di tali errori nel sistema operativo mobile è stato ridotto da 223 a 85.

L’anno scorso, Microsoft ha avviato il processo di migrazione del kernel di Windows su Rust.

La versione 11 della build del sistema operativo, rilasciata a maggio 2023, conteneva driver in questo linguaggio. Allo stesso tempo, si è saputo dei piani del colosso tecnologico per aumentare in modo simile la sicurezza del processore Pluton, che non ha ancora trovato un utilizzo diffuso.

Rust la chiave dei bug di memoria

Il linguaggio di programmazione Rust è stato progettato per risolvere problemi legati alla sicurezza della memoria e alla gestione concorrente dei dati, affrontando alcune delle vulnerabilità più comuni presenti in linguaggi come C e C++. Ecco i principali tipi di bug che Rust risolve:

1. Bug di gestione della memoria (Memory Safety Issues)

• Dereferenziazione di puntatori nulli (Null Pointer Dereference): In linguaggi come C e C++, è comune che i puntatori nulli causino crash del programma o comportamenti imprevisti. Rust previene questo problema usando il tipo Option, che fornisce un modo sicuro di gestire valori che potrebbero essere nulli.
• Use-After-Free: Questo bug si verifica quando un programma tenta di accedere a un’area di memoria che è già stata liberata. In Rust, grazie al sistema di proprietà (ownership) e al concetto di borrow checker, non è possibile accedere alla memoria dopo che è stata rilasciata.
• Double Free: In C o C++, liberare la stessa area di memoria due volte può causare instabilità o vulnerabilità. Rust gestisce la liberazione della memoria in modo automatico e sicuro attraverso la sua gestione di ownership, prevenendo il rischio di liberazioni multiple della stessa risorsa.

2. Race conditions e problemi di concorrenza (Concurrency Bugs)

• Data Race: Una data race si verifica quando due thread accedono contemporaneamente alla stessa memoria, con almeno uno che esegue un’operazione di scrittura, senza la necessaria sincronizzazione. Rust usa tipi come Mutex e RwLock, e il borrow checker assicura che le risorse condivise siano accessibili in modo sicuro, prevenendo le data race a compile-time.
• Thread Safety: Rust applica rigorose regole di concorrenza e sincronizzazione attraverso il sistema di tipi, assicurandosi che le risorse condivise tra thread siano sicure da usare.

3. Buffer overflow

• Questo è uno dei bug di sicurezza più comuni in linguaggi come C e C++, dove l’accesso a buffer di memoria oltre i limiti definiti può causare comportamenti imprevisti o vulnerabilità di sicurezza. Rust impedisce questo bug grazie al suo controllo rigoroso dei limiti degli array e delle slice, rendendo impossibile l’accesso fuori dai limiti a meno che non sia esplicitamente consentito.

4. Dangling Pointers

• Un dangling pointer è un puntatore che fa riferimento a una locazione di memoria che non è più valida. In Rust, il sistema di ownership impedisce la creazione di puntatori invalidi o di riferimenti a memoria liberata, eliminando i dangling pointers.

5. Memory Leaks

• Anche se Rust non garantisce di prevenire ogni perdita di memoria (poiché può esserci memoria ciclicamente referenziata che non viene rilasciata), è molto più difficile incorrere in memory leaks rispetto a linguaggi come C/C++. La gestione della memoria basata su ownership e il sistema di borrowing fanno sì che le risorse vengano rilasciate automaticamente quando non sono più utilizzate.

6. Errori di tipo (Type Safety Issues)

• Rust è un linguaggio fortemente tipizzato, e molte operazioni che in altri linguaggi potrebbero fallire a runtime vengono bloccate a compile-time. Questo impedisce errori legati al tipo di dati, come assegnare valori a variabili di tipo incompatibile o effettuare operazioni non valide tra tipi diversi.

7. Stack Overflow per ricorsione non controllata

• Rust include l’uso di tail-call optimizations per ridurre il rischio di overflow dello stack nelle funzioni ricorsive. Anche se non previene completamente il problema, il suo sistema di tipi e la gestione delle risorse rendono più facile evitare errori di questo tipo.

L'articolo Rust contro i bug di Memoria del Firmare. Riscrivere in logica Shim le librerie è la chiave proviene da il blog della sicurezza informatica.

Il Decreto Legislativo di attuazione della direttiva (UE) 2022/2555, noto anche come NIS2, segna un importante passo avanti nella gestione della sicurezza informatica in Italia e nell’Unione Europea. Con la finalità di rafforzare la protezione delle infrastrutture critiche e migliorare la resilienza delle aziende contro le crescenti minacce informatiche, questo decreto introduce nuovi obblighi per i soggetti considerati essenziali e importanti.

Struttura del Decreto

Il decreto si articola in 6 Capi e 44 articoli, e sostituisce il precedente Decreto Legislativo n. 65 del 2018, che implementava la prima direttiva NIS (Network and Information Systems) del 2016. Le nuove disposizioni mirano a rafforzare il livello di sicurezza delle reti e dei sistemi informativi, soprattutto per quanto riguarda i soggetti considerati essenziali e importanti. Tra questi figurano fornitori di servizi di cloud computing, data center, piattaforme di social network, motori di ricerca online e mercati digitali.

Obblighi per i Soggetti Essenziali e Importanti

Un elemento cruciale del decreto è l’obbligo, per gli organi di amministrazione e direttivi delle aziende considerate essenziali e importanti, di approvare e sovrintendere all’implementazione delle misure di gestione dei rischi per la sicurezza informatica. Questi organi sono inoltre responsabili delle violazioni del decreto e devono assicurarsi che i dipendenti ricevano una formazione continua in materia di sicurezza informatica (Articolo 23).

L’articolo 24 specifica le misure di gestione dei rischi, che devono includere l’uso di tecnologie sicure e aggiornate, la protezione contro accessi non autorizzati, e la gestione e registrazione degli incidenti di sicurezza. Inoltre, si pone particolare attenzione alla continuità operativa e alla rapidità di ripristino delle attività in caso di incidenti.

Notifica di Incidenti Significativi e Quasi-Incidenti

Il decreto impone l’obbligo di notifica tempestiva degli incidenti significativi entro 24 ore dalla loro rilevazione, con una relazione dettagliata da fornire entro 72 ore. Questi incidenti devono essere accompagnati da informazioni riguardanti il loro impatto e le misure di mitigazione adottate. Inoltre, il decreto introduce l’obbligo di notificare anche i “quasi-incidenti”, ovvero quegli eventi che potrebbero avere un impatto significativo ma che non hanno ancora causato danni rilevanti (Articolo 25 e 26).

Tempistica e Fase di Prima Applicazione

La fase di prima applicazione del decreto prevede una serie di scadenze ben definite. In particolare, i fornitori di servizi di dominio, cloud, data center e altre categorie devono registrarsi sulla piattaforma digitale predisposta entro il 17 gennaio 2025. Gli obblighi previsti dagli articoli 23, 24 e 29 dovranno essere rispettati entro diciotto mesi dalla ricezione della comunicazione da parte delle autorità competenti. La registrazione iniziale e gli aggiornamenti annuali dei dati saranno cruciali per garantire il monitoraggio continuo da parte delle autorità.

Implicazioni e Importanza

Il recepimento di questa direttiva in Italia rappresenta un ulteriore passo avanti verso la protezione delle infrastrutture critiche e delle informazioni sensibili contro minacce informatiche in costante evoluzione. L’Agenzia per la Cybersicurezza Nazionale (ACN) è confermata come l’autorità competente per l’attuazione delle disposizioni del decreto, rafforzando così il quadro normativo italiano in materia di cybersecurity.

Attività e Scadenze per le Aziende

Le aziende rientranti nel campo di applicazione della direttiva dovranno affrontare una serie di obblighi e scadenze. Di seguito sono riportate le principali attività richieste:

1. Dal 18 ottobre 2024
   
   • l’Agenzia per la Cybersicurezza Nazionale dovrà mettere a disposizione un portale per le iscrizioni, le aziende che ritengo far parte dei soggetti che rientrano nella direttiva potranno e dovranno iscriversi.

   
   

2. Ogni anno dal 1 gennaio al 28 febbraio
   
   • Le aziende devono registrarsi o aggiornare la propria registrazione sulla piattaforma digitale, fornendo informazioni quali ragione sociale, recapiti, punto di contatto e settore di appartenenza.

   
   

3. Entro il 31 marzo di ogni anno
   
   • L’Agenzia per la Cybersicurezza Nazionale (ACN) redige l’elenco aggiornato dei soggetti registrati e comunica ai partecipanti la loro inclusione o permanenza nell’elenco, oppure la loro eventuale rimozione.

   
   

4. Dal 15 aprile al 31 maggio di ogni anno
   
   • Le aziende che hanno ricevuto una notifica dall’ACN devono fornire informazioni aggiornate sui propri indirizzi IP pubblici, i nomi a dominio utilizzati e i responsabili della sicurezza.

   
   

5. Dal 1 maggio al 30 giugno di ogni anno
   
   • Le aziende devono comunicare e aggiornare le informazioni relative alle attività e ai servizi forniti, includendo dettagli necessari per l’assegnazione di una categoria di rilevanza.

   
   

Conclusione

Il Decreto Legislativo di attuazione della direttiva (UE) 2022/2555 rappresenta un tassello fondamentale per la creazione di un ambiente digitale più sicuro e resiliente. Le aziende dovranno adeguarsi a una serie di nuovi obblighi che includono la gestione dei rischi informatici, la notifica tempestiva di incidenti e l’aggiornamento periodico delle informazioni sulla sicurezza. L’implementazione di queste misure non solo contribuirà a rafforzare la sicurezza delle infrastrutture critiche, ma promuoverà anche una maggiore fiducia nel mercato digitale europeo. Le scadenze previste richiedono un’attenta pianificazione e collaborazione tra aziende e autorità competenti, al fine di garantire un’efficace protezione contro le minacce informatiche emergenti​

L'articolo NIS2: il Decreto Legislativo di Attuazione della Direttiva (UE) 2022/2555 in ambito Italia proviene da il blog della sicurezza informatica.

European consumer groups on Thursday (12 September) accused the world's biggest video game companies of "purposefully tricking" consumers, including children, to push them to spend more.

euractiv.com/section/digital/n…

They don’t call slot machines one-armed bandits for nothing. And although it’s getting harder and harder to find slot machines with actual pull-able handles instead of just big buttons, you can easily simulate the handle at home with the right kind of limit switch, as [Andrew Smith] did with their micro slot machine.

This baby slot machine is built around the Adafruit 5×5 NeoPixel grid, which is an add-on for the QT Py. As you’ll see in the brief demo video after the break, the switch actuates on release, which starts the lights a-spinning. [Andrew] says the constraints of the SAMD21-powered QT Py made this a particularly fun challenge.

Whereas most physical slot machines have different reel sequences, this build uses just one. [Andrew] declared hex values to ID each color, and then created the reel manually with different color frequencies. When the lever is released, the columns are animated and slowly to come to rest at a random offset. You can check out the code on GitHub.

youtube.com/embed/NdhRO1JrY0I?…

hackaday.com/2024/09/11/2024-t…

EU antitrust chief Margrethe Vestager is concluding her mandate at the European Commission with two major victories as the top EU court ruled against Apple’s Irish tax arrangements and Google’s anti-competitive practices.

euractiv.com/section/digital/p…

One major flaw of designing societies around cars is the sheer amount of signage that drivers are expected to recognize, read, and react to. It’s a highly complex system that requires constant vigilance to a relatively boring task with high stakes, which is not something humans are particularly well adapted for. Modern GPS equipment can solve a few of these attention problems, with some able to at least show the current speed limit and perhaps an ongoing information feed of the current driving conditions., Trains, on the other hand, solved a lot of these problems long ago. [Philo] and [Tris], two train aficionados, were recently able to get an old speed indicator from a train and get it working in a similar way in their own car.

The speed indicator itself came from a train on the Red Line of the T, Boston’s subway system run by the Massachusetts Bay Transportation Authority (MBTA). Trains have a few unique ways of making sure they go the correct speed for whatever track they’re on as well as avoid colliding with other trains, and this speed indicator is part of that system. [Philo] and [Tris] found out through some reverse engineering that most of the parts were off-the-shelf components, and were able to repair a few things as well as eventually power everything up. With the help of an Arduino, an I/O expander, and some transistors to handle the 28V requirement for the speed indicator, the pair set off in their car to do some real-world testing.

This did take a few tries to get right, as there were some issues with the power supply as well as some bugs to work out in order to interface with the vehicle’s OBD-II port. They also tried to use GPS for approximating speed as well, and after a few runs around Boston they were successful in getting this speed indicator working as a speedometer for their car. It’s an impressive bit of reverse engineering as well as interfacing newer technology with old. For some other bits of train technology reproduced in the modern world you might also want to look at this recreation of a train whistle.

youtube.com/embed/KPlC6PoRjn8?…

hackaday.com/2024/09/11/train-…

A few years back NVIDIA created a dedicated cryptocurrency mining GPU, the CMP 170HX. This was a heavily restricted version of its flagship A100 datacenter accelerator, using the same GA100 chip. It was intended for accelerating Ethash, the Etherium proof-of-work algorithm, and nothing else. [niconiconi] bought one to use for accelerating PCB electromagnetic simulations and put a lot of effort into repairing the card, converting it to water-cooling, and figuring out how best to use this nobbled GPU.

Typically, the GA100 silicon sits in the center of the mighty A100 GPU card and would be found in a server rack, cooled by forced air. This was not an option at home, so an off-the-shelf water-cooling block was wedged in. During this process, [niconconi] found that the board wouldn’t power on, so they went on a deep dive into the power supply tree with the help of a leaked A100 schematic. The repair and modifications can be found in the appendix, right down to the end of the article. It is a long read to get there.

This Nvidia GA100 GPU is severely crippled on this board
NVIDIA has a history of deliberately restricting silicon in consumers’ hands to justify the hefty price tags of its offerings to big businesses, and this board is no different. The plan was to restrict the peak performance of the board to only applications with the same compute requirements as Ethash, specifically memory-intensive algorithms. The FP64 performance was severely limited, but instructions were not removed. This meant the code would run really badly, considering what the GPU is capable of.

The memory was limited to 8 GB, despite some A100 cards hosting a whopping 80 GB. The strategy was to use fuses to limit the crucial instructions, particularly the FP32 FMA and MAD instructions, which are used for multiply-add operations and are crucial for general computing applications. Finally, the PCIe bus was nobbled to run only as a Gen 1 interface with a single lane. They reduced the lane count by removing the coupling capacitors on the PCB, which meant they could just be added later, but it’s still only a slow interface.

[niconconi] went into great detail benchmarking the instruction types, keeping their EM simulation application in mind. After a few tweaks to make it work, they determined it was a good purchase. This article is worth reading for all those hardcore GPU nerds!

If you need a primer on GPU mining, we’ve got you covered. Once you’ve understood proof-of-work crypto, perhaps take a look at Chia?

Thanks to [gnif] for the tip!

hackaday.com/2024/09/11/hackin…

IBM got their PCs and PS/2 computers into schools in the 1980s and 1990s. We fondly remember educational games like Super Solvers: Treasure Mountain. However, IBM had been trying to get into the educational market long before the PC. In 1969, the IBM Schools Computer System Unit was developed. Though it never reached commercial release, ten were made, and they were deployed to pilot schools. One remained in use for almost a decade! And now, there’s a new one — well, a replica of IBM’s experimental school computer by [Menadue], at least. You can check it out in the video below.

The internals were based somewhat on the IBM System/360’s technology. Interestingly, it used a touch-sensitive keypad instead of a traditional keyboard. From what we’ve read, it seems this system had a lot of firsts: the first system to use a domestic TV as an output device, the first system to use a cassette deck as a storage medium, and the first purpose-built educational computer. It was developed at IBM Hursley in the UK and used magnetic core memory. It used BCD for numerical display instead of hexadecimal or octal, with floating point numbers as a basic type. It also used 32-bit registers, though they stored BCD digits and not binary. In short, this thing was way ahead of its time.

[Menadue] saw the machine at the IBM Hursley museum and liked it so much that he proceeded to build a prototype machine based partially on a document shown at the museum that showed the instructions. Further research revealed a complete document explaining the instruction set. The initial prototype was made on a small PCB with a Raspberry Pi Pico W, an OLED display, and key switches, which proved that he understood the system enough to replicate it.
An inside view
After that prototype, work began on the replica. It’s a half-scale model, but it does use a touch keyboard like the original. The attention to detail is nice, with the colours of the case matching and even a small IBM logo replica on the front! It’s made from a metal chassis, with the keyboard surround being plastic (as on the original) so as not to interfere with the touch keyboard. It’s programmed using the same set of instructions as the original — a combination of low-level commands, similar to assembly for microprocessors, but with an extra set of slightly higher-level instructions that IBM called Extra Codes. For a more in-depth explanation, check out the video going over the original system and the prototype replica!

youtube.com/embed/5U0TUGt13F4?…

Photos courtesy of IBM Hursley Museum

hackaday.com/2024/09/11/ibms-1…

This week Jonathan Bennett and Aaron Newcomb chat with Andreas Kling about Ladybird, the new browser in development from the ground up. It was started as part of SerenityOS, and has since taken on a life of its own. How much of the web works on it? How many people are working on the project? And where’s the download button? Listen to find out!

• awesomekling.com/
• ladybird.org/
• ladybird.org/posts/fork/
• ladybird.org/posts/announcemen…
• ladybird.org/posts/why-ladybir…

youtube.com/embed/ea086YeIrPA?…

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

hackaday.com/2024/09/11/floss-…

"se non si è ancora effettuato il check-in, è ammesso il cambio data e ora fino alle 23:59 del giorno precedente la data del viaggio, salvo diverse disposizioni regionali;

se non si è ancora effettuato il check-in, è ammesso il cambio ora fino alle 23:59 del giorno del viaggio, salvo diverse disposizioni regionali;"

da lefrecce.it/Channels.Website.W…
…confesso che ci ho messo unpo' a trovare la differenza

Oscilloscopes are one of our favorite tools for electronics development. They make the hidden dances of electrons visually obvious to us, and give us a clear understanding of what’s actually going on in a circuit.

The question few of us ever ask is, how do they work? Most specifically—how do you design a circuit that’s intended to measure another circuit? Aleksa Bjelogrlic has pondered that very idea, and came down to explain it all to us at the 2023 Hackaday Supercon.

All Up Front

youtube.com/embed/6kINL2e2XGs?…
Aleksa’s scope design had humble beginnings.
Aleksa has spent five years designing an open-source oscilloscope known as the ThunderScope. He wanted an oscilloscope that could measure a circuit while streaming out samples at speed to a computer, so he decided to build his own. His idea was to put the analog part of a high-speed scope in a box, while offloading the digital processing to an attached computer. This would allow the software side of things to be regularly updated to stay with the times. It would be easy to add new triggers or protocol decoders to the setup without having to mess with the hardware.

His early experiments saw him streaming samples from a test scope he built, but it wasn’t perfect. He used USB 3 Gen 1, but it was only giving him 350 MB/s transfer rates. He needed closer to 1 GB/sec to properly stream samples of high-speed signals. He also had issues with his front-end design, with poor frequency response. He soon switched over to PCI-Express for higher transfer rates, and built a new scope with a better front-end. This was the first revision of ThunderScope. Later revisions improved the front end further, tackled clock-generator issues, and generally refined the design into something more functional and useful.
The front end has been one of the main areas of improvement and revision as Aleksa has worked on the ThunderScope.
The development process is mere context, though. The real purpose of Aleksa’s talk was to dive into the nitty gritty of oscilloscope front-end designs. While his scope has had four major revisions, the front end has had over a dozen updates. The front end’s job is to take an analog signal, and finesse it into something that the scope’s analog-to-digital converter can actually handle. It’s job is, in part, to act as an electrical interface to allow the scope to measure all kinds of different signals. Aleksa explains that it can allow you to view AC signals superimposed on large DC voltages, or measure large signals beyond the voltage range of the scope’s ADC. It can also help scale signals that might otherwise be out of range for the ADC itself.

Aleksa explains input impedance, capacitance of the front end, and why you have to compensate a probe to suit your individual scope. He also covers the eternal challenge facing the designer—minimizing noise while maximising bandwidth, while also maintaining a flat response from DC all the way up to high frequency signals. And of course, you need to be able to measure and quantify how your front end is performing, so Aleksa dips into the basics in that regard.

AC and DC coupling is also covered. This is critical for when you want to look at an AC waveform without all that annoying DC bias in the way. Naturally, this is achieved with an in-line capacitor, which blocks DC while allowing the AC component to pass. Then there’s the helpful discussion about how resistors come with stray capacitance and inductance “for free”—and capacitors in turn come with resistance and inductance, too. When you’re chasing around weird dips in your response curve, you’ve got to be across these things.
That’s a horrifying response curve, but Aleksa was eventually able to track down the culprit and eliminate the dip.
If you’ve ever considered creating your own oscilloscope from scratch, Aleksa’s talk is a great primer. It’s really useful stuff. After all, getting the front end right is as important as getting the right tires on your car. If it’s not up to the task, all your measurements will be suspect from the drop. It’s a deep and rich topic, and one that you could spend years studying in detail. Indeed, Aleksa has, and his work on the ThunderScope is the ultimate proof of that.

hackaday.com/2024/09/11/superc…

La Cybersecurity and Infrastructure Security Agency ( CISA ) degli Stati Uniti D’America ha emesso un avvertimento su tre pericolose vulnerabilità che vengono attivamente sfruttate dagli aggressori. Questi errori minacciano molti programmi e sistemi popolari, creando seri rischi per organizzazioni e utenti.

La prima vulnerabilità, CVE-2016-3714 (punteggio CVSS: 8,4), colpisce ImageMagick, un popolare pacchetto software di elaborazione delle immagini. Il problema è legato a un’insufficiente convalida dei dati di input, che porta alla possibilità di esecuzione di codice arbitrario nel sistema durante l’elaborazione di un’immagine appositamente predisposta.

Una seconda vulnerabilità, CVE-2017-1000253 (punteggio CVSS: 7,8), è stata scoperta nel kernel Linux. È correlato alla corruzione del buffer dello stack nella funzione load_elf_binary(). Lo sfruttamento di questa falla consente a un utente malintenzionato locale di aumentare i privilegi e ottenere l’accesso non autorizzato ai dati critici del sistema.

La terza vulnerabilità, CVE-2024-40766 (punteggio CVSS: 9,8), colpisce il sistema operativo SonicWall SonicOS, utilizzato nei firewall. Una falla nel controllo degli accessi consente agli aggressori di accedere alle risorse di sistema e causare il crash del firewall. Nonostante la mancanza di informazioni sui possibili casi di utilizzo della vulnerabilità negli attacchi, il suo impatto sulla sicurezza della rete rimane critico.

La CISA consiglia di installare urgentemente gli aggiornamenti forniti dagli sviluppatori o di rifiutarsi di utilizzare software vulnerabile se non sono disponibili soluzioni. Il termine ultimo per l’attuazione delle misure è il 30 settembre 2024.

L’agenzia sottolinea la necessità di attuare rapidamente misure di protezione e aggiornamenti. Si consiglia alle organizzazioni di non ritardare l’aggiornamento dei propri sistemi per prevenire possibili attacchi informatici e violazioni dei dati.

L'articolo Dal CISA tre bug di sicurezza che devono essere risolti entro il 30 Settembre proviene da il blog della sicurezza informatica.

Following in the tracks of unconventional science projects, [The Thought Emporium] seeks to answer the question of whether you can use a potato as a photograph recording medium. This is less crazy than it sounds, as ultimately analog photographs (and photograms) is about inducing a light-based change in some kind of medium, which raises the question of whether there is anything about potatoes that is light-sensitive enough to be used for capturing an image, or what we can add to make it suitable.

Unfortunately, a potato by itself cannot record light as it is just starch and salty water, so it needs a bit of help. Here [The Thought Emporium] takes us through the history of black and white photography, starting with a UV-sensitive mixture consisting out of turmeric and rubbing alcohol. After filtration and staining a sheet of paper with it, exposing only part of the paper to strong UV light creates a clear image, which can be intensified using a borax solution. Unfortunately this method fails to work on a potato slice.

The next attempt was to create a cyanotype, which involves covering a surface in a solution of 25 g ferric ammonium oxalate, 10 g of potassium ferricyanide and 100 mL water and exposing it to UV light. This creates the brilliant blue that gave us the term ‘blueprint’. As it turns out, this method works really well on potato slices too, with lots of detail, but the exposure process is very slow.

Speeding up cyanotype production is done by spraying the surface with an ammonium oxalate and oxalic acid solution to modify the pH, exposing the surface to UV, and then spraying it with a 10 g / 100 mL potassium ferricyanide solution, leading to fast exposure and good details.

This is still not as good on paper as an all-time favorite using silver-nitrate, however. These silver prints are the staple of black and white photography, with the silver halide reacting very quickly to light exposure, after which a fixer, like sodium thiosulfate, can make the changes permanent. When using cyanotype or silver-nitrate film like this in a 35 mm camera, it does work quite well too, but of course creates a negative image, that requires inverting, done digitally in the video, to tease out the recorded image.

Here the disappointment for potatoes hit, as using the developer with potatoes was a soggy no-go. Ideally a solution like that used with direct positive paper that uses a silver solution suspended in a gel, but creates a positive image unlike plain silver-nitrate. As for the idea of using the potato itself as the camera, this was also briefly attempted to by using a pinhole in a potato and a light-sensitive recording surface on the other side, but the result did indeed look like a potato was used to create the photograph.

youtube.com/embed/BlWyKKJF0r4?…

hackaday.com/2024/09/11/using-…

Everyone loves, and should respect, lithium-ion batteries. They pack a ton of power and can make our projects work better. I’ve gathered a number of tips and tricks about using them over the years, based on my own hacking and also lessons I’ve learned from others.

This installment includes a grab-bag of LiIon tricks that will help you supercharge your battery use, avoid some mistakes, and make your circuits even safer. Plus, I have a wonderful project that I just have to share.

Hot-swapping Cells

When your device runs out of juice, you might not always want to chain yourself to a wall charger. Wouldn’t it be cool if you could just hot-swap cells? Indeed it is, I’ve been doing it for years, it’s dead simple to support, but you can also do it wrong. Let me show you how to do it right!

Recently, a new handheld has hit the hacker markets – the Hackberry Pi. With a Blackberry keyboard and a colour screen, it’s a pretty standard entry into the trend of handheld Pi Zero-backed computers with Blackberry keyboards. It’s not open-source and the author does not plan to open-source its hardware, so I want to make it absolutely clear I don’t consider it hacker-friendly or worth promoting. It did publish schematics, though, and these helped me find a dangerous mistake that the first revision made when trying to implement LiIon battery hot-swap.
This is not how you connect batteries in parallel,
It uses BL-5C cells, which are widely available as aftermarket batteries for Nokia phones. It’s a smart choice, though it’s worth remembering that vendors constantly inflate the capacity on the label, and my gut feel is that the more inflated the number is, the more shady the cell you’re getting. Remember, there’s a physical limit to the capacity you can shove into a certain cell volume, with 18650s limited to about 3500 mAh, as the market offerings show. (And if you try to put more capacity into a cell of certain volume, you get the Galaxy Note 7. Ahem.)

The batteries in the Hackberry Pi should be hot-swappable – no supercaps, they’re just in parallel with nothing in between the cells. Nothing in between? Question – what happens when you connect two batteries, one charged and one discharged, in parallel? Remember, LiIon batteries can give out a ton of current, and phone batteries doubly so due to the GSM modem peak current requirements. Decent voltage difference, very low resistance – you get a lot of current flowing, discharging the full cell needlessly or causing a brownout at best, and charring PCB tracks at worst.
but just two more components make it a fair bit better.
The easy solution is to use PTC resettable fuses in series with the positive or negative terminal, either between each cell, or just one between two cells. If current surges sharply, the fuse will heat up and increase its resistance, limiting the current.

But remember, a fuse’s current rating is deceiving, and a 2 A fuse won’t actually trip at exactly 2.1 A. This is beneficial for you, though – while doing hotswap, one cell will have to produce twice the current than normally, even if for a short moment. Also, remember to size the cell protection fuse not just for device consumption, but also the charging current it will receive!

It’s certain that the new Hackberry Pi revision will fix this, and if you have the first revision, just swap batteries carefully and you will be 100% fine. Hotswap doesn’t have to be complicated – now you all know how to do a very simple form of it. Oh, and, having adding the fuse, you can easily get a good few extra features with only a few components, like, say, polarity protection!

The Polarity Hacks

With 18650 holders, it’s easy to insert a cell the wrong way by accident – I’ve burned out a good few boards like that, spending precious hours and dollars replacing burned out components. A 18650 cell holds a ton of energy and can burn out a lot of silicon very easily. Or if you’re using pouch cells using JST-PH connectors, you have to watch out for two polarity conventions. In short, polarity reversal is a real risk. How do you protect from it?

The reverse polarity crowbar circuit is a dead simple way to add polarity protection – all you need is a diode across the battery, placed after the fuse, flipped in a way that it will conduct when the polarity is wrong, tripping the fuse before any circuitry is damaged. The diode’s rating has to be higher than the fuse’s trip point – otherwise, the diode will burn out before the fuse trips, negating the circuit. I’ve tested this, it works, it’s now being manufactured in hundreds.

You might also want the user, whether you or someone else (especially someone else!) to quickly notice that the polarity is flipped. The solution is simple – add a LED and a resistor flipped in a way it lights up when the cell is reversed, before the fuse. Use a red or orange LED to make it crystal clear that something is wrong; don’t use green or blue, or any colours that often mean “the device is working normally”; add silkscreen markings to indicate that this is a “wrong polarity” LED.

Back to cells with JST-PH connectors. Are you developing a project that will get into hackers’ hands, and you don’t want to have them rewire their entire LiIon cell arsenal just for your device? Thankfully, 0 R resistors save the day; it’s dead simple to add two pairs of 0603 0R’s next to a JST-PH 2-pin connector. Make one polarity the default, and leave the option of switching the polarity in there. Again, this goes before the fuse, and before the reverse polarity LED, too. Of course, your users will have to make sure the red wire goes to positive, but at least you’re helping them get there.

This quickly, we have dealt with a number of polarity problems, using barely any components, all of them cheap, no fancy ICs. Your boards deserve to be fail-proof, serving you no matter the mistakes you make.

A New 18650 Holder Enters The Scene

Leaf contact holders are great. Unlike spring holders, they’re low-inductance, high-current, resillient to shocks, reliable, and cheap to find. Unfortunately, the leaf often catches on the cell’s heatshrink ends when you unplug the battery, slowly tearing it off piece by piece, and at some point even causing the positive terminal protective ring to detach – which risks a massive short-circuit as you unplug the battery or just drop the holder hard enough. Not great!

I’ve developed a pretty unique holder for 18650s, that I currently use for a pretty substantial portable device project of mine. It’s got all the advantages of spring holders, but it wraps around the battery fully, protecting it from shocks and the elements, and closes with a twist-on locking cap. Plus, it’s belt-mountable, thanks to a 3D-printed holder. It lends itself wonderfully to hotswap, too! Most of all, it’s fully 3D printable. All you need is some threaded inserts and some leaf contacts from Keystone that I found on Mouser – a baggie with 25 of them is quite cheap, and worth the money. (Remember to scroll through categories for things like battery contacts, you will find cool stuff!) There are definitely drawbacks to this type of holder, but it’s seriously great.
Just a few threaded inserts and screws, and off you go!
It’s parametric, designed in FreeCAD, so you can change a fair few parameters without breaking a sweat. The holder is designed for quick swap – just twist the cap and the battery falls out. Swapping 18650 cells is a cakewalk. High current consumption: tested; portability: tested; not damaging the cell wrappers: tested. I’ve been actively using these holders for about nine months now – they fulfilled their purpose and far more.

There’s something that makes it feel like military equipment, but I can assure you that it’s not designed by the lowest bidder. Put these on a belt, screw these into a project, or slap two of them together back to back – maybe even lengthen it and use three cells in series! Thanks to someone’s advice from Twitter, there are also vent holes at the positive terminal’s place. (Of course, if your cell starts venting, you have a big problem on your hands no matter what you’re using.) Still, it’s got these holes, in addition to ten other features. And it’s printable vertically with no supports.

Are there possible failure modes? Absolutely. The main one is the cylinder breaking across the layer lines under pressure, especially if you drop it. I’ve tried printing the holder laying down, so that layer lines are aligned differently, but cleaning the tube from internal supports is damn brutal and the tolerances for the 18650 inside are pretty tight. I’m going to pick up a roll of PLA-Plus, since it supposedly is more strong, and print a new set of holders. If you print it, let us know!

Another failure mode is the spring’s compressing over time. I might be overcompressing the metal, so I just ought to check the datasheets and adjust the width. Of course, strong compression is a plus, but it’s of no use if the holder starts being super bump-sensitive after a few months of use. Last but not least, the positive wire is a failure point, though the channel i’ve recently introduced mostly fixes that.

More To Come

There are a few additions in the queue for the v3 holder. One is unifying the threaded inserts so that you don’t have to buy too many different ones, and improving mounting for the belt holster to limit the molten plastic backflow. Another is adding strips on the side that’d be a base for a long metal plate, which would acts as extra backing for the 18650 holder. The only problem is finding a suitable metal plate – flat, 70 mm long, about 4 mm wide, with screw holes alongside, or, at least, on both ends. Anyone have any ideas, especially if it’s something commonly found that can be repurposed?

I’m currently working on a custom PCB for this holder – involving protection, fuse holding, reverse polarity protection and warning LED, and maybe even an opamp circuit for roughly measuring the battery voltage. In short, including all of the tips shared here.

What are your favorite tricks for using lithium batteries?

Dopo tre anni di sviluppo, il team Flipper Zero ha annunciato il rilascio di una nuova versione firmware (1.0). L’aggiornamento include un nuovo sottosistema NFC, supporto JavaScript, caricamento dinamico di applicazioni di terze parti e molto altro.

Come scrive Pavel Zhovner nel suo canale Telegram : “Questa è la versione principale in 3 anni di sviluppo. In esso speriamo di sistemare le principali API per gli sviluppatori e di non interrompere le cose fondamentali per qualche tempo.”

Molte le differenze e i miglioramenti

Gli sviluppatori affermano che il nuovo firmware implementa 89 protocolli radio, 20 protocolli RFID e aggiunge 4 tipi di telecomandi IR universali. Anche Bluetooth e NFC sono stati accelerati, è apparso il supporto JavaScript, è apparso il caricamento dinamico di applicazioni di terze parti e la durata della batteria del dispositivo in modalità standby è ora di un mese.

Sebbene alcune delle funzionalità elencate dagli sviluppatori fossero già presenti nelle versioni precedenti del firmware Flipper Zero, potrebbero non funzionare in modo molto stabile e gli utenti potrebbero riscontrare problemi. La versione attuale dovrebbe fornire maggiore stabilità e prestazioni migliori.

In un post dedicato al rilascio del firmware 1.0, il team di Flipper Zero evidenzia le seguenti caratteristiche chiave.

Uno sguardo alle nuove funzionalità

• Caricamento dinamico delle app : gli utenti potranno installare app sviluppate dalla community da un catalogo, risparmiando memoria di sistema eseguendo app dai file FAP (Flipper Application Package) sulla scheda microSD.

• Aggiornamento del sottosistema NFC : NFC è stato riscritto poiché gli sviluppatori hanno completamente riprogettato la libreria RFAL, migliorando la velocità di lettura delle carte, aggiungendo il supporto per nuovi tipi di carte (ad esempio, ICODE® SLIX, FeliCa™ Lite-S) e anche attivando il plug-in nel sistema. E i dump delle carte MIFARE Classic® possono ora essere visualizzati e modificati direttamente nell’applicazione mobile Flipper.

• Supporto JavaScript : Flipper Zero ora supporta JavaScript, il che dovrebbe rendere lo sviluppo di app più accessibile. Come scrive Pavel Zhovner: “Per ora le funzioni API non raggiungono ciò che può essere fatto tramite C/C++, ma gradualmente diventerà più interessante.”

• Miglioramenti sub-GHz : aggiunto il supporto per 89 protocolli radio, la possibilità di ascoltare radio analogiche e un nuovo formato file BinRAW per un’archiviazione e uno scambio di segnali più efficienti.

• Miglioramenti IR : sono presenti nuovi telecomandi IR universali per vari dispositivi (TV, condizionatori, sistemi audio e proiettori) e supporto per apparecchiature IR esterne con LED più potenti.
• Miglioramenti generali del sistema: la durata della batteria ora raggiunge un mese in modalità standby. Le velocità di trasferimento Bluetooth con i dispositivi Android sono aumentate fino a due volte e gli aggiornamenti del firmware vengono ora scaricati il ​​40% più velocemente tramite Bluetooth (il programma di aggiornamento Flipper Zero supporta l’ algoritmo di compressione heatshrink ).

• Miglioramenti IR : sono presenti nuovi telecomandi IR universali per vari dispositivi (TV, condizionatori, sistemi audio e proiettori) e supporto per apparecchiature IR esterne con LED più potenti.
• Miglioramenti generali del sistema: la durata della batteria ora raggiunge un mese in modalità standby. Le velocità di trasferimento Bluetooth con i dispositivi Android sono aumentate fino a due volte e gli aggiornamenti del firmware vengono ora scaricati il ​​40% più velocemente tramite Bluetooth (il programma di aggiornamento Flipper Zero supporta l’ algoritmo di compressione heatshrink ).

Sul sito Flipper Zero è già disponibile la versione firmware 1.0 , e la sua installazione è possibile sia via Bluetooth da dispositivo mobile che da computer utilizzando l’applicazione qFlipper.

L'articolo Flipper Zero rilascia il Firmware 1.0! Tutto un altro Mondo per fare Hacking proviene da il blog della sicurezza informatica.

Il team di Malwarebytes ha scoperto che il gruppo ransomware RansomHub utilizza lo strumento legittimo TDSSKiller per disabilitare gli strumenti EDR su un dispositivo. Oltre a TDSSKiller, i criminali informatici utilizzano anche LaZagne per raccogliere dati. Questi programmi sono conosciuti da tempo tra i criminali informatici, ma questa è la prima volta che vengono utilizzati da RansomHub. LaZagne è un’utilità per estrarre password da varie applicazioni e sistemi, che può aiutare nei test di penetrazione.

TDSSKiller, originariamente sviluppato da Kaspersky Lab per rimuovere i rootkit, è stato utilizzato per disabilitare i sistemi EDR. Dopo aver condotto una ricognizione e identificato gli account con privilegi elevati, RansomHub ha tentato di disabilitare il servizio di sicurezza MBAMService.

Lo strumento è stato eseguito da una directory temporanea utilizzando un nome file generato dinamicamente per rendere difficile il rilevamento. Poiché TDSSKiller è un programma legittimo con un certificato valido, molti sistemi di sicurezza non riconoscono che gli hacker criminali stanno effettuando azioni malevole.

Dopo aver disabilitato i sistemi di sicurezza, RansomHub ha lanciato lo strumento LaZagne per raccogliere credenziali dai sistemi infetti. Il programma estrae le password da varie applicazioni come browser, client di posta elettronica e database, consentendo agli aggressori di aumentare i propri privilegi e spostarsi lateralmente attraverso la rete. In questo caso l’obiettivo dei criminali informatici era quello di ottenere l’accesso alla banca dati che permettesse di controllare i sistemi critici.

Durante l’attacco, LaZagne ha creato più di 60 file, la maggior parte dei quali conteneva login e password. Per nascondere le tracce del programma, gli hacker hanno anche cancellato alcuni file una volta completata l’operazione.

Rilevare LaZagne è abbastanza semplice, poiché la maggior parte dei programmi antivirus lo contrassegna come malware. Tuttavia, se TDSSKiller veniva utilizzato per disabilitare i sistemi di protezione, l’attività del programma diventa invisibile alla maggior parte degli strumenti.

ThreatDown incoraggia le organizzazioni a prendere ulteriori precauzioni per proteggersi da tali attacchi. In particolare, si consiglia di limitare l’uso di driver vulnerabili come TDSSKiller e monitorare i comandi sospetti utilizzati sui sistemi. È inoltre importante segmentare la rete e isolare i sistemi critici per ridurre al minimo il rischio che le credenziali vengano compromesse.

L'articolo Quando l’Antivirus diventa un’Arma! RansomHub utilizza TDSSKiller per infiltrarsi nelle reti proviene da il blog della sicurezza informatica.

After 47 years it’s little wonder that the hydrazine-powered thrusters of the Voyager 1, used to orient the spacecraft in such a way that its 3.7 meter (12 foot) diameter antenna always points back towards Earth, are getting somewhat clogged up. As a result, the team has now switched back to the thrusters which they originally retired back in 2018. The Voyager spacecraft each have three sets (branches) of thrusters. Two sets were originally intended for attitude propulsion, and one for trajectory correction maneuvers, but since leaving the Solar System many years ago, Voyager 1’s navigational needs have become more basic, allowing all three sets to be used effectively interchangeably.

The first set was used until 2002, when clogging of the fuel tubes was detected with silicon dioxide from an aging rubber diaphragm in the fuel tank. The second set of attitude propulsion thrusters was subsequently used until 2018, until clogging caused the team to switch to the third and final set. It is this last set that is now more clogged then the second set, with the fuel tube opening reduced from about 0.25 mm to 0.035 mm. Unlike a few decades ago, the spacecraft is much colder due energy-conserving methods, complicating the switching of thruster sets. Switching on a cold thruster set could damage it, so it had to be warmed up first with its thruster heaters.

The conundrum was where to temporarily borrow power from, as turning off one of the science instruments might be enough to not have it come back online. Ultimately a main heater was turned off for an hour, allowing the thruster swap to take place and allowing Voyager 1 to breathe a bit more freely for now.

Compared to the recent scare involving Voyager 1 where we thought that its computer systems might have died, this matter probably feels more routine to the team in charge, but with a spacecraft that’s the furthest removed man-made spacecraft in outer space, nothing is ever truly routine.

hackaday.com/2024/09/11/voyage…