Reading a hidden password via a FINDSTR bug

[Aacini]

I discovered a strange bug in FINDSTR command that happen when this command is used to show characters in color AND the output of such a command is redirected to CON. For details on how use FINDSTR command to show text in color, see this topic.

When the output of this form of FINDSTR command is redirected to CON device, something strange happens after the text is output in the desired color: all the text after it is output as "invisible" characters, although a more precise description is that the text is output as black text over black background. The original text will appear if you use COLOR command to reset the foreground and background colors of the entire screen. However, when the text is "invisible" we could execute a SET /P command, so all characters entered will not appear on the screen.

Code: Select all

@echo off
setlocal

set /P "=_" < NUL > "Enter password"
findstr /A:1E /V "^$" "Enter password" NUL > CON
del "Enter password"
set /P "password="
cls
color 07
echo The password read is: "%password%"

Tested on Windows 8.1

Antonio

[npocmaka_]

Cool

Works on windows 10 too.

[Hackoo]

A beautiful find !
works on my windows 10 too

Code: Select all

@echo off
Title Multi-Lines Comments and Reading a hidden password via a FINDSTR bug
rem.||(
Today on 01/08/2018 ; I learned two nice codes :
This is a multiline comments from here ==> https://www.dostips.com/forum/viewtopic.php?p=57621#p57621
And this comment from Reading a hidden password via a FINDSTR bug ==> https://www.dostips.com/forum/viewtopic.php?p=57620#p57620
When the output of this form of FINDSTR command is redirected to CON device,
something strange happens after the text is output in the desired color: all the text after it is output as "invisible" characters,
although a more precise description is that the text is output as black text over black background.
The original text will appear if you use COLOR command to reset the foreground and background colors of the entire screen.
However, when the text is "invisible" we could execute a SET /P command, so all characters entered will not appear on the screen.
)
setlocal
set /P "=_" < NUL > "Enter password"
findstr /A:0A /V "^$" "Enter password" NUL > CON
del "Enter password"
set /P "password="
cls
color 1F
echo The password read is: "%password%"
pause>nul

[elzooilogico]

Nice find Antonio. Working in WIn 8 Enterprise. But the password is still accesible through the keyboard buffer (just hit the up arrow key). I would suggest clearing the buffer after password read

Code: Select all

@echo off
setlocal

set /P "=_" < NUL > "Enter password"
findstr /A:1E /V "^$" "Enter password" NUL > CON
del "Enter password"
set /P "password="
doskey /listsize=0 >NUL 2>&1 & doskey /listsize=50 >NUL 2>&1 
cls
color
echo The password read is: "%password%"

[Squashman]

Not working on my Windows 7 Pro machine. The output is still all black.
Also tested on 2008, 2012 and 2016 Server, with the same result. The color never gets reset. It just stays black.

The only way I have gotten it to work is to force the color back to the default by using color 07 in the code. Just using COLOR does not seem to want to reset it back to the default.


EDIT: I figured out the problem. If i open a cmd prompt first and then run the batch file, everything is fine. If I run the batch file with my mouse then it does not work unless I force the color setting back.

[jeb]

Works fine on my Win7 x64 Professional.

I'm astonished at the findstr redirection to CON.
I didn't expected any color effects for redirected text to CON at all, I expected to see control codes like for

Code: Select all

CLS > CON

I saw this effect before, when I build the findstr color technic, but I always assumed the cmd.exe had crashed, as any output was gone

[Squashman]

Works fine on my Win7 x64 Professional.

Strange. Then I don't know what is wrong with my Win7 X64 Professional and my three servers at work.

[dbenham]

Freaky and fun Nice find

On my Win 10 machine I see the same behavior as Squashman if I launch the script (with an added PAUSE) by double clicking in Windows Explorer - The COLOR command does not restore the color, it remains black on black.

The color chosen for the /A option does not matter. The color is set to black on black even if the chosen /A option matches the current screen color.

One other note - the color is only set to black on black if the FINDSTR command outputs at least one filename (or line number, or line offset) with the /A option. If no match is found, then there is no effect. I was hoping the technique could be modified to have the script search itself with a search string that does not match anything, but no luck

Aacini - Do you want to update your SO answer to my FINDSTR undocumented features question to include the newly discovered behavior? If not then I will try to incorporate the info in my answer.


Dave Benham

[Aacini]

I wrote a general-use subroutine that allows to read a hidden password using this technique.
You must call this file "Enter password.bat":

Code: Select all

@echo off
setlocal

call :Init
cd "%~P0"
findstr /B /R /C:"1. .....2" "%~NX0" NUL > CON
set /P "password="
cls
color 07
endlocal & set "%1=%password%"
exit /B

:Init
ver > NUL
call :End 2> NUL
if %errorlevel% equ 0 exit /B
for /F %%a in ('echo prompt $H ^| cmd') do set "BS=%%a"
(
   echo :End
   echo exit /B
   set /P "=1%BS% %BS%%BS%%BS%%BS%%BS%2   %BS%%BS%%BS%%BS%%BS% " < NUL
) >> "%~F0"
exit /B

Example of use:

Code: Select all

@echo off
setlocal

call "%~P0Enter password.bat" pass=
echo The password read is: "%pass%"
pause

This method works correctly even if the main Batch file is started via a double click in the explorer as long as the "Enter password.bat" subroutine be located in the same subdirectory as the main file.

@Dave: I will modify my answer at S.O. in order to include this new bug.

Antonio

[npocmaka_]

You can also update your answer here:
https://stackoverflow.com/a/24792070/388389

[Aacini]

Aacini - Do you want to update your SO answer to my FINDSTR undocumented features question to include the newly discovered behavior? If not then I will try to incorporate the info in my answer.

Dave Benham

You can also update your answer here:
https://stackoverflow.com/a/24792070/388389

Done. In both places. Thanks...

Antonio