Windows - IDT table entries all 0's

NTDEV
21

[quote]
Yes, knowledge is power, and what goes along with that power is a
responsibility not to screw things up. The whole world of kernel software is
one of trust. Trust that YOU will not screw up my code and trust that I will
not screw up your code. That trust is earned by demonstrating you can be
responsible with the power you have. This is very different than user mode
software, where the assumption is we don’t have to trust each other, because
the operating system will protect us from each other. Even in user mode
software, this isolation is not perfect.

[quote]

Huzza!

Dave Cattley

22

On Wed, May 26, 2010 at 9:58 PM, Gregory G Dyess wrote:
> Very excellent summarization of the situation. ?If I can just add one thing
> left out. ?Many of the techniques discussed here can also be twisted and
> used for purposes of creating intentionally destructive software (malware,
> Trojans, root kits, etc).u

The point is the very same technique can be used for good thing, too.
For ex, all the malware scanners need to hook deeply inside the kernel
to catch system activities. Even more than that, honeypot uses exactly
same covert methods used by rootkits to evade detection.

That is why people asking these kind of questions are not necessarily
bad guys, or going to do bad thing with the this kind of knowledge.

Thanks,
Jun

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> Sent: Wednesday, May 26, 2010 2:36 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Windows - IDT table entries all 0’s
>
> If you just want to hack on Intel processors, you’d be WAY better off
> fooling with an OS than has full source access.
>
> If you want to learn to write commercial driver software for Windows, there
> is a pretty significant technical knowledge and culture you will need to
> learn about. A large percentage of us here on this list are commercial
> driver developers. It’s kind of like many of us are highly experienced
> surgeons, and we don’t want to have to deal with the mess left by somebody
> else.
>
> I won’t mind you writing Windows drivers if you don’t mind me performing
> brain surgery on you. A little difference is you can pretty easily say NO
> when I show up with my Dremel tool, but I don’t really have any easy way of
> assuring any code you write will not end up running on my or one of my
> customers systems, so all I and other list members can do it try to convince
> YOU not to do irresponsible things in software.
>
> You may think software is totally safe and no harm can come to anybody, but
> just a couple months ago, a large software company had a glitch in their
> antivirus software which brought down vast numbers of systems. I heard one
> hospital emergency room had to refuse treating anybody who was not in
> critical condition, because all their computers were down. Your computer may
> not be all that critical, but there are organizations and people in the
> world who correct operation of their computer literally can mean the
> difference in someone’s life.
>
> So next time you drive across a bridge, or are in a tall building, or fly in
> an airplane, think to yourself: “Do I want the people who designed this to
> just be fooling around, and anything that doesn’t instantly fall apart is
> ok, or do I want them to be as skilled as possible, and use engineering
> practices that have evolved over many years to the point of an advanced
> science”. MANY pieces of software are no different than the engineering for
> that airplane, where the consequences of flaws can ruin your life. Even for
> very skilled software professionals, using the best processes available, the
> overall quality of software is not as good as it needs to be.
>
> Yes, knowledge is power, and what goes along with that power is a
> responsibility not to screw things up. The whole world of kernel software is
> one of trust. Trust that YOU will not screw up my code and trust that I will
> not screw up your code. That trust is earned by demonstrating you can be
> responsible with the power you have. This is very different than user mode
> software, where the assumption is we don’t have to trust each other, because
> the operating system will protect us from each other. Even in user mode
> software, this isolation is not perfect.
>
> Jan
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-412421-
>> xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
>> Sent: Tuesday, May 25, 2010 9:46 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] Windows - IDT table entries all 0’s
>>
>> Jun: I think people here wants to authenticate my intentions :slight_smile:
>>
>> Further addition to your comments: -
>> There is nothing in Intel manual saying IDT should never be touched,
>> and I don’t know why it’s much of an issue reading IDT table. Knowledge
>> is power and gaining knowledge shouldn’t be considered a bad thing.
>>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

23

I have to disagree, most of the people who are doing the type of work
you point as beneficial know how to do these things, or have the smarts
to work through it themselves. Worse yet this is a public forum, so
even if the OP intentions are totally pure and good, you don’t know how
many lurkers are out there who only want to attack systems.

Years ago, I was foolish enough to answer a “questionable technique”
question like this on a microsoft.public newsgroup. For years I was
haunted by finding references to it on Black Hat type sites.

So as far as I am concerned at best you are being incredibly naïve about
having someone answer this.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Jun Koi [mailto:xxxxx@gmail.com]
The point is the very same technique can be used for good thing, too.
For ex, all the malware scanners need to hook deeply inside the kernel
to
catch system activities. Even more than that, honeypot uses exactly
same
covert methods used by rootkits to evade detection.

That is why people asking these kind of questions are not necessarily
bad
guys, or going to do bad thing with the this kind of knowledge.

24

Don,

why are you so principal about the question? Poor guy just misunderstood
the documentation. SIDT returns not a physical address, but a linear
one. Instead of MmMapIoSpace MDL-related functions should be used.

IDT is well-protected. Yes, sidt instruction could be executed on
user-space, but IDT memory is protected from r3 access. And if you are
already in the driver on the kernel-space what security are you talking
about?

Best regards,
Anna

Don Burn пишет:

I have to disagree, most of the people who are doing the type of work
you point as beneficial know how to do these things, or have the smarts
to work through it themselves. Worse yet this is a public forum, so
even if the OP intentions are totally pure and good, you don’t know how
many lurkers are out there who only want to attack systems.

Years ago, I was foolish enough to answer a “questionable technique”
question like this on a microsoft.public newsgroup. For years I was
haunted by finding references to it on Black Hat type sites.

So as far as I am concerned at best you are being incredibly naïve about
having someone answer this.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

> -----Original Message-----
> From: Jun Koi [mailto:xxxxx@gmail.com]
> The point is the very same technique can be used for good thing, too.
> For ex, all the malware scanners need to hook deeply inside the kernel
to
> catch system activities. Even more than that, honeypot uses exactly
same
> covert methods used by rootkits to evade detection.
>
> That is why people asking these kind of questions are not necessarily
bad
> guys, or going to do bad thing with the this kind of knowledge.
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

25

> That is why people asking these kind of questions are not necessarily

bad guys, or going to do bad thing with the this kind of knowledge.

Correct, but don’t forget: Nothing written in a public forum is easily
forgotten. Lots of the stuff can be found using any search engine.
And we know the “bad guys” know how to use a search engine.

=> Driver developers *have* to be extra careful.

My advice is: learn about how the IDT is handled by an open-source
operating system (where you can look at the handling code).

Then you have enough background knowledge to either come back to Windows
and find that IDT readout is now irrelevant to you.
Or you have learned enough to find a way to do what you want - e.g. in a
virtual machine, with e.g. an older incarnation of the operating system.

26

I think you have missed the most essential thought from Jan’s post: it
is dangerous to fool around stuff like IDT which is directly
inaccessible thru documented API/DDI. And reading IDT is only one step
from modifying it. So no matter how harmless your intensions are most
people here won’t give you an answer for a good reason: OSR groups are
publicly available therefore knowledge from here can be used for
malicious purposes.

And come on, put some effort into this research, most of this stuff can
be figured out if not then maybe that’s one of the good reasons why you
shouldn’t really touch it at all.

Btw. since you only need to learn about how IDT looks then it’s not the
end of the world if you have only one system to play with (not to
mention about all flavours of free VMs). You just need to generate
kernel memory dump somehow - for starter livekd (from sysinternals) is
your friend.

Kris

-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Posted At: Wednesday, May 26, 2010 12:48 PM
Posted To: ntdev
Conversation: Windows - IDT table entries all 0’s
Subject: RE: Windows - IDT table entries all 0’s

Jan Bottorff: You wrote quite a bit of story. I understand your
professionalism. I am a software professional too but the only
difference is you are a drive professional and I am not. However, at the
same time, if somebody asks for a help I am always ready for it but you
seems to be totally opposite. Sorry!!! I am here not to start word’s war
because it won’t make any difference to you or me.

Too keep story short if you can advise what I am missing in my code;
well and good, if not that’s also well and good because I am going to
find out sooner or later.

27

Anna, there is just no point in getting the IDT from code, if he really
wants to do research only (he gets the benefit of the doubt) a debugger is
èxactly what he needs.

We could point out to him his structures are wrong and it returns a virtual
address and not a physical one etc. But then we did not HELP him, instead we
only sent him deeper into a dark forest without a light. Likewise we don’t
send people into the desert without any water. Soon another similar question
is going to popup without having an idea where he is going.

Personally I have no problem with people using whatever techniques to reach
their goals but only if there are no alternatives. He said his goal is
research so a debugger is what he needs.

I find the malware argument the weakest of all for not giving him
information. There are plenty of samples on the net which show even how to
do this on Windows. Then there are the intel and AMD manuals. The fact he
needs to ask around here does not make him look more dangerous.

What is important is, how can we really HELP him. I think the best help he
can get is pointing out that his attitude is wrong and he should hook up a
debugger to a virtual machine as he only has one system at his disposal.

//Daniel

“Anna V” wrote in message news:xxxxx@ntdev…
> Don,
>
> why are you so principal about the question? Poor guy just misunderstood
> the documentation. SIDT returns not a physical address, but a linear one.
> Instead of MmMapIoSpace MDL-related functions should be used.
>
> IDT is well-protected. Yes, sidt instruction could be executed on
> user-space, but IDT memory is protected from r3 access. And if you are
> already in the driver on the kernel-space what security are you talking
> about?
>
> Best regards,
> Anna
>
>
> Don Burn пишет:
>> I have to disagree, most of the people who are doing the type of work
>> you point as beneficial know how to do these things, or have the smarts
>> to work through it themselves. Worse yet this is a public forum, so
>> even if the OP intentions are totally pure and good, you don’t know how
>> many lurkers are out there who only want to attack systems.
>>
>> Years ago, I was foolish enough to answer a “questionable technique”
>> question like this on a microsoft.public newsgroup. For years I was
>> haunted by finding references to it on Black Hat type sites.
>>
>> So as far as I am concerned at best you are being incredibly naïve about
>> having someone answer this.
>>
>>
>> Don Burn (MVP, Windows DKD)
>> Windows Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Jun Koi [mailto:xxxxx@gmail.com]
>>> The point is the very same technique can be used for good thing, too.
>>> For ex, all the malware scanners need to hook deeply inside the kernel
>> to
>>> catch system activities. Even more than that, honeypot uses exactly
>> same
>>> covert methods used by rootkits to evade detection.
>>>
>>> That is why people asking these kind of questions are not necessarily
>> bad
>>> guys, or going to do bad thing with the this kind of knowledge.
>>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>

28

The problem is that you are not only wasting your time you also waste our
time by posting questions that can best be answered via WinDbg. Oh yeah …
I forgot … you don’t have WinDbg because you are just “playing around” and
“learning” so you come here to waste our time in “teaching” you something
you can learn for yourself, if you simply had a target/host and WinDbg.

The personal opinion of
Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, May 25, 2010 11:48 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Windows - IDT table entries all 0’s

“If your company can’t afford to get you a second system, perhaps they need
to rethink their need to develope kernel software. It’s the cost of doing
business in the kernel.”

This is not bussiness Gary, it’s my own learning experience and I am happy
to waste my time for now.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus signature
database 5147 (20100526) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 5147 (20100526) __________

The message was checked by ESET Smart Security.

http://www.eset.com

29

Bingo … a poor-mans target/host WinDbg setup.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Wednesday, May 26, 2010 5:04 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Windows - IDT table entries all 0’s

Personally I think there is nothing wrong with learning how interrupt
handling and the local APIC work on Windows. However this is a professional

forum, as driver writers don’t need to touch the IDT directly you will meet
some hostility when posting questions like this. There is little point in
doing this from code.

I suggest you install Windows inside a virtual machine (VmWare is great,
VirtualBox comes for free). Then attach WinDbg to that and use the !idt
command, that will dump the IDT for you. WinDbg may be hard to set up the
first time but the time invested on it will pay off soon.

//Daniel

wrote in message news:xxxxx@ntdev…
> I don’t have target / host system.
>
> I have only 1 HP laptop, thus, can’t use WinDbg. This is the reason for my

> driver I have to output debug contents to a file.
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Information from ESET Smart Security, version of virus signature
database 5147 (20100526)

The message was checked by ESET Smart Security.

http://www.eset.com

Information from ESET Smart Security, version of virus signature
database 5147 (20100526)

The message was checked by ESET Smart Security.

http://www.eset.com

30

xxxxx@yahoo.com wrote:

I don’t have target / host system.

I have only 1 HP laptop, thus, can’t use WinDbg.

That is simply false. Start up Windbg, press Ctrl-K, pick “Local”, then
enter !idt.

My question is why direct poking is not working. I have read through Intel documentation which clearly states that SIDT will return IDT base physical address. Am I missing something here?

Yes, you are. SIDT returns the VIRTUAL address of the IDT, not the
PHYSICAL address.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

31

Tim Roberts wrote:

> My question is why direct poking is not working. I have read through Intel documentation which clearly states that SIDT will return IDT base physical address. Am I missing something here?
>

Yes, you are. SIDT returns the VIRTUAL address of the IDT, not the
PHYSICAL address.

Expanding on this just a little bit, there is only one
publicly-available register in the entire x86 architecture that holds a
physical address, and that’s CR3, which has the base address of the page
table directory. EVERYTHING else uses linear addresses and passes
through the page tables for translation.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

32

Not quite Tim. You will then get a bitch box that provides info on what to
do to enable local debug on Vista and above and that it is not supported by
WOW64.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, May 26, 2010 11:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows - IDT table entries all 0’s

xxxxx@yahoo.com wrote:

I don’t have target / host system.

I have only 1 HP laptop, thus, can’t use WinDbg.

That is simply false. Start up Windbg, press Ctrl-K, pick “Local”, then
enter !idt.

My question is why direct poking is not working. I have read through Intel
documentation which clearly states that SIDT will return IDT base physical
address. Am I missing something here?

Yes, you are. SIDT returns the VIRTUAL address of the IDT, not the
PHYSICAL address.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus signature
database 5147 (20100526) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 5148 (20100526) __________

The message was checked by ESET Smart Security.

http://www.eset.com

33

>

I have created windows test driver which reads through to IDT entries
(only
top 5 so far) to display or output IDT entry contents. However, I am
getting
all 1’s or 0xFFFFFFFF in 8 bytes. I don’t know what I am missing.
Below is the
code. Can somebody please help

Check what the debugger says… maybe the first 5 entries are actually
0xFFFFFFFF. Also fill your IDT structure with non-0xFFFFFFFF data and
see if sidt changes it. And allocate enough memory for them. And use the
__sidt intrinsic - no need for asm, and then you can be sure of what you
are getting.

In my PV drivers for Xen I hook the IDT to capture DbgPrint output under
XP and 2003 (an API to do this didn’t get invented until Vista AFAIK).
My code is available at
http://xenbits.xensource.com/ext/win-pvdrivers.hg?file/213306951ec5/ and
specifically
http://xenbits.xensource.com/ext/win-pvdrivers.hg?file/213306951ec5/xenp
ci/xenpci_dbgprint.c is the file where the reading / hooking is done.

James

34

Tim, I am getting below error as per your stated steps. How do I get setup symbols. Help required

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KINTERRUPT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KINTERRUPT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPCR ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPCR ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KIDTENTRY ***
*** ***
*************************************************************************

Can’t read kernel symbols.

35

Anna,

Thanks for your reply. After bombarded with dis-hearting comments by so many posters here, I end up searching over the net, and came across article stating 3 different types of memory types

  1. Physical Address
  2. Linear Address
  3. Logical Address

And then it stuck suddenly that I am using the wrong one. I thought next morning I will try Linear to Physical address conversion and then map physical address back to virutal using MmMapIoSpace(…) to read IDT correctly.

And you confirmed it by posting the answer. Can you please advise if MmGetPhysicalAddress will give me correct IDT physical page entry address?

Thanks heaps n heaps

  
Don,  
  
why are you so principal about the question? Poor guy just misunderstood   
the documentation. SIDT returns not a physical address, but a linear   
one. Instead of MmMapIoSpace MDL-related functions should be used.  
  
IDT is well-protected. Yes, sidt instruction could be executed on   
user-space, but IDT memory is protected from r3 access. And if you are   
already in the driver on the kernel-space what security are you talking   
about?  
  
Best regards,  
Anna
36

> How do I get setup symbols. Help required

GIYF

37

You wrote:

Thanks for your reply. After bombarded with dis-hearting comments by so
many posters here, I end up searching over the net, and came across
article stating 3 different types of memory types

  1. Physical Address
  2. Linear Address
  3. Logical Address

And then it stuck suddenly that I am using the wrong one. I thought next
morning I will try Linear to Physical address conversion and then map
physical address back to virutal using MmMapIoSpace(…) to read IDT
correctly.

Good heavens, no! The address you get from SIDT is a linear address, exactly like every address in a flat-model program. In the Windows kernel, DS can access the entire 32-bit linear address space. DS:[0x81234500] is linear address 0x81234500. So, just load the SIDT address into a pointer and dereference it. No mapping, no conversion.

However, you REALLY need to get a more fundamental understanding of the x86 architecture before you proceed much further. You’re poking around in areas that has many sharp edges, and you are currently unprepared to face them.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

38

Hagen Patzke wrote:

GIYF

I had to look this up but at first I thought it stood for “Google it, you f…”

39

Uhhh … Hagen, is that the Germanic form of RTFM?

And mgup …

Have you looked at the manual? Open the help file, type in “symbol server”
in either the index or search, and read. You need to set a symbol server and
allow the symbols to be downloaded from that server. The symbols will be
downloaded to a path you define on your local system such as “C:\Symbols”.
Your symbol path for WinDbg will appear something like this:

“srv*C:\Symbols*http://msdl.microsoft.com/download/symbols”

In fact cut that line removing the quotes, enter Ctl+S in WinDbg, and then
Ctl+V. Voila! Symbols will be loaded and placed in C:\Symbols.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Thursday, May 27, 2010 2:22 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Windows - IDT table entries all 0’s

How do I get setup symbols. Help required

GIYF

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus signature
database 5150 (20100527) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 5150 (20100527) __________

The message was checked by ESET Smart Security.

http://www.eset.com

40

[GIYF]

Uhhh … Hagen, is that the Germanic form of RTFM?

No, that would likely be “LDVH” (we don’t have the exact equivalent).

GIYF = Google Is Your Friend.

I’ve seen it here first (the phrase, not the acronym):
http://catb.org/~esr/faqs/smart-questions.html

Here in this forum probably it should be BIYF (Bing Is Your Friend), as
to my knowledge “Bing” is the search engine behind MSDN search. :wink: