La società xAI di Elon Musk ha introdotto il suo primo modello multimodale, Grok 1.5 Vision (Grok-1.5V). Il modello è progettato per competere con OpenAI e ha la capacità di analizzare testi, documenti, grafici, diagrammi, screenshot e fotografie.

Nel novembre 2023, la società ha rilasciato la prima versione del suo modello Grok e a marzo xAI ha reso pubblici l’architettura e i pesi del modello base. Il nuovo modello multimodale Grok 1.5 Vision è arrivato appena un mese dopo.

Secondo il sito web dell’azienda, Grok 1.5V è in grado di connettere il mondo fisico e quello digitale. Il modello può, ad esempio, convertire un’immagine del diagramma di flusso in codice Python o calcolare il contenuto calorico di un prodotto da un’etichetta nutrizionale.

Può anche creare una fiaba basata sul disegno di un bambino o spiegare perché un particolare meme è divertente.

Il modello non solo intrattiene, ma svolge anche compiti pratici: converte le tabelle in formato CSV, aiuta a correggere gli errori nel codice e fornisce anche suggerimenti per la ristrutturazione della casa in base alle immagini fornite. I risultati dei test hanno mostrato che Grok 1.5V supera significativamente gli altri modelli AI.
Confronto delle prestazioni di vari compiti Grok 1.5V con altri modelli
Inoltre, xAI ha introdotto un nuovo benchmark, RealWorldQA, che valuta la capacità di comprendere il mondo reale in termini spaziali. Il nuovo benchmark RealWorldQA è progettato per valutare le capacità di base di comprensione del mondo reale dei modelli multimodali.

Anche se molti dei compiti del benchmark sembrano semplici per gli esseri umani, sono impegnativi per i modelli AI. La prima versione di RealWorldQA presenta oltre 700 immagini con domande e risposte verificabili, comprese immagini di veicoli anonimizzate e altri scenari del mondo reale.

Il set di dati è disponibile per il download con una licenza CC BY-ND 4.0.

Elon Musk, in una recente intervista, ha espresso l’opinione che entro la fine del 2025 l’intelligenza artificiale sarà più intelligente di qualsiasi essere umano. Tutti gli occhi sono ora puntati sui miglioramenti che la sua azienda apporterà allo sviluppo dell’intelligenza artificiale nei prossimi mesi. xAI sta inoltre pianificando miglioramenti significativi in ​​altri settori come audio, voce e video.

Il modello Grok 1.5 Vision sarà presto disponibile per il test da parte degli utenti esistenti.

L'articolo Grok 1.5V: Il modello che vuole comprendere la realtà come un essere umano proviene da il blog della sicurezza informatica.

The usual way to put a durable threaded interface into a 3D print is to use a heat-set insert, but what about other options? [Thomas Sanladerer] evaluates a variety of different threaded inserts, none of which are actually made with 3D printing in mind but are useful nevertheless.

There are a number of other easily-available threaded inserts, including the rivnut (or rivet nut), chunky hex socket threaded inserts intended for wood and furniture, heli-coils or helical inserts (which resemble springs), self-tapping threaded inserts (also sold as thread adapters), and T-nuts or prong nuts. They all are a bit different, but he measures each one and gives a thorough rundown on how they perform, as well as offering his thoughts on what works best.

[Thomas] only tests M5 fasteners in this video, so keep that in mind if you get ideas and go shopping for new hardware. Some of the tested inserts aren’t commonly available in smaller sizes. Self-tapping threaded inserts, for example, are available all the way down to M2, but the hex socket threaded inserts don’t seem to come any smaller than M4.

These threaded inserts might be just what your next project calls for, so keep them in mind. Heat-set inserts are of course still a great option, and our own Sonya Vasquez can tell you everything you need to know about installing heat-set inserts into 3D printed parts in a way that leaves them looking super professional.

https://www.youtube.com/embed/lYXTiJo_FQQ?feature=oembed

Lo sapevamo. Dietro al bello di CHAT GPT e Midjourney, il potenziamento continuo di robotica e AI, progetti classificati venivano realizzati in tutto il mondo.

Droni autonomi, sistemi di controllo e di pianificazione delle operazioni e chissà quale altra diavoleria bolliva in pentola all’interno delle agenzie militari di questo pianeta.

Ora è il momento di togliere il sipario: benvenuti nella Guerra AI.

L’intelligenza artificiale sta svolgendo un ruolo importante, e secondo alcuni molto preoccupante, nella guerra di Israele a Gaza, con recenti rapporti investigativi che suggeriscono che l’esercito israeliano ha avviato un programma di intelligenza artificiale capace di prendere di mira migliaia di attivisti di Hamas nei primi giorni della guerra, e potrebbe aver avuto un ruolo nelle uccisioni sconsiderate e imprecise, nella distruzione dilagante e nelle migliaia di vittime civili.

L’esercito di occupazione israeliano respinge categoricamente questa affermazione, mentre un rapporto del sito web americano business insider fornisce uno sguardo terrificante su dove potrebbe portare la nuova guerra.

Un futuro terrificante

“La decisione di uccidere un essere umano è una decisione molto importante”, ha detto a BI Mick Ryan, un maggiore generale e stratega australiano in pensione che si concentra sugli sviluppi della guerra.

All’inizio di questo mese, un’indagine congiunta della rivista +972 e Local Call ha rivelato che le forze di occupazione israeliane stavano utilizzando un programma di intelligenza artificiale chiamato “Lavender” per creare obiettivi sospetti per Hamas nella Striscia di Gaza, citando interviste con sei ufficiali anonimi dell’intelligence israeliana.

Il rapporto sostiene che l’IDF faceva molto affidamento su Lavender e trattava essenzialmente le informazioni su chi dovesse essere ucciso “come se fosse una decisione umanitaria”, dicono le fonti.

Una volta che un palestinese veniva collegato ad Hamas e veniva determinata l’ubicazione della sua casa, l’IDF ha effettivamente approvato la decisione della macchina, hanno detto le fonti. Gli ci sono voluti solo pochi secondi per esaminarla lui stesso.

L’indagine congiunta ha scoperto che la rapidità degli attacchi israeliani ha fatto ben poco per cercare di ridurre al minimo i danni ai civili nelle vicinanze. Lo scorso autunno sono venuti alla luce i dettagli del programma Gospel di Israele, rivelando che il progremma aveva aumentato la capacità di identificare obiettivi mirati, da circa 50 all’anno a più di 100 al giorno.

Interrogato sul rapporto, l’IDF ha rinviato il report con una dichiarazione “qualsiasi altra accusa dimostra una mancanza di conoscenza sufficiente delle operazioni dell’esercito di occupazione israeliano.”

Kobbi Shoshani, Console Generale di Israele a Mumbai (rappresentante ufficiale dello Stato di Israele nel Maharashtra, Gujarat, Madhya Pradesh e Goa), ha descritto il sistema come un database di controllo “progettato per aiutare l’analisi umana, non per sostituirla”, ma ci sono comunque dei rischi potenziali di falsi positivi, come in qualsiasi altro software ai, solo che in questo caso non è l’etichettatura di un prodotto, è la vita delle persone.

La diffusione dell’intelligenza artificiale in guerra si è ampliata

Israele non è l’unico paese che esplora il potenziale dell’intelligenza artificiale in guerra. Questa ricerca è accompagnata da una maggiore attenzione all’uso di sistemi senza pilota, come il mondo vede sempre più spesso in Ucraina e altrove, le preoccupazioni sui robot assassini non sono più solo fantascienza

“Proprio come l’intelligenza artificiale sta diventando più comune nel nostro lavoro e nella nostra vita personale, lo è anche nella nostra guerra”, ha detto a BI Peter Singer, un esperto di guerra del futuro presso il think tank New America, spiegando che “stiamo vivendo un nuovo rivoluzione industriale.” Proprio come con la recente meccanizzazione, il nostro mondo sta cambiando, sia in meglio che in peggio.

L’intelligenza artificiale si sta evolvendo più velocemente degli strumenti necessari per tenerla sotto controllo, e gli esperti hanno affermato che i rapporti sull’uso militare da parte di Israele sollevano una serie di preoccupazioni che sono da tempo al centro del dibattito sull’intelligenza artificiale nella guerra futura.

Molti paesi, tra cui Stati Uniti, Russia e Cina, hanno dato priorità all’implementazione di programmi di intelligenza artificiale nei loro eserciti, e al progetto americano Maven, che dal 2017 ha fatto grandi passi avanti per aiutare le forze sul terreno vagliando enormi quantità di informazioni. Tuttavia, la tecnologia si è spesso sviluppata più velocemente di quanto i governi riescano a tenere il passo.

econdo Ryan, la tendenza generale “è che la tecnologia e i requisiti del campo di battaglia stanno andando oltre la considerazione delle questioni legali ed etiche relative all’applicazione dell’intelligenza artificiale in guerra”. Gli attuali sistemi governativi e burocratici possono fare in modo che le politiche su queste questioni non possano tenere il passo, ha detto, aggiungendo che “potrebbero non riuscire mai a tenere il passo.”

Lo scorso novembre, durante una conferenza delle Nazioni Unite, diversi governi hanno espresso preoccupazione sulla necessità di nuove leggi per regolamentare l’uso dei programmi killer autonomi, ovvero macchine guidate dall’intelligenza artificiale coinvolte nel prendere decisioni per uccidere gli esseri umani.

Ma alcuni paesi, soprattutto quelli attualmente all’avanguardia nello sviluppo e nell’implementazione di queste tecnologie, si sono mostrati riluttanti a imporre nuove restrizioni e, in particolare, Stati Uniti, Russia e Israele sono sembrati particolarmente riluttanti a sostenere nuove leggi internazionali in materia.

Saremo responsabili nell’uso militare dell’intelligenza artificiale!

“Molti militari hanno detto: ‘Fidati di noi, saremo responsabili di questa tecnologia’”, ha detto a BI Paul Scharre, un esperto di armi autonome presso il Center for a New American Security. Ma in assenza di supervisione, è improbabile che molte persone si fideranno dell’uso dell’intelligenza artificiale da parte di Alcuni paesi, come Israele, hanno poca fiducia nel fatto che i militari utilizzeranno sempre le nuove tecnologie in modo responsabile.

Un programma come Lavender, secondo quanto riferito, non sembra fantascienza ed è del tutto in linea con il modo in cui gli eserciti globali mirano a utilizzare l’intelligenza artificiale, ha detto Paul Scharre. e prendere decisioni su quali obiettivi attaccare. “Obiettivi come carri armati o pezzi di artiglieria”, ha detto a BI.

Il passo successivo è trasferire tutte queste informazioni in un piano di targeting, associarle ad armi o piattaforme specifiche e quindi agire effettivamente in base al piano.

Ci vuole molto tempo e, nel caso di Israele, c’è probabilmente il desiderio di sviluppare molti obiettivi molto rapidamente, ha detto Paul Scharre. Gli esperti hanno espresso preoccupazione sull’accuratezza di questi programmi di targeting dell’intelligenza artificiale. Utilizzare una varietà di canali di informazione, come i social media e l’uso del telefono, per fissare i propri obiettivi.

Nel rapporto +972 Magazine and Local Calls, le fonti affermano che il tasso di precisione del 90% del programma è considerato accettabile. Il problema evidente è il restante 10%, che rappresenta un sacco di errori considerando la portata della guerra aerea israeliana e la sua significatività.

L’intelligenza artificiale impara continuamente, nel bene e nel male, e con ogni utilizzo questi programmi acquisiscono conoscenza ed esperienza che poi utilizzano per prendere decisioni future. Con un tasso di precisione del 90%, osserva il rapporto, l’apprendimento automatico di Lavender può migliorare le informazioni corrette e sbagliate uccidendo vite umane.

Consentire all’intelligenza artificiale di prendere decisioni in guerra

Le guerre future potrebbero vedere l’intelligenza artificiale lavorare a fianco degli esseri umani per elaborare enormi quantità di dati e suggerire potenziali linee d’azione nel vivo della battaglia, ma ci sono molte possibilità che potrebbero inasprire tale partnership.
I dati raccolti potrebbero essere troppi da elaborare o comprendere per gli esseri umani. Se un programma di intelligenza artificiale elabora enormi quantità di informazioni per preparare un elenco di potenziali obiettivi, potrebbe raggiungere un punto in cui gli esseri umani si sentiranno rapidamente sopraffatti e incapaci di contribuire in modo significativo al processo decisionale.

Esiste anche la possibilità di agire troppo rapidamente e fare ipotesi basate sui dati, aumentando la probabilità di errori, hanno scritto su tale questione nell’ottobre 2023 il consigliere militare e del gruppo armato del CICR Robin Stewart e il consigliere legale Georgia Hinds.

“Uno dei vantaggi militari dichiarati dell’intelligenza artificiale è l’aumento del ritmo decisionale che offre all’utente rispetto al suo avversario. Aumentare il ritmo spesso porta a rischi aggiuntivi per i civili, motivo per cui le tecnologie che riducono il ritmo, così come “pazienza tattica”, vengono utilizzati per ridurre le vittime civili.“
Nel loro tentativo di muoversi rapidamente, gli umani possono togliere le mani dal volante e fidarsi ciecamente dell’intelligenza artificiale con poca supervisione, secondo il rapporto della rivista 972+ e Local Calls. Infatti gli obiettivi vengono esaminati dall’IA per soli 20 secondi, di solito solo per assicurarsi che l’aspirante assassino fosse maschio, prima di autorizzare il colpo.

Rapporti recenti sollevano seri interrogativi sulla misura in cui le persone sono “in loop” durante il processo decisionale. Secondo Singer, è anche “un possibile esempio di ciò che a volte è noto come ‘distorsione della macchina’”, una situazione in cui “un essere umano inganna se stesso facendogli credere che, poiché una macchina ha fornito la risposta, deve essere corretta”. Quindi, l’essere umano potrebbe alle lunghe non fare il suo lavoro e fidarsi ciecamente delle macchine.

A ottobre, il segretario generale delle Nazioni Unite António Guterres e il capo del Comitato internazionale della Croce Rossa, Mirjana Spoljaric, hanno lanciato un appello congiunto affinché gli eserciti “devono agire ora per mantenere il controllo umano sull’uso della forza” in combattimento.
“Il controllo umano sulle decisioni sulla vita e sulla morte deve essere mantenuto. La presa di mira degli esseri umani da parte delle macchine è una linea etica che non dobbiamo oltrepassare”, hanno affermato. “Il diritto internazionale deve vietare alle macchine capacità di uccidere senza l’intervento umano .”

L’altra faccia dell’intelligenza artificiale

Ma anche se ci sono dei rischi, l’intelligenza artificiale potrebbe avere molti vantaggi militari, come aiutare gli esseri umani a elaborare un’ampia gamma di dati e fonti per consentire loro di prendere decisioni informate, oltre a fornire una varietà di opzioni su come gestire le situazioni.

Una significativa collaborazione “human-in-the-loop” può essere vantaggiosa, ma alla fine spetta all’essere umano mantenere la fine di quella relazione. in altre parole, mantenere il potere e il controllo sull’intelligenza artificiale. Siamo padroni delle macchine, sia che si voli su un aereo, si guidi una nave o un carro armato, ma con molti di questi sistemi autonomi e nuovi algoritmi.

Molti eserciti non sono preparati per una simile trasformazione. Come hanno scritto Ryan e Clint Henot in un commento per War on the Rocks all’inizio di quest’anno, “Nel prossimo decennio, le imprese militari potrebbero realizzare una situazione in cui i sistemi senza pilota superano in numero gli esseri umani”.

“Attualmente, le tattiche, l’addestramento e i modelli di leadership delle organizzazioni militari sono progettati per istituzioni militari che sono principalmente umane, e questi umani esercitano uno stretto controllo sulle macchine”, hanno scritto.

“Cambiare l’istruzione e la formazione per preparare gli esseri umani a interagire con le macchine – e non solo a usarle – è un’evoluzione culturale necessaria ma difficile”, hanno affermato. Ma questo è ancora un lavoro in corso per molti militari.

Cosa ci riserverà il futuro? Difficile dirlo.

Sicuramente senza una corretta regolamentazione delle AI ad uso militare ci saranno molte più guerre per via del fatto che gli eserciti non saranno più faccia a faccia uno contro l’altro. Ma l’uso indiscriminato delle armi autonome porterà a molte vittime civili per via di quel 10% che abbiamo analizzato prima.

E il 10 per cento sono 10 vite umane innocenti perse vanamente per via di un bug del silicio.

L'articolo Israele Iran, Ucraina Russia: Benvenuti nell’AI-War. Quando uccidere è solo questione di Silicio proviene da il blog della sicurezza informatica.

In risposta alle crescenti minacce informatiche, la Germania ha annunciato la creazione di un’unità informatica specializzata all’interno delle sue forze armate. La decisione è stata annunciata dal ministro della Difesa tedesco Boris Pistorius.

Il nuovo Cyber ​​and Information Domain Service (CIR) diventerà il quarto dipartimento indipendente dell’esercito tedesco, insieme alle forze di terra, alla marina e all’aeronautica. Tutti i tipi di truppe saranno subordinate ad un unico centro di coordinamento del comando operativo della Bundeswehr. Il progetto di riorganizzazione dell’esercito viene chiamato “Struttura della Bundeswehr”.

Il compito principale della nuova unità è combattere le minacce ibride, comprese le operazioni di disinformazione e influenza, nonché svolgere compiti tattici nel campo della guerra informatica.

Boris Pistorius ha sottolineato che la creazione del CIR ha lo scopo di adattare le forze armate tedesche alla mutevole situazione geopolitica. Inoltre, il Ministro della Difesa ha indicato la necessità di aumentare il bilancio della difesa tedesco di 7,06 miliardi di dollari nel 2025 al fine di raggiungere l’obiettivo di spesa per la difesa della NATO pari al 2% del PIL.

L'articolo Germania in Prima Linea Contro le Minacce Informatiche: Nasce il CIR, l’Unità Speciale dell’Esercito! proviene da il blog della sicurezza informatica.

Back in the 1990s, you could get a tape player shaped like a can of Coca Cola. [Simon the Magpie] scored one of these decks and decided to turn it into a tape echo effect instead. It didn’t work so well, but the concept is a compelling one. You can see the result in the video below.

The core of the effect is a tape loop, which [Simon] set up to loop around a pair of hacked-up cassette shells. This allows him to place one half of the loop in the Coca-Cola cassette player and the other half in a more conventional desktop tape deck. A 3D-printed bracket allows the two decks and the tape loop to be assembled into one complete unit.

The function is simple. The desktop tape deck records onto the loop, with the Coca-Cola unit then playing back that section of tape a short while later. Hey, presto — it’s a tape delay! It’s super lo-fi, though, and the tape loop is incredibly fragile.

There’s some charm in the warbly, weird sounds coming out of the Coca-Cola tape player. [Simon] turns this to his advantage and drops an incredibly catchy avant-garde pop hook with great results. It reminds us of some great DIY hardware we saw many years ago. We’ve been seeing a lot of tape echos lately, but we don’t know why.

https://www.youtube.com/embed/bKU9rQnIBCE?feature=oembed

The Compaq Portable III hails from the 386 era — in the days before the laptop form factor was what we know today. It’s got a bit of an odd design, but a compelling one, and the keyboard is pretty nifty, too. [r0r0] found one of these old-school machines and decided it was well worth refitting it to give it some modern grunt.

The Portable III ended up scoring a mini-ITX build, with an AMD Ryzen 7 3700X and an AMD RX580 GPU. Cramming all this into the original shell took some work, like using a vertical riser to fit in the GPU. Hilariously, the RGB RAM sticks are a little bit wasted when the enclosure is closed.

For the purists out there, you’ll be relieved to know the machine’s original plasma display was dead. Thus, a larger modern LCD was fitted instead. However, [r0r0] did play around with software to emulate the plasma look just for fun.

It’s funny to think you could once score one of these proud machines for free at a swap meet.

https://cdn.hackaday.io/files/1956008368550400/1.mp4
https://cdn.hackaday.io/files/1956008368550400/2.mp4

If you have a well-equipped shop, it isn’t unusual to have a welder. Stick welders have become a commodity and even some that use shield gas are cheap if you don’t count buying the bottle of gas. But plasma cutters are still a bit pricey. Can you get one from China for under $300? Yes. Do you want one that cheap? [Metal Massacre Fab Shop] answers that question in the video below.

First impressions count, and having plasma misspelled on the unit (plasme) isn’t promising. The instructions were unclear, and some of the fittings didn’t make him happy, so he replaced them with some he had on hand. He also added some pipe tape to stop any leaking.

The first test was a piece of quarter-inch steel at 35 amps. The machine itself is rated to 50 amps. Sparks ensued, and with a little boost in amperage, it made a fair-looking cut. At 50 amps, it was time to try a thicker workpiece. It made the cut, although it wasn’t beautiful. The leaking regulator and the fact that he can’t run the compressor simultaneously as the cutter didn’t help.

From the look of it, for light duty, this would be workable with a little practice and maybe some new fittings. Unsurprisingly, it probably isn’t as capable as a professional unit. Still could be very handy to have.

It is possible to convert a welder into a plasma cutter. A handheld unit like this probably won’t benefit from a Sharpie.

https://www.youtube.com/embed/X-peLKTniwQ?feature=oembed

The cassette is one of the coolest music formats ever, in that you could chuck them about with abandon and they’d usually still work. [Chris Borge] recently decided to see if he could recreate these plastic audio packages himself, with great success.

He kicked off his project by printing some examples of an open source cassette model he found online. The model was nicely accurate to the original Compact Cassette design, but wasn’t exactly optimized for 3D printing. It required a great deal of support material and wasn’t easy to customize.

[Chris] ended up splitting the model into multiple components, which could then be assembled with glue later. He then set about customizing the cassette shells with Minecraft artwork. Details of the artwork are baked into the model at varying heights just 1/10th of the total layer height. This makes it easy to designate which sections should be printed with which filament during his multi-colored print. And yet, because the height difference is below a full layer height, the details all end up on the same layer to avoid any ugly gaps between the sections. From there, it’s a simple matter of transferring over the mechanical parts from an existing cassette tape to make the final thing work.

It’s a neat trick, and the final results are impressive. [Chris] was able to create multicolored cassettes that look great. It’s one of the better uses we’ve seen for a multi-colored printer. This would be an epic way to customize a mixtape for a friend!

We’ve seen some great 3D printed cassettes before, too, like these retro reel-to-reel lookalikes.

https://www.youtube.com/embed/o0a3_SLwcNM?feature=oembed

Last time, we looked into using a logic analyzer to decode SPI signals of LCD displays, which can help us reuse LCD screens from proprietary systems, or port LCD driver code from one platform to another! If you are to do that, however, you might find a bottleneck – typically, you need to capture a whole bunch of data and then go through it, comparing bytes one by one, which is quite slow. If you have tinkered with Pulseview, you probably have already found an option to export decoded data – all you need to do is right-click on the decoder output and you’ll be presented with a bunch of options to export it. Here’s what you will find:

2521888-2521888 I²C: Address/data: Start
2521896-2521947 I²C: Address/data: Address write: 22
2521947-2521954 I²C: Address/data: Write
2521955-2521962 I²C: Address/data: ACK
2521962-2522020 I²C: Address/data: Data write: 01
2522021-2522028 I²C: Address/data: ACK
2522030-2522030 I²C: Address/data: Start repeat
2522038-2522089 I²C: Address/data: Address read: 22
2522089-2522096 I²C: Address/data: Read
2522096-2522103 I²C: Address/data: ACK
2522104-2522162 I²C: Address/data: Data read: 91
2522162-2522169 I²C: Address/data: NACK
2522172-2522172 I²C: Address/data: Stop

Whether on the screen or in an exported file, the decoder output is not terribly readable – depending on the kind of interface you’re sniffing, be it I2C, UART or SPI, you will get five to ten lines of decoder output for every byte transferred. If you’re getting large amounts of data from your logic analyzer and you want to actually understand what’s happening, this quickly will become a problem – not to mention that scrolling through the Pulseview window is not a comfortable experience.

The above output could look like this: 0x22: read 0x01 ( DEV_ID) = 0x91 (0b10010001). Yet, it doesn’t, and I want to show you how to correct this injustice. Today, we supercharge Pulseview with a few external scripts, and I’ll show you how to transfer large amounts of Sigrok decoder output data into beautiful human-readable transaction printouts. While we’re at it, let’s also check out commandline sigrok, avoiding the Pulseview UI altogether – with sigrok-cli, you can easily create a lightweight program that runs in the background and saves all captured data into a text file, or shows it on a screen in realtime!

Oh, and while we’re here, I’d like to show you a pretty cool thing I’ve found on Aliexpress! These are tiny FX2 boards with the same logic analyzer schematic, so they work with the FX2 open-source firmware and Sigrok – but they’re much smaller, have USB-C connectors instead of cable struggle that is miniUSB, and are often even cheaper than the ‘plastic case’ FX2 analyzers we’ve gotten used to. In addition to that, since you can see the exposed PCB, unlike with the ‘plastic case’ analyzers, you know whether you’re getting input buffers or not!

Boiling It Down

As an example, let’s consider a capture of the I2C bus of the Pinecil soldering iron. On this bus, there’s three I2C devices – a 96×16 OLED screen at the address 0x3c, an accelerometer at 0x18, and the FUSB302B USB-PD PHY at 0x22. The FUSB302B is a chip that we remember from the USB-C low-level PD communication articles where we built our own PD trigger board. I could only have written those articles because I got the logic analyzer captures, processed them into transaction printouts, and used those to debug my PD code – now, you get to learn how to use such captures for your benefit, too.

If you open the above files in Pulseview – you will see a whole bunch of I2C traces. I wanted to zone in on the FUSB302, naturally – accelerometer and OLED communications are also interesting but weren’t my focus. You will also see that there’s a protocol decoder called “I2C filter” attached. Somehow, it’s been remarkably useless for me whenever I try to use it, not filtering out anything at all. No matter, though – right click on the I2C decoder output row (the one that shows decoded bytes and events), click “Export all annotations for this row”, pick a filename, then open the file in a text editor.

The view you get is a bit overwhelming – we get 22,000 lines of text, which is nowhere near the kind of data you could feasibly read through. Of course, most of that is LCD transfer data, and there’s a fair bit of accelerometer querying, too – you want to filter out both of these if you want to only see the FUSB302 transactions. Nevertheless, it’s a good start – you get a text file that contains all the activity happening on the I2C bus, it’s just too much text to read through on your own.

Here’s an example line: 2521783-2521834 I²C: Address/data: Address write: 30. This is very easy to process, if you take a closer look at it! Each line describes an I2C event, and it starts with two timestamps – event start and event end, separated by - . Then, we get three more values, separated by spaces – decoder name, decoder event type, and the decoder event itself. This output format can be changed in Pulseview settings, if you’re so inclined, however, you can easily parse it as-is. For this format, we can simply split the string by space (not splitting further than three spaces), getting a timestamp, decoder name, decoder output type and decoder event.

I’ll be using Python for parsing, but feel free to translate the code into anything that works for you. Here’s a bit of Python that reads our file line-by-line and puts the useful parts of every line into variables:
with open('decoded.txt', 'r') as f:
line = f.readline()
while line:
line = line.strip()
if not line: # empty line terminates the loop, use `continue` to ignore empty lines instead
break
# ignoring decoder name and decoder output type - they don't change in this case
tss, _, _, d = line.split(' ', 3)
[ "do something with this data" ]
line = f.readline() # get a new line and rerun the loop body

Parsing lines of text into event data is simple enough – from there, we need to group events into I2C transactions. As you can see, a transaction starts with a Start event, which we can use as a marker to separate different transactions within all the events we get. We can do the usual programming tactic – go through the events, have one “current transaction” list that we add new events to, and an “all transactions so far” list where we put transactions we’ve finished processing.

The plan is simple – in the same loop, we look at the event we get, and if it’s not a Start event, whether it’s a write/read/ACK/NACK bit event, or Stop/Start repeat event, we simply put it into the “current transaction” list. If we get a new Start event, we consider this “current transaction” list finished and add it to our list of received transactions, then start a new “current transaction” list. While we’re at it, we can also parse address and data bytes – we receive them as strings and we need to parse them as hex digits, unless you change the I2C decoder to output something else.

Here’s a link to the relevant code section. I could talk more about what it does, for instance, it filters out the FUSB302 transfers by the address, but I’d like to cut to the chase and show the input lines compared to the output transaction list. You can get this output if you run python -i parse.py and enter tr[0] in the REPL:
>>> tr
[0]['start', 34, 'wr', 'ack', 'wr', 1, 'ack', 'start repeat', 34, 'rd', 'ack', 'rd', 145, 'nack', 'stop']

Now, this is a proper I2C transaction! All of these elements are things we can visually discern in the Pulseview UI. Mind you, this code is tailored towards the FUSB302 transaction parsing, but it should not be hard to modify it so that it singles out and parses accelerometer or OLED transactions instead. From here, it’s almost enough to simply concatenate the transaction list elements and get a semi-human-readable transaction, but let’s not stop our ambitions here – the FUSB302 has documentation available, and we can get to a perfectly readable decoding of what the code actually does!

I’ve scrolled through the datasheet, and put together a Python dictionary with a register address-name mapping. Using that, we can easily go through transactions, mapping them to specific register reads and writes, and convert the raw transaction data into lines of text that clearly tell us – first, we write this byte to SWITCHES0 register, then we write a this byte into POWER register, and so on. Here’s the code I wrote to make verbose transactions – and it helps you turn logic analyzer captures into Python code!

Say, you’re writing a replacement open-source firmware for something you own, or perhaps you’re poking around copying the implementation of some protocol for your own purposes, like I copied the Pinecil’s PD implementation to help me debug my own PD code. Here’s the cool part – you can translate this kind of output into your own high-level code near-instantly, to the point where you can even modify this decoding script to output Python or C code! This is just like decompiling, except you get a language of your choice, and a human-readable description of the code’s external behaviour, which is often what you actually want.

Here’s how a verbose transaction list looks: [34, '0x22', 1, '0x01 ( DEV_ID)', 'rd', [145], '0x91 (0b10010001)']. And, this is how I can format such a transactions, using a helper function included in the code I’ve linked:
>>> tr_as_upy(transactions[0])
i2c.readfrom_mem(0x22, 0x1) # rd: DEV_ID 0x91 (0b10010001)
>>> tr_as_upy(transactions[1])
i2c.writeinto_mem(0x22, 0xc, b'\x01') # wr RESET: 0x01 (0b00000001)

Such code allows you to rapidly reverse-engineer proprietary and open-source devices, while getting a good grasp on what is it specifically that they do. What more, with such a decoder, you can also write a protocol decoder for Sigrok so that you can easily access it from Pulseview! For instance, if you’re capturing reads/writes for an I2C EEPROM, there’s an I2C EEPROM decoder in Sigrok that you can add – and, there’s never enough Sigrok decoders, so adding your own decoder to the pile is a wonderful contribution to the open-source logic analysis software that everybody knows and loves.

Going Further With Commandline

This decoding approach gives you the most control over your output data, which massively helps if you have to process large amounts of it. You can also debug intricate problems like never before. For instance, I’ve had to help someone debug a web-based ESP8266 flasher that can’t flash particular kinds of firmware images properly, and for that, I’m capturing the UART data being transferred between the PC and the ESP8266.

There’s a problem with such capturing, too – during flashing, the UART baudrate changes, with the bootloader baudrate being 76800, the flashing baudrate being 468000, and the software baudrate being 115200. As a result, you can’t pull off the usual trick where you connect a USB-UART adapter’s RX pin to your data bus and have it stream data to a serial terminal window on your monitor. Well, with granular control over how you process data captured by the logic analyzer, you don’t have to bother with that!
Bytes received at 76800 marked in orange, bytes received at 11500 marked in greed; the exact commandline visible in the screenshot, too!
The idea is – you connect a logic analyzer to the data bus, and stack two UART decoders onto the same pin! Each decoder is going to throw error messages whenever the current signal is on a different baudrate than the decoder’s expected one. Now, Sigrok being a reasonably modular and open-source project, you can absolutely write a UART decoder for Sigrok that works with multiple baudrates. If you’re like me and don’t want to do that, you can also go the lazy way about it and mash the output of two decoders together in realtime, using error messages as guidance on where the switch occured!

For this kind of purpose, having realtime and text-only processing of Sigrok-produced data is more than enough. Thankfully, the FX2 analyzers let you capture data indefinitely, and Sigrok commandline lets you stack protocol decoders that will then run in realtime! So, I’ve made a script that you can pipe sigrok-cli output into, which compares decoder output to figure out which baudrate is currently being used, and outputs data from the decoder with the least faults. The code’s missing a smarter buffering algo, so the switching-between-baudrates moment is a bit troublesome, as you can see in the screenshot, but it’s working otherwise!

With this Sigrok commandline approach, you gain one more logic analyzer superpower! Since FX2 analyzers let you capture data indefinitely, streaming it to your PC as it is captured, a commandline decoder lets you wire up a FX2 analyzer to a Pi Zero – so you can build a tiny device capturing and decoding a data bus 24/7. Set the FX2 and Pi Zero combo near whatever you’re trying to tap into, run sigrok, have it save data with timestamps onto an SD card, and you can collect weeks of bus activity data easily! This is the kind of capability I wish I had when I was tasked with reverse-engineering a special piece of industrial machinery, controlled over CAN and using a semi-proprietary communication algorithm; having lots of data seriously helps in such scenarios and I was struggling to capture enough.

If you’d rather keep to low-depth GUI experiments, this kind of parsing is useful too – Sigrok protocol decoders are written in Python, which means you can also take your Python output-parsing code and turn it into Pulseview-accessible protocol decoder reasonably easily. All in all, this kind of experimentation lets you squeeze as much as possible out of even the cheapest logic analyzers out there. In the next article, I’d like to go more in-depth through other kinds of logic analyzers we have available – especially all the the cheap options. Given that Sigrok has recently merged the PR with support for the Pi Pico, there’s a fair bit you can get beyond what the FX2-based analyzers have to offer!

The T1000, also known as the Terminator, was like some kind of non-giving up robot guy. The robot assassin viewed the world through a tinted view with lines of code scrolling by all the while. It was cinematic shorthand to tell the audience they were looking through the eyes of a machine. Now, a YouTuber called [Open Source] has analyzed that code.

The video highlights one interesting finds, concerning graphics seen in the T-1000’s vision. They appear to match the output of various code listings and articles in Nibble Magazine, specifically its September 1984 issue. One example spotted was a compass rose, spawned from an Apple Basic listing. it was a basic quiz to help teach children to understand the compass. Another graphic appears to be cribbed from the same issue in the MacPaint Patterns section.

The weird thing is that the original film came out in October 1984 — just a month after that article would have hit the news stands. It suggests perhaps someone involved with the movie was also involved or had access to an early copy of Nibble Magazine — or that the examples in the magazine were just rehashed from some other earlier source.

Code that regularly flickers in the left of the T-1000s vision is just 6502 machine code. It’s apparently just a random hexdump from an Apple II’s memory. At other times, there’s also 6502 assembly code on screen which includes various programmer comments still intact. There’s even some code cribbed from the Apple II DOS 3.3 RAM Disk driver.

It’s neat to see someone actually track down the background of these classic graphics. Hacking and computers are usually portrayed in a fairly unrealistic way in movies, and it’s no different in The Terminator (1984). Still, that doesn’t mean the movies aren’t fun!

https://www.youtube.com/embed/GXkgbjpM49I?start=9&feature=oembed

Thanks to [Stephen Waters] for the tip!

La settimana scorsa, le autorità cinesi hanno ordinato ai tre maggiori colossi delle telecomunicazioni del Paese – China Telecom, China Mobile e China Unicom – di eliminare completamente i semiconduttori statunitensi dalle loro apparecchiature nei prossimi tre anni. Gli operatori dovranno fornire progetti per la graduale sostituzione di questi chip con analoghi nazionali.

Questa decisione, presa dal Ministero cinese dell’Industria e dell’Information Technology, non è di buon auspicio per Intel e AMD , poiché il mercato cinese rappresentava rispettivamente il 27% e il 15% dei ricavi delle società nel 2023.

Questo ordine è stata la risposta della Cina alla decisione della Federal Communications Commission statunitense di cinque anni fa. Questo quando l’organizzazione ha vietato l’uso dei prodotti Huawei e ZTE nelle reti di telecomunicazioni americane. La ragione di ciò era il timore che queste apparecchiature potessero contenere backdoor per lo spionaggio, perché secondo le leggi cinesi, le aziende locali sono obbligate a trasferire qualsiasi informazione alle autorità. Tuttavia, Huawei ha più volte dichiarato che non permetterà mai che i suoi prodotti vengano utilizzati per tali scopi e rispetta rigorosamente le leggi dei paesi in cui opera.

Tuttavia, non è ancora chiaro se verrà fornito sostegno finanziario agli operatori di telecomunicazioni cinesi per compensare i costi di sostituzione dei chip stranieri con quelli nazionali.

Come ha dimostrato l’esperienza americana con l’abbandono delle apparecchiature Huawei, questo processo può essere molto costoso. Sebbene la Federal Communications Commission abbia stanziato 1,9 miliardi di dollari ai produttori, le aziende hanno richiesto oltre 5,6 miliardi di dollari in più.

La scadenza del 2027 per completare la transizione ai chip cinesi è solo un passo negli sforzi in corso da parte della Cina per ridurre la propria dipendenza dalla tecnologia americana. Alla fine dell’anno scorso, Pechino ha anche pubblicato un elenco di 18 processori approvati per l’uso nel paese. Questo elenco non includeva chip Intel e AMD, invece, c’erano chip cinesi compatibili con x86 sviluppati da Shanghai Zhaoxin basati su tecnologie della taiwanese VIA.

La Cina ha accelerato la sua mossa per sostituire la tecnologia occidentale con la propria a causa delle restrizioni statunitensi sull’accesso alla tecnologia avanzata dei processori di intelligenza artificiale e alle apparecchiature per la produzione di chip.

Nonostante le sfide, le aziende cinesi, tra cui Huawei e SMIC, hanno fatto progressi nella creazione di chip ad alte prestazioni. Questa settimana Huawei ha annunciato che costruirà un centro di ricerca e sviluppo vicino a Shanghai che svilupperà le proprie attrezzature per produrre componenti per comunicazioni wireless, apparecchiature di rete e smartphone.

Come spesso abbiamo riportato su queste pagine, l’effetto delle sanzioni statunitensi sta alimentando una corsa alla tecnologia proprietaria sia in Russia che in Cina, portando le due superpotenze ad una loro autonomia nel mondo tecnologico. La Cyber-politica e la sicurezza nazionale oggi è un elemento imprescindibile per ogni regione dello scacchiere geopolitico moderno e solo il tempo potrà fornirci una chiara indicazione se la politica statunitense basata sulle “sanzioni”, avviata ormai da anni porterà un vantaggio o uno svantaggio strategico.

Va da se che ad oggi, l'”autonomia tecnologica” e le “tecnologie domestiche” sono diventati un argomento di importante discussione a livello politico sia in Cina che in Russia, quando altri paesi non sanno neppure l’esistenza del concetto.

L'articolo Addio influenza e controllo. La Cina in 3 anni eliminerà i chip stranieri dai sistemi di telecomunicazione proviene da il blog della sicurezza informatica.

Secondo gli specialisti di Data Leakage & Breach Intelligence (DLBI), il gruppo di hacker di DumpForums ha annunciato di aver violato il server del Dipartimento di tecnologia dell’informazione di Mosca (mos[.]ru/dit/).

Gli aggressori affermano di aver rubato circa 40 TB di dati.

Nel loro canale Telegram, il gruppo ha riferito che l’hacking sarebbe avvenuto un anno fa e per tutto questo tempo erano stati sulla rete DIT, poiché tutti i tentativi di bloccare il loro accesso erano stati invani.

“Durante la nostra permanenza, siamo riusciti ad hackerare tutte le risorse tecniche del DIT, a scaricare 40 TB di database di varie risorse di Mosca tra cui: EMIAS, IS UDRVS, Portale del sindaco di Mosca, SUDIR e altri. Tutte le informazioni ricevute sono state elaborate, quindi tutto il necessario è stato estratto e lo stiamo già utilizzando per lavorare su altri obiettivi”, ha affermato DumpForums.

Per confermare le loro parole, gli hacker hanno pubblicato un dump con la tabella utente (cwd_user) della risorsa interna jira.cdp.local.

DLBI scrive che la tabella contiene 335.586 righe, tra cui:

• Nome utente;
• Cognome;
• indirizzo email (288.395 indirizzi nel dominio @mos.ru);
• data di registrazione e aggiornamento anagrafico (dal 24/05/2019 al 20/06/2023);
• identificatori interni.

I ricercatori notano inoltre che, secondo i loro dati, qualche tempo fa in una vendita chiusa è apparso un dump con i dati presumibilmente zdrav.mos[.]ru, datati settembre 2023.

I rappresentanti del DIT Mosca non hanno ancora commentato le dichiarazioni degli hacker

L'articolo Gli Hacker rubano 40 TB di dati dal server del Dipartimento IT di Mosca proviene da il blog della sicurezza informatica.