Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


disassembly not done for certain opcoded in windbg

raj_rraj_r Member - All Emails Posts: 983
since fnsave mnemonic came up in one latest thread i thought ill post some
discrepencies in windbgs disassembly

windbg does not disassemble 0F 3F opcodes it shows ??? instead of
disassembly

*0:000> e eip 0f 3f 05 26 cc cc cc cc*

*0:000> ? eip;db eip l5; u eip l2;t;? eip;*

Evaluate expression: 2089872112 = 7c90eaf0

7c90eaf0 0f 3f 05 26 cc .?.&.

ntdll!KiUserExceptionDispatcher+0x4:
7c90eaf0 0f ???
7c90eaf1 3f aas

(9dc.9e0): Illegal instruction - code c000001d (first chance) *CREATES AN
EXCEPTION IN UM BUT IN KERNEL MODE IT Executes perfectly well it seems
*Evaluate expression: 2089872112 = 7c90eaf0

0:000>





*kd> u vpc_8042+0xd210 l4*


*vpc_8042+0xd210:
fa9b2210 0f ???
fa9b2211 3f aas
fa9b2212 0526*8b2d54 add eax,542D8B26h
fa9b2217 90 nop

kd> bp vpc_8042+0xd210
kd> g
*Breakpoint 0 hit
vpc_8042+0xd210:
fa9b2210 0f ???*

kd> kb 4
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be
wrong.
fafaf900 805c8dde 80000578 00000000 fafaf900 vpc_8042+0xd210
fafaf944 80591ce3 e15a1630 00000001 80000578
nt!PipCallDriverAddDeviceQueryRoutine+0x235
fafaf990 80592434 fafafa1c e15a161c fafaf9f0
nt!RtlpCallQueryRegistryRoutine+0x3b1
fafaf9f4 805addac 00000000 00000084 00000001 nt!RtlQueryRegistryValues+0x2a6
*kd> t
vpc_8042+0xd214:
*fa9b2214 8b2d54909afa mov ebp,dword ptr [vpc_8042+0x4054 (fa9a9054)]

what did those 4 bytes do ?

these both break too

kd> s -b fa9a5000 l? (fa9b6000-fa9a5000) 0f 3f
fa9a6e17 0f 3f 07 0b 83 4d fc ff-83 4d fc ff b0 01 eb 0d .?...M...M......
fa9a7cdd 0f 3f 05 22 85 d2 78 15-8b 45 08 89 58 10 89 48 .?."..x..E..X..H
fa9b2210 0f 3f 05 26 8b 2d 54 90-9a fa bb 38 30 34 32 53 .?.&.-T....8042S
kd> u fa9a6e17 l4
vpc_8042+0x1e17:
fa9a6e17 0f ???
fa9a6e18 3f aas
fa9a6e19 07 pop es
fa9a6e1a 0b834dfcff83 or eax,dword ptr [ebx-7C0003B3h]
kd> u fa9a7cdd l4
vpc_8042+0x2cdd:
fa9a7cdd 0f ???
fa9a7cde 3f aas
fa9a7cdf 052285d278 add eax,78D28522h
fa9a7ce4 158b450889 adc eax,8908458Bh



Breakpoint 2 hit
vpc_8042+0x2cdd:
fa9a7cdd 0f ???
kd> u eip l3
vpc_8042+0x2cdd:
fa9a7cdd 0f ???
fa9a7cde 3f aas
fa9a7cdf 052285d278 add eax,78D28522h
kd> kb 4
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be
wrong.
fafaf744 fa9b0b4c 811957a4 8122ca48 0000000c vpc_8042+0x2cdd
fafaf770 804dad9f 8122ca48 811954f0 0001001a vpc_8042+0xbb4c
fafaf770 fa9a7098 8122ca48 811954f0 0001001a nt!KiInterruptDispatch+0x3d
fafaf820 fa9a7eab 00000000 00000000 00000002 vpc_8042+0x2098
*kd> t <--------------------------------------------------------------- can
step perfectly well though no disassembly
vpc_8042+0x2ce1:
fa9a7ce1 85d2 test edx,edx *
**
*and 4 bytes again


*

likewise
i have seen windbg not differentiating between fsave / fnsave

a sample

0:000> a eip
7c93edc0 fsave [eax]
7c93edc3 fnsave [eax]
7c93edc5 fsave [ecx]
7c93edc8 fnsave [ecx]
7c93edca
0:000> u eip l5
ntdll!LdrpInitializeProcess+0xffa:
7c93edc0 9b wait
7c93edc1 dd30 fnsave [eax]
7c93edc3 dd30 fnsave [eax]
7c93edc5 9b wait
7c93edc6 dd31 fnsave [ecx]
0:000>

9B DD /6 FSAVE m94/108byte
Store FPU state to m94byte or m108byte after checking for pending unmasked
floating-point exceptions. Then re-initialize the FPU.

DD /6 FNSAVE* m94/108byte
Store FPU environment to m94byte or m108byte without checking for pending
unmasked floating-point exceptions. Then re-initialize the FPU

i remember reading somewhere in google that assembler issues FWAIT
and FNSAVE for FSAVE and processor executes them seperately
but didnt find specifics in intel man when i looked

regards

raj_r

Comments

  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    The ?fsave? mnemonic is an alias for a ?wait? instruction followed by an ?fnsave? instruction, so the disassembler is showing the right thing there, just it doesn?t collapse the two into one mnemonic.

    - S

    From: [email protected] [mailto:[email protected]] On Behalf Of raj_r
    Sent: Sunday, December 21, 2008 2:57 PM
    To: Kernel Debugging Interest List
    Subject: [windbg] disassembly not done for certain opcoded in windbg

    since fnsave mnemonic came up in one latest thread i thought ill post some discrepencies in windbgs disassembly

    windbg does not disassemble 0F 3F opcodes it shows ??? instead of disassembly

    0:000> e eip 0f 3f 05 26 cc cc cc cc

    0:000> ? eip;db eip l5; u eip l2;t;? eip;

    Evaluate expression: 2089872112 = 7c90eaf0

    7c90eaf0 0f 3f 05 26 cc .?.&.

    ntdll!KiUserExceptionDispatcher+0x4:
    7c90eaf0 0f ???
    7c90eaf1 3f aas

    (9dc.9e0): Illegal instruction - code c000001d (first chance) CREATES AN EXCEPTION IN UM BUT IN KERNEL MODE IT Executes perfectly well it seems
    Evaluate expression: 2089872112 = 7c90eaf0

    0:000>





    kd> u vpc_8042+0xd210 l4

    vpc_8042+0xd210:
    fa9b2210 0f ???
    fa9b2211 3f aas
    fa9b2212 05268b2d54 add eax,542D8B26h
    fa9b2217 90 nop

    kd> bp vpc_8042+0xd210
    kd> g
    Breakpoint 0 hit
    vpc_8042+0xd210:
    fa9b2210 0f ???

    kd> kb 4
    ChildEBP RetAddr Args to Child
    WARNING: Stack unwind information not available. Following frames may be wrong.
    fafaf900 805c8dde 80000578 00000000 fafaf900 vpc_8042+0xd210
    fafaf944 80591ce3 e15a1630 00000001 80000578 nt!PipCallDriverAddDeviceQueryRoutine+0x235
    fafaf990 80592434 fafafa1c e15a161c fafaf9f0 nt!RtlpCallQueryRegistryRoutine+0x3b1
    fafaf9f4 805addac 00000000 00000084 00000001 nt!RtlQueryRegistryValues+0x2a6
    kd> t
    vpc_8042+0xd214:
    fa9b2214 8b2d54909afa mov ebp,dword ptr [vpc_8042+0x4054 (fa9a9054)]

    what did those 4 bytes do ?

    these both break too

    kd> s -b fa9a5000 l? (fa9b6000-fa9a5000) 0f 3f
    fa9a6e17 0f 3f 07 0b 83 4d fc ff-83 4d fc ff b0 01 eb 0d .?...M...M......
    fa9a7cdd 0f 3f 05 22 85 d2 78 15-8b 45 08 89 58 10 89 48 .?."..x..E..X..H
    fa9b2210 0f 3f 05 26 8b 2d 54 90-9a fa bb 38 30 34 32 53 .?.&.-T....8042S
    kd> u fa9a6e17 l4
    vpc_8042+0x1e17:
    fa9a6e17 0f ???
    fa9a6e18 3f aas
    fa9a6e19 07 pop es
    fa9a6e1a 0b834dfcff83 or eax,dword ptr [ebx-7C0003B3h]
    kd> u fa9a7cdd l4
    vpc_8042+0x2cdd:
    fa9a7cdd 0f ???
    fa9a7cde 3f aas
    fa9a7cdf 052285d278 add eax,78D28522h
    fa9a7ce4 158b450889 adc eax,8908458Bh



    Breakpoint 2 hit
    vpc_8042+0x2cdd:
    fa9a7cdd 0f ???
    kd> u eip l3
    vpc_8042+0x2cdd:
    fa9a7cdd 0f ???
    fa9a7cde 3f aas
    fa9a7cdf 052285d278 add eax,78D28522h
    kd> kb 4
    ChildEBP RetAddr Args to Child
    WARNING: Stack unwind information not available. Following frames may be wrong.
    fafaf744 fa9b0b4c 811957a4 8122ca48 0000000c vpc_8042+0x2cdd
    fafaf770 804dad9f 8122ca48 811954f0 0001001a vpc_8042+0xbb4c
    fafaf770 fa9a7098 8122ca48 811954f0 0001001a nt!KiInterruptDispatch+0x3d
    fafaf820 fa9a7eab 00000000 00000000 00000002 vpc_8042+0x2098
    kd> t <--------------------------------------------------------------- can step perfectly well though no disassembly
    vpc_8042+0x2ce1:
    fa9a7ce1 85d2 test edx,edx
    and 4 bytes again




    likewise
    i have seen windbg not differentiating between fsave / fnsave

    a sample

    0:000> a eip
    7c93edc0 fsave [eax]
    7c93edc3 fnsave [eax]
    7c93edc5 fsave [ecx]
    7c93edc8 fnsave [ecx]
    7c93edca
    0:000> u eip l5
    ntdll!LdrpInitializeProcess+0xffa:
    7c93edc0 9b wait
    7c93edc1 dd30 fnsave [eax]
    7c93edc3 dd30 fnsave [eax]
    7c93edc5 9b wait
    7c93edc6 dd31 fnsave [ecx]
    0:000>

    9B DD /6 FSAVE m94/108byte
    Store FPU state to m94byte or m108byte after checking for pending unmasked floating-point exceptions. Then re-initialize the FPU.

    DD /6 FNSAVE* m94/108byte
    Store FPU environment to m94byte or m108byte without checking for pending unmasked floating-point exceptions. Then re-initialize the FPU

    i remember reading somewhere in google that assembler issues FWAIT and FNSAVE for FSAVE and processor executes them seperately
    but didnt find specifics in intel man when i looked

    regards

    raj_r
    --- You are currently subscribed to windbg as: [email protected] To unsubscribe send a blank email to [email protected]
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,642
    On Sun, Decr 21, 2008 2:57 PM, someone wrote:
    >
    > since fnsave mnemonic came up in one latest thread i thought ill post some
    > discrepencies in windbgs disassembly
    >
    > windbg does not disassemble 0F 3F opcodes it shows ??? instead of
    > disassembly
    >
    > 0:000> e eip 0f 3f 05 26 cc cc cc cc
    >
    > 7c90eaf0 0f 3f 05 26 cc .?.&.
    >
    > ntdll!KiUserExceptionDispatcher+0x4:
    > 7c90eaf0 0f ???
    > 7c90eaf1 3f aas

    What do you think that instruction should be? By the most recent opcode
    charts I can find, 0F 3F is defined only on the Centaur chip, originally
    from Cyrix, now from VIA.
    --
    Tim Roberts, [email protected]
    Providenza & Boeklheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    It was determined to be a Virtual PC backdoor communication mechanism.

    (BTW, wasn't Centaur from IDT, or am I misremembering?)

    ? S

    -----Original Message-----
    From: [email protected] <[email protected]>
    Sent: Tuesday, December 23, 2008 19:33
    To: Kernel Debugging Interest List <[email protected]>
    Subject: Re: [windbg] disassembly not done for certain opcoded in windbg


    On Sun, Decr 21, 2008 2:57 PM, someone wrote:
    >
    > since fnsave mnemonic came up in one latest thread i thought ill post some
    > discrepencies in windbgs disassembly
    >
    > windbg does not disassemble 0F 3F opcodes it shows ??? instead of
    > disassembly
    >
    > 0:000> e eip 0f 3f 05 26 cc cc cc cc
    >
    > 7c90eaf0 0f 3f 05 26 cc .?.&.
    >
    > ntdll!KiUserExceptionDispatcher+0x4:
    > 7c90eaf0 0f ???
    > 7c90eaf1 3f aas

    What do you think that instruction should be? By the most recent opcode
    charts I can find, 0F 3F is defined only on the Centaur chip, originally
    from Cyrix, now from VIA.
    --
    Tim Roberts, [email protected]
    Providenza & Boeklheide, Inc.

    ---
    You are currently subscribed to windbg as: [email protected]
    To unsubscribe send a blank email to [email protected]
  • raj_rraj_r Member - All Emails Posts: 983
    tim

    those 0f 3f series of opcodes seems to be used by virtual pc for some magic
    backdoor and seems to working in R0 only

    dont know what it actually be disassembled to

    yes i have seen 0f 3f in centaur listings only publically (christian
    ludloffs page holds one referance to 0f 3f on centaur iirc )

    regards

    raj



    On 12/24/08, [email protected] wrote:
    >
    > On Sun, Decr 21, 2008 2:57 PM, someone wrote:
    > >
    > > since fnsave mnemonic came up in one latest thread i thought ill post
    > some
    > > discrepencies in windbgs disassembly
    > >
    > > windbg does not disassemble 0F 3F opcodes it shows ??? instead of
    > > disassembly
    > >
    > > 0:000> e eip 0f 3f 05 26 cc cc cc cc
    > >
    > > 7c90eaf0 0f 3f 05 26 cc .?.&.
    > >
    > > ntdll!KiUserExceptionDispatcher+0x4:
    > > 7c90eaf0 0f ???
    > > 7c90eaf1 3f aas
    >
    > What do you think that instruction should be? By the most recent opcode
    > charts I can find, 0F 3F is defined only on the Centaur chip, originally
    > from Cyrix, now from VIA.
    > --
    > Tim Roberts, [email protected]
    > Providenza & Boeklheide, Inc.
    >
    > ---
    > You are currently subscribed to windbg as: [email protected]
    > To unsubscribe send a blank email to [email protected]
    >
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,642
    Skywing wrote:
    > It was determined to be a Virtual PC backdoor communication mechanism.
    >
    > (BTW, wasn't Centaur from IDT, or am I misremembering?)
    >

    There is quite a tangled history there. You are right, the Centaur team
    was originally part of IDT. The division was purchased by VIA in 1999,
    immediately after they also bought Cyrix. It's interesting that the
    Centaur web site makes no mention of IDT.

    The opcode map I looked at attributed it to Cyrix. That must have been
    a typo, and it's an easy mistake to make, given the history.

    --
    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE