Risultati sfida di decodifica

Lunedì 01 Dicembre 2025 08:45 - Scarica l'allegato

Cari studenti,

con colpevole ritardo eccomi a pubblicare l'elenco delle sottomissioni ricevute per il problema della Sfida di decodifica di file AMN:

• 22/10/2025, 01:13 - reversepa - soluzione parziale che non identifica lo schema di decodifica
• 23/10/2025, 17:53 - niccolob - soluzione parziale che non identifica completamente lo schema di decodifica
• 24/10/2025, 03:02 - eldavo - soluzione completa con aggiunta immobili
• 24/10/2025, 10:16 - niccolob - soluzione completa, ma senza aggiunta immobili
• 28/10/2025, 22:19 - AMNaggia - soluzione completa con aggiunta immobili

Risultati: eldavo (laureato magistrale da oltre 1 anno) fornisce la prima soluzione completa (con un bellissimo file html per fare la decodifica) ed è quindi il vincitore! 🍾 Visto il suo stato di "vecchio" studente ha deciso di lasciare il premio al successivo classificato che è AMNaggia (squadra di studenti del 2° anno di IngInf). A onor del vero la soluzione di AMNaggia è più completa nella parte di comprensione del formato e quindi il premio è meritatissimo. 🥳 

Terzo classificato niccolob e quarto reversepa. 👏🏻

Di seguito le descrizioni delle soluzioni fornite dai partecipanti (molto interessanti i diversi approcci). Trovate allegato al post uno ZIP con tutte le soluzioni. Comunque l'algoritmo di cifratura era una codifica a dizionario in cui ogni carattere veniva sostituito con una coppia di caratteri. Ci si poteva accorgere che i dati cifrati erano in Base64, osservando la periodicità molto sospetta. La possibilità di un Chosen-plaintext attack offerta dal campo Riferimento Immobile era chiaramente irresistibile.

reversepa

Descrizione della Soluzione (Reverse Amn)

L'analisi del formato .amn, utilizzato dal sito amministrazionicomunali.net per salvare i dati IMU, ha rivelato che non si tratta di crittografia standard, ma di una serializzazione di stato proprietaria. Il file è composto da tre parti: un header fisso, un payload contenente i dati e un footer variabile.

Attraverso un'analisi differenziale metodica, generando file .amn con modifiche isolate ai dati di input, è stato possibile mappare parzialmente la struttura del payload. Si è scoperto che i valori (numerici, testuali, selezioni) non sono codificati con algoritmi standard (es. Base64), ma tramite una mappatura di sostituzione contestuale: lo stesso valore può avere token diversi a seconda della sua posizione nel file, e lo stesso token può rappresentare valori diversi. Sono state identificate le posizioni e i token relativi a Rendita, Percentuale Possesso, Mesi, Aliquota e alcuni flag booleani per la categoria "Altre abitazioni".

L'analisi ha però dimostrato che la logica completa di codifica (e decodifica) risiede lato server (PHP). In particolare, il footer non è un semplice hash calcolabile dal payload, ma un blocco di stato complesso generato dal server, la cui logica non è accessibile client-side. Questo impedisce la creazione di uno script Python in grado di generare file .amn validi per il caricamento sul sito.

Sono stati creati script Python proof-of-concept per decodificare il payload di file esistenti (limitatamente alla categoria mappata "Altre abitazioni") e per codificare nuovi payload (senza però poter generare il footer corretto). Continuando con la generazione di altri file modificando tutte le possibili opzioni e i possibili campi si riesce ad avere un programma che effettua correttamente la decodifica e codifica dell'header fisso e del payload contenente i dati (aumentando le mappature che al momento sono poche in base alle prove che ho fatto). Per il footer non possiedo gli strumenti per fare il reverse engineering al momento.

niccolob

Ho innanzitutto notato, attraverso l'analisi testuale delle frequenze dei caratteri (singoli, a coppie e a terne), che, nella maggior parte dei documenti prodotti dal sito, le differenti coppie a comparire di volta in volta erano ricorrenti e in numero quasi sempre compreso tra le 60 e le 64. Questo mi ha portato a porre l'attenzione sulle coppie di caratteri. Ho poi individuato nel modulo un campo che non propagasse le modifiche ad esso in più punti del documento prodotto dal sito ("Riferimento Immobile"). Producendo diverse coppie di documenti con valori leggermente differenti tra l'uno e l'altro inseriti nel campo "Riferimento Immobile" (ad esempio, sequenze alfanumeriche con gli estremi invertiti o speculari), ho potuto identificare nel file prodotto la posizione esatta della stringa, notando che la sue dimensione (in numero di caratteri) cresceva in un rapporto di 8:3 dalla versione in chiaro a quella offuscata. Ricordandomi di considerare le coppie di caratteri, invece dei singoli, ho notato che in questo modo la proporzione si riduceva a 4:3, ovvero la stessa di una codifica in Base64. Con questi elementi a portata di mano, ho dovuto semplicemente costruire un dizionario di traduzione in questo modo: ho inserito nel campo "Riferimento Immobile" la seguente stringa: !!@!!A!!B!!C!!D!!E!!F!!G!!H!!I!!J!!K!!L!!M!!N!!O!!P!!Q!!R!!S!!T!!U!!V!!W!!X!!Y!!Z!![!!\!!]!!^!!_!!`!!a!!b!!c!!d!!e!!f!!g!!h!!i!!j!!k!!l!!m!!n!!o!!p!!q!!r!!s!!t!!u!!v!!w!!x!!y!!z!!{!!|!!}!!~!!?. Fatta eccezione per l'ultima tripletta di elementi, "!!?", la rappresentazione binaria di ogni altra tripletta sarebbe risultata nella forma 0010.0001.0010.0001.01xx.xxxx, permettendomi di individuare con chiarezza in che modo venissero codificati gli ultimi 6 bit di ogni sequenza di tre caratteri (essendo i valori in ordine crescente, il dizionario si costruito automaticamente in base all'indice della coppia di caratteri).
Avendo notato che questo approccio funzionava su piccole porzioni di documento (ma non su quello intero), ho effettuato qualche aggiustamento che mi ha portato a riuscire a decodificare gran parte del documento originale, senza però riuscire a correggere tutti gli errori di decodifica, ai quali sto ancora lavorando.

eldavo

La descrizione è inclusa nella soluzione

AMNaggia

Siamo partiti analizzando come vengono codificati i dati in formato AMN: prima, abbiamo recuperato l’URL e il formato della richiesta inviata dal sito al server PHP per la codifica;
poi siamo andati a tentativi per comprendere la logica con cui vengono codificati i messaggi e abbiamo scoperto che inviando delle sequenze di byte ordinate si ottiene un output strutturato da cui abbiamo osservato che i messaggi codificati sono composti da 64 "token" ciascuno formato da due lettere e che in qualche modo questi simboli sono utilizzati per contare, in modo simile ma non totalmente uguale a un sistema numerico posizionale in base 64; inoltre, abbiamo individuato una struttura comune tra i file .amn cioè che contengono un header, il body e dei footer.

Da queste informazioni abbiamo ricavato due algoritmi differenti per la codifica dei messaggi, confrontandoci continuamente e condividendo tutte le scoperte che abbiamo fatto.

Dopodiché abbiamo invertito l’algoritmo, anche con l’aiuto dell’intelligenza artificiale, per decodificare i file .amn ottenuti dal sito.

Da qui, abbiamo decodificato l’header e i footer per determinare quali dati sono contenuti al loro interno, e con questa informazione abbiamo completato l’algoritmo di codifica perché crei dei file .amn completi e leggibili dal sito.

Le alleghiamo lo script Python che permette di codificare file JSON in .amn e viceversa, con anche un file JSON di esempio, e l’altro algoritmo di codifica alternativo scritto in JavaScript e Node.js (abbiamo dovuto salvarlo con l'estensione .txt altrimenti viene bloccato per motivi di sicurezza).

Autore: Costantino GRANA - Ultima modifica: Lunedì 01 Dicembre 2025 09:16