Does anyone know ways of partially or fully automating driver test installation?
I am new to driver development and am used to more of a test-driven approach in higher level languages, so moving to the kind of environment where I can't easily test as I go has been a step up for me. I am using Virtual PC for my test environment and currently have to reset it, open device manager, choose the device, click through a bunch of "Are you really sure you wouldn't rather install one of these system drivers" type dialogs, then finally reset the test environment while restarting WinDbg in the host machine just as the test environment is booting up... argh.
After repeating this process many, many times already, surely there has to be a be a better way of doing this? What tools/methods/tricks do commercial driver developers use to run up their driver in a test environment?
Note, this isn't about unit testing drivers, I haven't got to that stage yet or know if it is even possible. This is just about firing up a test environment with WinDbg attached to make sure that some small change I may have done is doing what I expect.
It seems to me that a virtualization software + a "mock objects" (layering) approach (as suggested by Aaron Digulla) + scripts (as suggested by Sergius) can simplify device driver development.
But if you use Visual Studio to develop user-level applications, you can use it for kernel device driver development too with VisualDDK (+ VirtualKD to debug over a named pipe, which is faster than over a virtual COM port), which addresses specifically the annoyances that you mention; from its home page:
... This project brings the simplicity and
convenience of Windows application
development to the driver development
world. No more manual creation of
build scripts, copying of driver
files, installing drivers from INFs,
switching between WinDbg and the
source editor or waiting for seconds
after each step due to the extra-slow
virtual COM port. Just create a driver
project using a convenient Driver
Wizard, select a virtual machine, and
enjoy debugging your driver directly
from Visual Studio. Want to test a
change? Just normally press Shift-F5,
modify your driver, rebuild it and
launch again. VisualDDK will unload
the old driver, install the new one
and load it automatically and quickly.
Bored with WinDbg loading symbol files
for minutes and looking up symbols for
seconds? Just let VisualDDK optimize
this for you using its own DIA-based
symbol engine. Using C++/STLPort in
your drivers? VisualDDK will natively
visualize all STL containers and
strings, as good as Visual Studio does
for user-mode applications. ...
You can write some shell scripts (using sc.exe and devcon.exe) to automate deployment tasks (no opening device manager, clicking on buttons, etc). And make snapshot of the system ready to debug (needn't wait for system boot).
Don't forget to check your driver with DriverVerifier!
Example of my own script :)
sc create FsFilter type= filesys binPath= c:\FSFilterDrv.sys
sc start FsFilter
pause
sc stop FsFilter
sc delete FsFilter
Follow the advice I gave here. Basically, test as little as possible with the real system.
In your case, I've got another tip: Virtual PC is using a virtual hard disk (that's probably a file on your real hard disk).
You don't need to install your driver, you can simply replace the new files in the virtual hard disk. This is often not possible in the running system but in a virtual system, you can open the virtual disk file and change it (since Windows isn't locking the files in it).
I'm not sure about Virtual PC but other emulators come with tools to work with virtual disk images. If VPC can't do it, check out VirtualBox.
It all depends a little on what kind of driver you are writing. But in many cases, writing an appropriate makefile (or something similar) that handles driver installation, start/stop, and launching of a test harness can already be good enough.
I also configure all of my test machines to automatically logon (AutoAdminLogon), map net drives, and launch an appropriate command prompt after startup. Running a specific test is then a matter of typing in a single command only.
One word concerning VirtualPC: VirtualPC is very handy for kernel mode development, but do not forget that it emulates a uniprocessor machine only -- so be sure to regularly test the code on a multiprocessor machine as well. That said, the VHD trick may seem handy, but it somewhat ties you to Virtual PC -- writing appropriate scripts that equally work on VirtualPC as on a real machine therefore seems a better approach to me.
Finally, consider it a shameless plug, but if you are looking for a unit testing framework for Windows kernel mode code, I have written one: cfix.
I think the DevCon utility (described in this OSR Online article) will help you. You should be able to setup batch files that do the job on one click.
It's free to sign up with osronline.com, and you'll probably have to sign up to get to that article. And if you are writing drivers, you WANT to sign up. These guys have been doing this for a long time, and there's a LOT of really good info on that web site.
Related
I have a malicious .scr file which i heard steals your gaming account items. Is there a way to debug this .scr file in safe environment without executing it. I opened it in IDA PRO but did not find it much useful.
Any pointers regarding the debugging process will be highly appreciable.
Analysis of malware is risky. If you are committed you at least need a Linux host with Windows guest on a sacrificial computer that doesn't have a wireless card and is unplugged from internet. Malware often has a mechanism to detect the jail. Common VMs use standard drivers and checking if running in jail is easy. If in jail then do nothing is a one line of code. To make matters worse, decent malware often has a mechanism to jailbreak from a VM and infect host Windows. Don't even mention Sandboxie. Last, but not least - some malware starts revenging if you try to decompile it. So, instead of just a stolen game password you might have a big mess.
So, if you have a sacrificial computer and free time, then go ahead. But do it carefully.
First: DEBUG a program means that you execute it, so if you know that the program is a malware you should do it in a safe enviroment like a virtual machine.
Malware usually use to protect themselves from debuggers, so this kind of job needs so many skills.
A kind of analysis that you can do is to execute the malware in a virtual machine and take a snapshot of the machine, then analyze the dump with Volatily and see what connections have been made by the system, the state of process etc..
I tried to learn "Lena's reversing for newbies", when some trouble arise.
I start Pixtopian Book with ollyDbg, then try to have MessageBox with message about uregistered version.
Then i switch to OllyDbg, stop program executing and press "Alt+F9" for "Back to user mode" which stop the program after it exit from DLL.
But after this program does not work, it's frozen and does not respond to my actions.
If i turn off "Back to user mode" program normally work.
What's the problem? Can i try to use "Back to user mode" in IDA (uses WinDbg) or some other debugger and How i can do this? Can i repair it function in OllyDbg?
P.S. It's like the program stopped and didn't run after use "ALT+F9".
/Sorry for my English, i'm just learning ;-)/
First of all, Ollydbg is meant for 32 bit platform. It means that it will run only on a 32 bit OS and can only debug 32 bit apps.
In x64 Operating Systems (specifically Windows) there is a feature called compatibility mode that lets you run 32 bit apps. The 32 bit code is either run by emulation or natively (when the hardware itself implements the instruction set and then it is called x86-64).
So, when you try to run Ollydbg in a x64 environment it will run, but you will experience problems like the one you are facing. It occurs because Ollydbg is run in an emulation mode. Being a debugger it needs access to the registers and other system structures, which it is denied. What it can see is a virtual image of the system.
So the solution to the problem is using a Virtual Machine.
You would install a 32 bit OS in it and debug the app using Ollydbg. As far as Virtual Machines are concerned, I would recommend VMWare. You can use either the workstation or player version. The latter is free but does not support snapshots.
Other solutions are Virtual Box, Parallels Workstation and Microsoft Virtual PC.
The disadvantages of them are that Virtual Box does not support hardware breakpoints, Parallels Workstation is no longer supported as of 2014 and moreover there you would get a BSOD if you try to single step through FPU instructions. I have not tested Virtual PC though.
Note : Ollydbg does not supports x64 but its author is working on a x64 version.
I just learned how to update changes to the exe file for ollydby v 2.01e.
suppose I wished to change a jl command to a jmp; do this by clicking the executable modules button, choose the file and right click to view the file. then record the changes and save file. The saved file also has a backup in case something goes wrong.
I just did a thorough learning of the pixtopian file. When I downloaded
that tutorial I get the file pixtopian107.exe only. Since it didn't agree with the tutorial I investigated further. That file is an installation file. It produces a regular pixtopian.exe file which is the file you wish to play with.
I also noticed that in running the file it never enters the main module.
this is because of the TLS callback. right now I am trying to learn how
to overcome this which is how i came to this site in the first place.
I am using ollydbg vs2.01e very effectively.
Another thing, in vs 2.01e I am still trying to save changed data. Until I succeed I am recording the changes in the exe files using hex editor.
From my experience I can tell that this functionality won't work on Windows 7.
On Windows 7 64bit --> Won't work at all.
On Windows 7 32bit --> Will work partially, but only when using option "File>Attach" in OllyDbg.
For me, best solution was to use Windows XP 32bit, then it worked fine.
So I have used Cygwin on and off for the past few years and I've installed it a handful of times. However, I've never experienced the install hanging during the install process. When this happens, the install literally freezes and doesn't budge a "bit." I've read that this is a somewhat common problem but like I said, I've never come across it before.
Here's a play-by-play of what I'm doing and where it hangs on me.
Download the Setup-x86.exe from http://cygwin.com/install.html
Install from Internet
Use "C:\cygwin" as the default root directory for all users.
Use "C:\Users\Austin\Downloads" as the default local package directory
Direct Installation
Use http://mirrors.kernel.org per this question.
I don't specify any additional items for the install (I thought it would best to keep it as simple as possible after running into this problem multiple times.)
I don't change any of the "Resolving Dependencies" (whatever those are)
...and everything goes great until a certain package get's tripped up and causes the install to hang. This is almost always a different package at a different point in the install. In this instance, it was texinfo-5.2-1.tar.xz and the install was at 94%! So close!!!
So what I'm looking for is how do I help the installer continue from this point? What do I need to do to go in cygwin and give it the extra motivation it needs to finish the job.
Work around to the problem above:
So after fiddling with the install a little more, I discovered that if you close the frozen install, and re-execute the setup file, it forces the install past the point where it got snagged the previous time. For example, after canceling the snagged install at 94% (mentioned above), I ran the setup file again and got to 95% before the install snagged again. I repeated this setup about 5 times before successfully installing cygwin.
Like I said, this is just a work around and may be the best/only solution.
I had the exact same problem on my Win7 64 bits with the 64 bits installer. I successfully solved the problem by deleting the content of
c:\[cygwin_install_dir]\var\log
Which contained two files:
setup.log
setup.log.full
Restarted the installer and everything went well!
Hope this will help.
https://cygwin.com/faq.html#faq.setup.hang
I turned off my anti-virus software and the install proceeded through with no problems.
I want to share my solution which worked. BTW, I tried all the solutions listed here and could not solve.
Open Task Manager
Kill any dash.exe or bash.exe
Run Cygwin installation.
Make sure to use default install path. Somehow changing
it did not work for me.
Get to the first stuck point
When it is stuck at *.dash, kill dash.exe
When it is stuck otherwise, kill bash.exe
Then it will lead to successful setup.
I fixed the same type of problem installing CYGWIN on Windows 8 by turning off my firewall. The hang up disappeared and I had no problem after that.
Something that also worked for me, suggested from the cygwin mailing list, was doing a full rebase as follows:
Run /usr/bin/rebase-trigger full on the cygwin terminal
Reboot and terminate any cygwin-related processes and services
Run the the setup again
Look out for BLODA (Big List Of Dodgy Apps.) and uninstall
BLODA - A list of applications that interfere with the normal working of Cygwin by intrusively injecting themselves in the system call chain
https://cygwin.com/faq/faq.html#faq.using.bloda
What applications have been found to interfere with Cygwin? >>>
From time to time, people have reported strange failures and problems in Cygwin and Cygwin packages that seem to have no rational explanation. Among the most common symptoms they report are fork failures, memory leaks, and file access denied problems. These problems, when they have been traced, often appear to be caused by interference from other software installed on the same PC. Security software, in particular, such as anti-virus, anti-spyware, and firewall applications, often implements its functions by installing hooks into various parts of the system, including both the Explorer shell and the underlying kernel. Sometimes these hooks are not implemented in an entirely transparent fashion, and cause changes in the behaviour which affect the operation of other programs, such as Cygwin.
Among the software that has been found to cause difficulties are:
AR Soft RAM Disk
ATI Catalyst (some versions)
AVAST (disable FILESYSTEM and BEHAVIOR realtime shields)
Avira AntiVir
BitDefender
Bufferzone from Trustware
ByteMobile laptop optimization client
COMODO Firewall Pro
Citrix Metaframe Presentation Server/XenApp (see Citrix Support page)
Credant Guardian Shield
Earthlink Total-Access
Forefront TMG
Google Desktop
Iolo System Mechanic/AntiVirus/Firewall
Kerio, Agnitum or ZoneAlarm Personal Firewall
LanDesk
Lavasoft Web Companion
Lenovo IPS Core Service (ipssvc)
Lenovo RapidBoot Shield
Logitech webcam software with "Logitech process monitor" service
MacType
NOD32 Antivirus
NVIDIA GeForce (some versions)
Norton/McAfee/Symantec antivirus or antispyware
PC Tools Spyware Doctor
Panda Internet Security
Sonic Solutions burning software containing DLA component (when DLA disabled)
Sophos Anti-Virus 7
Spybot S&D TeaTimer
Various programs by Wave Systems Corp using wxvault.dll, including Embassy Trust Suite and Embassy Security Center
Webroot Spy Sweeper with Antivirus
Windows Defender
Windows LiveOneCare
IBM Security Trusteer Rapport (see its home page
Sometimes these problems can be worked around, by temporarily or partially disabling the offending software. For instance, it may be possible to disable on-access scanning in your antivirus, or configure it to ignore files under the Cygwin installation root. Often, unfortunately, this is not possible; even disabling the software may not work, since many applications that hook the operating system leave their hooks installed when disabled, and simply set them into what is intended to be a completely transparent pass-through mode. Sometimes this pass-through is not as transparent as all that, and the hooks still interfere with Cygwin; in these cases, it may be necessary to uninstall the software altogether to restore normal operation.
Some of the symptoms you may experience are:
Random fork() failures
Caused by hook DLLs that load themselves into every process in the system. POSIX fork() semantics require that the memory map of the child process must be an exact duplicate of the parent process' layout. If one of these DLLs loads itself at a different base address in the child's memory space as compared to the address it was loaded at in the parent, it can end up taking the space that belonged to a different DLL in the parent. When Cygwin can't load the original DLL at that same address in the child, the fork() call has to fail.
File access problems
Some programs (e.g., virus scanners with on-access scanning) scan or otherwise operate on every file accessed by all the other software running on your computer. In some cases they may retain an open handle on the file even after the software that is really using the file has closed it. This has been known to cause operations such as deletes, renames and moves to fail with access denied errors. In extreme cases it has been known for scanners to leak file handles, leading to kernel memory starvation.
Networking issues
Firewall software sometimes gets a bit funny about Cygwin. It's not currently understood why; Cygwin only uses the standard Winsock2 API, but perhaps in some less-commonly used fashion that doesn't get as well tested by the publishers of firewalls. Symptoms include mysterious failures to connect, or corruption of network data being sent or received.
Memory and/or handle leaks
Some applications that hook into the Windows operating system exhibit bugs when interacting with Cygwin that cause them to leak allocated memory or other system resources. Symptoms include complaints about out-of-memory errors and even virtual memory exhaustion dialog boxes from the O/S; it is often possible to see the excess memory allocation using a tool such as Task Manager or Sysinternals' Process Explorer, although interpreting the statistics they present is not always straightforward owing to complications such as virtual memory paging and file caching.
I was able to get this to work - mine was just stuck on 0/Perpetual with no progress bar. It was Windows defender, I added my cygwin folder (C:\cygwin64) into the exceptions for windows defender and progress started immediately.
I understand how powerful windbg can be at debugging, but when is an appropriate or best time to use it to debug an issue? Is it more issue specific, or just experience, intuition, and knowing that using it can just get the job done best?
It's a little bit of all those things, and a lot of personal perference. Many WinDbg people only use WinDbg so that's what they are best at debugging with.
WinDbg also has some good extensions out there like SOS. So a particular extension might provide you with the specific piece of information that another debugger does not.
One reason to use a different debugger in certain circumstances is if you believe the debugger is incorrect. This is rare of course. For things like stack walking for instance, the debuggers use different methods, so you can confirm the stack is what you expect by using the other.
So sum up, for most issues it doesn't matter. It's whatever you are best at using. For some particular issues it's what you say, knowing which tool is the best for that particular issue.
While Windbg is also a fine tool for user-mode debugging, if you end up doing kernel-mode debugging it is really the only serious choice.
The kernel-mode debugging scenario often involves two machines, a debugger and a debuggee. You will be running Windbg on a debugger machine which is connected to the debuggee over a serial connection, Firewire or USB. In this scenario you can "freeze" the target machine and have full control over everything running on it. Often your debuggee (the target) will be a virtual machine running under VMWare or similar -- in this case the connection also typically uses virtual serial ports.
Here are instructions from VMWare on how to set up kernel debugging of a virtual machine:
http://www.vmware.com/support/ws5/doc/ws_devices_serial_advanced_example_debugging.html
You can also use VirtualKD which makes the setup easier and the connection much faster:
http://virtualkd.sysprogs.org/
You can also use Windbg for local kernel debugging. In this case, you only have a single machine where you connect Windbg to the running kernel. You cannot "freeze" the machine, as it would also freeze Windbg running on the same machine, but you can analyze the contents of memory and so on.
Good point. Another good solution for virtual kernel debugging is LiveKd from sysinternals.
http://technet.microsoft.com/en-us/sysinternals/bb897415.aspx
I have a multi-threaded Windows application that occasionally deadlocks. Inevitably this happens on a customer system and not when the software is in test. What is the easiest way of getting a Windows Minidump of the current state of the application? If it could also terminate the application so the user can restart it and continue using the system that would be great.
In Vista you can create a dump file directly from task manager. Right click on a process in the processes tab and choose 'create dump file'.
Prior to Vista I prefer the ntsd route, since although it is not totally user friendly it works without the user installing any other software and the instructions are actually fairly easy to follow.
See the Microsoft support article How to use ADPlus to troubleshoot "hangs" and "crashes", as well as the helpful blog post Debugging Production Applications using ADPlus.
Both of these articles are about "ADPlus", a VBScript tool supplied with Debugging Tools for Windows that can be used to generate minidumps from a production environment (which can later be loaded up with WinDbg on your development machine). ADPlus has a lot of functionality and a lot of options, so it may take some reading, experimentation, and practice to find the best way to use it in your environment.
I know how to achieve this. It's just my technique is a bit clunky. All Windows 2000 and later systems have a basic command line debugger as part of the default install called NTSD. What I do at the moment is run:
ntsd -pn MyApp.exe
When the debugger console appears I can then type the following into the debugger console:
.dump c:\my-deadlock.mdmp
.kill
What I'm looking for is something that's a little bit cleaner and easier to put in an email to customers to just run. I've seen it alluded to somewhere (that google can't find for now) that you can use drwtsn32.exe to extract a crash dump and terminate an application.
Edit: It is possible to streamline the command somewhat:
ntsd -pn MyApp.exe -c ".dump c:\my-deadlock.mdmp; .kill"
The command .detach can be given if the process has not terminally hung (e.g. a long network timeout) and you want the process to keep going.