Questa immagine contiene dati segreti?

8

Sto analizzando una grande applicazione basata su cloud. Durante l'analisi ho scoperto che uno dei file più grandi (> 3 MB) utilizzati in questa app è un file molto piccolo (16x16) icon.png .

Ulteriori analisi hanno rivelato che il file contiene oltre 60000 righe di metadati, costituiti per lo più da <rdf:li> tag all'interno di <photoshop:DocumentAncestors> tag. Ecco un esempio:

     <photoshop:DocumentAncestors>
        <rdf:Bag>
           <rdf:li>0</rdf:li>
           <rdf:li>00094172844843523D09FDF552DF119E</rdf:li>
           <rdf:li>000B84DD32F5ABCC8D7B5E8681465EE9</rdf:li>
           <rdf:li>0013FA92942B6EC5451A4D9D4972AD7E</rdf:li>
           <rdf:li>0017ED7FA617555EF7D04797B72E2946</rdf:li>
           <rdf:li>0030491E2F4C927C3D67B20A9710BC01</rdf:li>
           <rdf:li>003287E12D0B5EA81D0AED63DDC335E5</rdf:li>
           <rdf:li>004657FECAF7D9DF3A459A2C0820D29A</rdf:li>
           <rdf:li>0048B527A1E225804FA1FE3E90A74F50</rdf:li>
           <rdf:li>0061E7DAD11961FF150102241FDE8BF5</rdf:li>

Come posso verificare se questi metadati sono stati inseriti qui "naturalmente" o contengono alcuni dati hiddent?

    
posta Kao 18.03.2015 - 09:27
fonte

2 risposte

9

Sembra che questi metadati riportino gli ID dei documenti che sono stati utilizzati durante la creazione del file. Puoi controllare questo articolo: link , cerca "< sezione> Antenati ".

Quindi, contiene metadati tecnici che possono essere inseriti lì 'naturalmente' dalle applicazioni Adobe.

    
risposta data 18.03.2015 - 11:32
fonte
5

Credo che tutto ciò che ho collegato sia sicuro. Scusa per il formato, cercherò di risolvere il problema quando possibile.

Ecco alcuni candidati con conteggi di metadati altrettanto grandi. I collegamenti ai rapporti provengono da Google "Numero eccessivo di articoli per * DocumentAncestors" (che deriva da exiftool , apparentemente utilizzato da VirusTotal).

Ecco un jpg o mp3 (report) , un png con testo spam (report) , a png alone (report) e due con lo stesso md5 (31a02712515ace35f1a593c14a7b5150), ma questo inizia con" 0 ", come fa il tuo esempio. png (report) e un esempio di live png tablet Samsung (SAMPLE) . Il campione proviene dall'hash; gli altri non hanno prodotto campioni.

Un istogramma dall'esempio "samsung" (ho diviso rapidamente ogni byte di 107.000 voci, ordinato e inviato tramite "uniq") può essere di utilità limitata, tranne che per mostrare che i byte non sono completamente casuali. Questo può essere previsto dato come alcune operazioni sono probabilmente codificate, ma stavo assumendo un errore di programmazione che genera UUID puramente casuale. Questa non è l'immagine più carina, quindi posso lavorarci su. Decimal 17 (0x11) è il grande picco in basso.

Hoprovatoalcuniesperimentipervederesepotrebberoessercialcunidaticodificati(ancheilpuntodell'istogramma)macisiamoperlopiùavvicinaticomesemplicimetadatigeneratimentreunfileèstatoelaborato.

Eccoalcuniobiettiviaggiuntivi:

UnaltropostsulforuminAdobe Photoshop CC sta creando file JPEG problematici che fanno perdere OSX Preview.app mente con un file collegato (Note4Cover1.jpg) che è altrettanto grande ma non così ben formattato all'interno.

Qualcun altro con un numero eccessivo di elementi , penso che questo link suggerisca come rimuovere l'extra dati (avviso che potrebbe rimuovere elementi che desideri):

exiftool -xmp:all= -tagsfromfile @ "-all:all<xmp:all" FILE

Un avvertimento: ho scoperto che l'apertura e il salvataggio con un nuovo nome utilizzando GIMP rimuovevano i dati a prescindere dalle caselle di controllo impostate per salvarlo. Sembra che non dovrebbe accadere secondo gli standard collegati da altre risposte qui.

Infine, differisce (different.readthedocs.org) è una libreria di segnalazione di immagini. Non l'ho valutato perché mentre sembra utile e scarica statistiche da strumenti may (come exiftool e imagemagick) potrebbe essere un po 'complicato da configurare ( github ). Potrebbe ancora essere utile per i dati forensi.

    
risposta data 19.03.2015 - 06:35
fonte

Leggi altre domande sui tag