Fråga:
Varför lägger IDA till "db" -uttalanden mellan demonterad kod
Thomas Perl
2017-08-25 17:13:57 UTC
view on stackexchange narkive permalink

Jag försöker analysera en MS-DOS COM-fil som jag skrev för några år sedan med IDA Free 5.0, sedan dess har jag bytt namn på segmentet till code_and_data och namngett konstanter och ställt in datatyper korrekt. Men när man tittar på demonteringen får jag db pseudo-instruktioner i listan, så här: 

 code_and_data: 0106 replacement_irq_handler:; DATA XREF: start + 81ocode_and_data: 0106 clicode_and_data: 0107 push bxcode_and_data: 0108 db 3Ehcode_and_data: 0108 cmp byte ptr ds: 3BEh, 'C'code_and_data: 010E jnz short call_original_dos_interst__data 'code_and_data: 0116 jnz short call_original_dos_interrupt_handlercode_and_data: 0118 db 3Ehcode_and_data: 0118 cmp byte ptr ds: 3C2h,' K'code_and_data: 011E jnz short call_original_dos_interrupt_handlercode_and call_original_dos_interrupt_handlercode_and_data: 0128 db 3Ehcode_and_data: 0128 cmp byte ptr ds: 3C6h, 'N'code_and_da ta: 012E jnz kort call_original_dos_interrupt_handlercode_and_data: 0130 push StartOfIndexTablecode_and_data: 0133 pop bx

Jag förstår att det inte finns några ytterligare byte där, eftersom db och cmp instruktion efter att den börjar på samma adress (se vänster kolumn). Varför visar / lägger IDA till db pseudo-instruktioner?

Finns det något sätt att säga att det inte ska visas, eller finns det en anledning till att det kan vara användbart (jag kunde bara gissa att eftersom samma segment både används för kod och data, försöker det vara "användbart" och visa koden också som data)?

Men i så fall, varför visar den bara den första byten i instruktionen (om du tittar på adresserna till vänster igen är dessa instruktioner längre än 1 byte).

Är inte ett db-uttalande en decompilers sätt att säga "Jag kan inte förstå det, eller hur?"
Två svar:
Michael Karcher
2017-08-25 23:14:30 UTC
view on stackexchange narkive permalink

Byten 3Eh är kodningen för segmentöverstyrningen DS: . Du observerar det i en instruktion som 

  cmp byte ptr ds: 3BEh, 'C'

Hexkodningen för denna instruktion är (jag gjorde det manuellt , en bit kan vara fel) 

  3E - segment override prefix80 - 8 bit ALU instruction3E - mod / rm byte (reg = 7 -> instruction is CMP, mod = 0 / rm = 6 - > omedelbar adress) BE 03 - förskjutning av data som ska jämföras43 - omedelbar databyte

Sekvensen 3E 80 3E BE 03 53 är 6 byte lång, vilket matchar verklig instruktionslängd på 6 byte ( 010Eh - 0108h ). Om du monterar sammansättningskällkoden enligt IDA med hjälp av en standard x86-samlare (som MASM ), kommer prefixet DS: att utelämnas, eftersom adresseringsläget "omedelbar adress "är relativt datasegmentet som standard . IDA visar den extra DB instruktionen för att berätta för dig (eller en samlare som försöker återmontera listan) att det redundanta, överflödiga segmentprefixet faktiskt är kodat i binären. Om du vill dölja den informationen, markera Alternativ -> Allmänt -> Analys -> "Processorspecifika analysalternativ" -> "Visa inte redundanta instruktionsprefix".

Tack, det är verkligen detaljerat. Instruktionens hexkodning som du angav är densamma som i min inmatningsfil. Och alternativet var det jag letade efter, så att det döljer pseudo-instruktionerna `db` i listan. Häftigt!
Megabeets
2017-08-25 18:23:40 UTC
view on stackexchange narkive permalink

Redigera: Tack Michael för förtydligandet, det här är inte grenråd utan segmentprefix. Att hålla svaret som referens och för personer som kommer från sökmotorer.

Dessa är "Grenråd" som syftar till för att ge processorn en "ledtråd" om huruvida en gren sannolikt kommer att inträffa.

Branch Prediction

Det används för optimering som kallas Branch Prediction - ett försök som görs av processorn för att förutsäga vilken gren koden skulle ta. CPU: n kan fortsätta bearbeta genom att göra antaganden om riktningen för en gren innan ett tillstånd löses. Annars var det "sittande" och väntade på att det tillstånd som filialen är beroende av skulle lösas.

Från Wikipedia:

I datorarkitektur är en grenprediktor en digital krets som försöker gissa vilken sätt en gren (t.ex. en if-then-else-struktur) kommer att gå innan det är säkert känt. Syftet med grenprediktorn är att förbättra flödet i instruktionsrörledningen. Grenprediktorer spelar en avgörande roll för att uppnå hög effektivitet i många moderna pipelined mikroprocessorarkitekturer som x86.

Grenråd

Du kan antyda CPU: n om sannolikheten att en gren skulle tas med hjälp av ledtrådsbyte som sätts in före en villkorlig hoppinstruktion. Detta görs genom att använda gren-ledtrådsbyte som sätts in direkt före den villkorliga hoppinstruktionen.

Byten är 3Eh och 2Eh och de betyder enligt följande:

2Eh kod> - antydan om att filialen inte kommer att förekomma för det mesta.
3Eh - antydan om att filialen kommer att förekomma för det mesta.

Mer information:

Du kan läsa mer om ledtrådar och optimering här (rekommenderas) och här.
Om du vill läsa mer om Branch Prediction rekommenderar jag den här artikeln om Dynamic Branch Prediction.

Det är vettigt, tack - jag känner till begreppet att undvika felförutsägelser från GLibs "G_LIKELY ()" / "G_UNLIKELY ()" -makron, intressant att se att grenråd har funnits så länge. Så är det en brist på IDA att inte generera pseudo-montering för dem?
nedröstade eftersom detta svar missar frågan. "2Eh" och "3Eh" fungerar bara som grenråd om de föregår en hoppinstruktion. I det här fallet prefixerar de en minnesinstruktion och fungerar på det ursprungliga sättet - det vill säga som segmentprefix.


ⓘ
Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...