Using digital techniques has caused a resurgence of interest in VLF — very low frequency — radio. Thanks to software-defined radio, you no longer need huge coils. However, you still need a suitable antenna. [Electronics Unmessed] has been experimenting and asks the question: What really matters when it comes to VLF loops? The answer he found is in the video below.

This isn’t the first video about the topic he’s made, but it covers new ground about what changes make the most impact on received signals. You can see via graphs how everything changes performance. There are several parameters varied, including different types of ferrite, various numbers of loops in the antenna, and wire diameter. Don’t miss the comment section, either, where some viewers have suggested other parameters that might warrant experimentation.

Don’t miss the 9-foot square antenna loop in the video. We’d like to see it suspended in the air. Probably not a good way to ingratiate yourself with your neighbors, though.

Between software-defined radio and robust computer simulation, there’s never been a better time to experiment with antennas and radios. We first saw these antennas in an earlier post. VLF sure is easier than it used to be.

youtube.com/embed/S7nQ2fnaA3Y?…

hackaday.com/2025/09/04/optimi…

Developing Android applications seems like it should be fairly straightforward if you believe the glossy marketing by Google and others. It’s certainly possible to just follow the well-trodden path, use existing templates and example code – or even use one of those WYSIWYG app generators – to create something passable that should work okay for a range of common applications. That’s a far cry from learning general Android development, of course.

The process has changed somewhat over the years, especially with the big move from the Eclipse-based IDE with the Android Development Tools (ADT) plugin, to today’s Jetbrains IntelliJ IDEA-based Android Studio. It’s fortunately still possible to download just the command-line tools to obtain the SDK components without needing the Google-blessed IDE. Using the CLI tools it’s not only possible to use your preferred code editor, but also integrate with IDEs that provide an alternate Android development path, such as Qt with its Qt Creator IDE.

Picking Poison

Both Qt Creator and ADT/Android Studio offer a WYSIWYG experience for GUI design, though the former’s design tools are incomparably better. Much of this appears to be due to how Qt Creator’s GUI design tools follow the standard desktop GUI paradigms, with standard elements and constraint patterns. After over a decade of having wrangled the – also XML-based – UI files and WYSIWYG design tools in ADT/Android Studio, it never ceases to amaze how simple things like placing UI elements and adding constraints love to explode on you.

The intuitive Android Studio WYSIWYG experience.

Somewhat recently the original Android API layouts also got ditched in favor of the ‘refactored’ AndroidX API layouts, with apparently now this Jetpack Compose being the (high-level) way to use. Over the years of me having developed for Android, many APIs and tools have been introduced, deprecated and removed at an increasingly rapid pace, to the point where having Android Studio or the CLI tools not freak out when confronted with a one year old project is a pleasant surprise.

Designing GUIs in Qt Creator’s Designer mode.

Although Qt isn’t the only alternative to the Android Studio experience, it serves to highlight the major differences encountered when approaching Android development. In fact, Qt for Android offers a few options, including building a desktop Qt application for Android, which can also use the Qt Quick elements, or including Qt Quick within your existing Android application. For Qt Quick you want to either create the UIs by hand, or using Qt Quick Designer, though I have so far mostly just stuck to using Qt Creator and liberally applied stylesheets to make the UI fit the target Android UI.

Whichever way you choose, it’s important to know your requirements and take some time to work through a few test projects before investing a lot of time in a single approach.

The Build System

No matter what approach you choose, the build system for Android is based on what is objectively one of the worst build automation tools conceivable, in the form of Gradle. Not only does it take ages to even start doing anything, it’s also agonizingly slow, insists on repeating tasks that should already have been completed previously, provides few ways to interact or get more information without getting absolutely swamped in useless verbosity, and loves to fail silently if you get just the wrong Gradle version installed in your Android project.

Did I mention yet that the entire Gradle tool is a permanent fixture of your Android project? Android Studio will want to upgrade it almost every time you open the project, and if you don’t use an IDE like it which automates Gradle upgrades, you better learn how to do it manually. Don’t forget to install the right Java Development Kit (JDK) either, or Android Studio, Gradle or both will get very upset.

If your IDE doesn’t pave over many of these inane issues, then getting familiar with the Gradle wrapper CLI commands is right on the top of your list, as you will need them. Fortunately sticking to an IDE here tends to avoid the biggest pitfalls, except for having enough time with each build session to fetch a coffee and go on a brisk walk before returning to address the next build failure.

There are no real solutions here, just a call for perseverance and documenting solutions that worked previously, because you will always encounter the same errors again some day.

Test, Debug And Deploy

Creating a new virtual Android device.

Even if you have built that shiny APK or app bundle, there’s a very high likelihood that there will be issues while running it. Fortunately the one advantage of JVM-based environments is that you get blasted with details when something violently explodes. Of course, that is unless someone screwed up exception handling in the code and your backtrace explodes somewhere in thin air instead. For the same reason using a debugger is pretty easy too, especially if you are using an IDE like Android Studio or Qt Creator that provides easy debugger access.

Logging in Android tends to be rather verbose, with the LogCat functionality providing you with a veritable flood of logging messages, most of which you want to filter out. Using the filter function of your IDE of choice is basically essential here. Usually when I do Android application debugging, I am either already running Qt Creator where I can start up a debug session, or I can fire up Android Studio and do the same here as at its core it’s the same Gradle-based project.

The NymphCast Player Android build, with default skin.

Of course, in order to have something catch on fire you first need to run the application, which is where you get two options: run on real hardware or use an emulator. Real hardware is easier in some ways, as unlike an emulated Android Virtual Device (AVD) your application can directly access the network and internet, whereas an AVD instance requires you to wrangle with network redirects each session.

On the other hand, using an AVD can be handy as it allows you to create devices with a wide range of screen resolutions, so it can be quite nifty to test applications that do not require you to connect to externally via the network. If you want to know for example how well your UI scales across screen sizes, and how it looks on something like a tablet, then using an AVD is a pretty good option.

Some hardware devices are also quite annoyingly locked-down, such as Xiaomi phones that at least for a while have refused to allow you to toggle on remote debugging via USB unless you install a SIM card. Fortunately this could be circumvented by clicking through an alternate path that the Xiaomi developers had not locked down, but these are just some of the obnoxious hurdles that you may encounter with real hardware.

With that out of the way, deploying to an AVD or real device is basically the same, either by using the ‘Start’ or similar function in your IDE of choice with the target device selected, or by doing so via the command-line, either with ADB, or via the Gradle wrapper with ./gradlew InstallDebug or equivalent.

This will of course be a debug build, with creating a release build also being an option, but this will not be signed by default. Signing an APK requires a whole other procedure, and is honestly something that’s best done via the friendly-ish dialogs in an IDE, rather than by burning a lot of time and sanity on the command-line. Whether you want to sign the APK or app bundle depends mostly on your needs/wants and what a potential app store demands.

Ever since Google began to demand that all developers – including Open Source hobbyists – send in a scan of their government ID and full address, I have resorted to just distributing the Android builds of my NymphCast player and server via GitHub, from where they can be sideloaded.

This NymphCast server is incidentally the topic of the next installment in this mini-series, in which we will be doing a deep dive into native Android development using the NDK.

hackaday.com/2025/09/04/bootst…

Microsoft ha ufficialmente reso pubblico il codice sorgente della sua prima versione di BASIC per il processore MOS 6502, che per decenni è esistito solo sotto forma di fughe di notizie, copie da museo e build non ufficiali. Ora, per la prima volta, è pubblicato con licenza libera e disponibile per studio e modifica.

La prima versione del BASIC di Microsoft apparve nel 1975 per il microcomputer Altair 8800 basato sul processore Intel 8080. Fu scritta dai fondatori dell’azienda, Bill Gates e Paul Allen. Un anno dopo, Gates, insieme al secondo dipendente Microsoft, Rick Weiland, portò il BASIC sul processore MOS 6502. Nel 1977, Commodore acquistò la licenza per 25.000 dollari e la integrò nei suoi sistemi PET, VIC-20 e Commodore 64.

Gli ultimi due computer vendettero milioni di copie e divennero uno dei fattori determinanti nella diffusione di massa della tecnologia informatica.

La versione 1.1 è stata resa pubblica, tenendo conto dei miglioramenti al garbage collector proposti dall’ingegnere Commodore John Feagans e dallo stesso Gates nel 1978. Nei dispositivi PET, questa versione era nota come BASIC V2. Il codice contiene 6.955 righe di assembler è pubblicato su GitHub con licenza MIT, che ne consente l’uso e la rivendita senza restrizioni.

Microsoft ha fornito al repository note storiche e commit eseguiti con timestamp di “48 anni fa”. Il codice sorgente implementa la compilazione condizionale per diverse piattaforme dell’epoca: Apple II, Commodore PET, Ohio Scientific e KIM-1.

Le funzionalità includono un set completo di operatori BASIC, supporto per array, gestione delle stringhe, aritmetica in virgola mobile, I/O, garbage collection delle stringhe e archiviazione dinamica delle variabili.

Particolare enfasi è posta sull’uso efficiente della memoria, fondamentale per i sistemi a 8 bit. Il codice contiene anche gli Easter egg di Bill Gates, nascosti nelle etichette STORDO e STORD0, confermati dallo stesso Gates nel 2010.

Il MOS 6502, per il quale fu creato l’interprete, divenne una leggenda del settore.

Fu la base dell’Apple II, delle console di gioco Atari 2600 e NES e di un’intera linea di home computer Commodore. La semplicità e l’efficienza dell’architettura lo resero popolare tra i produttori e influenzarono la formazione del mercato dei personal computer. Oggi, l’interesse per il 6502 non accenna a diminuire: gli appassionati creano repliche FPGA, sviluppano emulatori e persino preparano una nuova riedizione “ufficiale” del Commodore 64 basata su logica programmabile.

Microsoft sottolinea che è stato il BASIC a rendere l’azienda un attore significativo sul mercato, molto prima della comparsa di MS-DOS e Windows. La concessione in licenza di massa di questo interprete da parte di vari produttori è diventata il fondamento del modello di business di Microsoft nei suoi primi anni.

Dal 1977 a oggi, il BASIC continua a vivere: dal cursore lampeggiante sullo schermo del Commodore alle versioni FPGA del 2025. Oggi, il codice storico non solo viene preservato, ma anche trasferito nelle mani della comunità, per studio, adattamento e nuovi esperimenti gratuiti.

L'articolo Dal Commodore 64 a GitHub! Il BASIC di Gates e Allen diventa open source dopo 48 anni proviene da il blog della sicurezza informatica.

Negli ultimi anni si è diffusa una forma di phishing particolarmente insidiosa: il Quishing o QRishing, una strategia basata sull’utilizzo di codici QR contenenti link malevoli che, una volta scansionati, reindirizzano le vittime su siti web falsi, creati appositamente per rubare le loro credenziali o informazioni sensibili.

Gli esperti di Barracuda Networks, principale fornitore di soluzioni di cybersecurity che offre una protezione completa dalle minacce complesse per aziende di ogni dimensione, hanno scoperto due tecniche innovative utilizzate dai criminali informatici per consentire ai codici QR malevoli di aggirare i sistemi di sicurezza negli attacchi di phishing. Queste tattiche, descritte in dettaglio in un nuovo report, prevedono la suddivisione in due parti di un codice QR per confondere i sistemi di scansione tradizionali, oppure l’inserimento di un codice QR dannoso all’interno o accanto a un secondo codice QR legittimo.

In particolare, gli analisti di Barracuda hanno riscontrato l’impiego di queste tecniche di suddivisione e accorpamento (o, secondo la definizione tecnica, “annidamento”) in attacchi condotti tramite alcuni dei principali kit di Phishing-as-a-Service (PhaaS), quali Tycoon e Gabagool.

Codici QR divisi in due

Gli hacker che hanno utilizzato Gabagool si sono serviti di codici QR splittati in una truffa che simula una richiesta di reset della password da parte di Microsoft. La loro strategia consiste nel dividere il codice QR in due immagini separate e inserirle molto vicine tra loro in un’e-mail di phishing.

In questo modo, all’occhio umano l’immagine appare come un unico codice. Tuttavia, quando i sistemi di sicurezza tradizionali analizzano il messaggio, rilevano due immagini distinte dall’aspetto innocuo, anziché un QR code completo. Ma se il destinatario scansiona l’immagine, viene reindirizzato su un sito di phishing creato doloso appositamente per rubare le sue credenziali.

Codici QR accorpati

Il kit PhaaS Tycoon, invece, utilizza la tecnica dell’annidamento per circondare un codice QR legittimo con uno dannoso: il codice QR esterno reindirizza a un URL doloso, mentre il codice QR interno rimanda a Google. Una tecnica ideata con buona probabilità per rendere più difficile l’individuazione della minaccia da parte degli scanner, poiché i risultati appaiono ambigui.

“I codici QR malevoli sono molto usati dai criminali informatici perché hanno un aspetto legittimo e possono aggirare le misure di sicurezza tradizionali, come i filtri e-mail e gli scanner URL”, dichiara Saravanan Mohankumar, manager, threat analysis team di Barracuda.

“Poiché per scansionare il codice i destinatari devono spesso utilizzare un dispositivo mobile, si finisce per operare al di fuori del perimetro di sicurezza dei computer e, di conseguenza, dalle relative protezioni. I cybercriminali continuano a sperimentare nuove tecniche per restare sempre un passo avanti rispetto alle misure di difesa. Per questo, una protezione integrata e potenziata dall’intelligenza artificiale può davvero fare la differenza”.

Codici QR in continua evoluzione: come difendersi

Oltre all’adozione di pratiche di base fondamentali come attività di formazione e sensibilizzazione sulla sicurezza informatica, autenticazione a più fattori e solidi filtri anti-spam e per le e-mail, è importante valutare l’introduzione di una protezione e-mail multilivello che includa capacità di AI multimodale per rilevare le minacce in continua evoluzione. Infatti, l’intelligenza artificiale multimodale rafforza la protezione identificando, decodificando e ispezionando il codice QR senza la necessità di estrarne il contenuto incorporato.

L'articolo Nuova ondata di attacchi di Quishing: Le tattiche innovative dai criminali informatici proviene da il blog della sicurezza informatica.

Dopo una lunga pausa estiva, nella giornata di ieri il CERT-AgID ha pubblicato un nuovo avviso su una nuova campagna MintsLoader, la prima dopo quella registrata lo scorso giugno.

Rispetto alle precedenti ondate, il template dell’email risulta solo leggermente modificato, mantenendo però lo schema già noto. In particolare:

• invece del consueto link ipertestuale sulla parola “Fattura“, l’email presenta ora un file ZIP allegato;
• all’interno dell’archivio compresso è presente un file JavaScript offuscato che avvia la catena di compromissione.

Abuso di caselle PEC

Come già osservato nelle precedenti ondate, anche questa campagna mantiene la stessa natura di diffusione: i messaggi vengono inviati da caselle PEC compromesse a caselle PEC dei destinatari, sfruttando quindi il canale certificato per aumentare la credibilità e l’efficacia dell’attacco.

L’obiettivo finale è la compromissione dei sistemi delle vittime, in particolare macchine Windows (dalla versione 10 in poi), dove la disponibilità del comando cURL viene sfruttata per avviare la catena d’infezione e installare malware, generalmente appartenenti alla categoria degli infostealer.

Strategia temporale

È inoltre interessante evidenziare come venga mantenuta la stessa strategia temporale già descritta nel precedente avviso del CERT-AGID, con un ritorno delle attività in coincidenza con la ripresa lavorativa post-estiva.

Raccomandazioni

Si raccomanda di prestare attenzione a messaggi email sospetti, in particolare a quelli con oggetto relativo a fatture scadute e contenenti allegati ZIP, evitando in ogni caso di estrarre gli archivi e interagire con i file al loro interno. Nel dubbio, è sempre possibile inoltrare le email ritenute sospette alla casella di postamalware@cert-agid.gov.it

Azioni di contrasto

Le attività di contrasto sono state già messe in atto con il supporto dei Gestori PEC. Gli IoC relativi alla campagna sono stati diramati attraverso il Feed IoC del CERT-AGID verso i Gestori PEC e verso le strutture accreditate.

L'articolo Nuova Campagna MintsLoader: Buovi Attacchi di Phishing tramite PEC sono in corso proviene da il blog della sicurezza informatica.

Editoria scolastica: pubblicato il rapporto preliminare dell’Autorità Garante della Concorrenza e del Mercato

L’Autorità Garante della Concorrenza e del Mercato ha reso nota nel bollettino 30/2025 del 04/08/2025 la pubblicazione di un due provvedimenti sull’editoria scolastica e di un interessante allegato al provvedimento, recante il rapporto preliminare sull’editoria scolastica che analizza in profondità le dinamiche economiche e strutturali del settore.

Il termine per la conclusione del procedimento è stato prorogato al 31 dicembre 2025.

L’indagine nasce esattamente un anno fa dalla necessità di comprendere meglio come vengono adottati, distribuiti e utilizzati i libri di testo nelle scuole italiane, con particolare attenzione ai costi sostenuti dalle famiglie e all’effettiva transizione verso il digitale.

Il mercato dell’editoria scolastica in Italia ha un valore stimato di circa 800 milioni di euro, con pochi grandi gruppi editoriali che dominano l’offerta. Nonostante la crescente disponibilità di contenuti digitali, la modalità più diffusa resta quella mista, che combina il libro cartaceo con contenuti online. Tuttavia, l’utilizzo effettivo delle risorse digitali è ancora molto limitato: solo una piccola percentuale delle licenze viene attivata e gli accessi alle piattaforme sono sporadici. Questo evidenzia una transizione digitale incompleta, ostacolata da carenze infrastrutturali, scarsa formazione del personale docente e da sistemi chiusi che limitano la condivisione e la flessibilità.

Il rapporto sottolinea anche le forti disparità territoriali e sociali. I libri sono gratuiti solo nella scuola primaria, mentre nelle secondarie le spese ricadono interamente sulle famiglie, con costi che possono superare i mille euro l’anno per studente. I tetti di spesa imposti dal Ministero risultano spesso inefficaci e facilmente aggirati, aggravando il peso economico soprattutto nelle regioni del Sud.

Un altro punto critico riguarda il mercato dell’usato, che rappresenta una risorsa importante per molte famiglie ma che viene ostacolato dalle politiche editoriali, in particolare per quanto riguarda i contenuti digitali, che non possono essere riutilizzati o ceduti. Inoltre, il rapporto evidenzia come le risorse educative aperte (OER) e le autoproduzioni didattiche siano ancora marginali, frenate da vincoli normativi e dalla mancanza di incentivi.

In conclusione, l’AGCM invita a ripensare il modello editoriale scolastico, promuovendo maggiore interoperabilità tra piattaforme, incentivando la produzione di contenuti aperti e sostenendo economicamente le famiglie e le scuole. L’obiettivo è rendere l’istruzione più accessibile, equa e al passo con le trasformazioni digitali.

Qui:

• il testo con i due provvedimenti sull’editoria scolastica (pagine 66 e 69)
• l'allegato al provvedimento, con il rapporto preliminare sull’editoria scolastica

@Scuola - Gruppo Forum

On 16 July 2025, EDRi participated in the European Commission’s GDPR Implementation Dialogue. We defended the GDPR as a cornerstone of the EU’s digital rulebook and opposed further attempts to weaken it under the banner of ‘simplification’. The discussion was more divided than the official summary suggests.

The post EDRi warns against GDPR ‘simplification’ at EU Commission dialogue appeared first on European Digital Rights (EDRi).

The following is a comment from PPI’s main representative at UNOV, Kay Schroeder, who recently tried to attend the United Nations “Convention against Corruption” (UNCAC) in Vienna.

“This week, the “Conference of the States Parties to the United Nations Convention against Corruption” has begun in Vienna. Unfortunately, I cannot attend, as civil society is barred from participating. Nevertheless, I would like to share my thoughts on the topic of anti-corruption, the obvious impossibility of addressing this issue by the very suspects themselves, and the accompanying shadowboxing.

UNCAC is the highest decision-making body of the United Nations in the fight against corruption. Its tasks include implementing adopted measures, coordinating new initiatives, and deciding on future anti-corruption efforts. A commendable agenda, yet one that falters due to the nature of the states themselves—being the very subjects of corruption through their own representatives in the UN bodies tasked with oversight and enforcement.

It is evident that an institution composed exclusively of state actors can hardly contribute meaningfully to combating corruption, as its representatives are part of the problem. The exclusion of civil society from participation reinforces this impression, especially since we as Pirates have always stood for transparency and decentralization—two essential pillars of anti-corruption that rarely find their way into these forums.

There is, however, some good news from the perspective of anti-corruption. Quite unironically, Austria has today abolished official secrecy. After 100 years, the Freedom of Information Act is making its debut. That’s longer than the UN has existed.”

We thank Mr. Schroeder and all of our PPI UN representatives for their hard work attempting to represent us at the UN and reporting back to us.

If you or any other Pirates you know would like to participate in UN events, please let us know by filling out the volunteer form: lime.ppi.rocks/index.php?r=sur…

If you would like to help PPI continue to send representatives to these meetings, please consider making a small donation to our organization or becoming a member. If you would like to be involved personally in the movement, by writing about these issues or attending events, please let us know.

pp-international.net/donations…

pp-international.net/2025/09/r…