Ötletelés - hard reset 4 byte-nyi kódból, x86 Assembly, real mode

 ( Szenti | 2015. február 6., péntek - 20:16 )

Sziasztok!

Úgy alakult, hogy lesz egy kis szabadidőm nosztalgiázni, és x86 assembly-vel foglalkozni. Kb. 20 éve, amikor elkezdtem az x86 Assembly-vel ismerkedni, találtam egy 4 byte hosszú reset.com-ot, ami képes volt a gépet újraindítani. Mivel az eredeti négy bájtot már elfelejtettem (és nem biztos, hogy megvan valahol elásva a reset.com), az lenne a kérdésem, hogy ti milyen kóddal oldanátok meg? Mindenféle megoldás érdekel, de főleg a 4 byte-osak.

5 byte hosszú megoldások:

  • Az eredeti IBM PC reboot kódja elérhető például az FFFF:0000 címre való long jumppal: JMP FFFF:0000 (EA 00 00 FF FF).
  • Ugyancsak az eredeti IBM PC-ben az FFFF:0000 címen egy jmp utasítás van az F000:F553 címre (lehet, hogy tévedek, ma megnézem újra), kézenfekvő tehát egyből odaugrani (EA 53 F5 00 F0).

4 byte hosszú megoldások:

  • Ha kiindulhatunk abból, hogy egy EXE/COM fájl futtatásánál a négy alapregisztert nullázza a DOS, akkor egyszerűen: DEC AX; PUSH BX; PUSH AX; RETF; (48 53 50 CB)

Egyéb ötlet? :)

u.i.: 2 byte-os soft resetre ott van az int 19h (CD 19)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Úgy emlékszem valami ilyesmi volt, mivel a KBD mikrovezérlőnek egy GPIO-ját rávezették a resetre, bár mint írják, tesztelés nélkül nem számít igényes megoldásnak.:
http://www.delorie.com/djgpp/v2faq/faq22_26.html

Volt valami sidt megoldás is, de az nem tudom hány bájt és nem tudjuk, hogy milyen gépre kell.

Mivel úgyis legalább egy klusztert el fog foglalni a diszken, akkor nem mindegy, hogy hány bájtos a futtatható? Lásd busybox is ezért használ symlinkeket és $0-t.

OT:
Megnézni nem tudom, de ha busybox symlinket használ diszkspórolási okokból, akkor miért nem hard linkeket használ (nyilván ott, ahol a bbox és a másik-neve.exe ugynazon az FS-en csücsül)? Csak mert minden egyes symlink +1 db i-node (és fájlrendszer függően +1 töredékblokk, ahol a link által hivatkozott fájlnevet tárolja - ez utóbbit bizonyos fájlrendszerek és fájlnévhosszok esetén magában az i-node-ban)
/OT

- far jmp helyett lehetne far call is (0xca) :)
- rémlik, hogy esetleg lehetne játszani a 0x64 port legalsó bitjével, de ez csak tipp
induláskor az alapregiszterek közül csak kettő 0. ax és bx. cx-ben 0xff, dx-ben psp segcíme van.

Ha csak az AX-ról tudnánk, hogy nulla:

PUSH AX
DEC AX
PUSH AX
RETF


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem rossz, de ez a 0000:FFFF-re ugrik.

Teljesen szabályosan lehetne például:
XOR AX, AX ; AX nullázása két byte-on. A MOV AX, 0 hossza 3 byte.
DEC AC
PUSH AX
INC AX
PUSH AX
RETF

Ez így 7 byte. :)

Teljességgel nem gondoltam végig a sorrendet. Abból indultam ki, hogy a topicgazda előbb 0x0000-t, majd 0xFFFF-et tett a stack-re, s ha az jó, akkor egy azzal kompatibilis megoldás is az. Ezek szerint a felvetésben is el lett szúrva.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

5 bájtos:

push ax
dec ax
push ax
pushf
iret

bocs, fasságot írtam, offs, seg, flag sorrenben fogja popolni az iret. helyesen (ha ax és bx 0):

pushf
dec ax
push ax
push bx
iret

vagy 5-re még (ha ax és bx 0):

not ax
push ax
push bx
retl

de lehetne movsx-szel is -1 vmelyik reg, de az extended instruction, így az már maga 3 bájt...

Köszi, ez jónak tűnik, mindjárt kipróbálom. :)

Működik, köszönöm!

Tárgytalan :)