problem with some video cards?
Jun Koi
the documentation says that we have some problem with several
accelerated video drivers, such as Nvidia cards, which prevent us from
writing to video memory.
but i dont understand why, and how these drivers cause the issue? what
are the technical reasons?
many thanks,
J
Jon Larimer
The reason is that there are differences in the way that graphics
modes operate when using an accelerated driver. In a regular,
unaccelerated VGA driver, the display framebuffer for the screen is
mapped to a linear section of physical memory, which then gets
re-mapped to virtual memory by the driver. In that case, it's simple
math to figure out what memory location to write to to place a pixel
on the screen.
The accelerated driver will put the card into a mode where the entire
display framebuffer memory isn't necessarily mapped to memory. The
driver will use commands exposed by the video hardware to render the
display, which frees up CPU time. For example: the driver will draw a
window to memory (as a texture) and then tell the video card the
location (X, Y) of the window on the screen, but the graphics card
itself will handle rendering it onto the display screen. This is how
you get the nice smooth show-window-contents-while-moving effect - the
CPU isn't constantly trying to update the framebuffer with the new
location of the window, the GPU handles it.
So anyway, this means that each graphics card supported by HyperDbg
would need it's own driver to work correctly in an accelerated mode.
HyperDbg would need to know how to allocate a texture, write to it,
then display it on the screen. The APIs on the graphics hardware to do
this are proprietary in most cases, so it's not easy to figure out.
SoftICE had a Universal Video Driver, but I'm not totally sure how it
worked. Since it required DirectX support, it probably made calls
directly to the DirectX driver for your card to manipulate the screen.
I don't know if something like that will be possible with HyperDbg or
not - SoftICE operated at Ring0, at the same level as every other
driver. VMX mode is a bit different. It might be a bit tricky to call
other drivers from the hypervisor.
Hope this helps,
-jon
Jun Koi
Jon, thanks a lot for a very clear explanation.
I believe the video output is the most important problem to be fixed.
I am wondering how software like Syser solves it.
Thanks,
J
Aristide Fattori
@Jon: thanks for your extensive explanation on the video card drivers
issue. I am planning, if you agree of course, to publish some of your
contributions on setting up the development environment and other
issues on the wiki, obviously by giving you appropriate credits, is it
ok for you?
@Jun: while I believe that the issue of having to compile HyperDbg
with a predefined screen resolution is a problem to be fixed asap, I
disagree with the "seriousness" of the video driver issue, after all
you just need to disable the super-advanced video driver in order to
get hdbg video GUI working. As a secondary, but not less important
point, the current version of the GUI would need only some minor
changes (in how the loader driver allocates memory for the gui before
switching to root mode) to be ported on a different operating system
(i.e., linux). On the contrary, a "syser-like" solution would mess up
with OS-dependent components and, while giving us a more beautiful
GUI, it would also ensure a complete lack of OS-independence. One of
the guidelines that we followed in developing HyperDbg was to keep the
code as much platform independent as possible, that is why we adopted
a "Rasta Ring 0 Debugger-like" GUI and not a "syser-like" one :-).
Of course, this is only my opinion and I am open to further discussion :-)
Cheers,
Aristide
--
GnuPG Key on keyserver.pgp.com ID 291D712D
http://security.dico.unimi.it/~joystick/
Jun Koi
<aristid...@gmail.com> wrote:
> Hi everybody,
>
> @Jon: thanks for your extensive explanation on the video card drivers
> issue. I am planning, if you agree of course, to publish some of your
> contributions on setting up the development environment and other
> issues on the wiki, obviously by giving you appropriate credits, is it
> ok for you?
>
> @Jun: while I believe that the issue of having to compile HyperDbg
> with a predefined screen resolution is a problem to be fixed asap, I
> disagree with the "seriousness" of the video driver issue, after all
> you just need to disable the super-advanced video driver in order to
> get hdbg video GUI working. As a secondary, but not less important
> point, the current version of the GUI would need only some minor
> changes (in how the loader driver allocates memory for the gui before
> switching to root mode) to be ported on a different operating system
> (i.e., linux). On the contrary, a "syser-like" solution would mess up
> with OS-dependent components and, while giving us a more beautiful
> GUI, it would also ensure a complete lack of OS-independence. One of
> the guidelines that we followed in developing HyperDbg was to keep the
> code as much platform independent as possible, that is why we adopted
> a "Rasta Ring 0 Debugger-like" GUI and not a "syser-like" one :-).
while you are at it, would you mind explaining how Syser works in this
aspect? I am curious ....
thanks,
J
Aristide Fattori
details on it. Syser offers two different solutions for the GUI:
User Mode: Use Ring3 DirectX API to lock screen frame buffer, send
frame buffer info to syser kernel debugger. this method is high
compatibility. But could't work under DirectX mode.
Kernel Mode: Hook video driver DirectX function , some video card
driver is strange, so could't work nice on all kinds of video card.
(source: http://www.sysersoft.com/help.html)
I tried both of them on a Windows box, the first worked pretty well,
the second one crashed unmercifully my machine every time I tried to
launch syser. As you can see from: "some video card driver is strange,
so could't work nice on all kinds of video card." they probably are
not free from our "driver-dependence" problem either.
Cheers,
A.
Jun Koi
>
> @Jon: thanks for your extensive explanation on the video card drivers
> issue. I am planning, if you agree of course, to publish some of your
> contributions on setting up the development environment and other
> issues on the wiki, obviously by giving you appropriate credits, is it
> ok for you?
>
> @Jun: while I believe that the issue of having to compile HyperDbg
> with a predefined screen resolution is a problem to be fixed asap, I
> disagree with the "seriousness" of the video driver issue, after all
> you just need to disable the super-advanced video driver in order to
> get hdbg video GUI working.
by "disable the video driver", you mean remove the driver, and ask OS
to use VGA compatibility driver??
is that always possible?
thanks,
J
Aristide Fattori
> by "disable the video driver", you mean remove the driver, and ask OS
> to use VGA compatibility driver??
Yep, just like when you install Windows from scratch, before
installing NVIDIA/ATI proprietary drivers, Windows uses standard VGA
drivers included in the OS. Of course you won't get your video card
best performances, but you can just reinstall the drivers when you
finish working on HyperDbg.
> is that always possible?
To the best of my knowledge, yes. By this I mean that it has been
possible on every machine on which I tested HyperDbg and/or the video
part on its own. Unfortunately, this is not a very wide range of
physical machines as we perform tests on real hardware on our or
friends' private desktop/laptop as our Lab does not have machines
with VT-x CPU extensions.
Cheers,
A.
> thanks,
Jun Koi
<aristid...@gmail.com> wrote:
> Hi,
>
>> by "disable the video driver", you mean remove the driver, and ask OS
>> to use VGA compatibility driver??
>
> Yep, just like when you install Windows from scratch, before
> installing NVIDIA/ATI proprietary drivers, Windows uses standard VGA
> drivers included in the OS. Of course you won't get your video card
> best performances, but you can just reinstall the drivers when you
> finish working on HyperDbg.
>
>> is that always possible?
>
> To the best of my knowledge, yes. By this I mean that it has been
> possible on every machine on which I tested HyperDbg and/or the video
> part on its own. Unfortunately, this is not a very wide range of
> physical machines as we perform tests on real hardware on our or
> friends' private desktop/laptop as our Lab does not have machines
> with VT-x CPU extensions.
>
so it seems that these accelerated cards always offer the frame buffer
as a second choice, when their native drivers are not available?
another problem is that in that case, how to locate the frame buffer
area? i experienced this issue, when a VGA driver is used: in that
case, Windows fails to find any information about the video device,
and also information on frame buffer: these information in the
"Resource" tab are not simply available.
thanks,
J
Aristide Fattori
On Sun, May 30, 2010 at 11:49 AM, Jun Koi <junko...@gmail.com> wrote:
> so it seems that these accelerated cards always offer the frame buffer
> as a second choice, when their native drivers are not available?
sorry, I don't get what you mean here. Please check out Jon's mail for
a detailed explanation of the framebuffer usage by modern video cards.
> another problem is that in that case, how to locate the frame buffer
> area? i experienced this issue, when a VGA driver is used: in that
> case, Windows fails to find any information about the video device,
> and also information on frame buffer: these information in the
> "Resource" tab are not simply available.
Mmh, I never experienced this problem, what kind of video card do you
have? Is HyperDbg able to automatically locate the framebuffer address
by scanning the PCI bus (if you comment the line "#define
VIDEO_ADDRESS_MANUAL)? If nor windows nor HyperDbg are able to locate
the framebuffer address you may be facing a problem that we didn't
consider, please give us more details about your hardware and we will
try to understand why it behaves like that.
Thanks,
A.
Jon Larimer
<aristid...@gmail.com> wrote:
> Hi everybody,
>
> @Jon: thanks for your extensive explanation on the video card drivers
> issue. I am planning, if you agree of course, to publish some of your
> contributions on setting up the development environment and other
> issues on the wiki, obviously by giving you appropriate credits, is it
> ok for you?
That would be great!
-jon
Jon Larimer
> so it seems that these accelerated cards always offer the frame buffer
> as a second choice, when their native drivers are not available?
Basically, yes... there's always a VGA compatibility mode in modern
graphics cards. That's how you can use an old OS with a new PC. The
graphics adapter still provides the regular VGA/VESA BIOS extensions.
Of course, the graphics performance is pretty horrible.
To get the best performance out of newer graphics cards, you need
custom drivers provided by the adapter manufacturer (or open source
drivers based on the open specs...)
-jon
Jun Koi
> On Sun, May 30, 2010 at 5:49 AM, Jun Koi <junko...@gmail.com> wrote:
>
>> so it seems that these accelerated cards always offer the frame buffer
>> as a second choice, when their native drivers are not available?
>
> Basically, yes... there's always a VGA compatibility mode in modern
> graphics cards. That's how you can use an old OS with a new PC. The
> graphics adapter still provides the regular VGA/VESA BIOS extensions.
> Of course, the graphics performance is pretty horrible.
i dont see any problem with graphic performance in our case, as that
is not what we care about. long as we can make sure that hyperdbg
works with all video cards, that will be nice.
Jon: if i understand correctly, in case video cards are in accelerated
mode, there is no more guarantee about the frame buffer? because if
that is the case, switching back to VGA compatibility mode (by
disabling native driver) is the only solution to have frame buffer,
and that is really a problem, because not everybody wants to do that
(because they still desire high performance graphics, for ex).
thanks,
J
Jon Larimer
>
> Jon: if i understand correctly, in case video cards are in accelerated
> mode, there is no more guarantee about the frame buffer? because if
> that is the case, switching back to VGA compatibility mode (by
> disabling native driver) is the only solution to have frame buffer,
> and that is really a problem, because not everybody wants to do that
> (because they still desire high performance graphics, for ex).
>
That's right. Each graphics adapter is different, so HyperDbg would
need a different driver to control each one (just like Windows or X).
That's why it only works with Windows using VGA mode which is standard
across all PC platforms.
It is technically possible to write a lot of code to make HyperDbg's
graphics work more like Syser or SoftICE and interface with the video
drivers for the OS (instead of writing new drivers for each card), but
like Aristide said, the goal is for the HyperDbg code to be as
OS-independent as possible. Maybe once the codebase is more mature and
feature-rich across platforms, someone will be willing to spend time
on the graphics issue.
-jon
Lorenzo Martignoni
Would it be possible, in your opinion, to query the status of the
graphic driver before loading hyperdbg, replace the accelerated river
with one with a traditional framebuffer interface (using the same
resolutions), and restore the original driver when hyperdbg is
unloaded?
Lorenzo
Jon Larimer
> Would it be possible, in your opinion, to query the status of the
> graphic driver before loading hyperdbg, replace the accelerated river
> with one with a traditional framebuffer interface (using the same
> resolutions), and restore the original driver when hyperdbg is
> unloaded?
>
Maybe... it might depend on the driver. In Windows 7 on my desktop
(NVIDIA adapter), I can right-click my adapter in 'Display Adapters'
in the Device Manager, disable the device, and Windows will revert to
the VGA driver (VgaSave) without rebooting. On my laptop with Windows
XP (Intel driver), doing the same thing requires a reboot.
I don't know if that's an OS issue or a driver issue. If you can
unload the accelerated driver in XP without rebooting, it'll be
possible to do what you want.
-jon
Roberto Paleari
However, I don't remeber if the driver replaces the video driver used by
Windows, or if the debugger switches to its own driver "on-the-fly", when
activated by the user.
I'm quite sure that, when switching into SoftICE, there was a "flickering" of
the video. Maybe it was a sympthom of the driver switching, or maybe the
debugger was just changing the video mode.
Roberto
Jon Larimer
<rob...@security.dico.unimi.it> wrote:
> If I remember well, SoftICE relies on a custom VGA driver.
>
> However, I don't remeber if the driver replaces the video driver used by
> Windows, or if the debugger switches to its own driver "on-the-fly", when
> activated by the user.
>
> I'm quite sure that, when switching into SoftICE, there was a "flickering" of
> the video. Maybe it was a sympthom of the driver switching, or maybe the
> debugger was just changing the video mode.
>
The flickering was due to a mode switch - when using a regular driver
(not the Universial Video Driver), it switched into text mode. That
does simplify the debugger UI code a bit, but you still need to know
how to switch the graphics card between text and graphics mode.
Figuring that out for every graphics adapter wouldn't be any easier
than figuring out how to render a window on the screen when in an
accelerated mode.
-jon
Jun Koi
note that in this approach, you have to save context and status of the
original driver before you replace it with the VGA driver, then
restore them when you load it back, so everything still functions
normally, as if nothing happens. that doesnt guarantee out of the box
with all the drivers and video devices, i guess.
thanks,
J