home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,621 of 4,675   
   Terje Mathisen to R.Wieser   
   Re: Indirect INT calling   
   28 Oct 18 09:06:17   
   
   From: terje.mathisen@nospicedham.tmsw.no   
      
   Selfmodifying code, i.e. fixing the 60h constant to whichever INT value   
   is being used, is by far the simplest to implement in asm.   
      
   You can also do it by emulating an INT, it is after all a push of flags   
   followed by an indirect far call:   
      
   Copy the relevant far address into a local variable:   
      
      mov bx,[intnr]   
      xor ax,ax   
      shl bx,2   
      
      push ax   
      pop es   
      
   ; At this point ES:[BX] points at the relevant vector entry:   
      
      mov ax,es:[bx]   
      mov [local_int],ax   
      mov ax,es:[bx+2]   
      mov [local_int+2],ax   
      
      
   Then when you need to call the driver you can do this:   
      
      pushf   
      CLI   
      call far [local_int]   
      
   Terje   
      
      
   R.Wieser wrote:   
   > Rod,   
   >   
   >> I would suggest hooking two interrupts.  One is for the random   
   >> or changing or relocatable interrupt that you call to access the   
   >> API.  The other would be on a fixed interrupt with a unique   
   >> registers value, say in AX, for the call to detect the presence or   
   >> installation of the packet driver API.   
   >   
   > I'm afraid you misunderstood: Finding the API (and by it its INT) isn't the   
   > problem, the packetdriver spec already took care of that (unique string at a   
   > fixed offset).   
   >   
   > The problem is that my program needs to adjust to the found INT value.   By   
   > default the packetdrivers at INT 0x60, but it can be pretty much anywhere.   
   >   
   > In short, how do I change that "0x60" (in my program) into something   
   > flexible -or- how do I create a single-point-of-change procedure (instead of   
   > having to implement a fixup for multiple INT 0x60 calls).   
   >   
   >   
   > Currently the absolute simpelest (in my mind) solution is to create a   
   > procedure with only "INT 0x60", "ret" sequence in it, and have the   
   > initialisation code change that (single!) 0x60 into whatever it found.   The   
   > downside to that is that the call itself adds another WORD to the used stack   
   > (a total 8 bytes instead of 6).   
   >   
   >> DJGPP's online RBIL has a table of used or in-use AX values   
   >> for INT 0x2F here:   
   >   
   > :-) Ralf Browns intlist has been my to-go source for literallly years, and   
   > its files (still) have a dominant place on my machine.   
   >   
   > Regards,   
   > Rudy Wieser   
   >   
   >   
   >   
   >> So, it seems INT 0x2F might be a good place to install an   
   >> installation check or interrupt number check in your case.   
   >   
   > I didn't think of such a method   
   >   
   >   
   >   
   >   
   >> I would suggest hooking two interrupts.   
   > ..   
   > Rick Hodgin also mentioned that (and I thought of it as well).   I decided   
   > against it though, as its too easy to have programs clash that way.  Just   
   > imagine two programs using that same mechanimsm (but targetting different   
   > packet drivers) ...   
   >   
   >   
   >   
   >   
   > "Rod Pemberton"  wrote in message   
   > news:pr3j19$1hgt$1@gioia.aioe.org...   
   >> On Sat, 27 Oct 2018 14:51:35 +0200   
   >> "R.Wieser"  wrote:   
   >>   
   >>> I'm dealing with a packet driver, which API (ABI?) can be put behind   
   >>> any available INT (by specifying the number when loading it).   
   >>>   
   >>> I would like my program to find the right INT at runtime (which is   
   >>> not hard, as the packet driver has a certain string at a certain   
   >>> place, just so you can check if its actually there) and than use that.   
   >>>   
   >>   
   >> I would suggest hooking two interrupts.  One is for the random or   
   >> changing or relocatable interrupt that you call to access the API.  The   
   >> other would be on a fixed interrupt with a unique registers value, say   
   >> in AX, for the call to detect the presence or installation of the   
   >> packet driver API.  This is the same way you detect DPMI or XMS etc,   
   >> e.g., DPMI installs INT 0x2F, AX=1687h and XMS installs INT 0x2F,   
   >> 4300h.  However, DPMI's main interrupt is on INT 0x31 whereas XMS   
   >> returns an address to a function on INT 0x2F, AX-4310h.  So, it seems   
   >> INT 0x2F might be a good place to install an installation check or   
   >> interrupt number check in your case.   
   >>   
   >> DJGPP's online RBIL has a table of used or in-use AX values for INT   
   >> 0x2F here:   
   >>   
   >> http://www.delorie.com/djgpp/doc/rbinter/ix/2F/   
   >>   
   >>   
   >> Rod Pemberton   
   >> --   
   >> Bitcoin is a pump-and-dump scam driven by a perpetual Ponzi scheme.   
   >>   
   >   
   >   
      
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca