This is cool. Microsoft is releasing some of their internal tools used in Secure Development Lifecycle for free.

You can download them at SDL tools.

Update: Damn! BinScope requires .NET 3.5 framework. So Win2000 is ruled out!! Unfortunately we are still using Windows 2000 at office.

I have clearcase 7.0.1.2 on Win2k OS.
When I built a project using Visual Studio .NET 2003, files are created in output “Release” directory which gets created under the vob. In this folder one particular file “vc70.idb” started creating problems. During further builds, VS is not able to delete this file to overwrite. My first reaction was to delete it from explorer only to find “Invalid DOS function” or such similar error message. Next step was to open CMD and try to delete this file. This too gave the same useless error message.  Due to urgency, I renamed the “Release” to “Release_somenumber”, changed output directory to my local drive and did further builds.

I got back to the problem later and there was no other way to delete this vc70.idb file. Name shows up in the explorer but just cannot get rid of these files. Our IT support guys were told about the problem and they came down, struggled for few hours and finally left saying they will escalate to IBM team. I did not wait for them because I know they will take few weeks to solve this.

So I decided to solve this myself with ever useful sysinternals tools. Solving this issue was trivial.

1. I fired up filemon.exe from sysinternals.
2. I opened explorer and tried deleting this “vc70.idb” file.
3. Stopped filemon capturing. Filemon shows the actual file location vc70.idb points to in the clearcase view. It leads to something like
“\\networkshare\csv_view.vws\.s0018\80000eabbglslvc70.idb”
4. Now it is trivial: open notepad and save the file with the same name shown by filemon in that location.
5. Go to explorer and simply delete the file!! voila!!

Interesting article on rootkit overview can be found at SecurityFocus

get it from WHDC. Or www.windbg.org for quick links

As explained by Volker von Einem here, WinDbg 6.70.05.0 is special in the sense it has CLR debugging support. Microsoft erred and released this version which is actually internal release. It is not available for download anymore and those who have kept copies are lucky. Worst still, MS never intends to release this CLR support in the foreseeable future.

Just in case if you are that unlucky one and have not got 6.70.05.0 version with you, I digged out a link which seems to work:

hxxp://cert.sjtu.edu.cn/download/mdt/dbg_x86_6.7.05.0.exe

I need to get MD5 hash from Volker since he has original one from MS. I’ll then update this post just to make sure Chinese website has not modified it in anyway.

Here is simple batch file to store symbols of released versions of your product. Symstore.exe is used from Debugging Tools. I use this regularly to save debugging symbols of our product locally in structured manner.

set BUILDNUM=%1

“C:\Program Files\Debugging Tools for Windows\symstore.exe” add /r /f “<path-to-your-prod-symbols-in-the-build>\*.pdb” /s \\<path-to-symbol-store-folder> /t “My Product Name” /v “Build %BUILDNUM%”

Developers can then append path to existing symbols path:

SRV*C:\WinSymbols*http://msdl.microsoft.com/download/symbols;<path-to-your-symbol-store-folder>

If some product is buggy and you don’t want symbols of it anymore, you can use Symstore to remove by using ID. This ID can be found in “<path-to-your-symbol-store-folder>00Admin” folder.  “History.txt” in this location will also show the date when storing is done and corresponding ID.

Advantage using symstore is, needless to say, you don’t have to worry about looking for right symbols when debugging your product. WinDbg resolves it for you

WHDC site announced new WinDbg release 6.10.3.233

http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.10.3.233.msi

“Diamonds are forever but bugs are an error”

I had the chance to debug into CGroupPolicyObject::New method in GPEdit.dll since the call is failing.

My finding is that if a thread’s Security Impersonation Level is anything other than Anonymous, the call will fail.

SecurityAnonymous, SecurityIdentification,
  SecurityImpersonation,
  SecurityDelegation

The reason is that the code in this method is as follows ( this is my code guessed from disassembly):

HTOKEN hToken = NULL;

OpenThreadToken(GetCurrentThread(),TOKEN_DUPLICATE,TRUE,&hToken);

…

CGroupPolicyObject::EnableSecurityPriv();

…

SetThreadToken(0,hToken);

You see, they are opening the token without TOKEN_IMPERSONATE flag and SetThreadToken will throw error if this flas is not used in the access token. Reason why it works for anonymous level is OpenThreadToken fails and sets hToken to NULL. And the resulting call is SetThreadToken(0,NULL) which will succeed. See SetThreadToken() in MSDN.

Tool used: WinDbg