I am looking to get into operating system kernel development and figured and have been reading books on operating systems (Tannenbaum) as well as studying how BSD and Linux have tackled this challenge but still am stuck on several concepts.
If I wanted to mimic the Windows Blue Screen of Death on an operating system, would I simply put this logic in the panic kernel method?
Are there ways to improve upon how Windows currently performs this functionality?
I'm not exactly sure where to look in the source but you might want to look into ReactOS, an open source Windows clone which has BSOD already.
BSDs actually handled this much better then Windows with DDB :)
Here's another link to FreeBSD Kernel Debugging docs.
You can emulate Windows's bugcheck functionality wherever you want. Most Linux systems put it in XScreenSaver.
However, I doubt that this is what you're really asking about. Are you asking how to generate a dump file?
To improve Windows bugchecks, Windows driver developers can use KeRegisterBugCheckReasonCallback() to record more information about the state of their drivers in the generated minidump. This potentially may improve the effectiveness of post-mortem debugging when full kernel/memory dumps are not enabled.
Related
Is there a Windows standard way to do things such as "start fan", "decrease speed" or the like, from C/C++?
I have a suspicion it might be ACPI, but I am a frail mortal and cannot read that kind of documentation.
Edit: e.g. Windows 7 lets you select in your power plan options such as "passive cooling" (only when things get hot?) vs. "active cooling" (keep the CPU proactively cool?). It seems the OS does have a way to control the fan generically.
I am at the moment working on a project that, among other things, controls the computer fans. Basically, the fans are controlled by the superIO chip of your computer. We access the chip directly using port-mapped IO, and from there we can get to the logical fan device. Using port-mapped IO requires the code to run in kernel mode, but windows does not supply any drivers for generic port IO (with good reason, since it is a very powerful tool), so we wrote our own driver, and used that.
If you want to go down this route, you basically need knowledge in two areas: driver development and how to access and interpret superIO chip information. When we started the project, we didn't know anything in either of these areas, so it has been learning by browsing, reading and finally doing. To gain the knowledge, we have been especially helped by looking at these links:
The WDK, which is the Windows Driver Kit. You need this to compile any driver you write for windows, With it comes a whole lot of source code for example drivers, including a driver for general port-mapped IO, called portio.
WinIO has source code for a driver in C, a dll in C that programmatically installs and loads that driver, and some C# code for a GUI, that loads the dll and reads/writes to the ports. The driver is very similar to the one in portio.
lm-sensors is a linux project, that, among other things, detects your superIO chip. /prog/detect/sensors-detect is the perl program, that does the detecting, and we have spent some time going through the code to see how to interface with a superIO chip.
When we were going through the lm-sensors code, it was very nice to have tools like RapidDriver and RW-everything, since they allowed us to simulate a run of sensors-detect. The latter is the more powerful, and is very helpful in visualising the IO space, while the former provides easier access to some operations which map better to the ones in sensors-detect (read/write byte to port)
Finally, you need to find the datasheet of your superIO chip. From the examples, that I have seen, the environment controllers of each chip provide similar functionality (r/w fan speed, read temperature, read chip voltage), but vary in what registers you have to write to in order to get to this functionality. This place has had all the datasheets, we have needed so far.
If you want something real quick to just lower fans to a level where you know things won't overheat, there's the speedfan program to do so. Figuring out how to configure it in the early versions to automatically lower fans to 50% on computer startup was so painful that my first approach was to simply byte-patch it to start the only superio managed fan I had at lower speed. The newer versions are still bit tough but it's doable - there's a graphical slider system that looks like audio equalizer except that the x axis is temp and y is fan speed. You drag them down one by one. After you figure out how to get manual control for the fan you want, this is next step.
There's a project to monitor hardware (like fans) with C#:
http://code.google.com/p/open-hardware-monitor/
I haven't extensively looked at it, but the source code and use of WinRing0.sys atleast gives the impression that if you know what fan controller you have and have the datasheet, it should be modifiable to also set values instead of just getting them. I don't know what tool is suited (beside kernel debugger) to look at what Speedfan does, if you preferred to snoop around and imitate speedfan instead of looking at the datasheets and trying things out.
Yes, It would be ACPI, and to my knowledge windows doesn't give much/any control over that from user space. So you'd have to start mucking with drivers, which is nigh impossible on windows.
That said, google reveals there are a few open source windows libraries for this for specific hardware... so depending on your hardware you might be able to find something.
ACPI may or may not allow you to adjust the fan settings. Some BIOS implementations may not allow that control though -- they may force control depending on the BIOS/CMOS settings. One might be hard-pressed for a good use case where the BIOS control (even customized) is insufficient. I have come across situations where the BIOS control indeed was insufficient, but not for all possible motherboard platforms.
WIndows Management Instrumentation library (WMI) does provide a Win32_Fan Class and even a SetSpeed method. Alas, the docs say this is not implemented, so I guess it's not very helpful. But you may be able to control things by setting the power state.
I want to write a program that will monitor memory in a driver and print the memory contents every so often.
However, I'm not finding any resources in the Windows API that seem to allow me to grab a pointer (Handle) to a specific driver.
I'd appreciate any answer either from User space OR kernel space.
If you want to know exactly what I'm doing, I'm attempting to duplicate the results from this paper except on Windows. After I gain the ability to monitor a buffer in a basic windows console program, I intend to monitor from the GPU.
[For the record: I am a Graduate Student who is pursuing this as a summer project... this is ethical malware research.]
============UPDATE ==================
This might technically be better suited as an answer, but not really until I have a working solution.
My initial plan of attack is to use WinDbg to do dynamic analysis on the keyboard driver when it gets loaded, so I can get some idea about normal loading/unloading behavior. I'm using chapter 10 of this book, to guide setting up my testbed and once I understand more about the keyboard structure and its buffer, I'll work backwards towards getting a permanent reference to this structure and see about passing it into the graphics card and monitoring it with DMA as the original paper did on Linux.
You won't solve this problem by "grabbing a pointer to a specific driver". You need to locate the specific buffer used by the keyboard driver that resides on top of the USB driver.
You will have to actually grok the keyboard and USB drivers for Windows. At least part of which is probably available if you have a DDK (driver development kit) [aka WDK, Windows Driver Kit]. You will definitely need a graphics driver for this part of the project.
You will also have to develop a driver mechanism to map an arbitrary (kernel) lump of memory to your graphics driver - which means you need access to the source code for the graphics driver. (In theory, you could perhaps hack about in the page-tables, but Windows itself isn't too keen on software messing with the page-tables, and you'd definitely need to be VERY careful if the system is SMP, since modifying page-tables in an SMP system requires that you flush the TLB's of the "other" CPU(cores) in the system after updates).
To me, this seems like a rather interesting project, but a really tough one in a closed source system like Windows. At least in Linux, the developer has the source-code to read. When it comes to Windows, most of the relevant source code is completely unavailable (unless your school has special license to the MS Source code - I think there are some that do).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am attempting to create my own operating system and I am just wondering if there is a way to tell the BIOS to set a VGA pixel on my screen in C++.
C as a language does not provide any built-in graphics capabilities. If you want graphics, you have to use some OS-specific library.
Aside from that, modern operating systems generally don't allow any old program to poke around in memory however it wants to. Instead, they use intermediates called drivers and, yes, graphics libraries and APIs such as OpenGL.
If you really want to do it yourself get a copy of MS-DOS and dig up some old VGA specs and start from there.
You can turn on a given pixel, but this requires platform specific code and may not portable when the OS or platform changes.
My understanding is you want direct access to the screen buffer with nothing between stopping you. Here's the way to go.
Common Research
On your platform, find out the graphics controller, brand name and model name, if you are using one. Search the web for the data sheets on the graphics controller chip. Most likely, the screen memory is inside the chip and not directly accessible by the CPU.
Next, find out how to access the board that the Graphics Controller resides on. You may be able to access the Graphics Controller chip directly by I/O ports or memory addresses; or you may have to use an interrupt system. Research the hardware.
Linux
Download a source distribution for the Linux kernel. Find the graphic driver. Search the code in the graphic driver to see how the Graphics Controller is manipulated.
For Linux, you will have to write your own graphics driver and rebuild the kernel. Next you will need to write a program that accesses your driver and turns on the pixel. Research "Linux driver API". There are books available on writing Linux drivers and the standard API that they use.
Windows
Windows uses the same concept of drivers. You will have to write your own Windows driver and let the OS know you want to use it. Your driver will talk to the Graphics Controller. There are books available about writing Windows drivers. After writing the driver, you will need to write a demo program that uses your driver.
Embedded Systems
Embedded systems range from simple to complex as far as displays go. This simplest embedded system uses memory that the display views. Any writes to this memory are immediately reflected on the display.
The more complex embedded systems use Graphic Controllers to control the display. You would need to get the data sheets on the Graphic Controller, figure out how to set it up, then how to turn on a pixel.
Driver Writers
Drivers are not an easy thing to write. Most drivers are written by teams of experts and take months to produce. Graphic Controller chips are becoming more and more complex as new features are added. The driver must be able to support new features and the older models. Not an easie issue.
Summary
If you really want to access a pixel directly, go ahead. It may require more research and effort that using an Off The Shelf (OTS) library. Most people in the industry use OTS libraries or frameworks (such as QT, wxWidgets and XWindows). Drivers are only rewritten or modified for performance reasons or to support new graphics hardware. Driver writing is not a simple task and requires a quality development process as well as a verification strategy.
Good luck on writing your pixel. I hope your library has something better to offer than the many graphic libraries already in existence.
For fun i'd like to write code that runs on OSless hardware. I think writing code that will run in a VM (like VMware or virtualbox) would be good. However i don't want to start from scratch. I'd like the C++ runtime to be available. Something that allows me to read/write (maybe FAT32 filesystem code). Graphics for text and if i can graphics for drawing on screen (pixel by pixel. sdl support would be a bonus but not essential).
I'll write my own threads if i want them. I'll write everything else (that i want to use) needed for an OS. I just want a basic filesystem, gfx and keyboard/mouse support.
Take a look at the list of projects on osdev.org - (http://wiki.osdev.org/Projects) - most of these are hobbyist, open-source and range from just-a-bootsector through to proper threads/graphics/terminal support.
Minix3 targets your desires pretty well.
You should definitely take a look at OSKit (links to source code on this site are dead but there is a mirror here). Unfortunately, OSKit has no support for C++ but using this information you may be able to use GCC libraries.
I need to analyse some malware that I have on a vmware image (vmware is a virtual machine), in particular I need to do a full dump of a certain process. I know that vmware,on pausing, writes the whole RAM into a .vmem file. The platform the image is taken of is Windows XP. I know that there are certain tools that do this but they are mostly closed source or don't work for Windows XP. I need it to be done in reasonable time (under one second if that is possible somehow) and to run it from my own C++ program, any help would be really appreciated.
You seem to be asking to interact with processes and their memory from a suspended VM.
Give some forensic tools a shot. This one looks promising:
http://code.google.com/p/volatility/