När du har en hammare ser alla problem ut som naglar ...

Jag har studerat något som heter Normalised Compression Distance - NCD - för en tid sedan, och jag skulle prova om jag hade ett liknande problem som ditt.

1. Jag skulle skapa en databas med exempel. Skulle ta 20 program för varje arkitektur du vill veta, med variabla storlekar, och spara dem.

2. När jag konfronteras med ett program som jag ville veta vilken arkitektur det är, jag Skulle beräkna det är NCD mot alla mina exempel.

3. Jag skulle välja den bästa (mindre) NCD och skulle sedan verifiera det om det var en riktig match (låt oss säger, försöker köra den på den upptäckta arkitekturen).

Uppdatera

Jag har alltid gjort i för hand när det gäller NCD. Hur jag gjorde det:

• du har 20 filer för SPARC och du kallar dem A01, A02, A03 och så vidare. Dina x86-filer: B01, B02 osv.

• Du får den okända filen och kallar den XX.

• Välj din föredraget komprimeringsverktyg (jag använde Gzip, men se kommentarer i slutet av detta svar).

• Beräkna NCD för det första paret:

NCD (XX, A01) = (Z (XX + A01) - min (Z (XX), Z (A01)) / max (Z (XX), Z (A01))

Z (något) -> betyder att du komprimerar något med Gzip och får filstorleken efter komprimering. Till exempel 8763 byte, så Z (något) = 8763.

XX + A01 -> betyder att du sammanfogar saker. Du lägger till A01-filen i slutet av XX-filen. I Linux kan du göra en ´cat XX A01> XXA01´.

min ( ) och max () -> du beräknar den komprimerade storleken på XX och A01 och använder det lägsta och högsta som du får.

Så du får ett NCD-värde: det ligger mellan 0 och 1 och använd så många decimaler som möjligt, för ibland är skillnaden i den 7: e eller 8: e siffran. Det blir som att jämföra 0.999999887 till 0.999999524.

Y du gör det för varje fil, så du får 20 NCD-resultat för SPARC, 20 för x86 ...

Skaffa den mindre NCD av alla. Låt oss säga att B07-filen gav dig den mindre NCD. Så förmodligen är unknown-filen en x86.

Tips:

• din unknown och dina testfiler måste ha samma storlek. När du jämför en fil med större eller mindre, kommer NCD inte att göra det magiskt. Så om du testar filer på 5 till 10k skulle jag få testfiler på 2,5k, 5k, 7,5k, 10k, 12,5k ...

• Under min magisterexamen fick jag bättre resultat och använde alltid det mindre NCD-värdet. Den näst bästa metoden var att rösta: få de 5 mindre NCD-resultaten och se vilken arkitektur som fick fler röster. Ex .: mindre NCD var A03, A05, B02, B06, B07 -> B go 3 röster, så jag skulle säga att det är en x86 ...

• kompressorbaserade på Zip-konstruktionen har en begränsning på 32 kB: hur de komprimerar saker, överväger de bara 32 kB i taget. Om din XX + A01 är större än detta, kommer Gzip, Zip etc. inte att ge dig bra resultat. Så för filer som är större än 15 eller 16 kB skulle jag välja en annan kompressor: PPMD, Bzip ...

Det finns några verktyg som kan skanna binära filer efter vanliga opkoder som finns i olika arkitekturer. Binwalk s -A-alternativet gör detta till exempel (det söker efter ARM / MIPS / x86 och flera andra arkitekturer).

Normalt försöker jag först de vanligaste processorerna (ARM, PPC, MIPS och AVR), försöker hitta om någon av de vanliga strängarna säger något om processorn osv ... Och när allt annat misslyckas ger jag ett försök till vad du ber om: statistisk analys av opkoder (om jag är säker på att den inte är krypterad eller komprimerad).

Jag rekommenderar att du läser Alexander Chernov och Katerina Troshina-presentationen "Omvänd teknik för binära program för anpassade virtuella maskiner". Att skriva ett verktyg som det de skrev måste vara väldigt svårt (antar jag) men att skriva ett verktyg för att försöka bestämma vilken CPU som verkar vara kompilerad för att använda teknikerna som beskrivs i den presentationen är inte så svårt (så länge du kan samla in tillräckligt prover för flera olika arkitekturer).

Mitt lata hack: ett litet Python-skript som beräknar bigram- och trigramantal. Jag söker sedan efter ett par av de vanligaste sekvenserna på Google (citerad hex). Ganska ofta lyckas jag hitta några hex-dumpningar och kan räkna ut CPU: n ur sammanhanget. Det skulle fungera ännu bättre om Google kunde söka efter råa binära värden ...

Maskininlärning kan användas för att identifiera mål-CPU för maskinkod med hög noggrannhet. Exempelvis kan verktyget ISAdetect identifiera maskinkod inriktad på 23 olika arkitekturer med maskininlärning. Det finns ett webb-API som man kan använda för att ladda upp körbara binärer eller bitar av maskinkod som ska analyseras av detta verktyg.

Här är artikeln som diskuterar de tekniker som implementerats av ISAdetect:

Mot användbar automatiserad detektering av CPU-arkitektur och ändamålsenlighet för godtyckliga binära filer och objektkodssekvenser