Hi,
Just looking at this again. Your advice to base a driver on the event
example was a big help. It did give me an easy way to have a little look
at some of the kernel tables. Miserable results though.
Firstly sldt shows me that the LDTR is zero.
I then tried building for both x86 and x64, and using the x86 test
program with the x64 driver, to see if calling from 32bit
compatibility mode might make a difference, but nope, still LDTR
is zero.
Then considered creating my own LDT, but the LDT must be referenced by
an entry in the GDT, and I can’t add a reference because of patchguard.
Then scanned the GDT on the off chance that there might be an LDT entry
already there unused (grabbing at straws). Of course there wasn’t.
Here’s the GDT:
GDT size in DWORDs: 28
0x0000000000000000
0x0000000000000000
0x00209b0000000000
0x00cf93000000ffff
0x00cffb000000ffff
0x00cff3000000ffff
0x0020fb0000000000
0x0000000000000000
0x02008bccf0700067
0x00000000fffff800
0x7e40f3fdd0003c00
0x0000000000000000
0x00cf9a000000ffff
0x0000000000000000
Not what I was expecting. There are four 32-bit descriptors in there,
and only one system entry, for a TSS. I was expecting more. Maybe I’m
reading it wrongly.
I’m now trying to think of ways around this. Patchguard is my main
enemy. Two ideas come to mind.
-
I’m sure no one here will be willing to even contemplate this,
but I wonder if I could emulate a debugger connecting and turn
off patchguard that way? For what I’m doing, it doesn’t matter
if the user sees warnings about the change in operating mode.
I’d want it to be up front if I was going to do anything like
that. I wish patchguard wasn’t forcing me to think of
such extremes.
-
Can I use IVT to just temporarily replace the whole GDT with
a copy that has the extra entry for an LDT, host and child
sharing almost everything? I’m thinking that IVT might provide
a methods to ensure that any call back into the kernel exits
back to host mode, so that patchguard never sees any changes.
Just my one app that needs LDT support would be called in
child mode. The whole idea is woolly at the moment.
Any thoughts?
Cheers,
Paul.
> Firstly sldt shows me that the LDTR is zero.
LDT is not used by Windows - neither 32-bit nor 64-bit version uses it…
Concerning working around patchguard… well, it may be possible, but I am sure no one here
is going to help you with that…
Anton Bassov
xxxxx@hotmail.com wrote:
> Firstly sldt shows me that the LDTR is zero.
LDT is not used by Windows - neither 32-bit nor 64-bit version uses it…
Yes it is. It’s essential to ntvdm and wow.
Concerning working around patchguard… well, it may be possible,
This is for a legitimate project. I’m trying to provide an alternative
to ntvdm, now that there is no DOS support on 64bit OSes
but I am sure no one here is going to help you with that…
Well, someone might. At least one of the gurus here pointed
out that patchguard is more of a barrier to legitimate projects
than to malware, because malware writers already have ways
around patchguard and are willing to use any dirty trick.
I thought it was you, but I obviously misremembered that.
All I want is the equivalent of NtSetLdtEntries, but working
for 32bit apps running in compatibility mode on a 64bit OS.
>This is for a legitimate project. I’m trying to provide an alternative
to ntvdm, now that there is no DOS support on 64bit OSes
There is already an alternative, run MS-DOS or XP or your MS-DOS environment
of choice in a virtual machine. Both Virtual PC and Virtual Server are FREE.
Or use VMWare, which also has free versions, or use one of the open source
VM’s.
Jan
Jan Bottorff wrote:
There is already an alternative, run MS-DOS or XP or your MS-DOS environment
of choice in a virtual machine. Both Virtual PC and Virtual Server are FREE.
Or use VMWare, which also has free versions, or use one of the open source
VM’s.
I’m looking to provide something a little simpler for people to set up
and a little better integrated than those options. Well I have done,
I just have this annoying barrier to running on 64bit verisons of
Windows.
>> but I am sure no one here is going to help you with that…
Well, someone might. At least one of the gurus here pointed
out that patchguard is more of a barrier to legitimate projects
than to malware, because malware writers already have ways
around patchguard and are willing to use any dirty trick
I thought it was you, but I obviously misremembered that.
Well, actually, I am very far from being a guru…
Indeed, I said many, many times that PatchGuard may do more harm that good, for the reasons you have mentioned above. However, disabling it leads you nowhere. Apparently, once it is used by the PatchGuard, connecting a debugger on 64-bit OS is more complex than just changing the state of KdDebuggerNotPresent exported symbol and friends - apparently, the system modifies quite a few internal memory locations when you connect a debugger, and does so on purpose, just to make sure that PatchGuard cannot be fooled that easily.
Certainly, you can disassemble the OS, find out what actually happens, and make things look as if debugger is around. However, don’t forget that, in order for PatchGuard to be meaningfull, MSFT has to change the protection scheme all the time. Therefore, you will spend a lot of time and effort in order to disable it… only to find out that some monir security patch rendered all your efforts useless, because MSFT had changed the protection scheme. In other words, you are entering a competition that you just cannot win…
Anton Bassov
If this may be a hint : I am able to run an ERD98 bootdisk within QEMU on Vista 64 bit !
Christiaan
----- Original Message -----
From: “Paul Gardiner”
To: “Windows System Software Devs Interest List”
Sent: Friday, August 10, 2007 11:42 PM
Subject: Re: [ntdev] 64bit Windows LDT access blues
> Jan Bottorff wrote:
>> There is already an alternative, run MS-DOS or XP or your MS-DOS environment
>> of choice in a virtual machine. Both Virtual PC and Virtual Server are FREE.
>> Or use VMWare, which also has free versions, or use one of the open source
>> VM’s.
>
> I’m looking to provide something a little simpler for people to set up
> and a little better integrated than those options. Well I have done,
> I just have this annoying barrier to running on 64bit verisons of
> Windows.
>
>
> —
> 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
Christiaan Ghijselinck wrote:
If this may be a hint : I am able to run an ERD98 bootdisk within QEMU
on Vista 64 bit ! Christiaan
Yeah, maybe I should consider that mechanism… or just give up.
The annoying thing is that what VDos32 is doing is far far
simpler than QEMU. It just loads 32bit DOS code into memory
and executes it, catching interrupts and IO etc with simple
SEH exception handling. I’d really like to continue down the
simple path I’ve started from, but it requires access to the LDT.
It all works fine under 32bit Windows where NtSetLdtEntries is
supported.
On Sat, Aug 11, 2007 at 08:28:54AM +0100, Paul Gardiner wrote:
Yeah, maybe I should consider that mechanism… or just give up.
The annoying thing is that what VDos32 is doing is far far
simpler than QEMU. It just loads 32bit DOS code into memory
and executes it, catching interrupts and IO etc with simple
SEH exception handling. I’d really like to continue down the
simple path I’ve started from, but it requires access to the LDT.
It all works fine under 32bit Windows where NtSetLdtEntries is
supported.
Jumping in a little late here, but would it be possible for you to
emulate the behavior of the LDT by making use of invalid segment
selectors (such as the null selector)? In this way, memory accesses
will result in an exception that you can then emulate the appropriate
address translation for. There would definitely be processing overhead
– handling an exception for each memory access through an invalid
segment selector would be quite noticeable.
I’m not familiar with the scope in which you were planning on using the
LDT, so this may not be feasible.
Matt
xxxxx@hotmail.com wrote:
Indeed, I said many, many times that PatchGuard may do more harm
> that good, for the reasons you have mentioned above. However,
disabling it leads you nowhere.
Yep, I’ve given up on that approach completely. I’ve had other
advice about how emulating a debug connection might be done.
I never really wanted to use security subverting
techniques like that. I just considered it on the off chance
that it might be simple - daft thought really.
The other mechanism I mentioned, using IVT or AMD’s equivalent
virtualisation wouldn’t be disabling patchguard. I just
wondered if I could create a very simple hypervisor (if
that’s the right word) that would give just the one
task running VDos32 the same Windows environment as
all other apps but with a slightly altered GDT. IVT
looks hopeful because it should provide a way to
ensure that everything is restored to normal whenever
the machine enters the kernel, so there would be
nothing for Patchguard to complain about. I was hoping
there might be a trick, avoiding going for a full VM
solution by having host and guest almost being identical.
You wrote :
Yeah, maybe I should consider that mechanism… or just give up.
The annoying thing is that what VDos32 is doing is far far
simpler than QEMU. It just loads 32bit DOS code into memory …
The primary goal of my contribution was to point to the fact that QEMU is
open source. Digging into it could propably reveal how they create the DOS
environment. So far , I did not find the rebuild environment for windows of
QEMU , but it may be there somewhere.
Christiaan
----- Original Message -----
From: “Paul Gardiner”
To: “Windows System Software Devs Interest List”
Sent: Saturday, August 11, 2007 9:28 AM
Subject: Re: [ntdev] 64bit Windows LDT access blues
> Christiaan Ghijselinck wrote:
>>
>> If this may be a hint : I am able to run an ERD98 bootdisk within QEMU
>> on Vista 64 bit ! Christiaan
>
> Yeah, maybe I should consider that mechanism… or just give up.
>
> The annoying thing is that what VDos32 is doing is far far
> simpler than QEMU. It just loads 32bit DOS code into memory
> and executes it, catching interrupts and IO etc with simple
> SEH exception handling. I’d really like to continue down the
> simple path I’ve started from, but it requires access to the LDT.
> It all works fine under 32bit Windows where NtSetLdtEntries is
> supported.
>
> —
> 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
Christiaan Ghijselinck wrote:
You wrote :
> Yeah, maybe I should consider that mechanism… or just give up.
>
> The annoying thing is that what VDos32 is doing is far far
> simpler than QEMU. It just loads 32bit DOS code into memory …
The primary goal of my contribution was to point to the fact that QEMU
is open source. Digging into it could propably reveal how they create
the DOS
environment. So far , I did not find the rebuild environment for windows of
QEMU , but it may be there somewhere.
Christiaan
Oh right, thanks. I think I took the wrong hint. 
I got the impression that QEMU avoided the LDT issue by
using dynamic translation, but I’ll take a closer
look.
Cheers,
Paul.
Matt Miller wrote:
Jumping in a little late here, but would it be possible for you to
emulate the behavior of the LDT by making use of invalid segment
selectors (such as the null selector)? In this way, memory accesses
will result in an exception that you can then emulate the appropriate
address translation for. There would definitely be processing overhead
– handling an exception for each memory access through an invalid
segment selector would be quite noticeable.
Interesting idea, especially as most of a 32bit DOS program
is set up for the flat address model. Typically though
there can be quite a number of infrequently used descriptors
with non-zero bases. Although, performance wise, I could
probably get away with handling access to those in the way
you suggest, I think 0 is the only invalid selector that
can be loaded into a segment register, so I’d have to
trap any instruction that altered segment registers to
keep track of what’s supposed to be in them at any time.
Also I see some bits of run-time loaded code that runs
in 16bit protected mode. Those would be a problem too,
I think.
Cheers,
Paul.