Generelle forutsetninger

Når du analyserer binærfiler, er det viktig å kunne sette det som observeres i sammenheng. For eksempel, hvordan kan CPU-instruksjoner skilles fra data i en binær med et ikke-standardformat? Dette krever litt bakgrunnskunnskap om datasystemer generelt. Jeg vil hevde at før det gjøres noe forsøk på reversering av firmware, kreves det i det minste grunnleggende kjennskap til følgende konsepter:

• Dataarkitektur / datasystemorganisasjon sterk >

  • CPU-design og funksjon (f.eks. registre, instruksjonspekeren, minnetilgang)
  • minne og minnehierarkiet
  • instruksjonssett, montering, opkoder, adresseringsmodi, syntaks, mnemonics
  • informasjonsrepresentasjon (binær, hex, endianness)

• Operativsystemkonsepter sterk>

  • Virtuelt minne
  • usermode vs kernelmode, kjernen, kjernegrensesnittet (systemanrop)
  • prosessoppsett i minnet - stack, heap , data, instruksjoner
  • kjørbare formater
  • applikasjons binære grensesnitt
  • programinngangspunkter

• kildekode til objektkodetransformasjon

  • kompilering, montering, kobling
  • C / C ++ programmering
  • Assembl y programmering
  • kilde-til-enhet-konstruksjon korrelasjon (f.eks. gjenkjenning av sløyfe, bryterkonstruksjoner i montering)
  • demontering vs dekompilering

Mitt råd er følgende:

• les så mye du kan: tekniske spesifikasjoner, montering / demontering, svar på RE-spørsmål om firmware, forskningspapirer, opplæringsprogrammer, blogger, lærebøker, manuelle sider
• etterlign / kopier metodene som brukes og tilnærminger tatt av proffer
• få erfaring så raskt som mulig: se på og eksperimentere med mange forskjellige typer filer (kjørbare filer, bildefiler, komprimerte filer, firmware osv.), programmer i montering for å få en følelse av det, demontere mange kjørbare filer

Firmware RE Resources

" Intro to Embedded Reverse Engineering for PC reversers" av Igor Skochinsky gir en oversikt over hva som er involvert i reversering av firmware, og i " Embedded Devices Security: Firmware Reverse Engineering" skisserer Jonas Zaddach og Andrei Costin en generell metode for å reversere firmware som begynner på lysbilde 31.

Se på svar gitt av proffene:

• devttys0
• ebux
• Igor Skochinsky
• 6EQUJ5

Disse kan være nyttige eller interessante:

devttys0s blogg

ea blogg

Igors blogg

firmware.re

IOActive Labs Research-blogg

sviehbs blogg

Innebygde systemer bruker ofte MIPS eller ARM-prosessorer, og i tillegg MIPS eller ARM instruksjonssett. Dette betyr at det å være kjent med MIPS- og ARM-montering vil være veldig nyttig når man analyserer firmware for disse systemene.

Analysering av binær

Del 1: Identifikasjon av målenhetens arkitektur

Vi kan ikke stole på hørselshør for å få den informasjonen som kreves for å analysere fastvaren. Gyldigheten av informasjon om firmware må bevises ved bruk av empirisk bevis. Det er ikke nok å ha en binær blob fra en bruktkilde og et prosessornavn fra et annet spørsmål.

1. Identifiser målenheten

Heldigvis er det i dette tilfellet enkelt å i det minste få enhetsnavnet: SMOK X Cube II. Når leverandørens firmware- og verktøystøtteside undersøkes, viser det seg at det finnes en ekte enhet med det navnet. .Hex-filen er pakket med et oppgraderingsverktøy fra taiwansk halvlederprodusent Nuvoton kalt " NuMicro ISP Programming Tool":

  ~ / firmware / e-cig / XCUBE II oppgraderingsverktøy $ file * config.ini: ASCII text, with CRLF line terminators NuMicro ISP Programming Tool.exe: PE32 executable (GUI) Intel 80386, for MS WindowsNuMicro ISP Programming Tool User's Guide.pdf: PDF document, version 1.5XCUBE II-VIVI-52 (160616) V.1.098 (checksum = 0x28F9) .hex: ASCII text, with CRLF line terminators  

Denne heksefilen er rett fra produsenten av prosessoren i stedet for fra en bruktkilde. Det er også en nyere versjon - v1.098 i stedet for v1.07. Jeg bestemte meg for å analysere den eldre firmwareversjonen (v1.07) siden dette er den versjonen av den binære i spørsmålet.

2 . Identifiser prosessoren

Det er noen interessante ting på bildene som brukes til å beskrive oppgraderingsprosessen: navnet NuMicro og akronymet ISP i verktøynavnet , begrepet DataFlash , en referanse til noe som heter APROM , og viktigst av alt, delenummeret: NUC220LE3AN . Hvilken "del" er dette et tall for? En Nuvoton-utviklet mikrokontroller basert på ARMs Cortex-M0-prosessor.

3. Identifiser instruksjonsarkitekturen

Nuvoton er snill nok til å dele teknisk dokumentasjon for NuMicro NUC220-serien, inkludert datablad og teknisk referansehåndbok, i tillegg til forskjellige programvareverktøy og opplæringsmateriell (klikk på "Ressurser" -fanen øverst på NUC220LE3AN-produktsiden).

Fra databladet, Seksjon 1: "Generell beskrivelse", side 7 (vektlegging min ):

NuMicro NUC200-serien 32-biters mikrokontrollere er innebygd med den nyeste ARM® Cortex ™ -M0-kjernen med en kostnad tilsvarende tradisjonell 8-biters MCU for industriell kontroll og applikasjoner som krever omfattende kommunikasjonsgrensesnitt. NuMicro NUC200-serien inkluderer NUC200 og NUC220 produktlinjer.

Er dette nok informasjon til å konkludere med at koden i firmwarebinaren består av 32-biters ARM-instruksjoner? Nei, det er det ikke . La oss se nøye på prosessorens funksjonelle beskrivelse (kapittel 6: Funksjonell beskrivelse, del 1: ARM Cortex-M0 Core, side 48):

La oss være spesielt oppmerksom på følgende informasjon:

• Prosessoren kan utføre tommelfinger-kode og er kompatibel med en annen Cortex®-M-prosessor.

• ARMv6-M Thumb® instruksjonssett

• Thumb -2 teknologi

Merk at prosessoren er en ARM Cortex-M0 Core og ikke ARM Cortex-M0 + Core, som har et annet instruksjonssett.

Fra ARMs Cortex-M0 tekniske referansehåndbok:

Prosessoren implementerer ARMv6-M Thumb instruksjonssett, inkludert et antall 32-bit instruksjoner som bruker Thumb-2 teknologi. ARMv6-M instruksjonssettet består av:

• alle 16-biters tommelinstruksjoner fra ARMv7-M unntatt CBZ, CBNZ og IT

• 32-biters tommelinstruksjoner BL, DMB, DSB, ISB, MRS og MSR.

Hva er "Thumb code" og "Thumb instruksjonssett "?

Fra" Introduksjon til ARM thumb "av Joe Lemieux (vektlegging av meg):

Thumb instruksjonssett består av 16-biters instruksjoner som fungerer som en kompakt forkortelse for en delmengde av 32-biters instruksjoner i standard ARM. Hver tommelinstruksjon kunne i stedet utføres via tilsvarende 32-biters ARM-instruksjon. Imidlertid er ikke alle ARM-instruksjoner tilgjengelig i Thumb-undergruppen; for eksempel er det ingen måte å få tilgang til status eller kopiprosessorregistre. Noen funksjoner som kan utføres i en enkelt ARM-instruksjon, kan også bare simuleres med en sekvens med tommelinstruksjoner.

På dette punktet kan du spørre hvorfor har to instruksjonssett i samme CPU? Men egentlig inneholder ARM bare ett instruksjonssett: 32-bitersettet. Når den fungerer i tommelfingerstatus, utvider prosessoren ganske enkelt de mindre stenografiske instruksjonene hentet fra minnet til deres 32-biters ekvivalenter.

Forskjellen mellom to likeinstruksjoner ligger i hvordan instruksjonene blir hentet og tolket før utførelse, ikke i hvordan de fungerer. Siden utvidelsen fra 16-biters til 32-biters instruksjon oppnås via dedikert maskinvare i brikken, reduserer den ikke utførelsen enda en gang. Men de smalere 16-biters instruksjonene gir hukommelsesfordeler.

Thumb-instruksjonssettet gir mest mulig funksjonalitet som kreves i et typisk program. Aritmetiske og logiske operasjoner, belastning / lagring av databevegelser og betingede og ubetingede grener støttes. Basert på det tilgjengelige instruksjonssettet, kan hvilken som helst kode skrevet i C kunne utføres vellykket i tommelfingerstat. Enhetsdrivere og unntakshåndterere må imidlertid ofte skrives i det minste delvis i ARM-tilstand.

Her er en god forklaring fra SO: ARM, Thumb and Thumb 2 instruksjoner forvirring

Fra ARMv6-M Architecture Reference Manual, Kapittel A5: Tommelinstruksjons-koding, seksjon 1: Tommelinstruksjons-koding, side 82:

I tillegg:

NuMicro NUC200 Series støtter bare lite endian dataformat.

For å oppsummere: koden i firmwarebinæren vil bestå av 16-biters ARM-tommelinstruksjoner med liten endian pluss noen 32-biters Thumb2-instruksjoner som skal utføres av en 32-bit ARM Cortex-M0-prosessor som implementerer ARM 16- bit Thumb instruksjonssett med støtte for Thumb2.

4. Identifiser enhetens minneoppsett

Tilgang til den tekniske referansehåndboken lar oss bestemme hva APROM og ISP er. Fra kapittel 6: Funksjonsbeskrivelse, avsnitt 4.4.1: Organisering av flashminne, side 191:

Flashminnet i NuMicro NUC200-serien består av programminne (APROM), Data Flash, ISP-lasterprogramminne (LDROM) og brukerkonfigurasjon. Programminne er hovedminne for brukerapplikasjoner og kalles APROM. Brukeren kan skrive applikasjonen sin til APROM og stille systemet til å starte fra APROM.

ISP loader programminne er designet for en loader for å implementere In-System-Programming funksjon. LDROM er uavhengig av APROM, og systemet kan også settes til å starte fra LDROM. Derfor kan brukeren bruke LDROM for å unngå systemoppstart mislykkes når koden til APROM ble ødelagt.

Og fra kapittel 6: Funksjonell beskrivelse, avsnitt 4.4.5: In-System-Programming (ISP) , side 199:

ISP gir muligheten til å oppdatere systemfastvare om bord. Ulike perifere grensesnitt lar ISP-lasteren i LDROM for å motta ny programkode enkelt. Den vanligste metoden for å utføre ISP er via UART sammen med ISP-lasteren i LDROM. Generelt sett overfører PC den nye APROM-koden gjennom seriell port. Så mottar ISP-lasteren den og programmerer den om til APROM via ISP-kommandoer.

I henhold til informasjonen i config.ini -filen som følger med NuMicro ISP Programming Tool. , flash-minnestørrelse for APROM-segmentet er 128 KB:

  $ cat config.ini | grep NUC200LE3AN -B2 -A3 [0x00020000] NAME_STRING = NUC200LE3ANRAM_SIZE = 16FLASH_SIZE = 128  

Her er et diagram over adressekartet for flashminnet:

Vi vet at plassen fra 0x0000_0000 til 0x0001_FFFF = 131071 byte , som er 128 KB, og dette er regionen som binær fra hex-filen vil bli blinket til ved hjelp av oppgraderingsverktøyet. Over det er det en blokk med minne fra 0x0002_0000 til 0x0010_000 som er merket "Reservert for videre bruk". Størrelsen på dette "Reservert" -området er 0x0010_0000 - 0x0002_0000 = 0xE0000, eller 917504 byte. Dette er nesten 1 megabyte reservert plass. 128 KB reservert for APROM utgjør 12,5% av adresseområdet mellom 0x0000_0000 og 0x0010_0000, men er representert som større enn ~ 1 MB "Reservert" -blokk. Dette er veldig rart. Det er heller ingen dokumentasjon for denne reserverte blokken noe sted i den tekniske referansehåndboken som jeg kunne finne. Hvis man hadde fysisk tilgang til enheten, kan innholdet i flashminnet kanskje dumpes og analyseres for å finne ut hva som ligger i denne regionen.

Siden firmwarebinaren er skrevet til plass i flashminnet reservert for brukeren applikasjoner, virker det lite sannsynlig at firmwarebinaren inneholder kjernekode, bootloader-kode eller et filsystem. Dette er forskjellig fra fastvare fra ruteren, som i det minste har en tendens til å inneholde kjernekode.

Del 2: Direkte analyse av den binære

Rask oppsummering av det vi vet på dette punktet:

• Enhetsnavnet - SMOK X Cube II
• Prosessoren - En NuMicro NUC220LE3AN-prosessor, basert på en ARM Cortex-M0 Core-prosessor
• instruksjonsarkitektur - liten endian ARM-v6 M 16-biters tommel
• Plasseringen i flashminne som firmware skal skrives til - 128 KB APROM-regionen for brukerapplikasjoner (med andre ord, ikke kjernen )
• NuMicro er et Taiwan-basert selskap. Vi vil se hvorfor dette potensielt er relevant snart.
• Entropiplottet generert av binwalk inkludert i spørsmålet avslører at det ikke er krypterte eller komprimerte regioner i firmware
• Basert på informasjon som er inkludert i spørsmålet, finnes det ASCII strenger innebygd i filen som ser ut til å være relatert til funksjonaliteten til enheten

Potensielle komplikasjoner:

• firmware-binærfiler har ikke et standardformat som kjørbar binærfiler gjør
• Data kan blandes med kode / instruksjoner i binærfilen. Hvis dette er tilfelle, er det mulig at data som strenger demonteres som instruksjoner, noe som resulterer i en feil fremstilling av firmwarekoden

Foreløpig analyse

1. strenger og hexdump◄

Utdataene til strenger kan brukes til å raskt heuristisk for å avgjøre om firmware er kryptert / komprimert. Hvis det ikke er noen strenger i utdataene, er det en god indikator på at hele filen er tilslørt på en eller annen måte. hexdump med -C-argumentet kan brukes til å gi noen sammenheng for strengene, dvs. hvor i binærfasen de er i forhold til kode og i forhold til hverandre. Med andre ord, er strengene pakket sammen i en enkelt blokk, eller er de spredt over binæren? Svaret kan gi ledetråder om utformingen av fastvaren.

Ved å bruke hexump ser vi at ASCII-strengene er blandet med det som kan være kode:

  00002ed0 01 21 1b 20 fd f7 6e fe 21 46 38 6a 09 f0 16 fd |.!. ..n.! F8j .... | 00002ee0 64 21 09 f0 13 fd 08 46 0a 21 09 f0 0f fd 10 30 | d! ..... F.! ..... 0 | 00002ef0 14 21 48 43 42 19 01 21 25 20 fd f7 5b fe 73 e0 |.! HCB ..!% .. [. S. | 00002f00 68 e2 88 e0 57 41 54 54 0a 00 00 00 4d 4f 44 45 | h ... WATT .... MODE | 00002f10 0a 00 00 00 7c db 00 00 88 db 00 00 54 45 4d 50 | .... | ....... TEMP | 00002f20 0a 00 00 00 4d 45 4d 4f 52 59 0a 00 20 4d 4f 44 | .... MINNE .. MOD |
00002f30 45 20 0a 00 ac 01 00 20 53 54 52 45 4e 47 54 48 | E ..... STYRKE | 00002f40 0a 00 00 00 3c 0b 00 20 20 4d 49 4e 20 0a 00 00 | .... <. MIN ... | 00002f50 53 4f 46 54 0a 00 00 00 4e 4f 52 4d 0a 00 00 00 | SOFT .... NORM .... | 00002f60 48 41 52 44 0a 00 00 00 20 4d 41 58 20 0a 00 00 | HARD .... MAX ... | 00002f70 ea cf 00 00 42 4c 55 45 54 4f 4f 54 48 0a 00 00 | .... BLUETOOTH ... | 00002f80 20 20 20 4f 4e 20 20 20 20 0a 00 00 20 20 20 4f | PÅ ... O | 00002f90 46 46 20 20 20 0a 00 00 ea d0 00 00 20 20 20 4c | FF ....... L | 00002fa0 45 44 20 20 20 0a 00 00 6a d1 00 00 53 54 45 41 | ED ... j ... STEA | 00002fb0 4c 54 48 0a 00 00 00 00 20 4f 46 46 20 20 0a 00 | LTH ..... OFF .. | 00002fc0 20 20 4f 4e 20 20 0a 00 20 20 54 4f 44 41 59 20 | PÅ .. I DAG | 00002fd0 20 0a 00 00 80 96 98 00 f6 e1 00 00 83 e5 00 00 | ............... | 00002fe0 a0 86 01 00 10 27 00 00 21 46 38 6a 09 f0 8e fc | ..... '..! F8j .... | 00002ff0 0a 21 09 f0 8b fc 10 31 14 20 41 43 4a 19 01 21 |.! ..... 1. ACJ ..! |  

en annen gruppe ASCII-strenger andre steder i binærfilen:

  00004f70 84 e0 04 f0 40 fe 00 28 13 d0 00 20 03 f0 ec ff | .... @ .. (... .... | 00004f80 1e 49 80 31 08 69 88 61 35 4a 90 42 00 d3 8c 61 | .I.1.i.a5J.B .. .a | 00004f90 88 69 08 62 33 48 06 23 04 22 00 90 19 46 00 20 | .i.b3H. #. "... F. | 00004fa0 62 e0 6b e0 20 43 48 45 43 4b 20 20 0a 00 00 00 | bk CHECK .... | 00004fb0 41 54 4f 4d 49 5a 45 52 0a 00 00 00 f6 e0 00 00 | ATOMIZER ........ | 00004fc0 28 03 00 20 ac 01 00 20 7a e0 00 00 20 20 43 48 | (.. ... z ... CH | 00004fd0 45 43 4b 20 20 0a 00 00 10 4b 00 00 ba e0 00 00 | ECK .... K ...... | 00004fe0 44 4f 4e 27 54 0a 00 00 41 42 55 53 45 0a 00 00 | IKKE ... MISBRUK ... | 00004ff0 50 52 4f 54 45 43 54 53 21 0a 00 00 3c 0b 00 20 | BESKYTTELSER! .. .< .. | 00005000 20 57 41 54 54 20 0a 00 2c 2f 00 00 60 ea 00 00 | WATT .., / .. `... | 00005010 36 e1 00 00 2d 53 48 4f 52 54 2d 20 0a 00 00 00 | 6 ...- KORT- .... |
00005020 b2 eb 00 00 88 13 00 00 20 53 48 4f 52 54 20 20 | ........ KORT | 00005030 0a 00 00 00 81 0b 00 00 49 53 20 4e 45 57 0a 00 | .... .... ER NYTT .. | 00005040 43 4f 49 4c 3f 20 0a 00 59 0a 00 00 4e 0a 00 00 | SPOLE? ..Y ... N ... | 00005050 7c db 00 00 88 db 00 00 dc 05 00 00 a0 db 00 00 || ............... | 00005060 0f 27 00 00 94 db 00 00 fb f7 e0 fd 28 46 fd f7 | .'.......... (F .. | 00005070 a1 f8 fb f7 f0 fe 07 20 fd f7 08 fb af 20 fb f7 |. ...... ..... .. | 00005080 2f ff 00 20 fb f7 30 ff 38 bd ff 49 08 60 70 47 | / .. ..0.8..I.`pG | 00005090 fe 49 88 72 70 47 fd 48 80 7a 70 47 10 b5 13 24 | .I.rpG.H.zpG ... $ |  

flere ASCII-strenger andre steder:

  00005490 44 2f 00 00 34 0c 00 20 a0 db 00 00 88 db 00 00 | D / .. 4 .. ........ | 000054a0 94 db 00 00 7c db 00 00 ea d5 00 00 36 0a 00 00 | .... | ....... 6 ... | 000054b0 2e 0a 00 00 50 4f 57 45 52 0a 00 00 20 4f 46 46 | .... POWER ... OFF | 000054c0 20 0a 00 00 20 20 4f 4e 20 0a 00 00 e7 03 00 00 | ... ON ....... | 000054d0 0f 27 00 00 9f 86 01 00 33 08 00 00 5f db 00 00 |. '. ..... 3 ..._... | 000054e0 fb f7 a4 fb fd 49 20 68 07 f0 10 fa 7d 27 08 46 | ..... I h ....} '. F | 000054f0 ff 00 39 46 07 f0 0a fa f9 4e 00 01 80 19 01 22 | ..9F ..... N ..... "|  

Det er flere slike klynger av ASCII-strenger i forskjellige deler av filen. Noen av ASCII-strengene er nevnt i produktmanualen:

Imidlertid er mange av ASCII-strengene i binær er ikke nevnt i håndboken, som disse:

  00009d00 21 b0 f0 bd 00 01 00 50 00 ff 01 00 b4 ed 00 00 |! ...... P ........ | 00009d10 43 12 67 00 45 52 52 4f 52 3a 20 20 20 0a 00 00 | CGERROR: ... | 00009d20 4e 4f 20 53 45 43 52 45 54 0a 00 00 2d 4b 45 59 | NO SECRET ...- NØKKEL | 00009d30 21 20 20 20 20 0a 00 00 ef 48 00 68 c0 07 c0 0f |! .... H.h .... |  

Visualisering av binærprogrammet viser også at bytesekvenser som faller innenfor ASCII-området, er spredt over binærområdet (blå er ASCII):

2. Med tanke på lokaliteten ble firmware utviklet i betraktning

Firmware, oppgraderingsverktøyet og mikrokontrolleren er alle utviklet av Nuvoton, et taiwansk selskap. Kanskje er det også sekvenser av tradisjonelle kinesiske tegn i binærfilen.

Som standard søker strenger etter ASCII-tegnsekvenser og -C-alternativet for hexdump skriver ut byte innenfor ASII-området som ASCII-tegn. Men hva om det er Unicode -kodede strenger i binæren i tillegg til ASCII-kodede strenger? Radare2 kan brukes til å søke etter strenger i hex-filen direkte, i stedet for å stole på utdataene fra et annet verktøy ( hexdump er ganske fleksibelt, men det er raskere å bruke radare2). For å søke etter strenger, vil kommandoene izz brukes til å søke etter strenger i det binære:

  $ r2 ihex: // SMOK_X_CUBE_II_firmware_v1 .07.hex - Jeg er Pentium of Borg. Divisjon er nytteløst. Du blir tilnærmet. [0x00000000] > izzVil du skrive ut 1444 linjer? (y / N) < --- skriv inn "y", selvsagt  

Dette har noen potensielt interessante resultater:

  vaddr = 0x0000aa95 paddr = 0x0000aa95 ordinær = 1093 sz = 28 len = 13 seksjon = ukjent type = bred streng = h (胐 恇 ԇӕ 栠 だ i (胐⁇ ԇvaddr = 0x0000aab5 paddr = 0x0000aab5 ordinær = 1094 sz = 54 len = 26 seksjon = ukjent type = bred streng = i (胐 ⱇ 潩  HhШ ⣐ࡉ⡀ ѡ ⣠ ũ ड 蠅 灡 (h (胐 vaddr = 0x0000aaef paddr = 0x0000aaef ordinær = 1095 sz = 10 len = 4 seksjon = ukjent type = bred streng = Hh̨ ⣐ vaddr = 0x0000ab07 paddr = 0x0000ab07 ordinal = 1096 sz = 62 len = 30 snitt = ukjent type = bred streng = h (胐  ᄆ탕 HhШ 棐 칩 ࡉ 桀 ѡ 棠 ũ ड 蠅 桃 灡 i (胐  ༂ 웕 Hh̨ 棐 vaddr = 0x0000ab53 paddr = 0x0000ab53 ordinal = 1097 sz = 70 len = 34 snitt = ukjent type = vidstreng = i (胐  삵 汍 쁨 ԇǐ 栠 栠 h (胐 ꁇ ԇ˕ 栠 끠 h (胐 恇 ԇӕ 栠 だ i (胐 ԇ ԇ)
vaddr = 0x0000ab9d paddr = 0x0000ab9d ordinal = 1098 sz = 58 len = 28 seksjon = ukjent type = bred streng = i (胐 ⱇ 潩  ꧕HhШ ⣐ ꡩࡉ ⡀ ѡ ⣠ ũ ड 蠅 ⡃ 灡 h (灡 ꈂ ཌ vaddr = 0x0000abd7drdd7 ordinær = 1099 sz = 10 len = 4 seksjon = ukjent type = bred streng = Hh̨ ⣐ vaddr = 0x0000abef paddr = 0x0000abef ordinal = 1100 sz = 62 len = 30 seksjon = ukjent type = bred streng = h (胐  ᄆ 雕 HhШ 棐鑩 ࡉ 桀 ѡ 棠 ũ ड 蠅 桃 灡 i (胐  ༂ ̨ Hh̨ 棐 vaddr = 0x0000ac3b paddr = 0x0000ac3b ordinal = 1101 sz = 22 len = 10 seksjon = ukjent type = bred streng = i (胐  袽 腈 ཨ ሢ ᄅ 腃  

Jeg kan ikke lese disse tegnene, så jeg vet ikke hvilket språk de er fra. Kanskje det bare er gibberish.

3. Bruke en hex-editor

En hex editor med en GUI kan brukes til raskt å søke etter mønstre i dataene. For eksempel ser byte 0A ut den brukes som et avsluttende tegn for ASCII-strenger:

Demontering

Så hvordan skal binæren demonteres bruker r2? Er det noen spesielle argumenter eller kommandoer for 16-biters ARM Thumb instruksjoner + noen 32-bit Thumb2 instruksjoner?

Fra Hvordan demonteres til ARM UAL?:

-b16 antas for tommelen, ikke fordi instruksjonsstørrelsen eller registerstørrelsen. Det er et unntak for å gjøre ting enklere. Fordi det bare er en modus for CPU.

-b16 setter thumb2-modus i capstone-demonterer (så vel som i GNU). Thumb2 inneholder lengder på 2 byte og 4 byte. Tommelen var bare 2. Men tommel og tommel2 er binærnl-kompatible, så det er fornuftig å bruke tommel2 her, med mindre CPU-en ikke støtter det. og denne symtaksen skal være klar i capstone.

Capstone vet ingenting om kode eller data. Det demonteres bare.

For å demontere filen riktig, er det viktig at riktig arkitektur er spesifisert:

-b bits force asm.bits (16, 32, 64)

For denne fastvarebinaren skal -b 16 brukes, ikke -b 32 :

$ r2 -a arm -b 16 ihex: //SMOK_X_CUBE_II_firmware_v1.07.hex

Hvis -b 32 brukes, blir resultatet ganske mye av bytesekvenser r2 lyder som ugyldige på grunn av feiljustering:

For referanse, her er demontering som begynner ved samme forskyvning, 0x1e8 , med riktig 16-bits justering:

Dette er åpenbart helt annerledes.

For å analysere den demonterte koden, må man være kjent med ARM Thumb instruksjonssett og montering, og sannsynligvis ARM mer generelt (CPU-design, registre, etc.). Et godt utgangspunkt ser ut til å være Azeria Labs-veiledningen.

Ytterligere betraktninger

• ISP-oppgraderingsverktøyet er en kjørbar binær MS Windows PE32. Dette kan konverteres for å bestemme hvordan blinkingsprosessen foregår.
• Fysisk tilgang til mikrokontrolleren kan være nyttig. Hele innholdet i flashminnet kan dumpes og analyseres. Dette vil også gjøre det mulig for en å se nøyaktig hvordan alt er lagt ut i flashminne
• hvis kjente gode kodeblokker kan isoleres, er det mulig å dekompilere det

Konklusjon

Forhåpentligvis viser tilnærmingen som er brukt her nyttig for fremtidige RE-forsøk på fastvare. Analysering av fastvare gir sine egne utfordringer på grunn av det nære forholdet mellom den og maskinvaren den er designet for å være innebygd i. Siden utformingen og arkitekturen til enheten bestemmer utformingen og innholdet av firmware, kan firmware noen ganger ikke reverseres uten tilgang til enheten, eller i det minste å kjenne instruksjonsarkitekturen til enheten.