Recover Unencrypted Password using WinDBG

Interesting challenge at work today. A colleague of mine wanted to recover a password saved as part of an application’s configuration. The Administrator who had setup this Server was no longer with the Team!

I tried a couple of options, but listing the one that worked.

01-Cognos Password Screen

Launched the Application and had the particular window with the Password prompt open. This Configuration utility was loading each section dynamically.

After the configuration window was loaded and visible, the next step was to take a FULL memory dump (using Process Explorer).

Using WinDBG, searched for the username as shown below. The command does an ASCII Search from the base address to the maximum address (32 bit). Refer to the documentation for 64 bit syntax.

s -a 0 L?80000000 “Your Text”

02-Ascii String Search

Press ALT + 5 or Goto View | Memory menu.

03-View Memory

Typing the address as displayed in the ASCII search above. I was lucky enough to stumble upon a section of memory that had the unencrypted configuration with the username / password right next to each other. The security risk this might have posed is another topic


I also noticed that the other database credentials were not part of this memory dump. I had to redo these steps from the beginning to recover the other passwords. There were numerous other passwords that had to be recovered, but that is for another post.


Debugging Cognos Transformer (Cogtr.exe) Crash using Windbg

Cogtr.exe is the Cognos Transformer Executable, that can execute in batch mode (without a UI). Once in a while this process used to hang. It seemed to be random for the most part, but I did notice that the likelihood of this happening increased when multiple cubes were being refreshed in parallel. Since it pointed to some shared resource at this point, I used Process Monitor and Process Explorer to see if there were any common locks or files that were being shared. Cogtr does use the file system to denote locks for the Project file. There wasn’t anything that I could co-relate. Once this process hangs, the scheduled refresh of that particular cube would fail prompting end users to escalate. Ending the task seems to get things back to normal.

Taking a full memory dump of a process that had hung, I used Windbg to open the dump file.

The following command loads the symbols using the default path.

0:000> .symfix
0:000> .reload

The next step is to get to the stack trace of the method where it crashed. Bang Analyze, does just that. -v is for verbose mode.

0:000> !analyze -v


Staring with the stack trace, bottom up and ignoring the missing stack, since I did not have the symbol files for cogtr.exe, the “0027e3e4 68faa900 004ff028 03634f50 00000030 mfc100!CWinApp::ShowAppMessageBox+0x120” method call caught my attention. Cogtr was supposed to be in batch mode. A message box wasn’t supposed to be displayed without a UI. This could be the problem. The next step was to get the IBM engineers engaged. We were then able to identify that each cube needed it’s own preference file. More of the -f option here.


After configuration each cube refresh with its own preference file, this issue was resolved.