Announcement

Collapse
No announcement yet.

Intel SIB Byte decipher - Attn: Paul Dixon

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel SIB Byte decipher - Attn: Paul Dixon

    I am working on an error handler that thanx to Paul Dixon I have been pointed in the right direction, but I am TOTALLY stuck on the Intel Documentation on how to handle the SIB byte.

    Can someone explain how this is done? (Maybe they understand the page and can tell me what I should be doing?)


    [Updated]
    It might be that I am confusing my units (Hex replies vs Decimal replies etc, when they are all the same number up to 9 anyways)

    If anyone can explain in the meanwhile, I would really appreciate it.
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    I did a little google and came up with this...

    http://www.swansontec.com/sintel.html

    Search on SIB on that page and it seems to do a bit of explaining. I'm no intel assembly programmer (gimme back the ole 6809!) so I'm weak on reading op codes lingo.
    <b>George W. Bleck</b>
    <img src='http://www.blecktech.com/myemail.gif'>

    Comment


    • #3
      Cliff,
      the SIB byte stands for Scale Index Base byte.
      Scale = the first 2 bits
      Index = next 3 bits
      Base = last 3 bits.

      The SIB byte is present if the ModR/M byte has R/M = 4 and Mod = 0,1 or 2.


      If the SIB byte is present then it takes up 1 byte in the opcode. Apart from the following exception that's all there is to it.

      There is one exception, if Mod from the ModR/M byte = 0 and Base from the SIB byte = 5 then there is a 32 bit (4 byte) displacement in the instruction so you need to add 4 bytes to the instruction length.


      Paul.

      Comment


      • #4
        That may be where my confusion is.
        IF there is a SIB, then the extra bytes from MOD go before the SIB? or after?

        I think my problem for checking SIB is checking the wrong byte?
        Engineer's Motto: If it aint broke take it apart and fix it

        "If at 1st you don't succeed... call it version 1.0"

        "Half of Programming is coding"....."The other 90% is DEBUGGING"

        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

        Comment


        • #5
          Cliff,
          the order of bytes is as shown in the first diagram in "Chapter 2:Instruction format" of the Pentium manual I've mentioned previously:

          Code:
          1st optional prefixes in any order (0 to 4 bytes)
          2nd The main opcode (1 to 3 bytes)
          3rd The optional ModR/M byte (1 byte if needed)
          4th The optional SIB byte (1 byte if needed)
          5th The optional displacement (1,2 or 4 bytes) 
          6th The optional immediate value (1,2 or 4 bytes)
          e.g. an instruction such as
          Code:
          !mov dword ptr cs:[eax*2+&h99887766],&h12345678
          Will encode as:
          Code:
          2E:C70445 66778899 78563412        MOV DWORD PTR CS:[EAX*2+99887766],12345678
          Code:
          1st optional prefixes in any order (0 to 4 bytes) in this case 1 byte, 2E is the Code Segment override prefix
          2nd The main opcode (1 to 3 bytes)                in this case 1 byte, C7 is the MOV r/m32,imm32 opcode
          3rd The optional ModR/M byte (1 byte if needed)   in this case 1 byte, 04 specifies a complex addressing mode requiring SIB byte is needed   
          4th The optional SIB byte (1 byte if needed)      in this case 1 byte, 45 specifies a 32 bit displacement, no Base register and EAX x 2 index
          5th The optional displacement (1,2 or 4 bytes)    in this case the 4 bytes 99887766 (little endian)
          6th The optional immediate value (1,2 or 4 bytes) in this case the 4 bytes 12345678 (little endian)

          Paul.
          Last edited by Paul Dixon; 7 Jun 2009, 06:30 PM.

          Comment


          • #6
            Since a known exception will NOT call any ErrorHandler function I create while in DEBUG I have to guess at if my theory is flawed or not?


            So far my code works as follows, but I am still REALLY unsure if I have it right?

            Error Raised: Division by zero
            Byte Pointer Returned: (Insert # but I will just say 4233690) Note: # is in Hex
            Bytes needed to skip to next line of code as if no error had happened: 6

            I.) I look at byte 0 to see if 1 or more prefix bytes exist
            Ib.) No prefix bytes so then the following
            II.) I look at next byte for OpCode (in this case byte 0 and byte 1 which results in Byte0 = F7 and Byte1 = BD)
            III.) Looking up the value for BD indicates "disp32[EBP]" which I read as meaning 4 bytes but no SIB byte after so I stop checking.

            Total Bytes found: 2 for OpCode, 4 for ModR/M (I need 6 so this matches and lets me continue)

            My Return point is now 4233696

            Next I just want to skip a line, so using Debugger (with no error, just to see the # of bytes needed to skip the line I get 31 bytes)

            Performing the same procedure of steps I get
            Byte0 = 89hex and Byte1 = 85hex since I had no prefixes in this case either
            looking up 85hex I get the same "disp32[EBP]" which I read as meaning 4 bytes but no SIB byte after so I stop checking. (but why would I? seeing how I KNOW I need 31 bytes)
            Total bytes = 6 and I need 31

            What the heck am I doing wrong???? (Do I need to update EIP somehow and get a new pointer? or am I checking the wrong bytes and just happen to pass the 1st test by accident? or ??????)
            Engineer's Motto: If it aint broke take it apart and fix it

            "If at 1st you don't succeed... call it version 1.0"

            "Half of Programming is coding"....."The other 90% is DEBUGGING"

            "Document my code????" .... "WHYYY??? do you think they call it CODE? "

            Comment

            Working...
            X