Dario Fadda ha ricondiviso questo.

Pixel: il problema di autonomia della batteria si allarga, quasi 8 utenti su 10 colpiti


Il problema di consumo anomalo della batteria sui dispositivi Google Pixel sta assumendo proporzioni sempre più preoccupanti. Quello che inizialmente sembrava un disservizio circoscritto si sta rivelando un fenomeno di massa, con nuovi dati che confermano un impatto su larga scala degli utenti. Il problema: batteria che si scarica dopo l'aggiornamento di marzo A partire dall'aggiornamento di sistema rilasciato a marzo 2026, numerosi possessori di smartphone Pixel hanno iniziato a segnalare […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il problema di consumo anomalo della batteria sui dispositivi Google Pixel sta assumendo proporzioni sempre più preoccupanti. Quello che inizialmente sembrava un disservizio circoscritto si sta rivelando un fenomeno di massa, con nuovi dati che confermano un impatto su larga scala degli utenti.

Il problema: batteria che si scarica dopo l’aggiornamento di marzo


A partire dall’aggiornamento di sistema rilasciato a marzo 2026, numerosi possessori di smartphone Pixel hanno iniziato a segnalare un degrado significativo dell’autonomia. Il fenomeno non riguarda un singolo modello, ma si estende a più generazioni della gamma, come già riportato in precedenza su queste pagine.

Le segnalazioni sono esplose sui forum di community e sui social network, con utenti che descrivono un calo drastico delle prestazioni della batteria avvenuto improvvisamente dopo l’installazione dell’aggiornamento.

Sondaggio Android Authority: il 76% conferma il peggioramento


A fornire una dimensione concreta al problema ci ha pensato Android Authority con un sondaggio che ha coinvolto migliaia di utenti Pixel. Il risultato è inequivocabile: circa il 76% dei partecipanti ha dichiarato di aver riscontrato un peggioramento dell’autonomia dopo l’aggiornamento di marzo. Un numero che rende impossibile ignorare il problema.

I dati del sondaggio confermano che si tratta di un’anomalia diffusa e non di casi isolati, e la varietà di modelli coinvolti suggerisce un’origine software comune piuttosto che un difetto hardware specifico.

Google al lavoro su una soluzione


Di fronte a un’evidenza così schiacciante, Google non può permettersi di rimandare. L’azienda è consapevole del problema e si è impegnata a lavorare su una correzione, anche se al momento non è stata comunicata una data precisa per il rilascio di un aggiornamento risolutivo.

Nel frattempo, gli utenti Pixel colpiti possono tentare alcune contromisure temporanee come controllare le app in background, resettare le statistiche della batteria o, in casi estremi, eseguire un reset del dispositivo — soluzioni parziali che non eliminano il problema ma possono attenuarne l’impatto in attesa della patch ufficiale.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Samsung Galaxy Buds Able: in arrivo un nuovo auricolare open-ear con clip


Samsung si prepara a espandere la gamma Galaxy Buds con un modello inedito. Secondo quanto emerso dall'interno del software One UI, l'azienda sta sviluppando un nuovo auricolare di tipo open-ear con design a clip chiamato Galaxy Buds Able, pensato per chi vuole ascoltare musica senza isolarsi dall'ambiente. Design a clip: un'alternativa all'isolamento acustico La scoperta arriva dall'analisi dei dati interni di One UI, dove è stata trovata un'icona che raffigura un dispositivo con design […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Samsung si prepara a espandere la gamma Galaxy Buds con un modello inedito. Secondo quanto emerso dall’interno del software One UI, l’azienda sta sviluppando un nuovo auricolare di tipo open-ear con design a clip chiamato Galaxy Buds Able, pensato per chi vuole ascoltare musica senza isolarsi dall’ambiente.

Design a clip: un’alternativa all’isolamento acustico


La scoperta arriva dall’analisi dei dati interni di One UI, dove è stata trovata un’icona che raffigura un dispositivo con design completamente diverso rispetto agli attuali Galaxy Buds. Il nuovo modello adotta una forma a clip che si aggancia all’orecchio dall’esterno, senza inserirsi nel canale uditivo.

Questo tipo di auricolare, classificato come “open-ear”, permette di percepire i suoni ambientali mentre si ascolta musica o si effettuano chiamate. Una soluzione apprezzata da chi si muove in contesti urbani o svolge attività fisiche, dove la consapevolezza dell’ambiente circostante è importante per la sicurezza.

Una nuova categoria di prodotto, non solo una variante


I Galaxy Buds Able sembrano rappresentare qualcosa di più di una semplice variante del catalogo esistente. Il sistema di denominazione utilizzato internamente è distinto da quello dei Buds tradizionali, il che suggerisce l’intenzione di lanciare una linea separata, rivolta a un segmento di utenza diverso.

In passato era emersa la voce di un possibile auricolare a conduzione ossea con il nome in codice “Able”, ma le immagini attuali sembrano indicare un approccio più tradizionale con tecnologia open-ear convenzionale.

Il mercato open-ear è in forte crescita


Samsung non sarebbe certo la prima ad avventurarsi in questo segmento: Bose con gli OpenBuds e Anker con la serie SoundCore AeroFit hanno già dimostrato che c’è domanda per questi dispositivi. L’ingresso di un brand come Samsung darebbe ulteriore impulso a questa categoria. I Galaxy Buds Able potrebbero essere annunciati in concomitanza con la prossima generazione di dispositivi pieghevoli Samsung, probabilmente i Galaxy Z Fold 8 e Z Flip 8.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Galaxy Z TriFold 2: nuovo design delle cerniere per uno smartphone tri-fold ancora più sottile


Samsung non si ferma nell'evoluzione degli smartphone pieghevoli. Secondo nuove indiscrezioni provenienti dalla catena di approvvigionamento, il prossimo Galaxy Z TriFold 2 sarà dotato di un sistema di cerniere completamente riprogettato, con l'obiettivo di ridurre ulteriormente lo spessore del dispositivo rispetto al modello precedente. Cerniere inedite per uno spessore record Il cuore dell'aggiornamento sarebbe proprio il meccanismo di chiusura: le fonti parlano di una cerniera […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Samsung non si ferma nell’evoluzione degli smartphone pieghevoli. Secondo nuove indiscrezioni provenienti dalla catena di approvvigionamento, il prossimo Galaxy Z TriFold 2 sarà dotato di un sistema di cerniere completamente riprogettato, con l’obiettivo di ridurre ulteriormente lo spessore del dispositivo rispetto al modello precedente.

Cerniere inedite per uno spessore record


Il cuore dell’aggiornamento sarebbe proprio il meccanismo di chiusura: le fonti parlano di una cerniera “completamente nuova”, progettata appositamente per la struttura tri-fold che caratterizza questo modello. Nel caso di uno smartphone con tre pannelli e due punti di piegatura, la cerniera è il componente più critico in termini di ingombro, resistenza e affidabilità nel tempo.

Il Galaxy Z TriFold originale presentava uno spessore di circa 3,9–4,2 mm da aperto e di circa 12,9 mm quando chiuso. L’obiettivo per la versione 2 sarebbe quello di spingere questi valori ancora più in basso, avvicinandosi alle dimensioni degli smartphone tradizionali.

La tecnologia si estenderà all’intera gamma Galaxy Z


Le novità non riguarderanno solo il TriFold 2. Stando alle stesse fonti, la nuova soluzione tecnica per le cerniere potrebbe essere adottata anche dagli altri modelli della linea pieghevole Samsung. In particolare, si parla di una possibile integrazione su Galaxy Z Fold 8 e Galaxy Z Flip 8, aprendo la strada a uno spessore ridotto su tutta la gamma.

Si tratterebbe di un passo importante: le cerniere sono da sempre uno dei principali limiti tecnici degli smartphone pieghevoli, sia per le dimensioni che per la longevità. Un sistema più compatto e robusto potrebbe migliorare significativamente l’esperienza d’uso quotidiana.

Il primo TriFold aveva una distribuzione limitata


Il Galaxy Z TriFold di prima generazione era stato lanciato con disponibilità molto limitata, accessibile solo in alcuni mercati selezionati. Nonostante le recensioni positive sulla qualità costruttiva e la rigidità delle cerniere, il dispositivo non è mai diventato un prodotto di largo consumo.

Attesa per un lancio globale


Con il TriFold 2, Samsung punta a correggere questa situazione. Oltre alle migliorie tecniche, si spera in una distribuzione più ampia a livello internazionale. Se così fosse, il formato tri-fold potrebbe finalmente raggiungere un pubblico più vasto e segnare una svolta nel mercato degli smartphone pieghevoli premium. La sfida per Samsung è dimostrare che la piegatura in tre non è solo un esercizio di stile, ma una soluzione pratica e duratura per l’utente di tutti i giorni.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Xperia 1 VIII con fotocamera quadrata: i fan sono divisi ma la maggioranza aspetta di vedere il prodotto finito


Il design del prossimo flagship Sony potrebbe essere radicalmente diverso da quanto visto finora. Le indiscrezioni su Xperia 1 VIII parlano di un modulo fotocamera quadrato sul retro, abbandonando la storica disposizione verticale delle lenti. Un sondaggio condotto sul social X ha raccolto le opinioni degli utenti, con risultati sorprendentemente equilibrati. Il sondaggio: chi aspetta e chi ha già deciso Il sondaggio, promosso dall'account SUMAHO-DIGEST su X, ha chiesto agli utenti se […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il design del prossimo flagship Sony potrebbe essere radicalmente diverso da quanto visto finora. Le indiscrezioni su Xperia 1 VIII parlano di un modulo fotocamera quadrato sul retro, abbandonando la storica disposizione verticale delle lenti. Un sondaggio condotto sul social X ha raccolto le opinioni degli utenti, con risultati sorprendentemente equilibrati.

Il sondaggio: chi aspetta e chi ha già deciso


Il sondaggio, promosso dall’account SUMAHO-DIGEST su X, ha chiesto agli utenti se acquisterebbero uno Xperia 1 VIII con design a fotocamera quadrata. I risultati mostrano una netta prevalenza di chi preferisce rimandare la decisione:

  • Lo comprerei comunque: 19,8%
  • Non lo comprerei: 21,6%
  • Dipende dal design del prodotto reale: 34,2%
  • Dipende da prezzo e specifiche: 24,3%

La fascia più numerosa, oltre il 34%, vuole vedere il prodotto finito prima di esprimere un giudizio. Sommando chi è indeciso per motivi di design con chi attende prezzo e specifiche, si supera ampiamente la metà degli intervistati. Un segnale chiaro: la curiosità c’è, ma il giudizio è sospeso.

Pochi rifiuti categorici, molti “aspettiamo”


Uno degli aspetti più interessanti del sondaggio è che solo il 21,6% degli utenti ha dichiarato di non voler acquistare il dispositivo. Nonostante il cambio di design rappresenti una rottura netta con la tradizione Xperia, la maggioranza non chiude la porta. Questo suggerisce che il brand Sony conserva ancora una buona credibilità, e che gli utenti sono disposti a valutare il nuovo design senza pregiudizi, purché la qualità complessiva sia all’altezza.

Cosa sappiamo del design di Xperia 1 VIII


Secondo i leak circolati finora, il retro di Xperia 1 VIII potrebbe presentare un modulo fotografico quadrato che raggruppa le lenti in un unico blocco compatto, abbandonando la classica colonna verticale che caratterizzava i modelli precedenti. Le immagini trapelate su Weibo mostravano anche altri elementi familiari dell’ecosistema Xperia: il logo ZEISS, il tasto fisico per l’otturatore, il sensore di impronte integrato nel tasto di accensione e persino il jack per le cuffie da 3,5 mm.

Una svolta storica per Sony?


Se confermato, il nuovo layout rappresenterebbe la modifica estetica più significativa per la serie Xperia 1 negli ultimi anni. In precedenza si era ipotizzato un layout simile a quello di Xperia 10 VII, con lenti disposte orizzontalmente, ma i leak più recenti indicano invece una soluzione a modulo quadrato. Sony dovrà convincere il suo pubblico storico che il cambiamento vale la pena: la qualità fotografica, il prezzo competitivo e l’esperienza d’uso saranno determinanti per il successo del modello.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Chrome, Chromium e ungoogled-chromium: 3 modi diversi di usare lo stesso motore


Nel mondo dei browser disponibili per una distribuzione GNU/Linux, la famiglia basata su Chromium rappresenta una delle scelte più diffuse. Tutti e tre i progetti, cioè Google Chrome, Chromium e ungoogled-chromium, utilizzano lo stesso...

🔗 Leggi il post completo

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

RAG in .NET con Semantic Kernel: le insidie che i tutorial non ti dicono


Costruire un sistema RAG in produzione con .NET e Semantic Kernel va ben oltre i tutorial: chunking con overlap, soglie calibrate, caching semantico e osservabilità sono le vere discriminanti tra prototipo e sistema affidabile.
The media in this post is not displayed to visitors. To view it, please go to the original post.

RAG — Retrieval-Augmented Generation — è diventato il pattern dominante per integrare conoscenza dominio-specifica nei modelli linguistici. Ma tra un tutorial “hello world” e un sistema RAG che funziona davvero in produzione c’è un abisso. Questo articolo esplora le insidie reali che i tutorial non affrontano, partendo da un’implementazione in .NET con Semantic Kernel.

Il pipeline RAG in cinque fasi


Prima di entrare nei dettagli critici, è utile avere una mappa mentale del pipeline completo. Un sistema RAG ben strutturato si articola in cinque fasi sequenziali:

  1. Ingestion — caricamento dei documenti sorgente
  2. Chunking — suddivisione in segmenti adatti all’embedding
  3. Embedding — conversione dei chunk in vettori numerici
  4. Storage — persistenza dei vettori in un vector store
  5. Retrieval + Generation — ricerca dei chunk rilevanti e generazione della risposta

Ogni fase nasconde decisioni non banali. Vediamo quelle che fanno davvero la differenza.

Il chunking è la variabile più sottovalutata


La qualità del chunking influenza il retrieval più di qualsiasi altra scelta, incluso il modello di embedding. La maggior parte dei tutorial usa split naive basati su caratteri o token fissi, ignorando la struttura semantica del documento.

Con Semantic Kernel, la scelta corretta per documenti Markdown è TextChunker.SplitMarkdownParagraphs(), che rispetta i confini dei paragrafi:

var chunks = TextChunker.SplitMarkdownParagraphs(
    lines: markdownContent.Split('\n').ToList(),
    maxTokensPerParagraph: 512,
    overlapTokens: 50
);

Due parametri critici spesso ignorati:
  • overlapTokens: senza sovrapposizione, le frasi che cadono al confine tra due chunk vengono perse. Una sovrapposizione del 10-15% (qui 50 token su 512) risolve il problema.
  • Pre-processing HTML→Markdown: se i sorgenti sono pagine web, convertire in Markdown prima del chunking (con librerie come HtmlAgilityPack) elimina tag irrilevanti che degradano la qualità dell’embedding.

Un’altra best practice avanzata: separare i blocchi di codice dalla prosa e taggare ogni chunk con metadati (tipo di contenuto, sezione, sorgente) per poter filtrare durante il retrieval.

Le soglie di rilevanza non sono universali


I tutorial usano tipicamente soglie di similarità coseno tra 0.75 e 0.80. Questo valore è quasi sempre sbagliato per il tuo corpus specifico. La soglia ottimale dipende da: qualità dell’embedding model, distribuzione semantica del corpus, tipologia delle query.

L’approccio corretto:

  1. Costruire manualmente un set di valutazione di 20-30 coppie query/risposta attesa
  2. Partire da 0.70 e iterare misurando Context Recall
  3. Non affidarsi mai ai default senza validazione corpus-specifica


Scegliere il vector store giusto


Semantic Kernel supporta diversi backend. La scelta sbagliata genera complessità inutile o performance inadeguate:

  • VolatileMemoryStore — solo per demo, dati persi al restart
  • SqliteMemoryStore — sviluppo locale e prime versioni production: zero infrastruttura, persistenza garantita
  • Elasticsearch — stack esistenti con ricerca ibrida (full-text + vettoriale)
  • Azure AI Search — produzione su Azure, gestione scalabilità automatica
  • Qdrant / Pinecone — carichi vettoriali dedicati ad alta scala

Per molte applicazioni aziendali, SQLite è la scelta razionale fino a migliaia di documenti. Aggiungere infrastruttura vettoriale dedicata ha senso solo con volumi e requisiti di latenza che lo giustificano effettivamente.

Evitare il re-embedding a ogni avvio


Uno degli errori più costosi (in termini economici e di latenza) è re-embeddare l’intero corpus a ogni riavvio dell’applicazione. La soluzione è semplice: verificare l’esistenza della collection prima di procedere all’ingestion:

var collections = await sqliteStore.GetCollectionsAsync().ToListAsync();
if (!collections.Contains(CollectionName))
{
    await ragService.IngestDocumentsAsync(documents, CollectionName);
}

Con Azure AI Search o Qdrant, la logica è analoga ma si basa sulle API specifiche del provider.

Il prompt di grounding non è opzionale


La costruzione del prompt è la difesa principale contro le allucinazioni. C’è una differenza sostanziale tra queste due istruzioni:

  • “Usa il contesto seguente per rispondere” — il modello può integrare con la sua conoscenza generale
  • “Rispondi SOLO usando il contesto seguente. Se la risposta non è nel contesto, dillo esplicitamente.” — vincolo semantico forte

La parola “SOLO” cambia radicalmente il comportamento del modello. In produzione, il prompt di sistema deve essere esplicito e non ambiguo.

Semantic caching per ridurre latenza e costi


Un ottimizzazione ad alto impatto spesso ignorata: se una query è semanticamente simile a una già elaborata, si può restituire la risposta cached senza chiamare il vector store né il modello:

var cachedAnswer = await cacheService.FindSimilarAsync(query, threshold: 0.92f);
if (cachedAnswer != null)
{
    return cachedAnswer.Answer;
}

Con una soglia alta (0.90-0.95), il cache serve solo query davvero simili, evitando risposte errate. Per sistemi con pattern di query ripetitivi (FAQ, assistenti documentali), questo ottimizzazione può ridurre i costi LLM del 40-60%.

Osservabilità: cosa monitorare


Un sistema RAG senza osservabilità è un sistema cieco. I KPI da tracciare per ogni richiesta:

  • TopChunkScore: se costantemente sotto 0.75, il retrieval fatica. Rivedere chunking o embedding model.
  • ChunksRetrieved: se raggiunge sempre il limite massimo, espandere la finestra di ricerca.
  • CacheHit: se sempre false con alta latenza, la soglia del cache è troppo restrittiva.
  • Latency: separare la latenza di retrieval da quella LLM per identificare il bottleneck.


Valutazione continua e CI


Il rischio silenzioso del RAG è la regressione: una modifica al chunking o alla soglia migliora alcune query e ne peggiora altre. La soluzione è integrare un set di valutazione nel pipeline CI con xUnit:

  • Context Recall: i chunk corretti vengono recuperati?
  • Faithfulness: la risposta rimane ancorata al contesto?
  • Answer Correctness: corrisponde alla risposta attesa?

Il set di test deve includere query facili, domande che richiedono sintesi multi-documento, e domande a cui il sistema non dovrebbe rispondere (out-of-scope) — queste ultime sono fondamentali per rilevare allucinazioni.

Conclusione


Costruire un sistema RAG che funziona nei demo è relativamente semplice con Semantic Kernel. Costruirne uno che funziona in produzione — con costi controllati, latenza accettabile, assenza di allucinazioni e monitoraggio efficace — richiede decisioni architetturali precise. Il chunking con overlap, le soglie calibrate sul corpus reale, il caching semantico e l’osservabilità non sono optional: sono la differenza tra un prototipo e un sistema affidabile.

Fonte originale: RAG in .NET: What the Tutorials Don’t Tell You di Jamie Maguire.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Linux Mint conferma il cambio di strategia per la sopravvivenza: meno release, più qualità


Verso la metà dello scorso febbraio, commentando il consueto appuntamento mensile di aggiornamenti a proposito del progetto, avevamo ragionato sui problemi che un progetto come Linux Mint deve affrontare. Nata come distribuzione Linux derivata di Ubuntu, Linux Mint ha effettuato alcune scelte progettuali che se da un lato l’hanno resa unica, dall’altro hanno comportato un...

🔗 Leggi il post completo

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Oppo Find X9 Ultra: cinque nuovi accessori arrivano sul mercato globale il 21 aprile


In occasione del lancio globale di Oppo Find X9 Ultra, previsto per il 21 aprile 2026, Oppo ha annunciato anche cinque accessori ufficiali che faranno il loro debutto internazionale. Prodotti già noti in Cina, finalmente disponibili anche per i mercati europei e globali. Caricatori compatti ad altissima potenza Due dei nuovi accessori sono caricatori ultra-compatti. Il 120W Mini dispone di due porte e promette di caricare il Find X9 Ultra dallo 0% al 71% in soli 30 minuti. Il 100W Mini Pro […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

In occasione del lancio globale di Oppo Find X9 Ultra, previsto per il 21 aprile 2026, Oppo ha annunciato anche cinque accessori ufficiali che faranno il loro debutto internazionale. Prodotti già noti in Cina, finalmente disponibili anche per i mercati europei e globali.

Caricatori compatti ad altissima potenza


Due dei nuovi accessori sono caricatori ultra-compatti. Il 120W Mini dispone di due porte e promette di caricare il Find X9 Ultra dallo 0% al 71% in soli 30 minuti. Il 100W Mini Pro è invece a porta singola USB-C, per chi preferisce un design ancora più essenziale. Entrambi sono progettati per essere facilmente trasportabili, ideali per chi viaggia spesso.

Power bank da 15.000 mAh con SuperVOOC 120W


C’è anche un power bank da 15.000 mAh compatibile con la ricarica rapida SuperVOOC a 120W, con doppia porta (USB-A e USB-C). Il design compatto e le numerose protezioni di sicurezza lo rendono una scelta solida per chi vuole tenere il proprio smartphone Android sempre carico.

Accessori per il raffreddamento: innovazione e praticità


Oppo ha pensato anche alla gestione termica con due prodotti dedicati. Il Magnetic Ice Card Cooler è un raffreddatore ultrasottile (9,8 mm al punto più sottile) con modalità silenziosa a soli 22 dB. Il caricatore wireless magnetico da 50W combina ricarica e raffreddamento attivo in un unico accessorio con supporto integrato, pensato per sessioni di gaming o streaming prolungate.

Compatibilità con altri dispositivi Android


Vale la pena notare che molti di questi accessori, in particolare i caricatori, sono compatibili con qualsiasi smartphone Android dotato di porta USB-C. Alcuni di essi saranno distribuiti anche attraverso i canali OnePlus, confermando la sinergia tra i due brand dello stesso gruppo.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Xperia 1 VIII: render ufficiali trapelati mostrano fotocamere a modulo quadrato e tre sensori da 48 MP


Si avvicina il momento del lancio e le fughe di notizie si fanno sempre più dettagliate: nuovi render del Sony Xperia 1 VIII sono apparsi online, rivelando un design che segna una rottura netta con la tradizione della serie. Dopo anni di fotocamere disposte verticalmente in fila, Sony sembrerebbe pronta ad adottare un modulo fotografico di forma quadrata. Addio alla colonna verticale di obiettivi Da quando è nato nel 2019, Xperia 1 ha sempre mantenuto un'identità visiva riconoscibile: […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Si avvicina il momento del lancio e le fughe di notizie si fanno sempre più dettagliate: nuovi render del Sony Xperia 1 VIII sono apparsi online, rivelando un design che segna una rottura netta con la tradizione della serie. Dopo anni di fotocamere disposte verticalmente in fila, Sony sembrerebbe pronta ad adottare un modulo fotografico di forma quadrata.

Addio alla colonna verticale di obiettivi


Da quando è nato nel 2019, Xperia 1 ha sempre mantenuto un’identità visiva riconoscibile: tre o quattro obiettivi disposti in verticale lungo il bordo sinistro del pannello posteriore. I nuovi render suggeriscono che questa caratteristica verrà abbandonata a favore di un modulo rettangolare/quadrato, un design molto più comune tra i flagship Android contemporanei. Una scelta che potrebbe far storcere il naso ai fan di lunga data, ma che potrebbe anche rendere il dispositivo più immediatamente riconoscibile come top di gamma da un pubblico più ampio.

Tre fotocamere da 48 MP: la grande novità tecnica


Sul fronte fotografico, la vera rivoluzione sarebbe l’adozione di tre sensori da 48 megapixel per grandangolo, ultra-grandangolo e teleobiettivo. Sui modelli precedenti, la camera periscopica si fermava a 12 MP, una scelta voluta per privilegiare le ottiche Zeiss e il processore d’immagine, ma spesso criticata in confronto con la concorrenza. Con l’uniformazione a 48 MP su tutti e tre i sensori, la coerenza qualitativa nelle fotografie a diverse focali dovrebbe migliorare sensibilmente.

Le caratteristiche Sony restano: jack audio e microSD confermati


Nonostante il cambiamento estetico, Xperia 1 VIII manterrebbe le peculiarità che da sempre contraddistinguono la serie: il jack da 3,5 mm per le cuffie e lo slot microSD per l’espansione della memoria. Due dotazioni sempre più rare nel panorama flagship 2026, che continuano a essere un punto di forza per chi non vuole rinunciare alla praticità. L’annuncio ufficiale è atteso intorno a maggio 2026.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Dal Roblox script al breach di Vercel: come un infostealer ha quasi compromesso la supply chain di Next.js


Un dipendente di Context.ai infettato da Lumma Stealer tramite script Roblox ha aperto la porta a una potenziale supply chain attack su Vercel e Next.js. ShinyHunters rivendica il furto di codice sorgente, token NPM/GitHub e 580 record di dipendenti, offrendo il pacchetto per $2 milioni. Vercel conferma accesso limitato ma esclude compromissione dei framework open source.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Un dipendente che scarica script per un gioco su un dispositivo personale. Un infostealer silenzioso che raccoglie credenziali aziendali. Un gruppo criminale che usa quell’accesso come testa di ponte per violare una delle piattaforme di deployment più utilizzate al mondo dagli sviluppatori. La storia del breach di Vercel del 19 aprile 2026 è un manuale perfetto sulle supply chain attack nell’era dell’AI-as-a-service.

L’epicentro: Context.ai e il dipendente con Roblox


Tutto inizia con un’infezione apparentemente irrilevante. A febbraio 2026, un dipendente di Context.ai — un servizio di AI analytics utilizzato da numerose aziende tech tra cui Vercel — scarica sul proprio dispositivo degli script per automatizzare il gioco Roblox. Gli script sono trojanizzati e distribuiscono Lumma Stealer, uno degli infostealer-as-a-service più prolifici del 2025-2026, venduto nei mercati underground per pochi dollari al mese con funzionalità di raccolta credenziali da browser, password manager, wallet di criptovalute e token di sessione.

L’impatto è immediato: Lumma esfiltra le credenziali salvate sul dispositivo, tra cui accessi amministrativi a Google Workspace, Supabase, Datadog, Authkit e — il jackpot — account Vercel con privilegi elevati. I ricercatori di Hudson Rock hanno documentato come questa singola infezione abbia fornito il punto d’accesso iniziale che ha reso possibile tutta la catena successiva.

Il pivot: da Context.ai a Vercel


La vulnerabilità reale non era tecnica ma architetturale: Context.ai aveva accesso all’ecosistema Vercel tramite un’applicazione OAuth di Google Workspace. Una volta compromesso l’account Google del dipendente, il threat actor ha potuto usare quel token OAuth per accedere all’account Vercel collegato — senza bisogno di conoscere la password Vercel, senza trigger di MFA (perché il token era già autenticato), senza lasciare tracce convenzionali di accesso non autorizzato.

Questo tipo di attacco — noto come OAuth token hijacking tramite compromissione di terze parti — è sempre più frequente nell’ecosistema SaaS moderno, dove le integrazioni tra servizi si moltiplicano e la superficie d’attacco cresce esponenzialmente. L’analisi di Hudson Rock evidenzia come la “60-second OAuth Client ID audit” — una revisione rapida delle applicazioni OAuth connesse agli account aziendali — avrebbe potuto identificare e revocare l’accesso compromesso prima che la situazione degenerasse.

ShinyHunters rivendica: $2 milioni per codice sorgente e token


Il 19 aprile 2026, un threat actor utilizzando il nome ShinyHunters pubblica su forum underground l’offerta di un pacchetto di dati esfiltrati da Vercel, con un prezzo richiesto di 2 milioni di dollari. Il pacchetto includerebbe codice sorgente proprietario, token NPM e GitHub con accesso ai repository, credenziali database, API key interne e un file con 580 record di dipendenti Vercel contenenti nomi, email aziendali e timestamp di attività.

È importante notare che il gruppo criminale ShinyHunters — responsabile di breaches storici tra cui Ticketmaster (2024), Snowflake (2024) e decine di altri — ha pubblicamente negato il coinvolgimento in questo specifico breach. Questo è un pattern ricorrente: l’uso del brand di gruppi noti da parte di attori minori o criminali opportunisti che acquistano dati rubati da infostealer operations per poi rivenderli attribuendoli a APT o gruppi di alto profilo.

Il rischio supply chain: Next.js e Turbopack


La preoccupazione più grave non era la fuga di credenziali dei dipendenti, ma il potenziale impatto sulla supply chain software. Vercel è il creatore e maintainer principale di Next.js — il framework React più scaricato al mondo con oltre 6 milioni di download settimanali su NPM — e di Turbopack, il successore di webpack. L’accesso a token NPM e repository GitHub avrebbe potuto consentire la modifica del codice sorgente di questi framework e la pubblicazione di versioni trojanizzate, con un impatto a cascata su milioni di applicazioni web globalmente.

Vercel ha risposto rapidamente: il CEO Guillermo Rauch ha confermato che l’analisi della supply chain condotta con Google Mandiant ha verificato che Next.js, Turbopack e tutti i progetti open source della piattaforma non sono stati modificati. I token compromessi sono stati revocati immediatamente e le credenziali esposte sono state rigenerate. Un numero limitato di clienti è stato contattato direttamente per la rotazione delle variabili d’ambiente.

Il vettore più sottovalutato: i dispositivi dei dipendenti di terze parti


Questo incident è un caso di studio emblematico per un problema strutturale della sicurezza moderna: le organizzazioni investono massicciamente nella protezione dei propri endpoint aziendali, ma la catena di accesso si estende inevitabilmente ai dispositivi dei dipendenti di vendor, partner e fornitori di servizi SaaS — dispositivi su cui non hanno visibilità né controllo. Un dipendente di Context.ai che scarica uno script Roblox su un dispositivo personale non usato per lavoro potrebbe comunque avere credenziali aziendali salvate nel browser, vanificando ogni investimento in EDR aziendale.

Il 2025-2026 ha visto Lumma Stealer protagonista di decine di breaches di alto profilo. La sua distribuzione via gaming scripts, crack software e SEO poisoning è particolarmente insidiosa perché colpisce utenti che non percepiscono il rischio — e i cui dispositivi spesso hanno accesso a ecosistemi aziendali critici proprio in virtù delle integrazioni OAuth che caratterizzano il SaaS moderno.

Indicatori e azioni raccomandate

# Vettore iniziale
Lumma Stealer distribuito tramite script Roblox "auto-farm" trojanizzati

# Credenziali compromesse sul dispositivo Context.ai
- Google Workspace (account dipendente)
- Supabase (database as a service)
- Datadog (monitoraggio/osservabilità)
- Authkit (authentication service)
- Vercel (piattaforma di deployment — accesso admin)

# Dati rivendicati da ShinyHunters
- Codice sorgente proprietario Vercel
- NPM authentication tokens
- GitHub tokens
- Credenziali database
- 580 record dipendenti (nome, email, timestamp attività)

# Prezzo richiesto: $2.000.000 USD (forum underground)

# Stato supply chain (confermato da Vercel + Mandiant)
Next.js: NON compromesso
Turbopack: NON compromesso
Open source projects Vercel: NON compromessi

# Azioni immediate raccomandate per chi usa Vercel
1. Ruotare TUTTE le variabili d'ambiente non marcate "sensitive"
2. Revocare e rigenerare NPM tokens e GitHub tokens connessi a Vercel
3. Revisione audit log per accessi anomali (aprile 2026)
4. Audit OAuth apps connesse agli account Google Workspace aziendali
5. Verificare integrazioni AI tools di terze parti e relativi permessi OAuth

Lezione per i CISO: la sicurezza si ferma all’ultimo anello debole


La catena Roblox script → Lumma Stealer → Context.ai employee → OAuth token → Vercel admin access → potenziale supply chain attack su milioni di app Next.js è una dimostrazione pratica di come la sicurezza di un’organizzazione dipenda dall’anello più debole dell’intera rete di trust. I CISO devono estendere i programmi di gestione del rischio ai vendor di servizi AI — una categoria in rapida espansione con accesso privilegiato agli ambienti produttivi — e implementare politiche di revisione periodica delle OAuth app connesse agli account aziendali. La “60-second OAuth audit” non è un’esagerazione: pochi minuti potrebbero aver evitato un breach da $2 milioni e un potenziale disastro di supply chain.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Debian: Sruthi Chandran è la nuova leader del progetto per il 2026


La distribuzione GNU/Linux Debian è uno dei progetti più longevi e influenti dell’intero ecosistema del software libero. Nata nel 1993, è sviluppata da una vasta comunità internazionale di volontari e si distingue per la...

🔗 Leggi il post completo

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Rilasciato LXQt 2.4: novità e miglioramenti per l’ambiente desktop leggero basato su Qt


LXQt è un ambiente desktop libero e open source, progettato per offrire un’esperienza leggera, reattiva e adatta sia ai sistemi con risorse limitate sia agli utenti che preferiscono un’interfaccia essenziale ma moderna. Questo progetto...

🔗 Leggi il post completo

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Rust 1.95.0: cfg_select!, if-let guard nei match e nuove API per Vec e atomici


Rust 1.95.0 introduce la macro cfg_select! per condizionali di compilazione senza dipendenze esterne, gli if-let guard nei blocchi match e nuove API ergonomiche per Vec e i tipi atomici.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il 16 aprile 2026 è uscita Rust 1.95.0, una release che porta novità significative al linguaggio e alla sua libreria standard. Questa versione si segnala in particolare per l’introduzione della macro cfg_select!, il supporto agli if-let guard nei blocchi match, e una serie di nuove API per la gestione della memoria e degli atomici.

Vediamo nel dettaglio cosa cambia e come queste novità influenzano il codice quotidiano dei Rustaceans.

cfg_select!: condizionali di compilazione senza dipendenze esterne


La macro cfg_select! introduce un modo più espressivo per scrivere codice condizionale basato sulla configurazione di compilazione. Si comporta come un match valutato a compile-time sulle condizioni cfg, rimpiazzando di fatto il crate esterno cfg-if che molti progetti Rust usano da anni.

Prima di Rust 1.95, per scrivere codice dipendente dalla piattaforma si usava tipicamente:

// Prima: con cfg-if (dipendenza esterna nel Cargo.toml)
cfg_if::cfg_if! {
    if #[cfg(target_os = "linux")] {
        fn get_system_info() -> String {
            linux_system_info()
        }
    } else if #[cfg(target_os = "macos")] {
        fn get_system_info() -> String {
            macos_system_info()
        }
    } else {
        fn get_system_info() -> String {
            String::from("unknown")
        }
    }
}

Con cfg_select!, la stessa logica si esprime ora senza aggiungere dipendenze al progetto:
// Ora: built-in nella libreria standard
fn get_system_info() -> String {
    cfg_select! {
        target_os = "linux" => { linux_system_info() }
        target_os = "macos" => { macos_system_info() }
        _ => { String::from("unknown") }
    }
}

La sintassi è più pulita e il fatto di essere nella libreria standard elimina la necessità di dichiarare cfg-if nel Cargo.toml. Particolarmente utile per chi sviluppa librerie cross-platform o crate che devono supportare più sistemi operativi e architetture CPU.

if-let guard nei match: pattern matching più espressivo


Rust 1.95 stabilizza gli if-let guard all’interno delle espressioni match, costruendo sulle let chain introdotte in Rust 1.88. Un guard in un match è la condizione if che può seguire un pattern. Finora, questa condizione doveva essere un’espressione booleana semplice. Ora si può usare if let per abbinare pattern aggiuntivi direttamente nella guardia:

fn process(value: Option<Result<i32, String>>) {
    match value {
        Some(x) if let Ok(y) = x => {
            println!("Valore ottenuto: {}", y);
        }
        Some(Err(ref e)) => {
            println!("Errore: {}", e);
        }
        None => {
            println!("Nessun valore");
        }
    }
}

Questo permette di scrivere logica di pattern matching più complessa senza ricorrere a blocchi match annidati. Un caso d’uso pratico è la validazione combinata di metodo HTTP e corpo della richiesta:
fn handle_request(req: &Request) -> Response {
    match req.method() {
        Method::POST if let Ok(body) = serde_json::from_str::<Payload>(req.body()) => {
            process_payload(body)
        }
        Method::POST => {
            Response::bad_request("Payload JSON non valido")
        }
        _ => {
            Response::method_not_allowed()
        }
    }
}

Nota importante sull’esaustività: il compilatore non tiene conto dei pattern negli if-let guard per il controllo di esaustività (exhaustiveness checking). Questo significa che il compilatore non avvertirà se un pattern nell’if-let guard è irraggiungibile. Occorre quindi prestare attenzione quando si usano questi costrutti in match che devono essere esaustivi per correttezza.

Nuove API per Vec, VecDeque e atomici

push_mut e push_back_mut: riferimenti mutabili post-inserimento


Una delle aggiunte più pratiche riguarda i metodi push_mut e varianti per Vec e VecDeque. Questi metodi inseriscono un elemento e restituiscono immediatamente un riferimento mutabile all’elemento appena inserito, eliminando il doppio accesso che prima era necessario:

// Prima: due operazioni separate
let mut v: Vec<String> = Vec::new();
v.push(String::new());
let last = v.last_mut().unwrap(); // secondo accesso necessario
last.push_str("hello");

// Ora con push_mut: un unico accesso, più efficiente
let mut v: Vec<String> = Vec::new();
let elem = v.push_mut(String::new());
elem.push_str("hello"); // riferimento diretto all'elemento appena inserito

Metodi analoghi (push_back_mut, push_front_mut) sono disponibili anche su VecDeque, utile per code e buffer circolari.

update e try_update sugli atomici


I tipi atomici (AtomicUsize, AtomicBool, AtomicI32, ecc.) guadagnano i metodi update e try_update per semplificare i pattern read-modify-write senza dover scrivere manualmente il loop CAS (Compare-And-Swap):

use std::sync::atomic::{AtomicUsize, Ordering};

let counter = AtomicUsize::new(0);

// Incrementa atomicamente, restituisce il vecchio valore
let old = counter.update(Ordering::SeqCst, |x| x + 1);
println!("Valore precedente: {}", old);

// try_update: permette di fallire condizionalmente
// (ritorna Err se la chiusura restituisce None)
let result = counter.try_update(Ordering::SeqCst, |x| {
    if x < 100 { Some(x + 1) } else { None }
});

match result {
    Ok(old_val) => println!("Aggiornato da {}", old_val),
    Err(_) => println!("Limite raggiunto, nessun aggiornamento"),
}

Questi metodi gestiscono internamente il retry loop in caso di contesa tra thread, rendendo il codice più leggibile e meno soggetto a errori.

Stabilizzazioni in const context


Rust 1.95 estende il supporto ai const context per alcune API già stabili, consentendo un uso più ampio della valutazione a compile-time:

  • fmt::from_fn ora utilizzabile in contesti const
  • Metodi di ControlFlow ora const-stabili
  • Nuovi metodi unsafe per puntatori: as_ref_unchecked e as_mut_unchecked
  • Layout::dangling_ptr per manipolazione avanzata della memoria in allocatori custom


Breaking change: JSON target spec non più supportata su stable


Rust 1.95 rimuove il supporto alle specifiche di target in formato JSON sul canale stable. Questa funzionalità era già effettivamente limitata al canale nightly (costruire core richiedeva già nightly), quindi l’impatto pratico è minimo per la maggior parte dei progetti. Chi usa target custom non standard dovrà assicurarsi di usare il canale nightly o di migrare a definizioni di target ufficialmente supportate.

Come aggiornare


Per aggiornare Rust all’ultima versione stabile, basta eseguire:

rustup update stable

Per verificare la versione installata:
rustc --version
# rustc 1.95.0 (xxxxxxxx 2026-04-16)

Conclusioni


Rust 1.95.0 è una release solida che porta miglioramenti trasversali all’ergonomia del linguaggio. cfg_select! riduce la dipendenza da crate esterni per il codice condizionale, gli if-let guard aumentano l’espressività del pattern matching, e le nuove API per Vec e atomici semplificano pattern comuni nella gestione dello stato condiviso in contesti concorrenti.

Nel complesso, questa release conferma la direzione del progetto Rust: migliorare l’ergonomia senza compromettere la sicurezza, incorporando nella libreria standard soluzioni che prima richiedevano crate esterni.

Fonte: Announcing Rust 1.95.0 — The Rust Programming Language Blog

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Sony WH-1000XX: il decimo anniversario potrebbe portare un nuovo flagship per le cuffie 1000X


Una clamorosa svista sul sito ufficiale Sony di Nuova Zelanda e Australia ha rivelato in anticipo l'esistenza di un nuovo modello di cuffie premium: il WH-1000XX, ribattezzato "1000X THE COLLEXION". L'informazione è stata rimossa rapidamente, ma non abbastanza da sfuggire agli appassionati del settore. Un nome che celebra i dieci anni della serie Il nome "XX" non è casuale: la serie WH-1000X è nata nel 2016 con il primo modello, e il 2026 rappresenta il suo decimo anniversario. La doppia […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Una clamorosa svista sul sito ufficiale Sony di Nuova Zelanda e Australia ha rivelato in anticipo l’esistenza di un nuovo modello di cuffie premium: il WH-1000XX, ribattezzato “1000X THE COLLEXION“. L’informazione è stata rimossa rapidamente, ma non abbastanza da sfuggire agli appassionati del settore.

Un nome che celebra i dieci anni della serie


Il nome “XX” non è casuale: la serie WH-1000X è nata nel 2016 con il primo modello, e il 2026 rappresenta il suo decimo anniversario. La doppia X potrebbe essere un omaggio stilistico a questo traguardo, oltre che un segnale che Sony vuole alzare ulteriormente l’asticella qualitativa con questo modello. Il claim associato al prodotto suggerisce un’esperienza audio elevata all’ennesima potenza.

Specifiche tecniche già trapelate


Dall’analisi del testo accessorio pubblicato per errore, emergono alcune caratteristiche tecniche del WH-1000XX:

  • Disponibile in colorazioni nero e bianco
  • Cancellazione attiva del rumore (ANC) di nuova generazione
  • Chip MediaTek integrato
  • Supporto alla tecnologia DSEE Ultimate per il miglioramento audio
  • Cerniere in metallo per maggiore resistenza
  • Design non pieghevole
  • Prezzo indicativo attorno ai 629 euro
  • Produzione in Vietnam


Compatibilità Android ottima


Come già avviene per gli attuali WH-1000XM5, il nuovo modello sarà completamente compatibile con Android tramite l’app Sony Headphones Connect, che permette la personalizzazione del suono, la gestione dell’ANC e gli aggiornamenti firmware. Data la componente MediaTek e la connettività Bluetooth avanzata, ci si aspetta un’integrazione ancora più fluida con l’ecosistema Android.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Google Pixel 11 potrebbe dire addio al modem Samsung: in arrivo il chip MediaTek M90


Secondo le ultime indiscrezioni, Google Pixel 11 potrebbe rappresentare una svolta nella storia della serie: il modem Samsung, usato fin dal Pixel 6, verrebbe sostituito da una soluzione MediaTek. Nello specifico, si parla del modem M90, progettato per offrire migliori prestazioni energetiche e stabilità nelle comunicazioni. I problemi storici del modem Samsung nei Pixel Sin dall'adozione del chip Tensor, i Pixel hanno adottato il modem Samsung integrato nello stesso package del […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Secondo le ultime indiscrezioni, Google Pixel 11 potrebbe rappresentare una svolta nella storia della serie: il modem Samsung, usato fin dal Pixel 6, verrebbe sostituito da una soluzione MediaTek. Nello specifico, si parla del modem M90, progettato per offrire migliori prestazioni energetiche e stabilità nelle comunicazioni.

I problemi storici del modem Samsung nei Pixel


Sin dall’adozione del chip Tensor, i Pixel hanno adottato il modem Samsung integrato nello stesso package del processore. Nel tempo, questa scelta ha generato critiche per via di problemi ricorrenti: surriscaldamento durante le chiamate 5G, consumo energetico elevato in aree con segnale instabile e, in alcuni mercati, minor stabilità della connessione rispetto alla concorrenza. Questi difetti, segnalati da anni dalla community, hanno minato in parte la reputazione dei Pixel come dispositivi affidabili nel quotidiano.

Cosa porta il modem MediaTek M90


Il MediaTek M90 è un modem di fascia alta progettato con l’efficienza energetica come priorità. Una delle caratteristiche chiave è la capacità di ridurre i controlli di rete non necessari in standby, grazie a un sistema di notifica preventiva dalla rete stessa. Questo si traduce in un minor consumo della batteria nelle situazioni di uso quotidiano. Si prevede inoltre una migliore gestione termica e il supporto alla comunicazione satellitare, aprendo la strada a future funzionalità di connettività di emergenza anche su Pixel.

Implicazioni per sicurezza e aggiornamenti


Il cambio di modem potrebbe avere implicazioni anche sul fronte della sicurezza: il modem è un componente critico dello smartphone e storicamente alcune vulnerabilità nei modem Samsung hanno richiesto patch urgenti. Un fornitore diverso significa una diversa superficie di attacco e, potenzialmente, un ciclo di aggiornamenti più flessibile. Il Pixel 11 è atteso per l’autunno 2026 e potrebbe essere accompagnato da Android 17.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

La nuova mascotte Kit per Firefox ha scatenato un dibattito infuocato a proposito di… Gender!


Anche se, fino ad ora, la notizia è passata almeno da queste parti inosservata, lo scorso 17 marzo Mozilla ha presentato la nuova mascotte che si chiama Kit. Trattasi, come da immagine di apertura e indicazioni fornite, non di una volpe, non di un panda rosso, bensì di un Firefox. Vi chiederete: ma perché parlarne...

🔗 Leggi il post completo

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Oppo Find X9s appare su Geekbench: Dimensity 9500s sotto la scocca e batteria da 7.000 mAh


A pochi giorni dal lancio globale dell'Oppo Find X9 Ultra, un altro membro della famiglia fa la sua comparsa: l'Oppo Find X9s è stato avvistato su Geekbench, rivelando alcune specifiche hardware che confermano un posizionamento leggermente inferiore al modello Ultra ma comunque di altissima fascia. Il chipset: Dimensity 9500s Secondo il profilo Geekbench, il Find X9s monta il processore MediaTek Dimensity 9500s, una variante leggermente ottimizzata del Dimensity 9500 presente sul modello […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

A pochi giorni dal lancio globale dell’Oppo Find X9 Ultra, un altro membro della famiglia fa la sua comparsa: l’Oppo Find X9s è stato avvistato su Geekbench, rivelando alcune specifiche hardware che confermano un posizionamento leggermente inferiore al modello Ultra ma comunque di altissima fascia.

Il chipset: Dimensity 9500s


Secondo il profilo Geekbench, il Find X9s monta il processore MediaTek Dimensity 9500s, una variante leggermente ottimizzata del Dimensity 9500 presente sul modello top. Si tratta comunque di un chip flagship di ultimissima generazione, capace di prestazioni eccellenti sia in gaming che in ambito AI. La differenza con il 9500 “puro” è minima e difficilmente percepibile nel quotidiano.

Scheda tecnica prevista


Dalle indiscrezioni precedenti, si disegna un profilo tecnico molto ambizioso per il Find X9s:

  • Display OLED da circa 6,59 pollici con bordi ultrasottili
  • Batteria da oltre 7.000 mAh con ricarica rapida a 80W
  • Tripla fotocamera posteriore da 50 MP
  • Camera frontale da 32 MP
  • Sistema operativo: ColorOS basato su Android 16


Lancio imminente insieme al Find X9 Ultra


Oppo dovrebbe presentare il Find X9s in concomitanza con il Find X9 Ultra il 21 aprile 2026. La strategia è quella classica di offrire due livelli di premium: il massimo assoluto con l’Ultra, e un’opzione leggermente più accessibile ma comunque flagship con il Find X9s. Per gli utenti Android in cerca di un top di gamma con batteria monumentale, questo dispositivo promette di essere molto interessante.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Galaxy S26 Ultra con Android 17: primo benchmark su Geekbench, prestazioni in calo ma è normale


Il Galaxy S26 Ultra è stato avvistato su Geekbench con a bordo una versione alpha di Android 17 e della nuova interfaccia One UI 9. I risultati mostrano un leggero calo delle prestazioni rispetto alla versione stabile attuale, ma la spiegazione è semplice: il software è ancora lontano dall'ottimizzazione finale. I numeri del benchmark La voce è stata registrata su Geekbench il 17 aprile, con il modello SM-S948B (Galaxy S26 Ultra) che eseguiva un build alpha di One UI 9 basato su Android […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il Galaxy S26 Ultra è stato avvistato su Geekbench con a bordo una versione alpha di Android 17 e della nuova interfaccia One UI 9. I risultati mostrano un leggero calo delle prestazioni rispetto alla versione stabile attuale, ma la spiegazione è semplice: il software è ancora lontano dall’ottimizzazione finale.

I numeri del benchmark


La voce è stata registrata su Geekbench il 17 aprile, con il modello SM-S948B (Galaxy S26 Ultra) che eseguiva un build alpha di One UI 9 basato su Android 17. I risultati ottenuti sono stati 3.608 punti in single-core e 10.829 punti in multi-core. Confrontando con i valori della versione stabile (circa 3.695 single-core e 11.183 multi-core), si registra un calo del 2-3%.

Perché le prestazioni sono inferiori


Non c’è nulla di preoccupante in questo scenario: nelle versioni alpha e beta del software, l’ottimizzazione non è ancora una priorità. Gli ingegneri lavorano prima sulla stabilità e sull’implementazione delle nuove funzionalità. Con l’avanzare del ciclo di sviluppo, i numeri migliorano sistematicamente, e nella versione finale le prestazioni sono solitamente in linea o superiori alla release precedente.

Quando arriverà il beta pubblico di One UI 9?


In base ai tempi storici di Samsung, il programma beta pubblico di One UI 9 potrebbe partire entro la seconda metà di maggio 2026. Gli utenti Galaxy S26 Ultra che vogliono provare le novità di Android 17 in anticipo avranno quindi l’opportunità di farlo abbastanza presto. Android 17 includerà presumibilmente nuove funzionalità di intelligenza artificiale e miglioramenti alla privacy e alla gestione della batteria.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Starlink Direct supporterà LINE: messaggi anche senza copertura di rete, utile per Android


La comunicazione satellitare diretta da smartphone fa un importante passo avanti: Starlink Direct, il servizio che permette agli smartphone di connettersi direttamente ai satelliti SpaceX senza infrastrutture terrestri, aggiungerà il supporto a LINE, una delle app di messaggistica più utilizzate in Asia. La novità è particolarmente rilevante per gli utenti Android che operano in zone con scarsa copertura. Cosa cambia con il supporto a LINE Fino ad ora, Starlink Direct supportava SMS, […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

La comunicazione satellitare diretta da smartphone fa un importante passo avanti: Starlink Direct, il servizio che permette agli smartphone di connettersi direttamente ai satelliti SpaceX senza infrastrutture terrestri, aggiungerà il supporto a LINE, una delle app di messaggistica più utilizzate in Asia. La novità è particolarmente rilevante per gli utenti Android che operano in zone con scarsa copertura.

Cosa cambia con il supporto a LINE


Fino ad ora, Starlink Direct supportava SMS, condivisione della posizione e ricezione di messaggi d’emergenza, oltre ad alcune app selezionate. Con l’aggiornamento previsto per il 21 aprile, LINE verrà ufficialmente aggiunta all’elenco delle app compatibili con la comunicazione dati via satellite. Questo significa che sarà possibile inviare e ricevere messaggi LINE anche in aree senza alcuna copertura cellulare.

Utilissimo in situazioni di emergenza


Il vantaggio principale di questa integrazione riguarda gli scenari estremi: zone montane, aree marine, situazioni di calamità naturale. In questi contesti, poter utilizzare un’app di messaggistica familiare come LINE — senza dover imparare a usare strumenti satellitari dedicati — rappresenta un enorme miglioramento in termini di accessibilità. Gli utenti Android possono beneficiare di questa funzione senza configurazioni aggiuntive, purché il cielo sia visibile.

Espansione del servizio in corso


Il servizio Starlink Direct è attualmente disponibile per i clienti di au e SoftBank in Giappone. NTT Docomo inizierà l’erogazione del servizio a partire dal 27 aprile 2026, anche se il supporto a LINE non è ancora confermato per questo operatore. La strada è comunque tracciata: la comunicazione satellitare diretta da smartphone Android è sempre più reale e sempre più utile.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

PRISMEX: la suite di cyberspionaggio di APT28 che prende di mira Ucraina e alleati NATO con steganografia e cloud C2


APT28 ha lanciato una nuova campagna di cyberspionaggio contro Ucraina e alleati NATO con PRISMEX, una suite di malware inedita che combina steganografia 'Bit Plane Round Robin', COM hijacking e abuso di Filen.io come C2 cifrato. La campagna sfrutta due vulnerabilità Microsoft Office — CVE-2026-21509 e CVE-2026-21513 — con exploit pronti settimane prima della divulgazione pubblica.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Si parla di:
Toggle


Una suite di malware inedita, battezzata PRISMEX, porta la firma del GRU russo e punta diritto al cuore delle reti militari e governative legate al conflitto in Ucraina. La campagna combina steganografia proprietaria, COM hijacking e abuso di cloud storage cifrato per raggiungere i propri obiettivi restando praticamente invisibile agli strumenti di difesa tradizionali.

APT28 nel 2026: evoluzione di una minaccia permanente


APT28 — tracciato anche come Forest Blizzard, Fancy Bear e Pawn Storm — è l’unità cyber attribuita al GRU, l’intelligence militare russa. Operativo da oltre vent’anni, il gruppo ha all’attivo compromissioni di altissimo profilo: dal Partito Democratico USA nel 2016 al WADA, passando per decine di istituzioni europee e governi NATO. Ciò che distingue APT28 è la capacità di weaponizzare vulnerabilità ancora prima della loro divulgazione pubblica e di costruire toolchain modulari estremamente evasive.

La campagna documentata tra febbraio e aprile 2026 da Trend Micro, Zscaler ThreatLabz e Trellix — denominata Operation Neusploit — rappresenta un ulteriore salto qualitativo in questa direzione. L’analisi delle infrastrutture mostra che i preparativi erano in corso da settembre 2025, con exploitation attiva dal gennaio 2026.

I bersagli: una mappa geopolitica della catena logistica NATO


La selezione dei target riflette la precisa intelligence operativa del GRU. La campagna ha colpito organi esecutivi centrali ucraini, servizi di difesa, protezione civile e servizi idrometeorologici; operatori ferroviari polacchi coinvolti nella logistica degli aiuti militari; settore marittimo e trasportistico in Romania, Slovenia e Turchia; partner della filiera di approvvigionamento di munizioni in Slovacchia e Repubblica Ceca; unità droni nelle regioni di Kyiv e Kharkiv. Il denominatore comune è la catena di supporto alle operazioni militari ucraine — la stessa che il Cremlino ha interesse a monitorare e potenzialmente compromettere.

La catena di attacco: due zero-day, un RTF e un server WebDAV


Il vettore iniziale è uno spear-phishing particolarmente contestualizzato: email con lure tematici su addestramenti militari, allerte meteorologiche o contrabbando di armi — argomenti credibili per i destinatari designati. L’allegato è un documento RTF che sfrutta CVE-2026-21509, una vulnerabilità di bypass delle funzionalità di sicurezza di Microsoft Office.

All’apertura, il sistema vittima viene forzato a connettersi a un server WebDAV controllato dagli attaccanti, da cui viene recuperato automaticamente un file LNK malevolo. Questo sfrutta CVE-2026-21513 per bypassare le protezioni del browser ed eseguire silenziosamente il payload successivo. La tempistica è rivelatrice: l’infrastruttura per CVE-2026-21509 era operativa il 12 gennaio 2026, due settimane prima della divulgazione pubblica del 26 gennaio. La patch per CVE-2026-21513 è arrivata il 10 febbraio, lasciando una finestra di undici giorni da zero-day sfruttabile.

Anatomia di PRISMEX: quattro componenti, un ecosistema invisibile


PRISMEX non è un singolo malware ma una suite modulare di quattro componenti progettate per operare in concerto, ciascuna con un ruolo preciso:

  • PrismexSheet: dropper Excel con macro VBA che estrae payload nascosti nel file tramite steganografia. Mostra un documento decoy convincente (inventari droni, listini prezzi militari) per non destare sospetti e stabilisce persistenza via COM hijacking.
  • PrismexDrop: dropper nativo che prepara l’ambiente per lo sfruttamento successivo utilizzando scheduled task e COM DLL hijacking abbinati al riavvio di explorer.exe per la persistenza tra i riavvii.
  • PrismexLoader: proxy DLL che esegue codice malevolo mascherandosi da libreria legittima. Impiega la tecnica steganografica proprietaria “Bit Plane Round Robin” per estrarre payload nascosti all’interno di immagini apparentemente normali, con esecuzione interamente in memoria per minimizzare le tracce su disco.
  • PrismexStager: implant .NET basato sul framework Covenant, fortemente offuscato con nomi di funzione randomizzati. Comunica con i server C2 abusando di Filen.io, un servizio di cloud storage cifrato legittimo, rendendo il traffico malevolo indistinguibile da normali operazioni cloud.

In alcuni scenari di attacco è stato rilevato anche il deployment di MiniDoor, uno stealer specificamente progettato per l’esfiltrazione di email da Microsoft Outlook — un indicatore diretto del tipo di intelligence ricercata.

Living-off-the-Cloud: Filen.io come infrastruttura C2


L’abuso di Filen.io come canale C2 rappresenta una raffinata applicazione del paradigma Living-off-the-Cloud (LotC). Filen.io offre storage cifrato end-to-end, rendendo l’ispezione del contenuto del traffico particolarmente difficile anche per soluzioni avanzate di network detection. I sistemi di filtraggio basati su reputazione IP o domain non rilevano anomalie poiché il dominio è genuinamente legittimo e ampiamente utilizzato. Questa strategia, già osservata con OneDrive, Google Drive e Dropbox in campagne APT precedenti, viene qui applicata con un servizio meno noto e con cifratura robusta — un ostacolo aggiuntivo per i Blue Team.

Indicatori di compromissione (IOC)

# Domini usati per hosting/delivery degli exploit Office
wellnessmedcare[.]org
wellnesscaremed[.]com
freefoodaid[.]com
longsauce[.]com

# CVE sfruttate nella campagna
CVE-2026-21509 - Microsoft Office Security Feature Bypass
  Divulgazione pubblica: 26 gennaio 2026
  Infrastruttura attaccante attiva dal: 12 gennaio 2026

CVE-2026-21513 - Browser Security Feature Bypass
  Prime sample osservate: 30 gennaio 2026
  Patch Microsoft: 10 febbraio 2026 (finestra 0-day: 11 giorni)

# C2 infrastructure
Filen.io (cloud storage legittimo abusato per C2 cifrato)

# Framework C2 utilizzato
Covenant (Grunt implant) tramite PrismexStager

# Tecniche MITRE ATT&CK
T1566.001 - Spearphishing Attachment
T1221   - Template Injection (RTF)
T1574.001 - COM DLL Hijacking (PrismexDrop, PrismexSheet)
T1027.003 - Steganography: Bit Plane Round Robin (PrismexLoader)
T1053.005 - Scheduled Task/Job: Scheduled Task
T1102.002 - Web Service: Bidirectional Communication (Filen.io C2)
T1218.011 - Signed Binary Proxy Execution (Rundll32)

Consigli pratici per i difensori


La campagna PRISMEX evidenzia quanto i modelli di difesa basati su firme statiche e reputazione siano inadeguati contro attori di questo livello. Per i team di sicurezza che operano in settori ad alto rischio è essenziale: applicare immediatamente le patch CVE-2026-21509 e CVE-2026-21513 se non già fatto; monitorare comportamenti anomali di processi legittimi come explorer.exe, regsvr32 e processi COM; implementare regole di detection per COM hijacking e creazione non autorizzata di scheduled task; bloccare o monitorare il traffico verso servizi di cloud storage non approvati aziendalmente (incluso Filen.io); disabilitare le macro VBA nei documenti Office provenienti da fonti esterne tramite Group Policy o Intune; adottare una postura “assume breach” con hunting proattivo su anomalie comportamentali piuttosto che su indicatori statici.

Questa voce è stata modificata (2 settimane fa)

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Xperia 1 VIII: spunta un leak per la colorazione rossa, arriva da un insolito documento di pagamento


Un'insolita fonte ha riportato alla luce nuove indiscrezioni su Xperia 1 VIII, il prossimo flagship di Sony. Tutto è partito da un'immagine condivisa su un gruppo Facebook dedicato ai fan del brand giapponese, nella quale era visibile una ricevuta di pagamento con una descrizione molto particolare. Il documento di pagamento che ha scatenato le speculazioni Il post, condiviso dall'amministratore di un gruppo Facebook di appassionati Sony (presumibilmente il proprietario di un negozio […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Un’insolita fonte ha riportato alla luce nuove indiscrezioni su Xperia 1 VIII, il prossimo flagship di Sony. Tutto è partito da un’immagine condivisa su un gruppo Facebook dedicato ai fan del brand giapponese, nella quale era visibile una ricevuta di pagamento con una descrizione molto particolare.

Il documento di pagamento che ha scatenato le speculazioni


Il post, condiviso dall’amministratore di un gruppo Facebook di appassionati Sony (presumibilmente il proprietario di un negozio autorizzato), mostrava una transazione finanziaria con una nota in vietnamita: “Chuyen tien coc sony 1viii slot 6 mau do”, traducibile come “acconto per Sony Xperia 1 VIII, slot 6, colore rosso”. L’espressione “mau do” in vietnamita indica proprio il rosso.

Un colore mai visto prima per la serie


La notizia ha subito fatto il giro dei forum internazionali perché, storicamente, la serie Xperia 1 non ha mai incluso una variante rossa nel suo lineup. Questo ha alimentato sia l’entusiasmo che lo scetticismo della community. Lo stesso autore del post, di fronte alle domande degli utenti, ha risposto che si trattava solo di contenuto condiviso senza particolari implicazioni.

Leak credibile o semplice errore?


Al momento non è possibile stabilire con certezza se si tratti di una fuga di notizie autentica su un nuovo colore non annunciato, di un errore nella trascrizione del pagamento, o semplicemente di un’informazione inventata. Quello che è certo è che Xperia 1 VIII è atteso per la primavera-estate 2026, e le voci su un restyling del design stanno aumentando. L’eventuale introduzione di una colorazione rossa rappresenterebbe una svolta significativa per un brand che ha sempre puntato su palette piuttosto sobrie.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Come GitHub usa eBPF per rendere i deploy sicuri: architettura e implementazione


GitHub ha risolto il problema delle dipendenze circolari nei deploy usando eBPF: una tecnologia kernel-level che filtra il traffico di rete per processo, senza modificare gli script esistenti.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Quando si parla di deployment safety, pochi casi studio sono più istruttivi di quello di GitHub: un’azienda che ospita il proprio codice sorgente sulla piattaforma che sta cercando di aggiornare. Questo crea una dipendenza circolare potenzialmente devastante — durante un’interruzione del servizio, il deploy che dovrebbe ripristinarlo potrebbe fallire proprio perché si appoggia alla piattaforma non disponibile.

Un recente articolo del blog di ingegneria di GitHub descrive come il team abbia risolto questo problema usando eBPF (extended Berkeley Packet Filter), una tecnologia kernel Linux che permette di eseguire codice sandboxed direttamente nel kernel senza modificarlo.

Il problema delle dipendenze nei deploy


GitHub ha identificato tre categorie di dipendenze problematiche nei propri script di deploy:

  • Dipendenze dirette: script che scaricano binari da github.com durante il deploy
  • Dipendenze nascoste: tool che controllano aggiornamenti su GitHub senza una richiesta esplicita
  • Dipendenze transitive: servizi interni che chiamano dipendenze esterne in modo indiretto

Il rischio è evidente: se github.com non è disponibile e il deploy ne dipende, si entra in un loop da cui è difficile uscire. Serviva un meccanismo per rilevare — e bloccare — queste dipendenze prima che causassero problemi in produzione.

eBPF: filtraggio kernel-level senza modificare il kernel


eBPF è un framework che consente di iniettare programmi nel kernel Linux in modo sicuro e verificato. Originariamente nato per il filtraggio dei pacchetti di rete (da cui il nome “Berkeley Packet Filter”), si è evoluto in una piattaforma generale per osservabilità, sicurezza e networking a bassa latenza.

GitHub ha sfruttato due tipi specifici di programmi eBPF:

  • BPF_PROG_TYPE_CGROUP_SKB: monitora il traffico in uscita (egress) e applica regole di blocco IP basate sui risultati della risoluzione DNS
  • BPF_PROG_TYPE_CGROUP_SOCK_ADDR: intercetta le query DNS e le reindirizza a un proxy userspace che valuta le richieste rispetto a una lista di domini bloccati

I cgroup Linux vengono usati per isolare i processi di deploy. A questi cgroup vengono poi agganciate (attached) le mappe e i programmi eBPF, che possono così osservare e controllare il traffico di rete generato da quei processi specifici.

L’architettura del sistema


Il flusso di funzionamento è il seguente:

  1. Un processo di deploy tenta di risolvere un nome di dominio (es. github.com)
  2. Il programma eBPF intercetta la query DNS tramite BPF_PROG_TYPE_CGROUP_SOCK_ADDR
  3. La query viene reindirizzata a un proxy userspace
  4. Il proxy verifica il dominio rispetto alla policy attiva
  5. Se il dominio è nella lista bloccata, la risposta viene falsificata (restituendo un IP non raggiungibile)
  6. Il programma BPF_PROG_TYPE_CGROUP_SKB monitora il traffico IP per rafforzare il blocco
  7. Tutte le violazioni vengono loggate con PID, nome del processo, comando e transaction ID DNS

Particolarmente elegante è l’uso di mappe eBPF (BPF maps) per condividere stato tra i programmi kernel e il proxy userspace, consentendo aggiornamenti dinamici alla policy senza dover ricaricare i programmi.

Implementazione con cilium/ebpf e Go


Per semplificare lo sviluppo, il team ha usato la libreria Go cilium/ebpf, uno dei wrapper eBPF più maturi disponibili oggi. I programmi eBPF sono scritti in C e compilati con bpf2go, uno strumento che genera automaticamente le struct Go corrispondenti per interagire con le mappe e i programmi nel kernel.

Un esempio semplificato di come si carica e aggancia un programma eBPF con cilium/ebpf:

// Carica i programmi eBPF compilati
objs := bpfObjects{}
if err := loadBpfObjects(&objs, nil); err != nil {
    log.Fatalf("loading objects: %v", err)
}
defer objs.Close()

// Aggancia il programma al cgroup del processo di deploy
l, err := link.AttachCgroup(link.CgroupOptions{
    Path:    "/sys/fs/cgroup/deploy",
    Attach:  ebpf.AttachCGroupInetEgress,
    Program: objs.FilterEgress,
})
if err != nil {
    log.Fatalf("attaching cgroup: %v", err)
}
defer l.Close()

log.Println("eBPF program attached, monitoring egress traffic...")

La policy viene aggiornata dinamicamente scrivendo nelle mappe eBPF, senza necessità di riavviare nulla:
// Blocca un dominio aggiungendolo alla mappa eBPF
key := []byte("github.com")
value := uint32(1) // 1 = blocked
if err := objs.BlockedDomains.Put(key, value); err != nil {
    log.Fatalf("updating map: %v", err)
}

Questo approccio consente di modificare le policy a runtime, ad esempio durante un incidente, aggiungendo o rimuovendo domini dalla blocklist senza interrompere i processi in esecuzione.

Correlazione PID e DNS transaction ID


Uno degli aspetti più sofisticati dell’implementazione è la capacità di correlare le query DNS bloccate al processo specifico che le ha generate. Il sistema usa una mappa eBPF per tenere traccia della coppia (PID, DNS transaction ID): quando il proxy userspace vede una query, può risalire al processo che l’ha originata e loggare il percorso completo dell’esecuzione, incluso il comando invocato.

Questo livello di visibilità è fondamentale per il debugging: anziché sapere solo che “qualcosa ha chiamato github.com”, gli ingegneri possono vedere esattamente quale script, a quale riga, stava tentando di accedere alla risorsa bloccata.

Risultati dopo sei mesi di rollout


Dopo sei mesi di utilizzo in produzione, il sistema ha permesso a GitHub di:

  • Rilevare dipendenze problematiche prima che causino guasti durante i deploy
  • Identificare tool e script che accedevano silenziosamente a github.com durante le operazioni di deploy
  • Migliorare la velocità di recovery dagli incidenti, eliminando la circolarità delle dipendenze
  • Costruire un inventario delle dipendenze esterne degli script di deploy, utile per la pianificazione della resilienza


Perché eBPF è la scelta giusta per questo caso d’uso


Soluzioni alternative avrebbero avuto limitazioni significative: un firewall a livello di rete avrebbe bloccato il traffico in modo troppo grossolano, impedendo anche il normale funzionamento dei servizi. Proxy applicativi avrebbero richiesto modifiche agli script di deploy. eBPF consente invece di applicare policy granulari, per-processo e dinamiche, senza modificare gli script esistenti né aggiungere overhead significativo alle operazioni normali.

Il fatto che sia una tecnologia kernel-level la rende anche difficile da aggirare accidentalmente: non è sufficiente usare una libreria di networking alternativa o bypassare il resolver DNS del sistema per evadere i controlli.

Conclusioni


L’approccio di GitHub dimostra come eBPF stia trasformando la sicurezza e l’osservabilità delle infrastrutture moderne. Non più solo strumento per profiling di rete, eBPF diventa un componente architetturale per l’enforcement di policy a runtime, invisibile alle applicazioni e aggiornabile senza downtime.

Per chi gestisce infrastrutture critiche o pipeline CI/CD complesse, questo caso studio offre un modello replicabile: usare eBPF per imporre vincoli ai processi di deploy e garantire che il sistema possa sempre ripristinarsi indipendentemente dallo stato dei servizi che ospita.

Fonte: How GitHub uses eBPF to improve deployment safety — GitHub Engineering Blog

Questa voce è stata modificata (2 settimane fa)

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

SmokedHam e UNC2465: il backdoor dei ransomware operator che si nasconde nei tool IT più usati dagli amministratori


Orange Cyberdefense ha documentato una campagna di malvertising attiva nel 2026 in cui UNC2465, gruppo affiliato a DarkSide, LockBit e Qilin, distribuisce il backdoor SmokedHam tramite falsi installer di PuTTY, RVTools e altri tool IT. L'obiettivo finale è il ransomware.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Se siete amministratori di sistema e avete cercato su Google uno strumento come PuTTY, RVTools o Remote Desktop Manager nelle ultime settimane, potreste aver incontrato un annuncio pubblicitario che conduceva a una versione modificata del software, contenente un backdoor. È la tecnica di malvertising che il gruppo criminale UNC2465 ha affinato nel tempo, e che Orange Cyberdefense ha documentato in una nuova serie di attacchi condotti nel 2026 contro organizzazioni europee.

Chi è UNC2465: dai ex affiliati DarkSide agli operator Qilin


UNC2465 è un cluster di attività tracciato da Mandiant fin dal 2019. Il gruppo ha guadagnato notorietà come affiliato del ransomware DarkSide — lo stesso che colpì Colonial Pipeline nel 2021 causando una crisi energetica negli Stati Uniti. Dopo lo scioglimento di DarkSide, UNC2465 ha mantenuto la propria operatività affiliandosi con LockBit e, più recentemente, con Qilin (noto anche come Agenda ransomware), uno dei gruppi ransomware in più rapida crescita nel panorama della cybercriminalità organizzata.

Ciò che distingue UNC2465 da molti altri attori del crimine informatico è la sofisticazione operativa: il gruppo non si affida a exploit zero-day, ma a una combinazione di malvertising, trojanizzazione di software legittimo e tecniche di blending con attività normali — incluso l’uso di bossware commerciale legale per mascherare le proprie azioni malevole.

Il vettore: annunci di ricerca malevoli per tool IT


La campagna documentata da Orange Cyberdefense nel febbraio-aprile 2026 si basa su un meccanismo collaudato: acquistare spazi pubblicitari su motori di ricerca come Google e Bing per intercettare le ricerche di strumenti IT ampiamente utilizzati da system administrator e IT manager. I tool impersonati includono:

  • PuTTY e KiTTY — client SSH tra i più usati al mondo
  • RVTools — tool di inventario VMware indispensabile in ambienti virtualizzati
  • Remote Desktop Manager — gestore di sessioni RDP diffusissimo
  • Zoho Assist — software di supporto remoto
  • Total Commander — file manager Windows
  • Advanced IP Scanner — scanner di rete molto popolare

Il meccanismo è infido perché gli amministratori di sistema sono abituati a scaricare questi tool di frequente, spesso su nuove macchine, e la fiducia nel brand del software abbassa la guardia. Un click sull’annuncio — che compare sopra i risultati organici — porta a un dominio malevolo con un installer visivamente identico all’originale.

Anatomia di SmokedHam: il backdoor che evolve continuamente


Il payload distribuito tramite gli installer trojanizzati è SmokedHam (tracciato da ConnectWise anche come Parcel RAT), un backdoor basato su PowerShell e C# attivo dalla fine del 2019. Nelle versioni più recenti, SmokedHam è stato snellito rispetto alle prime varianti: la funzionalità di screen capture è stata rimossa e il keylogger è presente ma disattivato. L’obiettivo primario del backdoor, nella fase attuale, è quello di stabilire un canale C2 persistente e ricevere comandi PowerShell da eseguire.

Questa semplicità apparente è in realtà una scelta strategica: un backdoor minimale è più difficile da rilevare. La complessità dell’attacco viene delegata agli strumenti post-exploitation che vengono scaricati successivamente.

Il flusso di attacco dettagliato


L’installer NSIS (Nullsoft Scriptable Install System) scaricato dalla vittima esegue simultaneamente due operazioni: installa il software legittimo (per non insospettire l’utente) e avvia silenziosamente la catena di compromissione.

  • I file vengono estratti in C:\ProgramData\LogConverter\
  • La persistenza viene stabilita tramite una chiave di registro Run che punta a Microsoft.NodejsTools.PressAnyKey.lnk — un abuso di un binario legittimo di Visual Studio (LOLBin)
  • PowerShell esegue comandi offuscati per caricare SmokedHam direttamente in memoria (fileless)
  • Il backdoor contatta i propri server C2 nascosti dietro Cloudflare Workers e endpoint AWS, rendendo il traffico indistinguibile da comunicazioni legittime verso cloud provider


Il bossware come copertura: la tecnica più insidiosa


Una delle caratteristiche più originali di UNC2465, segnalata dal CERT di Orange Cyberdefense, è l’uso di software di monitoraggio dei dipendenti — il cosiddetto bossware — per mimetizzare le proprie attività malevole. Tool come ControlioNet e Teramind, normalmente impiegati dai datori di lavoro per monitorare la produttività, vengono installati dagli attaccanti sui sistemi compromessi. Poiché questi software sono commerciali, firmati e spesso già presenti nelle whitelist aziendali, le loro comunicazioni di rete e le loro funzioni (screenshot, keylogging, accesso remoto) non vengono flaggate come anomale.

In questa maniera, UNC2465 può condurre ricognizione prolungata, esfiltrare credenziali e preparare il terreno per il ransomware finale rimanendo sotto il radar per settimane o mesi.

Indicatori di compromissione (IoC)

# Domini C2 SmokedHam/Parcel RAT (Cloudflare Workers)
cloud-9cd9.wtf-system.workers[.]dev
cdn-adv.systems-scanner.workers[.]dev
cdn-cloude.extended-system.workers[.]dev
# Pattern comune: cdn-*.workers[.]dev con nomi che imitano CDN legittimi

# Directory di installazione sospetta
C:\ProgramData\LogConverter\

# Persistenza via registro
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  → Microsoft.NodejsTools.PressAnyKey.lnk

# LOLBin abusato
Microsoft.NodejsTools.PressAnyKey.exe (legittimo ma usato come launcher)

# Installer firmato sospetto
Firma: LLC DIAPROM (distribuito su domini che imitano siti ufficiali)

# Bossware da monitorare se non autorizzato
ControlioNet, Teramind

Raccomandazioni per i difensori


La campagna UNC2465 pone sfide particolari perché prende di mira esattamente le persone che si occupano di sicurezza e amministrazione dei sistemi. Ecco le contromisure più efficaci:

  • Download dai soli siti ufficiali: abituare tutti gli amministratori a scaricare tool esclusivamente dai siti ufficiali o tramite package manager interni verificati. Mai dal primo risultato di un motore di ricerca
  • Blocco degli annunci nei browser aziendali: implementare un ad-blocker a livello di DNS (Pi-hole, NextDNS, filtering proxy) per eliminare il vettore primario di questa campagna
  • Application allowlisting: garantire che solo software approvato possa essere eseguito, prevenendo l’installazione di bossware non autorizzato
  • Monitoraggio Cloudflare Workers: alert su connessioni verso domini *.workers.dev non presenti nelle baseline del traffico aziendale
  • Verifica degli hash prima dell’esecuzione: confrontare gli hash SHA-256 degli installer con quelli pubblicati dai vendor prima dell’installazione
  • EDR con analisi comportamentale: rilevare l’abuso di LOLBin come Microsoft.NodejsTools.PressAnyKey.exe e l’esecuzione di PowerShell offuscato

UNC2465 rappresenta un caso di studio esemplare su come i gruppi criminali di alto livello combinino tecniche di accesso iniziale mutuate dal cybercrime di massa (malvertising) con operazioni post-compromise da APT. L’obiettivo finale — il ransomware — arriva solo dopo un lungo periodo di radicamento silenzioso nella rete bersaglio. La prevenzione deve quindi concentrarsi sul vettore iniziale: un download sbagliato può compromettere un’intera infrastruttura.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

AOT-Friendly DTO Mapping in .NET: Source Generators al posto della reflection


Come implementare il mapping tra oggetti in .NET senza reflection grazie a ElBruno.AotMapper e i Roslyn Source Generators, per garantire compatibilità con NativeAOT e il trimming.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Con l’adozione crescente di NativeAOT e il trimming in .NET, uno dei nodi critici per molti progettisti è la gestione del mapping tra oggetti: le librerie classiche come AutoMapper si basano pesantemente sulla reflection a runtime, che è incompatibile con la compilazione Ahead-of-Time. In questo articolo esploreremo ElBruno.AotMapper, una libreria che risolve il problema spostando la generazione del codice di mapping a compile time grazie ai Roslyn Source Generators.

Il problema: reflection e AOT non vanno d’accordo


Quando si compila un’applicazione .NET con PublishAot=true oppure si abilita il trimming aggressivo, il runtime non può più analizzare dinamicamente i tipi come farebbe normalmente. Le librerie che usano System.Reflection per scoprire proprietà e invocare setter al volo — come AutoMapper nella sua configurazione classica — provocano errori in fase di esecuzione o vengono tagliate dal trimmer.

Le alternative tradizionali per chi vuole restare AOT-compatible sono:

  • Scrivere il mapping a mano (tedioso e soggetto a errori)
  • Usare Mapster con configurazione esplicita (verbosa)
  • Affidarsi a Source Generators che generano il codice prima della compilazione

ElBruno.AotMapper percorre la terza strada: usa un Source Generator basato su Roslyn per emettere metodi di estensione fortemente tipizzati già al momento del build, con zero reflection a runtime.

Come funziona: Source Generators al posto della reflection


I Roslyn Source Generators sono componenti che vengono eseguiti durante la compilazione e possono produrre file C# aggiuntivi. In questo caso, il generator analizza le vostre classi annotate con attributi specifici e genera automaticamente i metodi di mapping corrispondenti.

I vantaggi concreti di questo approccio:

  • Gli errori di mapping emergono in fase di compilazione, non a runtime
  • Zero overhead da reflection: il codice generato è codice C# diretto, ottimizzabile dal JIT o dall’AOT compiler
  • Compatibilità completa con NativeAOT e applicazioni trimmate
  • Il codice generato è visibile e debuggabile (potete ispezionarlo nelle cartelle di build)


Installazione


La libreria si divide in due package NuGet distinti:

# Attributi e interfacce core
dotnet add package ElBruno.AotMapper

# Il Source Generator (solo per il progetto che contiene i DTO)
dotnet add package ElBruno.AotMapper.Generator

Il Generator va aggiunto come PrivateAssets="all" in genere, per evitare che la dipendenza si propaghi ai progetti dipendenti:
<PackageReference Include="ElBruno.AotMapper.Generator" Version="x.y.z">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>

Utilizzo degli attributi di mapping

Mapping base con [MapFrom]


Il caso più semplice: due classi con le stesse proprietà. Si annota il DTO destinazione con [MapFrom] specificando il tipo sorgente:

// Entità del dominio
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public DateTime CreatedAt { get; set; }
}

// DTO di risposta annotato
[MapFrom(typeof(Product))]
public class ProductDto
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
}

Il Source Generator analizza questo codice e genera automaticamente un metodo di estensione. Dopo la compilazione potrete usarlo così:
var product = await dbContext.Products.FindAsync(id);
var dto = product.ToProductDto(); // Metodo generato, zero reflection

Rimappatura di proprietà con [MapProperty]


Quando i nomi delle proprietà non corrispondono tra sorgente e destinazione, si usa [MapProperty] per indicare esplicitamente il mapping:

[MapFrom(typeof(User))]
public class UserSummaryDto
{
    public int Id { get; set; }

    [MapProperty(nameof(User.FirstName))]
    public string Nome { get; set; } = string.Empty;  // Diverso da FirstName

    [MapProperty(nameof(User.LastName))]
    public string Cognome { get; set; } = string.Empty;
}

Ignorare proprietà con [MapIgnore]


Per escludere campi sensibili o non necessari:

[MapFrom(typeof(User))]
public class PublicUserDto
{
    public int Id { get; set; }
    public string UserName { get; set; } = string.Empty;

    [MapIgnore]
    public string? PasswordHash { get; set; }  // Non verrà mappato
}

Conversioni custom con [MapConverter]


Per logiche di conversione non banali, si implementa IMapConverter<TSource, TDestination>:

public class PriceToStringConverter : IMapConverter<decimal, string>
{
    public string Convert(decimal source) => source.ToString("C2");
}

[MapFrom(typeof(Product))]
public class ProductDisplayDto
{
    public string Name { get; set; } = string.Empty;

    [MapConverter(typeof(PriceToStringConverter))]
    public string FormattedPrice { get; set; } = string.Empty;
}

Integrazione in un Minimal API ASP.NET Core


Il package AspNetCore della libreria facilita l’integrazione con Dependency Injection. Ecco un esempio completo di endpoint:

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<AppDbContext>(...);

var app = builder.Build();

app.MapGet("/products/{id}", async (int id, AppDbContext db) =>
{
    var product = await db.Products.FindAsync(id);
    if (product is null) return Results.NotFound();

    // ToProductDto() è un metodo generato dal Source Generator
    return Results.Ok(product.ToProductDto());
});

app.Run();

Quando si pubblica con dotnet publish -r win-x64 -p:PublishAot=true, il codice di mapping generato viene incluso senza problemi perché è codice C# statico, non reflection dinamica.

Considerazioni pratiche


La libreria è indicata soprattutto per chi:

  • Sta migrando applicazioni verso NativeAOT o vuole abilitare il trimming
  • Sviluppa microservizi con startup time critico (AOT avvia le app molto più velocemente)
  • Preferisce avere errori di mapping evidenziati a compile time
  • Vuole ispezionare il codice generato per capire esattamente cosa succede

La libreria è ancora in evoluzione (work-in-progress secondo l’autore), quindi prima di adottarla in produzione è consigliabile valutare alternative mature come Mapperly, anch’essa basata su Source Generators e con una community più consolidata. Detto questo, ElBruno.AotMapper è un ottimo punto di partenza per capire come funziona il mapping AOT-friendly e i Source Generators in generale.

Conclusione


Il passaggio a NativeAOT e al trimming in .NET è una tendenza inesorabile, specialmente per applicazioni cloud-native e microservizi che richiedono avvio rapido e footprint ridotto. Le librerie di mapping basate su reflection appartengono a un’era che sta tramontando: i Source Generators sono il futuro, e ElBruno.AotMapper mostra come si possa risolvere un problema pratico quotidiano — il mapping DTO — con questo approccio moderno.

Se volete esplorare ulteriormente l’argomento, la documentazione ufficiale di Roslyn Source Generators è disponibile su Microsoft Learn, e il progetto di riferimento industriale è Mapperly.


Fonte originale: AOT-Friendly DTO Mapping in .NET – El Bruno

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Xperia 1 VIII con fotocamera quadrata: i fan sono divisi ma la maggioranza aspetta di vedere il prodotto finito


Il design del prossimo flagship Sony potrebbe essere radicalmente diverso da quanto visto finora. Le indiscrezioni su Xperia 1 VIII parlano di un modulo fotocamera quadrato sul retro, abbandonando la storica disposizione verticale delle lenti. Un sondaggio condotto sul social X ha raccolto le opinioni degli utenti, con risultati sorprendentemente equilibrati. Il sondaggio: chi aspetta e chi ha già deciso Il sondaggio, promosso dall'account SUMAHO-DIGEST su X, ha chiesto agli utenti se […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il design del prossimo flagship Sony potrebbe essere radicalmente diverso da quanto visto finora. Le indiscrezioni su Xperia 1 VIII parlano di un modulo fotocamera quadrato sul retro, abbandonando la storica disposizione verticale delle lenti. Un sondaggio condotto sul social X ha raccolto le opinioni degli utenti, con risultati sorprendentemente equilibrati.

Il sondaggio: chi aspetta e chi ha già deciso


Il sondaggio, promosso dall’account SUMAHO-DIGEST su X, ha chiesto agli utenti se acquisterebbero uno Xperia 1 VIII con design a fotocamera quadrata. I risultati mostrano una netta prevalenza di chi preferisce rimandare la decisione:

  • Lo comprerei comunque: 19,8%
  • Non lo comprerei: 21,6%
  • Dipende dal design del prodotto reale: 34,2%
  • Dipende da prezzo e specifiche: 24,3%

La fascia più numerosa, oltre il 34%, vuole vedere il prodotto finito prima di esprimere un giudizio. Sommando chi è indeciso per motivi di design con chi attende prezzo e specifiche, si supera ampiamente la metà degli intervistati. Un segnale chiaro: la curiosità c’è, ma il giudizio è sospeso.

Pochi rifiuti categorici, molti “aspettiamo”


Uno degli aspetti più interessanti del sondaggio è che solo il 21,6% degli utenti ha dichiarato di non voler acquistare il dispositivo. Nonostante il cambio di design rappresenti una rottura netta con la tradizione Xperia, la maggioranza non chiude la porta. Questo suggerisce che il brand Sony conserva ancora una buona credibilità, e che gli utenti sono disposti a valutare il nuovo design senza pregiudizi, purché la qualità complessiva sia all’altezza.

Cosa sappiamo del design di Xperia 1 VIII


Secondo i leak circolati finora, il retro di Xperia 1 VIII potrebbe presentare un modulo fotografico quadrato che raggruppa le lenti in un unico blocco compatto, abbandonando la classica colonna verticale che caratterizzava i modelli precedenti. Le immagini trapelate su Weibo mostravano anche altri elementi familiari dell’ecosistema Xperia: il logo ZEISS, il tasto fisico per l’otturatore, il sensore di impronte integrato nel tasto di accensione e persino il jack per le cuffie da 3,5 mm.

Una svolta storica per Sony?


Se confermato, il nuovo layout rappresenterebbe la modifica estetica più significativa per la serie Xperia 1 negli ultimi anni. In precedenza si era ipotizzato un layout simile a quello di Xperia 10 VII, con lenti disposte orizzontalmente, ma i leak più recenti indicano invece una soluzione a modulo quadrato. Sony dovrà convincere il suo pubblico storico che il cambiamento vale la pena: la qualità fotografica, il prezzo competitivo e l’esperienza d’uso saranno determinanti per il successo del modello.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Le notizie minori del mondo GNU/Linux e dintorni della settimana nr 16/2026


Ogni settimana, il mondo del software libero e open source ci offre una moltitudine di aggiornamenti e nuove versioni di software. Anche se non tutti sono di grande rilevanza, molti di questi possono risultare...

🔗 Leggi il post completo

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Galaxy Z TriFold 2: nuovo design delle cerniere per uno smartphone tri-fold ancora più sottile


Samsung non si ferma nell'evoluzione degli smartphone pieghevoli. Secondo nuove indiscrezioni provenienti dalla catena di approvvigionamento, il prossimo Galaxy Z TriFold 2 sarà dotato di un sistema di cerniere completamente riprogettato, con l'obiettivo di ridurre ulteriormente lo spessore del dispositivo rispetto al modello precedente. Cerniere inedite per uno spessore record Il cuore dell'aggiornamento sarebbe proprio il meccanismo di chiusura: le fonti parlano di una cerniera […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Samsung non si ferma nell’evoluzione degli smartphone pieghevoli. Secondo nuove indiscrezioni provenienti dalla catena di approvvigionamento, il prossimo Galaxy Z TriFold 2 sarà dotato di un sistema di cerniere completamente riprogettato, con l’obiettivo di ridurre ulteriormente lo spessore del dispositivo rispetto al modello precedente.

Cerniere inedite per uno spessore record


Il cuore dell’aggiornamento sarebbe proprio il meccanismo di chiusura: le fonti parlano di una cerniera “completamente nuova”, progettata appositamente per la struttura tri-fold che caratterizza questo modello. Nel caso di uno smartphone con tre pannelli e due punti di piegatura, la cerniera è il componente più critico in termini di ingombro, resistenza e affidabilità nel tempo.

Il Galaxy Z TriFold originale presentava uno spessore di circa 3,9–4,2 mm da aperto e di circa 12,9 mm quando chiuso. L’obiettivo per la versione 2 sarebbe quello di spingere questi valori ancora più in basso, avvicinandosi alle dimensioni degli smartphone tradizionali.

La tecnologia si estenderà all’intera gamma Galaxy Z


Le novità non riguarderanno solo il TriFold 2. Stando alle stesse fonti, la nuova soluzione tecnica per le cerniere potrebbe essere adottata anche dagli altri modelli della linea pieghevole Samsung. In particolare, si parla di una possibile integrazione su Galaxy Z Fold 8 e Galaxy Z Flip 8, aprendo la strada a uno spessore ridotto su tutta la gamma.

Si tratterebbe di un passo importante: le cerniere sono da sempre uno dei principali limiti tecnici degli smartphone pieghevoli, sia per le dimensioni che per la longevità. Un sistema più compatto e robusto potrebbe migliorare significativamente l’esperienza d’uso quotidiana.

Il primo TriFold aveva una distribuzione limitata


Il Galaxy Z TriFold di prima generazione era stato lanciato con disponibilità molto limitata, accessibile solo in alcuni mercati selezionati. Nonostante le recensioni positive sulla qualità costruttiva e la rigidità delle cerniere, il dispositivo non è mai diventato un prodotto di largo consumo.

Attesa per un lancio globale


Con il TriFold 2, Samsung punta a correggere questa situazione. Oltre alle migliorie tecniche, si spera in una distribuzione più ampia a livello internazionale. Se così fosse, il formato tri-fold potrebbe finalmente raggiungere un pubblico più vasto e segnare una svolta nel mercato degli smartphone pieghevoli premium. La sfida per Samsung è dimostrare che la piegatura in tre non è solo un esercizio di stile, ma una soluzione pratica e duratura per l’utente di tutti i giorni.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

PayoutsKing: il ransomware che si nasconde in una macchina virtuale per eludere gli antivirus


Un nuovo gruppo criminale sfrutta QEMU per eseguire una macchina virtuale nascosta nei sistemi compromessi, rendendo il ransomware PayoutsKing praticamente invisibile agli strumenti di sicurezza endpoint. Un'analisi tecnica dettagliata delle campagne STAC4713 e STAC3725.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Un gruppo criminale noto come GOLD ENCOUNTER ha trovato un modo per rendere il proprio ransomware quasi invisibile agli strumenti di sicurezza endpoint: eseguire tutte le operazioni malevole all’interno di una macchina virtuale creata silenziosamente sui sistemi delle vittime. Il ransomware PayoutsKing, attivo da novembre 2025, sfrutta QEMU — un emulatore open source legittimo — per nascondere ogni traccia dell’attacco al di fuori del perimetro di visibilità delle soluzioni EDR e antivirus.

Il contesto: quando la virtualizzazione diventa un’arma


La tecnica di utilizzare macchine virtuali per eludere i controlli di sicurezza non è del tutto nuova: già nel 2025 diversi gruppi ransomware avevano sperimentato l’abuso di hypervisor legittimi come VMware ESXi. Ma il gruppo GOLD ENCOUNTER ha portato questa tattica a un nuovo livello di raffinatezza, usando QEMU — uno strumento open source normalmente impiegato da sviluppatori e ricercatori — per creare ambienti virtuali nascosti direttamente sui sistemi Windows delle vittime.

I ricercatori di Secureworks, che tracciano le operazioni di GOLD ENCOUNTER, hanno identificato due campagne distinte: STAC4713 (attiva da novembre 2025) e STAC3725 (identificata da febbraio 2026), entrambe caratterizzate dall’uso di QEMU come vettore di persistenza e comando-e-controllo. Secondo alcune analisi, il gruppo potrebbe avere legami con ex affiliati di BlackBasta.

Come funziona l’attacco: dalla compromissione alla VM nascosta


Il vettore di accesso iniziale varia a seconda della campagna. In STAC4713, gli attaccanti hanno sfruttato principalmente dispositivi SonicWall VPN esposti senza autenticazione a più fattori e, in almeno un incidente documentato a gennaio 2026, la vulnerabilità CVE-2025-26399 in SolarWinds Web Help Desk. La campagna STAC3725, invece, ha fatto leva su CitrixBleed2, la seconda iterazione della vulnerabilità NetScaler che ha colpito migliaia di organizzazioni.

Una volta ottenuto l’accesso iniziale, gli attori procedono con una sequenza di azioni strutturata:

  • Creazione di un scheduled task denominato TPMProfiler con privilegi SYSTEM, che esegue il binario QEMU
  • Deployment di un’immagine disco virtuale (custom.qcow2) mascherata da file di database o librerie DLL per evitare il rilevamento
  • Avvio di una VM Alpine Linux 3.22.0 con port forwarding verso il sistema host
  • Instaurazione di un tunnel SSH inverso per il comando e controllo covert

Il principio è semplice ma devastante: le soluzioni di sicurezza endpoint monitorano i processi del sistema operativo host, ma non possono ispezionare l’interno di una macchina virtuale in esecuzione. Tutto ciò che avviene dentro la VM rimane completamente opaco agli EDR.

Il toolkit nella macchina virtuale: un arsenale da penetration test


La VM Alpine Linux non è un ambiente minimale: è un’armeria completa di strumenti offensivi. In STAC4713, la VM preinstallata conteneva:

  • AdaptixC2: framework C2 open source per il controllo remoto
  • Chisel: tunneling TCP/UDP attraverso HTTP
  • BusyBox: suite di utility Unix compatta
  • Rclone: tool per l’esfiltrazione dati verso storage cloud

In STAC3725, rilevata dal CERT di Secureworks in incidenti a febbraio 2026, il toolkit era ancora più sofisticato e compilato manualmente dagli operatori: Impacket, KrbRelayx, Coercer, BloodHound.py, NetExec, Kerbrute e un’istanza di Metasploit completamente funzionale. Un arsenale che denota una profonda conoscenza delle tecniche di post-exploitation in ambienti Active Directory.

Furto di credenziali e movimento laterale


Prima di distribuire il ransomware, GOLD ENCOUNTER conduce operazioni estese di ricognizione e furto credenziali. Le tecniche documentate includono:

  • Creazione di Volume Shadow Copies tramite vssuirun.exe per accedere a file altrimenti bloccati
  • Esfiltrazione via SMB di NTDS.dit, SAM e dei registry hive SYSTEM — il database completo degli utenti Active Directory
  • Enumerazione Kerberos con Kerbrute per identificare account validi
  • Ricognizione AD tramite BloodHound per mappare percorsi di escalation dei privilegi
  • Deployment di ScreenConnect e del framework Havoc C2 tramite DLL sideloading su ADNotificationManager.exe


Il ransomware PayoutsKing: cifratura furtiva


PayoutsKing utilizza uno schema di cifratura robusto: AES-256 in modalità CTR per la cifratura dei file, con scambio di chiavi tramite RSA-4096. Per i file di grandi dimensioni viene adottata una strategia di intermittent encryption — cifra solo porzioni del file — che accelera l’operazione e rende la cifratura meno rilevabile in tempo reale dai sistemi di monitoraggio comportamentale.

Le richieste di riscatto vengono gestite attraverso siti leak sul dark web, con la consueta doppia estorsione: pagare per il decryptor, o vedere i propri dati pubblicati.

Indicatori di compromissione (IoC)

# Scheduled Task sospetto
Nome task: TPMProfiler
Privilegi: SYSTEM
Binary: qemu-system-x86_64.exe (o varianti)

# File da monitorare
*.qcow2 in posizioni anomale (es. %APPDATA%, C:\ProgramData\)
File .qcow2 mascherati da .dll o .db

# Servizi sospetti installati
AppMgmt (uso anomalo)
CtxAppVCOMService

# Tool post-compromise da cercare
AdaptixC2, Chisel, Rclone, BloodHound.py
Kerbrute, Impacket, NetExec, KrbRelayx

# Traffico di rete
Tunnel SSH reversi su porte non standard
Connessioni SSH in uscita verso IP esterni insoliti
Traffico Rclone verso storage cloud (es. Mega, Dropbox)

Cosa fare per difendersi


La tecnica QEMU rappresenta una sfida concreta per i team di sicurezza perché sfrutta uno strumento legittimo e firmato. Le raccomandazioni per i difensori includono:

  • Application allowlisting: bloccare l’esecuzione di qemu-system-*.exe su tutti gli endpoint non espressamente autorizzati
  • Monitoraggio scheduled task: alert su qualsiasi task creato con privilegi SYSTEM che esegue binari non standard
  • MFA obbligatoria su VPN e accessi remoti: quasi tutti i vettori di accesso iniziale documentati avrebbero potuto essere bloccati con MFA
  • Patching tempestivo: CVE-2025-26399 (SolarWinds), CitrixBleed2 e vulnerabilità SonicWall devono essere priorità assolute
  • Network monitoring: rilevare port forwarding SSH non autorizzato e connessioni in uscita verso storage cloud da server
  • Hunt proattivo: cercare file .qcow2 e il processo qemu-system-x86_64.exe nell’intero parco macchine

La capacità di GOLD ENCOUNTER di operare per settimane o mesi all’interno di reti compromesse prima di distribuire il payload ransomware — sfruttando una VM nascosta impossibile da ispezionare dagli EDR — rende questo gruppo particolarmente pericoloso. È l’ennesima dimostrazione di come i ransomware operator stiano evolvendo verso tecniche da APT, con longevi periodi di dwell time dedicati alla ricognizione e alla maximizzazione del danno.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Command Pattern in C#: guida completa con undo, redo e Dependency Injection


Come implementare il Command Pattern in C# passo dopo passo: ICommand, Receiver, Invoker con stack undo/redo, Macro Commands e integrazione con Dependency Injection in ASP.NET Core.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il Command Pattern è uno dei design pattern comportamentali più utili nel mondo dello sviluppo software. In C#, la sua implementazione è particolarmente elegante e consente di costruire sistemi robusti con funzionalità di undo/redo, accodamento di operazioni e logging senza intaccare la logica di business. In questo articolo vedremo come implementarlo passo dopo passo, con esempi concreti e consigli pratici per applicazioni reali.

Cos’è il Command Pattern?


Il Command Pattern incapsula una richiesta come un oggetto autonomo, separando chi la emette da chi la esegue. Questo consente di parametrizzare i client con richieste diverse, accodare operazioni, supportare il rollback e costruire sistemi di macro o audit trail. In parole semplici: invece di chiamare direttamente un metodo, si crea un oggetto che “sa come” eseguire quella chiamata, e lo si passa all’esecutore.

I casi d’uso più classici includono:

  • Editor di testo o grafica con undo/redo illimitato
  • Sistemi di workflow con operazioni reversibili
  • Transaction scripts in architetture DDD
  • Logging e auditing di operazioni critiche
  • Macro recording nelle applicazioni di produttività


I componenti del pattern


Un’implementazione corretta del Command Pattern in C# prevede quattro attori principali:

  • ICommand: l’interfaccia contrattuale che definisce Execute(), Undo() e una proprietà descrittiva
  • Receiver: la classe che contiene la logica di business effettiva, ignara del pattern
  • Concrete Command: le implementazioni di ICommand, che catturano i parametri in costruzione e delegano al Receiver
  • Invoker: gestisce la coda di esecuzione e le stack di undo/redo


Implementazione passo dopo passo

Step 1: definire l’interfaccia ICommand


Il contratto deve essere minimale. Tutti i dati necessari all’esecuzione viaggiano dentro il comando stesso, non vengono passati ai metodi:

public interface ICommand
{
    string Description { get; }
    void Execute();
    void Undo();
}

La scelta di metodi senza parametri è deliberata: favorisce l’immutabilità del comando dopo la costruzione e impedisce il condizionamento da stato esterno.

Step 2: creare il Receiver


Il Receiver contiene la logica reale. Non sa nulla di comandi, stack o undo. È testabile in isolamento:

public class TextDocument
{
    private readonly List<string> _lines = new();

    public IReadOnlyList<string> Lines => _lines.AsReadOnly();

    public void AddLine(string text) => _lines.Add(text);

    public void RemoveLine(int index)
    {
        if (index >= 0 && index < _lines.Count)
            _lines.RemoveAt(index);
    }
}

Step 3: implementare i Concrete Commands


Ogni comando cattura i propri dati al momento della costruzione e implementa sia Execute che Undo. Notare che lo stato necessario per l’undo viene salvato durante Execute:

public sealed class AddLineCommand : ICommand
{
    private readonly TextDocument _document;
    private readonly string _text;

    public string Description => $"Aggiungi riga: "{_text}"";

    public AddLineCommand(TextDocument document, string text)
    {
        _document = document ?? throw new ArgumentNullException(nameof(document));
        _text = text ?? throw new ArgumentNullException(nameof(text));
    }

    public void Execute() => _document.AddLine(_text);

    public void Undo() => _document.RemoveLine(_document.Lines.Count - 1);
}

public sealed class RemoveLineCommand : ICommand
{
    private readonly TextDocument _document;
    private readonly int _index;
    private string? _removedText;

    public string Description => $"Rimuovi riga {_index}";

    public RemoveLineCommand(TextDocument document, int index)
    {
        _document = document;
        _index = index;
    }

    public void Execute()
    {
        // Salviamo lo stato per poter fare undo
        _removedText = _document.Lines[_index];
        _document.RemoveLine(_index);
    }

    public void Undo()
    {
        if (_removedText is not null)
            _document.AddLine(_removedText);
    }
}

Il punto critico è la cattura dello snapshot in Execute(): RemoveLineCommand ricorda il testo rimosso prima di cancellarlo, rendendo possibile il ripristino.

Step 4: costruire l’Invoker con history


L’Invoker mantiene due stack: uno per l’undo e uno per il redo. Quando si esegue un nuovo comando, la redo stack viene svuotata per evitare storie ramificate incoerenti:

public class CommandInvoker
{
    private readonly Stack<ICommand> _undoStack = new();
    private readonly Stack<ICommand> _redoStack = new();

    public void ExecuteCommand(ICommand command)
    {
        command.Execute();
        _undoStack.Push(command);
        _redoStack.Clear(); // Nuova azione invalida il redo
    }

    public bool CanUndo => _undoStack.Count > 0;
    public bool CanRedo => _redoStack.Count > 0;

    public void Undo()
    {
        if (!CanUndo) return;
        var cmd = _undoStack.Pop();
        cmd.Undo();
        _redoStack.Push(cmd);
    }

    public void Redo()
    {
        if (!CanRedo) return;
        var cmd = _redoStack.Pop();
        cmd.Execute();
        _undoStack.Push(cmd);
    }

    public IEnumerable<string> GetHistory() =>
        _undoStack.Select(c => c.Description);
}

Step 5: Macro Commands (Composite)


Il Command Pattern si combina naturalmente con il Composite Pattern per costruire macro che raggruppano più operazioni atomiche:

public sealed class MacroCommand : ICommand
{
    private readonly IReadOnlyList<ICommand> _commands;

    public string Description => $"Macro ({_commands.Count} operazioni)";

    public MacroCommand(IEnumerable<ICommand> commands)
    {
        _commands = commands.ToList();
    }

    public void Execute()
    {
        foreach (var cmd in _commands)
            cmd.Execute();
    }

    public void Undo()
    {
        // L'undo avviene in ordine inverso
        for (int i = _commands.Count - 1; i >= 0; i--)
            _commands[i].Undo();
    }
}

Step 6: integrazione con Dependency Injection


In applicazioni .NET moderne, il pattern si integra perfettamente con il DI container di ASP.NET Core:

// Program.cs
builder.Services.AddSingleton<TextDocument>();
builder.Services.AddSingleton<CommandInvoker>();
builder.Services.AddTransient<DocumentCommandFactory>();

// Factory per creare comandi on-demand
public class DocumentCommandFactory
{
    private readonly TextDocument _document;

    public DocumentCommandFactory(TextDocument document)
    {
        _document = document;
    }

    public ICommand AddLine(string text) => new AddLineCommand(_document, text);
    public ICommand RemoveLine(int index) => new RemoveLineCommand(_document, index);
}

I componenti longevi (TextDocument, CommandInvoker) sono Singleton; i comandi vengono creati on-demand tramite factory e rimangono short-lived.

Errori comuni da evitare


Chi si avvicina al Command Pattern per la prima volta tende a commettere questi errori:

  • Logica nel comando invece che nel Receiver: i comandi devono orchestrare, non implementare. La logica di business appartiene al Receiver, dove può essere testata in isolamento.
  • Mancato snapshot dello stato per l’undo: se dimenticate di catturare lo stato prima dell’esecuzione, l’undo diventa impossibile o inaffidabile.
  • Stato condiviso tra comandi: ogni comando deve essere autosufficiente. Lo stato mutabile condiviso porta a bug sottili quando i comandi vengono eseguiti in ordine diverso.
  • Undo implementato in modo forzato: per operazioni genuinamente non reversibili (come l’invio di un’email), meglio lanciare un’eccezione o documentare esplicitamente il limite, piuttosto che fingere un undo inesistente.


Conclusione


Il Command Pattern è uno strumento potente e sottovalutato. Quando il vostro sistema ha bisogno di storico operazioni, undo/redo, accodamento differito o audit trail, questo pattern vi offre una soluzione elegante e testabile. La separazione netta tra Receiver (logica) e Command (orchestrazione) rende il codice mantenibile anche su larga scala.

Se state sviluppando con C# e .NET, consideratelo ogni volta che la vostra architettura richiede operazioni reversibili o la composizione di azioni complesse.


Fonte originale: How to Implement Command Pattern in C# – DevLeader.ca

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Rilasciata Solus 4.9 “Serenity”


Solus è una distribuzione GNU/Linux indipendente, progettata esclusivamente per l’uso su desktop. A differenza di molte altre distribuzioni, Solus non deriva da progetti esistenti come Debian o Ubuntu, ma è una distribuzione indipendente, non derivata da altri progetti, con un focus...

🔗 Leggi il post completo

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

LINQ Max e i tipi valore nullable in C#: il comportamento inatteso che causa eccezioni a runtime


Il metodo LINQ Max si comporta in modo sorprendente con i tipi valore non nullable: su una sequenza vuota lancia InvalidOperationException invece di restituire null. Ecco perché succede e come prevenirlo con un semplice cast esplicito.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Chi usa LINQ in C# con una certa frequenza prima o poi si imbatte in un comportamento del metodo Max che, a prima vista, appare del tutto irrazionale: due chiamate sintatticamente quasi identiche producono risultati radicalmente diversi, e una delle due lancia un’eccezione a runtime su una sequenza vuota. Vediamo perché accade e come risolverlo.

Il problema: Max con proiezioni su tipi diversi


Consideriamo questo tipo record:

public record WithValues(string Label, int Number, DateTimeOffset Date);

Ora proviamo a chiamare Max su un array vuoto con tre proiezioni diverse:
WithValues[] empty = [];

string? maxLabel  = empty.Max(x => x.Label);   // Restituisce null
var     maxDate   = empty.Max(d => d.Date);     // Lancia InvalidOperationException
int?    maxNumber = empty.Max(x => x.Number);   // Lancia InvalidOperationException

La firma del metodo è:
public static TResult? Max<TSource, TResult>(
    this IEnumerable<TSource> source,
    Func<TSource, TResult> selector);

Il tipo di ritorno è dichiarato come TResult? — nullable. Eppure il comportamento cambia radicalmente in base a ciò che la funzione di proiezione restituisce.

La causa: come Max distingue i tipi internamente


Internamente, l’implementazione di Max usa un test per decidere come comportarsi su una sequenza vuota:

TResult val = default;
if (val == null)
{
    // Tipo reference o nullable: restituisce null per sequenze vuote
}
else
{
    // Tipo valore non nullable: lancia eccezione per sequenze vuote
}

Questo porta a tre comportamenti distinti:
  • Tipi reference (string): default(string) è null, quindi il ramo “restituisce null” viene eseguito correttamente.
  • Tipi valore non nullable (int, DateTimeOffset): i loro default non sono null, quindi viene eseguito il ramo che lancia InvalidOperationException.
  • Tipi valore nullable (int?, DateTimeOffset?): default(int?) è null, quindi rientra nel primo ramo e restituisce null.


Perché questo design?


Il ragionamento alla base è comprensibile: per i tipi valore, restituire il valore di default per una sequenza vuota sarebbe ambiguo. Se Max su una lista vuota di interi restituisse 0, come distinguere tra “il massimo è zero” e “la lista era vuota”? L’eccezione rimuove questa ambiguità, ma lo fa in modo sorprendente data la firma del metodo.

Il problema di fondo è storico: C# ha sviluppato la nullabilità in tre fasi distinte che non si integrano uniformemente nel codice generico:

  • I tipi reference erano sempre nullable (fin dalle origini del linguaggio).
  • I tipi valore nullable (Nullable<T>, ovvero T?) sono stati introdotti in C# 2.0.
  • Le nullable reference types (NRT) sono arrivate in C# 8.0 come feature opzionale.


La soluzione: cast esplicito al tipo nullable


La correzione è semplice: basta fare il cast esplicito della proiezione al tipo nullable corrispondente.

// Invece di:
var maxDate    = empty.Max(d => d.Date);
int? maxNumber = empty.Max(x => x.Number);

// Usare:
DateTimeOffset? maxDate    = empty.Max(d => (DateTimeOffset?)d.Date);
int?            maxNumber  = empty.Max(x => (int?)x.Number);

Il cast forza il compilatore a inferire TResult = DateTimeOffset? (o int?), il cui default è null, e Max segue quindi il percorso corretto, restituendo null invece di lanciare un’eccezione.

Alternativa: DefaultIfEmpty


Un’altra soluzione è preporre DefaultIfEmpty prima di Max:

int maxNumber = empty
    .Select(x => x.Number)
    .DefaultIfEmpty(0)
    .Max();

Questa alternativa è utile quando si vuole un valore di fallback esplicito invece di null, ma va usata con attenzione: il valore di default deve essere scelto consapevolmente per non introdurre ambiguità semantica nel risultato.

Quando questo si manifesta in produzione


Il problema diventa insidioso quando si lavora con sequenze filtrate dinamicamente che possono risultare vuote in certi contesti, o quando il codice viene testato sempre con dati non vuoti e crasha in produzione su edge case inaspettati. Una buona pratica difensiva è usare sempre il cast a tipo nullable quando si usa Max (o Min, che ha lo stesso comportamento) su tipi valore, a meno che non si abbia la certezza assoluta che la sequenza non sarà mai vuota.

Conclusioni


Il comportamento di LINQ.Max con i tipi valore è uno di quei casi in cui l’implementazione è tecnicamente coerente, ma la firma del metodo lascia intendere qualcosa di diverso da ciò che avviene a runtime. La regola da ricordare è semplice: se la proiezione restituisce un tipo valore non nullable e la sequenza potrebbe essere vuota, usare sempre un cast esplicito a T?. Un piccolo accorgimento che previene eccezioni difficili da diagnosticare in produzione.


Fonte originale: LINQ Max and nullable value types (Ian Griffiths, endjin.com) — tratto dal briefing Dew Drop del 17 aprile 2026

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

ColorOS 16.1 per Oppo e OnePlus: ecco tutti i modelli aggiornati e le date di rilascio


Oppo ha ufficializzato il calendario di aggiornamento a ColorOS 16.1 per i propri dispositivi e per quelli OnePlus. L'update porta numerose novità all'interfaccia e alla produttività, con la distribuzione della versione stabile prevista a partire da maggio 2026. Il programma beta parte ad aprile Il beta testing di ColorOS 16.1 è già partito, con le iscrizioni che si sono chiuse il 17 aprile. I partecipanti selezionati inizieranno a ricevere le build beta a partire dal 21 aprile. Il […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Oppo ha ufficializzato il calendario di aggiornamento a ColorOS 16.1 per i propri dispositivi e per quelli OnePlus. L’update porta numerose novità all’interfaccia e alla produttività, con la distribuzione della versione stabile prevista a partire da maggio 2026.

Il programma beta parte ad aprile


Il beta testing di ColorOS 16.1 è già partito, con le iscrizioni che si sono chiuse il 17 aprile. I partecipanti selezionati inizieranno a ricevere le build beta a partire dal 21 aprile. Il programma è riservato principalmente ai modelli di fascia alta.

Prima ondata: i top di gamma dal 10 maggio


La versione stabile sarà distribuita in due tranche. La prima, tra il 10 e il 20 maggio 2026, coprirà i modelli Oppo Find N6, Find N5, Find X9 e X8 series (incluso X8s), Oppo Pad 4 Pro, OnePlus Tablet 2 Pro, OnePlus 15 e 13 series, OnePlus Ace 6 e Turbo 6 series.

Seconda ondata: fascia media dal 21 maggio


La seconda distribuzione, tra il 21 e il 31 maggio, estenderà l’aggiornamento a Oppo Find X7 series, Oppo Reno 15 e Reno 14 Pro series, Oppo K15 series e K13 Turbo Pro, Oppo Pad 5, OnePlus 12, Ace 5 series e Tablet 2. Questi calendari si riferiscono ai modelli del mercato cinese; i dispositivi globali potrebbero ricevere l’aggiornamento con tempistiche leggermente diverse.

Le novità di ColorOS 16.1


ColorOS 16.1 porta importanti miglioramenti all’esperienza utente. Il sistema di notifiche è stato ridisegnato, con l’introduzione delle Live Activities che mostrano in tempo reale informazioni su chiamate, timer, navigazione e altri processi attivi. Il lock screen guadagna un nuovo media player, mentre nuovi elementi grafici a forma di pillola arricchiscono la barra inferiore con animazioni più fluide.

Parallelamente, Oppo ha già avviato lo sviluppo di ColorOS basato su Android 17, con beta già disponibili per alcuni dispositivi selezionati. Il ciclo di aggiornamenti si fa dunque sempre più serrato, a beneficio degli utenti.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Lenovo Legion Y70 2026: torna il gaming phone di Lenovo dopo 4 anni, sfida a RedMagic 11 Pro


Lenovo è pronta a tornare nel segmento degli smartphone gaming con il Legion Y70 2026, annunciato ufficialmente dopo settimane di teaser. L'ultimo capitolo della serie Legion risaliva al 2022, e questo nuovo modello si preannuncia come una risposta diretta ai rivali RedMagic 11 Pro e ROG Phone di ASUS. Quattro anni di assenza, poi il grande ritorno Il Legion Phone di Lenovo aveva fatto parlare di sé per le sue scelte di design originali, come il connettore USB posizionato lateralmente per […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Lenovo è pronta a tornare nel segmento degli smartphone gaming con il Legion Y70 2026, annunciato ufficialmente dopo settimane di teaser. L’ultimo capitolo della serie Legion risaliva al 2022, e questo nuovo modello si preannuncia come una risposta diretta ai rivali RedMagic 11 Pro e ROG Phone di ASUS.

Quattro anni di assenza, poi il grande ritorno


Il Legion Phone di Lenovo aveva fatto parlare di sé per le sue scelte di design originali, come il connettore USB posizionato lateralmente per giocare senza cavi di traverso, e per l’ottimo sistema di raffreddamento. Dopo il silenzio degli ultimi anni, il brand torna con un modello radicalmente rinnovato il cui lancio ufficiale è previsto a maggio 2026.

Design più sobrio, tripla fotocamera


Le immagini ufficiali mostrano un cambio di direzione estetica rispetto ai modelli precedenti. Il Legion Y70 2026 adotta un look più contenuto, lontano dall’estetica volutamente “gaming” con LED e angoli aggressivi. Il pannello posteriore ospita un modulo fotocamera rettangolare con configurazione a tripla fotocamera. Il dispositivo sarà disponibile almeno in due colorazioni.

Specifiche tecniche ancora non ufficiali


Lenovo non ha ancora svelato le specifiche complete, ma considerando il posizionamento del dispositivo ci si aspetta uno dei processori più potenti disponibili, probabilmente Snapdragon 8 Elite o superiore, affiancato da un sistema di dissipazione del calore avanzato, schermo ad alto refresh rate e batteria capiente con ricarica rapida.

Un mercato sempre più competitivo


Il segmento degli smartphone gaming vede oggi la concorrenza agguerrita di RedMagic (Nubia), ASUS ROG Phone e Black Shark. Il ritorno di Lenovo aggiunge un concorrente di peso con una storia consolidata nel gaming, essendo tra le più importanti aziende al mondo nel settore dei PC da gioco con il brand Legion. Il lancio è previsto per maggio 2026, con disponibilità iniziale quasi certamente sul mercato cinese prima di un’eventuale espansione globale.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Samsung: Galaxy AI si può disattivare completamente, e i telefoni compatti non torneranno


Samsung ha risposto direttamente alle domande degli utenti in un AMA su Reddit, chiarendo due questioni molto dibattute: la possibilità di disattivare completamente Galaxy AI e il futuro dei telefoni compatti nella gamma Galaxy. Le risposte arrivano da Anika Bizon, VP Marketing e Prodotto di Samsung UK. Galaxy AI: si può spegnere, funzione per funzione A chi si chiede se è possibile usare un Galaxy senza l'intelligenza artificiale, la risposta è sì. Samsung ha confermato che Galaxy AI […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Samsung ha risposto direttamente alle domande degli utenti in un AMA su Reddit, chiarendo due questioni molto dibattute: la possibilità di disattivare completamente Galaxy AI e il futuro dei telefoni compatti nella gamma Galaxy. Le risposte arrivano da Anika Bizon, VP Marketing e Prodotto di Samsung UK.

Galaxy AI: si può spegnere, funzione per funzione


A chi si chiede se è possibile usare un Galaxy senza l’intelligenza artificiale, la risposta è sì. Samsung ha confermato che Galaxy AI è completamente opzionale: già durante la configurazione iniziale del dispositivo si può scegliere di non attivarlo, e successivamente ogni singola funzione AI può essere abilitata o disabilitata individualmente dalle impostazioni.

Il messaggio di Samsung è chiaro: l’obiettivo non è imporre l’AI, ma renderla disponibile per chi la vuole usare. Bizon ha paragonato Galaxy AI all’elettricità, qualcosa che idealmente “c’è” senza che tu debba pensarci, invisibile e integrata nella vita quotidiana, ma non obbligatoria.

Niente smartphone compatti: il mercato chiede grandi schermi


Molti utenti speravano in un ritorno dei Galaxy di formato ridotto, ma Samsung ha raffreddato le aspettative. La domanda di mercato si concentra ormai sui grandi display, usati per video, gaming e multitasking, e Samsung non può permettersi di ignorare questo trend.

Per chi cerca portabilità senza rinunciare allo schermo grande, Samsung indica il Galaxy Z Flip come soluzione: in formato chiuso è compatto, aperto offre un display generoso.

Galaxy S26 Ultra: le novità in arrivo


Samsung ha anticipato alcune delle caratteristiche salienti del prossimo Galaxy S26 Ultra. In cima alla lista ci sono il potenziamento del motore fotografico ProVisual Engine, miglioramenti alla velocità di ricarica e l’introduzione del Privacy Display, una funzione che limita la visibilità dello schermo laterale — utile in luoghi pubblici, ma con qualche compromesso sulla luminosità.

Samsung sembra dunque voler mantenere una rotta equilibrata: innovazione tecnologica sì, ma senza forzare gli utenti ad abbracciare funzionalità che potrebbero non voler usare. Una strategia che potrebbe rivelarsi vincente in un mercato sempre più attento alla privacy e alla trasparenza.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Operation PowerOFF: 21 paesi coordinati smantellano 53 piattaforme DDoS-for-hire e identificano 75.000 cyberattaccanti


Europol ha coordinato la più vasta operazione globale contro le piattaforme DDoS-for-hire: 53 domini sequestrati, 4 arresti, 25 mandati di perquisizione e 75.000 utenti allertati in 21 paesi. L'operazione PowerOFF ha acquisito accesso a database con oltre 3 milioni di account criminali, segnando un cambio di paradigma nella lotta agli stresser commerciali.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Ventuno paesi hanno coordinato la più vasta azione globale mai condotta contro le piattaforme DDoS-for-hire: Operation PowerOFF, culminata il 13 aprile 2026 con il sequestro di 53 domini, l’arresto di 4 amministratori, l’emissione di 25 mandati di perquisizione e l’invio di comunicazioni di allerta a oltre 75.000 utenti identificati come clienti di servizi “booter”. Europol ha coordinato l’operazione insieme all’FBI, all’NCFTA e alle forze di polizia di Europa, America e Asia-Pacifico, acquisendo accesso a database con oltre 3 milioni di account criminali.

L’ecosistema dei booter: DDoS come servizio a 10 euro al mese


I servizi booter — chiamati anche stresser nel gergo del mercato underground — sono piattaforme commerciali che vendono potenza di fuoco DDoS a chiunque sia disposto a pagare una quota mensile, tipicamente tra i 10 e i 200 dollari. Il modello di business è quello di un SaaS criminale: interfacce web con dashboard intuitive, piani tariffari differenziati per banda e durata dell’attacco, e assistenza clienti. Le vittime sono target eterogenei — siti di e-commerce, server di gaming, infrastrutture governative locali, concorrenti aziendali — il denominatore comune è la disponibilità del pagante a causare interruzioni di servizio per denaro o vendetta.

Tecnicamente, i booter operano sfruttando due modelli di amplificazione: botnet di dispositivi IoT compromessi (router SOHO, telecamere IP, NAS) e reflection amplification tramite protocolli UDP vulnerabili — DNS, NTP, SSDP, memcached — che consentono di amplificare il traffico di attacco fino a 50.000x rispetto al volume inviato. La decentralizzazione e il frequente ricorso a frontend anonimi dietro CDN rendevano queste piattaforme particolarmente resilienti ai tentativi di takedown tradizionali.

Operazione PowerOFF: storia di un’escalation investigativa


PowerOFF non è nata il 13 aprile: è il risultato di anni di indagini parallele che Europol ha progressivamente coordinato in un’unica architettura operativa. La prima fase significativa risale al dicembre 2024, quando l’operazione aveva già portato al sequestro di 27 piattaforme — tra cui zdstresser.net, orbitalstress.net e starkstresser.net — con 3 arresti e l’identificazione di oltre 300 utenti. La seconda ondata, coordinata nell’aprile 2026, ha esteso la portata dell’operazione a livello globale, coinvolgendo per la prima volta paesi come Brasile, Thailandia e Giappone.

L’elemento innovativo della fase 2026 è stata l’approccio preventivo parallelo all’enforcement: mentre gli investigatori sequestravano server e domìni, un team specializzato lanciava una campagna di awareness mirata, rimuovendo oltre 100 URL pubblicitari dai risultati dei motori di ricerca che promuovevano servizi booter, e inviando messaggi di allerta direttamente sulle blockchain delle transazioni in criptovaluta usate per pagare i servizi — una tecnica nuova che segnala un’evoluzione nell’approccio investigativo alle piattaforme crypto-monetizzate.

75.000 allerte: la strategia della deterrenza scalabile


La novità più significativa di Operation PowerOFF 2026 non è il numero di domini sequestrati, ma la scelta strategica di non arrestare la stragrande maggioranza degli utenti identificati. Le autorità hanno inviato 75.000 comunicazioni personalizzate via email e posta ordinaria agli utenti dei servizi booter — molti dei quali sono giovani che non si percepiscono come criminali — spiegando le implicazioni legali delle loro azioni e le sanzioni previste. Questa strategia di deterrenza scalabile mira a modificare il comportamento prima che si consolidi in attività criminale conclamata.

L’accesso ai database con 3 milioni di account — ottenuto tramite le operazioni di sequestro dell’infrastruttura — ha permesso alle autorità di costruire un profilo dettagliato dell’ecosistema: età media degli utenti, distribuzione geografica, modelli di pagamento, target preferiti. Questi dati alimenteranno future indagini mirate sui soggetti recidivi o con profili di rischio elevato.

Paesi partecipanti e coordinamento internazionale


L’operazione ha visto la partecipazione di: Australia, Austria, Belgio, Brasile, Bulgaria, Danimarca, Estonia, Finlandia, Germania, Giappone, Lettonia, Lituania, Lussemburgo, Paesi Bassi, Polonia, Portogallo, Svezia, Thailandia, Regno Unito e Stati Uniti. Il coordinamento tecnico è stato gestito dall’EC3 di Europol (European Cybercrime Centre), con supporto dell’Eurojust per gli aspetti giuridizionali delle richieste di mutua assistenza internazionale (MLA). Per la prima volta, paesi tradizionalmente assenti da operazioni cyber-enforcement come Brasile e Thailandia hanno contribuito con azioni di sequestro locali — segnale di una maturazione del quadro normativo e investigativo globale.

Piattaforme disrupted: infrastruttura tecnica

# Tipologie di servizi smantellati
- Booter/stresser con interfaccia web (SaaS DDoS-for-hire)
- Layer 4 flood: UDP amplification (DNS, NTP, SSDP, memcached)
- Layer 7 HTTP flood su infrastruttura botnet IoT
- Servizi di anonimizzazione del pagamento (crypto mixer integration)

# Esempi di piattaforme sequestrate in operazioni precedenti
zdstresser.net
orbitalstress.net  
starkstresser.net

# Indicatori da monitorare
- Traffico UDP anomalo su porte 53, 123, 1900, 11211
- Elevato numero di SYN senza ACK su range IP distribuiti
- Picchi di amplification ratio >100x in NetFlow/IPFIX
- Query DNS flood con domain randomization (NXDOMAIN storm)

Implicazioni per i difensori e gli operatori di rete


Il takedown di 53 piattaforme non risolve strutturalmente il problema — nuovi servizi emergeranno, spesso ospitati in giurisdizioni meno cooperative. La risposta efficace per chi gestisce infrastrutture è combinare scrubbing center upstream con BGP blackholing d’emergenza e accordi preventivi con il proprio upstream provider per la gestione di volumetric attack. La vera svolta di PowerOFF è l’approccio sistemico: colpire non solo le piattaforme, ma anche la domanda (gli utenti) e il canale di acquisizione (pubblicità sui motori di ricerca). Se l’ecosistema booter viene reso meno accessibile e percepito come più rischioso, la domanda si riduce — e con essa la viabilità economica dei servizi stessi. Per le organizzazioni esposte ad attacchi DDoS frequenti, il momento è propizio per negoziare con i provider uplink accordi di DDoS Protection Service Level Agreement, mentre il mercato dei booter attraversa una fase di disruption e riorganizzazione.

Dario Fadda reshared this.

Dario Fadda ha ricondiviso questo.

Dimensity 9600 Pro: trapelano i benchmark di MediaTek, sfida aperta con Snapdragon


Il futuro chip di punta di MediaTek, il Dimensity 9600 Pro, inizia a farsi conoscere grazie ai primi benchmark trapelati in rete. I dati, attribuiti al noto leaker Digital Chat Station, mostrano un processore in evoluzione costante rispetto alla generazione precedente, anche se non si tratta di un salto generazionale rivoluzionario. I punteggi Geekbench 6 Stando alle indiscrezioni, il Dimensity 9600 Pro ottiene su Geekbench 6 circa 4.200-4.300 punti in single-core e circa 12.000-12.500 […]
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il futuro chip di punta di MediaTek, il Dimensity 9600 Pro, inizia a farsi conoscere grazie ai primi benchmark trapelati in rete. I dati, attribuiti al noto leaker Digital Chat Station, mostrano un processore in evoluzione costante rispetto alla generazione precedente, anche se non si tratta di un salto generazionale rivoluzionario.

I punteggi Geekbench 6


Stando alle indiscrezioni, il Dimensity 9600 Pro ottiene su Geekbench 6 circa 4.200-4.300 punti in single-core e circa 12.000-12.500 punti in multi-core (dati da campioni ingegneristici, non definitivi). Rispetto alla generazione precedente (circa 4.000 single-core e 11.000 multi-core), si registra un miglioramento misurabile ma non clamoroso: un’evoluzione solida piuttosto che una rivoluzione.

Architettura: due core ultra-performance a 5 GHz


Sul piano architetturale, il Dimensity 9600 Pro adotta una configurazione 2+3+3, con due core ad altissime prestazioni che operano a circa 5 GHz, tre core Gelas-b e tre core Gelas standard. Un’impostazione orientata alle performance assolute, particolarmente vantaggiosa nei carichi single-thread.

GPU Magni e processo produttivo TSMC N2P


La GPU integrata sarà basata sulla nuova architettura Arm Magni, mentre il processo produttivo adotterà il nodo TSMC N2P, una scelta che dovrebbe garantire miglioramenti significativi nell’efficienza energetica. Alcune fonti precedenti parlavano di una riduzione dei consumi del 25-30%, ma questo dato non è ancora confermato ufficialmente.

La sfida con Snapdragon 8 Elite Gen 6 Pro


Il principale rivale sarà lo Snapdragon 8 Elite Gen 6 Pro di Qualcomm, che secondo le indiscrezioni punta anch’esso ai 5 GHz di clock ma con margini di miglioramento inferiori al 20% rispetto alla generazione attuale. I primi smartphone dotati del Dimensity 9600 Pro dovrebbero essere i vivo X500 e gli OPPO Find X10. L’arrivo sul mercato europeo potrebbe avvenire entro la fine del 2026.

Dario Fadda reshared this.