Ever tear open a potentiometer? If you haven’t, you can still probably guess what’s inside. A streak of resistive material with some kind of contact that moves across it as you rotate the shaft, right? Usually, you’d be right, but [T. K. Hareedran] writes about a different kind of pot: ones that use magnetic sensing.

Why mess with something simple? Simplicity has its price. Traditional units may not be very accurate, can be prone to temperature and contamination effects, and the contact will eventually wear out the resistive strip inside. However, we were a little curious about how a magnetic potentiometer could offer a resistive output. The answer? It doesn’t.

Really, these would be better described as rotary encoders with a voltage output. They aren’t really potentiometers. The SK22B mentioned in the article, for example, requires a 5 V input and outputs somewhere between 10% and 90% of that voltage on the ersatz wiper pin.

That makes the devices much easier to puzzle out. The linearity of a device like that is better than a real pot, and, of course, the life expectancy is greatly increased. On the other hand, we’d rather get one with quadrature or I2C output and read it digitally, but if you need a voltage, these devices are certainly an option.

[T. K.] goes on to show how he fabricated his own non-contact sensor using photosensors and a gray-coded wheel with a single track. You do need to be careful about where you position the sensors, though.

Could you make a real non-contact resistive pot? Seems like you could get close with an FET output stage, but it wouldn’t be as generally applicable as a good old-fashioned smear of carbon. If you have a better idea, drop it in the comments or build it and give us a tip.

Want a 20A-capable device? Build it. Want to see how we like to read encoders?

hackaday.com/2025/09/06/faux-p…

For something non-explosive, this might be the most American project we’ve featured in a while. [Makerinator]’s domestic bliss was apparently threatened by the question “what shall we have for dinner”– that’s probably pretty universal. Deciding that the solution was automation is probably universal to software devs and associated personalities the world over. That the project, aptly called “The Decisioninator” apes a popular game-show mechanic to randomly select a fast-food restaurant? Only people with 100-octanes of freedom running through their veins can truly appreciate its genius.

In form factor, it’s a tiny slot machine which [Makerinator] fabbed up on his laser cutter. The lovely “paintjob” was actually a print out with dye-sublimation ink that was transferred to plywood before laser cutting. Mounted to this are illuminated arcade buttons and a small ISP display. The interface is simplicity itself: the big button spins a virtual “wheel” on the display (with sound effects inspired by The Price is Right) to tell the family what deliciously unhealthy slop they’ll be consuming, while the other button changes decision modes. Of course you can pick more than just dinner with The Decisioninator. You need only decide what spinners to program. Which, uh, that might be a problem.

Luckily [Makerinator] was able to come up with a few modes without recursively creating a The Decisioninator-inator. He’s got the whole thing running on a Pi4, which, with its 1980s supercomputer performance, is hilariously overpowered for the role it plays (in true American fashion). He’s coded the whole thing in the Flame Engine, which is a game engine built on the Flutter UI toolkit by American technology giant Google.

What’s more American than tech giants and fast food? A propane powered plasma cannon, for one thing; or maybe mental gymnastics to translate into freedom units, for another.

Thanks to [Makerinator] for the tip.

hackaday.com/2025/09/05/the-de…

Uno specialista di sicurezza indipendente, noto con il nickname BobDaHacker, ha scoperto delle falle di sicurezza in Pudu Robotics (il principale fornitore mondiale di robot di servizio commerciali). Le vulnerabilità consentivano agli aggressori di reindirizzare i robot in qualsiasi posizione e costringerli a eseguire comandi arbitrari.

Pudu Robotics è un’azienda cinese produttrice di robot che svolgono compiti che vanno dal servire il cibo nei ristoranti con BellaBot alla gestione di sistemi progettati dall’uomo come gli ascensori con FlashBot. Secondo Frost & Sullivan, l’azienda ha detenuto una quota di mercato del 23% per questi dispositivi lo scorso anno.

BobDaHacker ha scoperto di poter accedere al software di controllo dei bot perché l’accesso amministrativo non era bloccato. Per eseguire questo attacco, l’aggressore aveva bisogno di un token di autorizzazione valido, che poteva essere ottenuto tramite cross-site scripting o semplicemente creando un account di prova, progettato per testare i bot prima di acquistarli.

Dopo l’autenticazione iniziale, non sono stati effettuati ulteriori controlli di sicurezza, consentendo a chiunque di modificare gli ordini, spostare i robot in nuove posizioni e rinominarli per rendere più difficile il ripristino dopo un attacco.

In altre parole, l’aggressore è stato in grado di reindirizzare il cibo ordinato verso destinazioni arbitrarie o persino di disabilitare l’intera flotta di robot da ristorante. Il ricercatore osserva inoltre che gli aggressori potrebbero costringere FlashBot a danneggiare i sistemi dell’ufficio o a rubare proprietà intellettuale.

Quando il ricercatore ha provato a contattare i rappresentanti di Pudu Robotics per informarli del problema, non ha ricevuto risposta. Così, il 12 agosto, BobDaHacker ha inviato le prime e-mail, ma i reparti di assistenza tecnica, supporto e vendite non hanno risposto. Dopo aver atteso fino al 21 agosto, lo specialista ha inviato nuovamente nuove e-mail, contattando più di 50 dipendenti dell’azienda nel tentativo di attirare l’attenzione di almeno qualcuno.

Non avendo ricevuto risposta, il ricercatore ha contattato i clienti dei ristoranti di Pudu Robotics; la catena di ristoranti giapponese Skylark Holdings e la catena Zensho hanno preso sul serio gli avvertimenti.

Circa 48 ore dopo che BobDaHacker aveva contattato i clienti, Pudu Robotics ha finalmente risposto alla sua email. Tuttavia, l’esperto ha scritto che la risposta era chiaramente stata scritta da ChatGPT. “Non si sono nemmeno preoccupati di rimuovere il segnaposto nel modello di ChatGPT. È semplicemente uno sforzo incredibile”, ha affermato l’esperto.

L’azienda ha ringraziato lo specialista per aver scoperto le vulnerabilità con il seguente messaggio: “Grazie per il vostro prezioso contributo alla nostra sicurezza. Se desiderate condividere maggiori dettagli o avete domande, non esitate a contattarmi direttamente”, ha scritto il rappresentante dell’azienda.

Tuttavia, da allora Pudu Robotics ha risolto le vulnerabilità individuate dal ricercatore e ha messo in sicurezza i propri sistemi.

Il 3 settembre, BobDaHacker ha aggiornato il suo post e ha riferito che, a quanto pare, l’azienda non aveva ignorato i suoi messaggi. Le prime email non erano effettivamente arrivate ai destinatari previsti, ma una segnalazione dei problemi era stata successivamente ricevuta tramite altri canali. Successivamente, gli sviluppatori hanno iniziato a lavorare a una soluzione, ma l’azienda ha contattato il ricercatore solo quando la correzione era pronta per essere implementata..

L'articolo Robot da ristorante hackerabili: potevano servire il sushi… a casa dell’attaccante proviene da il blog della sicurezza informatica.

I sistemi di intelligenza artificiale sono stati criticati per aver creato report di vulnerabilità confusi e per aver inondato gli sviluppatori open source di reclami irrilevanti. Ma i ricercatori dell’Università di Nanchino e dell’Università di Sydney hanno un esempio del contrario: hanno presentato un agente chiamato A2, in grado di trovare e verificare le vulnerabilità nelle applicazioni Android, simulando il lavoro di un bug hunter. Il nuovo sviluppo è la continuazione del precedente progetto A1, che era in grado di sfruttare i bug negli smart contract.

Gli autori affermano che A2 ha raggiunto una copertura del 78,3% sulla suite di test Ghera , superando l’analizzatore statico APKHunt, che ha ottenuto solo il 30%. Eseguito su 169 APK reali, ha rilevato 104 vulnerabilità zero-day, di cui 57 confermate da exploit funzionanti generati automaticamente. Tra queste, un bug di media gravità in un’app con oltre 10 milioni di installazioni. Si trattava di un problema di reindirizzamento intenzionale che ha permesso al malware di prendere il controllo.

La caratteristica distintiva principale di A2 è il modulo di convalida, assente nel suo predecessore.

Il vecchio sistema A1 utilizzava uno schema di verifica fisso che valutava solo se un attacco avrebbe portato profitto. A2, invece, è in grado di confermare una vulnerabilità passo dopo passo, suddividendo il processo in attività specifiche. A titolo di esempio, gli autori citano uno scenario con un’applicazione in cui la chiave AES era memorizzata in chiaro. L’agente trova prima la chiave nel file strings.xml, quindi la utilizza per generare un token di reimpostazione della password falso e infine verifica che questo token bypassi effettivamente l’autenticazione. Tutte le fasi sono accompagnate da verifica automatica: dalla corrispondenza dei valori alla conferma dell’attività dell’applicazione e alla visualizzazione dell’indirizzo desiderato sullo schermo.

Per funzionare, A2 combina diversi modelli linguistici commerciali : OpenAI o3, Gemini 2.5 Pro, Gemini 2.5 Flash e GPT-oss-120b. Sono distribuiti in base ai ruoli: il pianificatore elabora una strategia di attacco, l’esecutore esegue le azioni e il validatore conferma il risultato. Questa architettura, secondo gli autori, riproduce la metodologia umana, il che ha permesso di ridurre il rumore e aumentare il numero di risultati confermati. Gli sviluppatori sottolineano che gli strumenti di analisi tradizionali producono migliaia di segnali insignificanti e pochissime minacce reali, mentre il loro agente è in grado di dimostrare immediatamente la sfruttabilità di un errore.

I ricercatori hanno anche calcolato il costo del sistema. Il rilevamento delle vulnerabilità costa tra 0,0004 e 0,03 dollari per app utilizzando modelli diversi, mentre un ciclo completo con verifica costa in media 1,77 dollari. Allo stesso tempo, se si utilizza solo Gemini 2.5 Pro, il costo aumenta a 8,94 dollari per bug. A titolo di confronto, l’anno scorso un team dell’Università dell’Illinois ha dimostrato che GPT-4 crea un exploit a partire dalla descrizione di una vulnerabilità per 8,80 dollari. Si scopre che il costo per individuare e confermare le falle nelle app mobili è paragonabile al costo di una vulnerabilità di media gravità nei programmi bug bounty, dove le ricompense sono calcolate in centinaia e migliaia di dollari.

Gli esperti sottolineano che A2 supera già le prestazioni degli analizzatori statici di programmi Android e A1 si avvicina ai migliori risultati negli smart contract. Sono fiduciosi che questo approccio possa accelerare e semplificare il lavoro sia dei ricercatori che degli hacker, perché invece di sviluppare strumenti complessi, è sufficiente richiamare l’API di modelli già addestrati. Tuttavia, rimane un problema: i cacciatori di ricompense possono utilizzare A2 per un rapido arricchimento, ma i programmi di ricompensa non coprono tutti i bug. Questo lascia delle scappatoie per gli aggressori che possono utilizzare direttamente gli errori trovati.

Gli autori dell’articolo ritengono che il settore stia appena iniziando a svilupparsi e che ci si possa aspettare un’impennata di attività sia negli attacchi difensivi che in quelli offensivi nel prossimo futuro. I rappresentanti del settore sottolineano che sistemi come A2 spostano le ricerche di vulnerabilità da allarmi infiniti a risultati confermati, riducendo il numero di falsi positivi e consentendo di concentrarsi sui rischi reali.

Per ora, il codice sorgente è disponibile solo per i ricercatori con partnership ufficiali, per mantenere un equilibrio tra scienza aperta e divulgazione responsabile.

L'articolo L’AI A2 ha rilevato 102 bug 0day e creato exploit nelle app Android a 1,77 dollari proviene da il blog della sicurezza informatica.

Nel panorama attuale della cybersecurity, le minacce si muovono sempre più rapidamente e con maggiore sofisticazione. I tradizionali strumenti di difesa non bastano più a garantire visibilità completa, soprattutto quando l’attacco non lascia tracce evidenti sugli endpoint o sfrutta tecniche fileless. In questo contesto si afferma il concetto diNetwork Detection and Response (NDR): una tecnologia progettata per rilevare comportamenti anomali all’interno del traffico di rete e attivare contromisure intelligenti.

Ma cos’è esattamente un NDR? Come funziona? E perché rappresenta una componente sempre più cruciale nella strategia di sicurezza aziendale?

Cos’è il Network Detection and Response

IlNetwork Detection and Responseè un sistema avanzato di monitoraggio e analisi del traffico di rete in grado di individuare, in tempo reale, attività sospette o malevole che sfuggono ai tradizionali controlli basati su firme o agent.

A differenza degli strumenti perimetrali tradizionali, l’NDR osserva il comportamento interno alla rete (trafficoest-ovest) e i flussi in uscita (nord-sud) per identificare anomalie indicative di compromissione: esfiltrazioni di dati, movimenti laterali, beaconing verso server di controllo (Command & Control), e molto altro.

L’obiettivo è chiaro:rilevare attacchi in corso anche in assenza di segnali evidenti, e rispondere prima che causino danni.

Come funziona un NDR

Un sistema NDR si basa su tre pilastri tecnologici:

Deep packet Inspection (DPI)
Analizza in profondità i pacchetti di rete, estraendo informazioni dettagliate su protocolli, payload e pattern di comunicazione.

1. Machine Learning e Behavioural Analytics
   Crea un modello del comportamento “normale” all’interno della rete, rilevando automaticamente deviazioni sospette che potrebbero indicare una minaccia.
2. Threat Intelligence e Indicatori di Compromissione (IOC)
   Confronta indirizzi IP, URL, certificati e altri metadati con blacklist note, fonti OSINT e feed di intelligence aggiornati.

Il risultato è unasorveglianza costante e invisibile, capace di riconoscere segnali deboli che potrebbero preludere a un attacco complesso.

Perché adottare un NDR

L’NDR non è un semplice strumento di controllo: è unarisorsa strategicaper qualunque azienda che voglia proteggere i propri asset digitali in modo proattivo.

Ecco perché:

• visibilità estesa: monitora tutti i flussi, anche tra dispositivi non gestiti o privi di agent;
• rilevamento in tempo reale: individua minacce sofisticate prima che causino danni;
• riduzione del dwell-time: accorcia il tempo medio di permanenza dell’attaccante nella rete;
• complementarietà con EDR/SIEM: fornisce una prospettiva unica e integrabile nelle architetture esistenti;
• adattabilità: si applica a contesti IT classici, ambienti OT, reti cloud e ibride.

In particolare, l’NDR è cruciale per contesti ad alta criticità (sanità, manifattura, infrastrutture OT) dove dispositivi non monitorabili direttamente – come PLC, HMI, SCADA – rappresentano un punto debole.

LECS: l’NDR evoluto, invisibile, adattivo

Nel panorama delle soluzioni NDR,LECSoffre un approccio radicalmente innovativo con il suo modulo proprietarioSpecto.

Progettato per unasorveglianza continua e non intrusiva, Specto analizza tutto il traffico in transito, impiegando tecniche proprietarie diHidden Analysise un motore AI avanzato integrato con la piattaformaTiresia.

Le caratteristiche distintive di Specto:

• Analisi full-packetcon modelli adattivi comportamentali
• Monitoraggio esteso a reti IT, OT e cloud-based
• Integrazione nativa con intelligenza artificiale LECS
• Reazione immediata attraverso il motoreRaises, che attiva l’isolamento automatico di asset compromessi (fino all’Air‑Gap energetico)
• Connettività diretta con il sistema XDR LECS per una visione cross-layer

Quando serve davvero un NDR?

Un NDR è particolarmente utile quando:

• gestiscireti mistecon dispositivi IoT/OT difficili da proteggere
• temi attacchifilelessoAPTche sfuggono ai tradizionali antivirus
• vuoi identificaremovimenti lateralipost-breach
• hai necessità divisibilità forensesul traffico per investigazioni rapide

Oggi,l’assenza di un NDR è una vulnerabilità. L’attaccante che entra nella tua rete senza lasciare traccia sull’endpoint potrebbe rimanere inosservato per settimane. Con LECS, puoi intercettarlo prima che sia troppo tardi.

Conclusione

Il Network Detection and Response rappresenta la risposta più concreta e intelligente alle minacce che si muovono sotto il radar delle soluzioni tradizionali. LECS, conSpecto,TiresiaeRaises, integra un NDR di nuova generazione in un ecosistema plug & play che unisce visibilità, automazione e reazione rapida.

Non lasciare cieca la tua rete. Metti LECS a sorvegliare! LECS è un prodotti di Cyber Evolution srl

L'articolo LECS powered by Cyber Evolution: la prima black box NDR completamente Made in Italy proviene da il blog della sicurezza informatica.

Nel secondo trimestre del 2025 i criminali informatici hanno lanciato un’ondata di attacchi malware contro i dispositivi mobili, con quasi 143.000 pacchetti dannosi individuati dai ricercatori della sicurezza. Questa crescita segna una forte escalation delle minacce rivolte a utenti Android e iOS, colpiti attraverso vettori studiati per sottrarre dati sensibili, compromettere informazioni finanziarie e aprire backdoor persistenti.

Il panorama del malware in questo periodo ha mostrato una varietà significativa sia nelle tecniche adottate sia nei target colpiti. I trojan bancari si sono confermati come la categoria più diffusa con 42.220 pacchetti individuati, seguiti dai ransomware mobili che hanno contribuito con altri 695 pacchetti.

Le strategie di attacco hanno sfruttato principalmente l’ingegneria sociale, falsi store di applicazioni e app legittime compromesse. I criminali hanno dimostrato notevoli capacità nel superare i sistemi di difesa più moderni, incrementando i rischi per milioni di utenti a livello globale.

Secondo i dati di Kaspersky Security Network, nello stesso trimestre sono stati bloccati 10,71 milioni di tentativi di infezione da malware, adware e software indesiderati. I trojan hanno rappresentato la tipologia di minaccia prevalente, responsabile del 31,69% delle attività dannose rilevate.

I ricercatori di Securelist hanno evidenziato tendenze preoccupanti come la diffusione di malware preinstallati su determinati modelli di dispositivi e l’evoluzione delle famiglie già note con nuove tecniche di elusione. Tra le minacce più gravi emerse figura SparkKitty, capace di colpire sia Android che iOS rubando immagini, in particolare screenshot contenenti codici di recupero di portafogli di criptovalute.

La pericolosità di SparkKitty risiedeva nella sua abilità di mascherarsi da app legittima e, al contempo, trasmettere dati visivi sensibili a server controllati dai criminali. Questa tecnica ha reso possibile l’accesso diretto a risorse digitali altamente vulnerabili.

Ulteriori esempi di sofisticazione si sono riscontrati in malware come Trojan-Spy.AndroidOS.OtpSteal.a, che si camuffava da client VPN per intercettare codici monouso e inviarli tramite bot su Telegram, eludendo l’autenticazione a due fattori. Altri campioni, come Trojan-DDoS.AndroidOS.Agent.a, hanno integrato SDK dannosi in applicazioni per adulti, creando botnet mobili capaci di attacchi distribuiti di negazione del servizio con parametri di attacco configurabili dinamicamente.

L'articolo 143.000 nuovi malware per gli smartphone nel 2025: la più grande ondata di sempre proviene da il blog della sicurezza informatica.

Lo studio della lingua della Torah riserva continue sorprese nell’esegesi della Scrittura, nella preparazione all’Eucaristia domenicale e nella meditazione sui Salmi. Gesù parlava aramaico – lingua affine all’ebraico, un vernacolare elegante, si potrebbe dire, più parlato che scritto – e respirava l’atmosfera della sinagoga, e in particolare assimilò perfettamente la didattica farisaica.

La storia d’amore che Elena Loewenthal (che è stata docente allo ISS dell’Università di Pavia) narra in riferimento a una lingua, l’ebraico, per la quale ella ha speso una vita di studi, saggi e traduzioni, non intende costituire né un compendio di grammatica, né un sintetico manuale, né una storia della letteratura, ma vuole testimoniare la passione per una lingua scarna e densa di rivelazioni, ruvida e a volte invece dolcissima. Una lingua senza vocali, inflessibile nell’evitare di nominare un Dio irrappresentabile, e assieme feconda di proposte per aggirare il divieto e collegare il Signore dell’alleanza con le vite di chi ha creduto alla sua promessa.

L’antichissima lingua ebraica, lingua «sacra» per antonomasia, non è mai morta, anche se per molto tempo non è stata praticata ufficialmente. Essa obbliga il neofita italiano a un ribaltamento visuale (si legge da destra a sinistra) e a una concentrazione lessicale inconsueta, dato che la radice consonantica va integrata con suoni vocalici appresi sia per regola sia per uso. Eppure, l’A. afferma che «ogni volta, ogni sacrosanta volta che ho visto l’italiano e l’ebraico incontrarsi – sulla pagina, nella voce –, è puntualmente successo che le due lingue si sono regalate qualcosa a vicenda: una sfumatura di significato, un’accoppiata di suoni ben riuscita, una costruzione della frase mai tentata prima» (p. 9).

Alcuni accostamenti sono folgoranti. La lingua di studio si dice Ivrit e il patriarca Abramo è il primo a essere chiamato Avraham haivri (cfr Gen 14,13), ossia «colui che sta dall’altra parte», che passa, oltrepassa, nella fiducia all’appello che si è sentito rivolgere: “Esci dalla tua terra…”» (p. 33). Colpisce la somiglianza del ritmo della lingua con la voce di Dio. Dio è infatti «voce» in quel passo di 1 Re 19,12 in cui dona a Elia una «voce: silenzio sottile» (qol demamah daqah).

Mentre ci introduce alle consonanti, alle contaminazioni d’uso e ai grandi letterati, l’A. distingue la safah dal leshon haqodesh. La prima è la tollerante lingua praticata, che gli ebrei utilizzavano accanto – e a volte ibridandola – alle altre lingue della loro travagliata diaspora. Il secondo è il lessico santo, intangibile, con cui Dio ha creato il mondo e dettato la Torah a Mosè sul Sinai.

Loewenthal regala un divertente «allegato» ai nostri primi manuali di apprendimento e ci invita a una strana libertà di interpretazione: le tavole della Legge sono «incise» (cherot) nella pietra, ma un maestro raccomandava di leggere, proprio in quel termine, cherut, cioè «libertà», nel senso che lo stesso spazio bianco può dire qualcosa di nuovo a chi medita una narrazione o una preghiera così antica di cui nessun glossario o nessuna grammatica può indicare il significato definitivo. L’obbedienza si accompagna alla creatività.

«Eccomi» (Hinneh), dice pregando colui che crede nel Dio di Gesù Cristo, ricordando la vicenda di Samuele. Dio ci chiama e noi rispondiamo: «Mi hai chiamato, eccomi». E poi, in modo più maturo: «Parla, Signore, il tuo servo ti ascolta». Ascoltiamo dunque la vibrazione di una parola, che si inscrive in una storia d’amore. Cifrata, come ogni storia d’amore.

The post Breve storia (d’amore) dell’ebraico first appeared on La Civiltà Cattolica.