/* the author and owner of this blog hereby allows anyone to test the security of this blog (on HTTP level only, the server is not mine, so let's leave it alone ;>), and try to break in (including successful breaks) without any consequences of any kind (DoS attacks are an exception here) ... I'll add that I planted in some places funny photos of some kittens, there are 7 of them right now, so have fun looking for them ;> let me know if You find them all, I'll add some congratz message or sth ;> */

Two days ago j00ru informed me that my cmd.exe add-on (the one that adds the ultra important feature - colors!) does not work on Windows 7 RC - so I decided to have a look, and so version 0.004d came into being!

If one is interested about what add-on am I referring to, and how does it work - please read this post. In the current post I'll focus only one the minor differences, between Vista's cmd.exe and W7RC cmd.exe, that were the direct cause of version 0.004c malfunction.

To tell you the truth, there was only one difference - function LoadLibraryA was missing in the IAT of cmd.exe - and I used IAT entry in the cmd.exe entry loader (that was executed before OEP and loaded AnsiSupport.dll). In addition to that, I had a bug in my patcher - an uninitialized variable - that prevented the patcher from printing the correct error message that would instantly tell me what is wrong. Instead of that, the patcher inserted a "random" address into the patch, and behaved as if everything was OK - and this caused of course the patched cmd.exe to crash.

The solution was simple - I have written a variation of the patch that uses LoadLibraryW (which is present in IAT of cmd.exe from W7RC), and made the patcher choose which patch to apply, depending on the presence of either LoadLibraryW or LoadLibraryA in the IAT.

@selybAs far as I know both Vista 64 (which I was using) and Win 7 64 have a 32-bit cmd.exe, so you should have no problem applying the patch.If you have any problem, or you in fact have a 64-bit version of cmd.exe, let me know ;>

@selybHmmm that's what I suspected. Well, thats what I get for using a 32-bit file manager on a 64-bit OS.... virtualized file system hehe ;>I'll work on a native 64-bit version and release it in the future ;>

@selybWell, you kinda answered yourself. You are using cscript.exe, and this hack is for cmd.exe ONLY. It's not global, it works only with batch scripts (which are handled with cmd.exe) and the cmd.exe command line interpreter itself.So it does not affect cscript.exe (however it might not be hard to hack the cscript.exe too using this code, and you are welcomed to do it of course ;>).

This morning (10/7/2009) I was created by a series of Symantec Endpoint Protection notifications related to _cmd.exe. It is complaining of a Trojan Horse.

I hope this is an example of a false positive.

Anyway, I tried downloading your new cmd_004d version and it is also being flagged as a trojan. Not any of the files in the .zip file mind you, just the _cmd.exe program that is created by ansihack.exe.

@csl2009Well, it's easy to check if there is a troyan or not there, since it's open source ;>

Anyway, it might be detected so, since I use some hooking techniques, that when spoted by AV soft might be marked as 'evil troyan or other ultra evil malware from dr. evil'.I'll contact the Symantec guys nevertheless and ask them to add it to the white list ;>

It gave me this error (sorry, it's a German copy):"Das System hat keinen Meldungstext für die Meldungsnummer 0x2350 in der Meldungsdatei Application gefunden."

I then went on testing it with a simple expression<code>ESC[1;36;44mthis should be colored textESC[0;37;40m</code>, run from a small batch file.

With that I managed to get *cyan* text on a *blue* background, which means it does work successfully so far. ---

Then I thought I'd be brave and tried 004c and 004d within a XP Mode cmd.exe window; in both cases when calling ansihack.exe, the action seemed to go through, but there was *no* _cmd.exe to find in the subdirectory as a result. (of course it might never be intended to work in such a case in the first place, though would be nice, hmm :-)

Update:* On the Win7 machine, after copying the two dlls and _cmd.exe to the /system32/ subdirectory, and adding the 'debugger' key to the registry, and having done a restart, I do still get the above mentioned error message (0x2350).* When using _cmd.exe, the sequence <code>ESC[0m</code> does not bring back the start situation, but only reduces high to normal intensity, leaving fg and bg colour untouched (which means it needs a full <code>ESC[0;37;40m</code> sequence to bring the window back to white on black).

I ran _cmd.exe manually to test this for Win7, I get the following errors when running a simple dir command:

C:\Install\cmd_ansihack_004d\tests>dirThe system cannot find message text for message number 0x235e in the message file for Application.The system cannot find message text for message number 0x235b in the message file for Application.

@SenilixSadly, no. It's on my TODO list, but I didn't yet have too much time to actually do it.

@TomThat's normal on Windows 7. It will stop acting like that once you move the hacked version do c:\windows\system32\cmd.exe (remember about DLL's; it's good to first take ownership of cmd.exe and remove any write/change privs from TrustedInstaller, or it will "recover" a non-hacked version for you, which isn't what you want).