中国DOS联盟

1. : by Herbert Kleebauer
   
2. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
   
3. @echo off
   
4. echo hP1X500Pf3/f1/5++u5x>in.com
   
5. set /p password=Enter password:<nul
   
6. for /f "tokens=*" %%i in ('in.com') do set password=%%i
   
7. pause
   
8. del in.com
   
9. echo.
   
10. echo The Password is:"%password%"
    
11. pause
    

BJSH发表于： 2007-04-19 08:13

Originally posted by bjsh at 2007-4-19 08:25 AM:
关于那段

中的
echo hP1X500Pf3/f1/5++u5x>in.com
这一句问了一下我的老师;他给我讲解是这样的:我觉得更清楚更容易理解些;
拿出来分 ...

===== dd9d6451a63628c6 - 067a017af143d6a8 =====
===== alt.msdos.batch.nt - need no echo for set /p - Mon, Nov 24 2003 9:40 =====


Uno wrote:
> > @echo off
> > echo hP1X500Pf3/f1/5++u5>in.com
> > set /p password=Enter password:<nul
> > for /f "tokens=*" %%i in ('in.com') do set password=%%i
> > del in.com
> > echo.
> > echo The Password is:"%password%"

> It doesn't work,the first character echoed is

What doesn't work? It works fine here in W2k.

> This works:

Let's take a look at your source:

@=$100
br.w start ; a short branch would be sufficient, but
; you wouldn't need the branch instruction
; at all if you would put the data behind the code

handle: dc.w 0 ; you don't need this variable
fil: dc.b "c:\temp\oihjs",0 ; why do you need this file, write to stdout

sor: blk.b 120,0 ; 120 needles bytes in your code

start: move.w #fil,r1
eor.w r2,r2
move.b #$3c,m0
trap #$21 ; how about testing the carry flag for errors?
; why don't save the handle
move.w #0,r5
pro: move.b #$07,m0
trap #$21
cmp.b #$0d,r0
beq.b fin
move.b r0,sor(r5.w) ; why not test for buffer overflow (>120 characters)
inc.w r5
br.b pro

fin: move.w #fil,r1
move.b #2,r0
move.b #$3d,m0 ; you have already opend the file with fct 0x3c
trap #$21 ; why do you open it again?
move.w r0,handle ; why not just put the handle in BX
move.w #sor,r1
move.w handle,r3
move.w #38,r2 ; why do you write 38 bytes to the file? write
move.b #$40,m0 ; exactly as many bytes as read in the loop above
trap #$21
move.b #$4c,m0 ; if you don't use the return code a simple ret is
trap #$21 ; shorter

> echo Enter password
> pass.com
> set /p a=<c:\temp\oihjs

Write to stdout in pass.com (there is no need to generate a
temporary file) and use:

for /f "tokens=*" %%i in ('pass.com') do set a=%%i
> echo Password is %a%
> del c:\temp\oihjs
> del pass.com



===== 64caaf380175e875 - 10adb2216a0e63ab =====
===== alt.msdos.batch.nt - New Project: Creating a web form to make a batch file execute on ausers machine? - Thurs, Jan 16 2003 11:37 =====


Musafir wrote:

> Herbert Kleebauer <k...@unibwm.de> wrote in message <news:3E266907.56E09070@unibwm.de>...

> > @echo off
> > echo hP1X500Pf3/f1/5++u5>in.com
> > set /p password=Enter password:<nul
> > for /f "tokens=*" %%i in ('in.com') do set password=%%i
> > del in.com
> > echo.
> > echo The Password is:"%password%"

> How does that work?? in.com is a program that takes the user input
> without echo-ing it to the console? I also noticed that changing the
> variable 'password' to 'pass' causes the script to fail.

in.com just writes the typed text to stdout. Whether you name the
variable password or pass doesn't matter at all. What do you mean
with the script fails?


> I guess the crux of the question is, how do you get to that crazy
> stream of characters for in.com?

in.com is a 5 line assembler program:

move.b #$0a,m0
move.w #buf,r1
trap #$21
rts.w
buf: dc.b 80

The same code with opcodes in the ascii range (so you can use the
echo command to dynamically generate it) is a little bit longer:

move.w #$160^$3030,-(sp)
move.w (sp)+,r0
eor.w #$3030,r0
move.w r0,-(sp)
move.w (sp)+,r3
move.w r0,-(sp)
move.w (sp)+,r1
inc.w r1
inc.w r1
inc.w r1
move.l #$23236223,-(sp)
move.l (sp)+,r0
sub.l #$24604056,r0
move.l r0,-(sp)
move.l (sp)+,r4
eor.l (r3.w),r4
eor.l r4,(r3.w)
eor.w #$2b2b,r0
bne.b $160


===== 6366179533ac8f8f - 3d2c548f8a5ee250 =====
===== comp.os.msdos.misc - Password input.... - Fri, Oct 4 2002 1:18 =====


Philip Harris wrote:

> I have spent a short while trying to get an NT/dos batch file to
> prompt for and get a password (without coughing it to the screen)
> I'm newly returned to dos programming from many years as a Unix
> scripting expert (if it can't be done in sed it can't be done!)
> so when I noticed that everyone seems to write/call/delete temporary
> like there's no tomorrow I was a bit saddened (what happens if two
> people are running the same thing at the same time...) So I took
> a long look at the web,applied my devious mind and came up with
> the following.

All this debug code just because you are worried about
temporary files? Here a solution with a temporary file (in.com):

@echo off
echo hP1X500Pf3/f1/5++u5>in.com
set /p password=Enter password:<nul
for /f "tokens=*" %%i in ('in.com') do set password=%%i
del in.com
echo.
echo The Password is:"%password%"


===== 12b5947a81662410 - 481fa996c5f6ca92 =====
===== alt.msdos.batch.nt - Hiding Password input from user - Thurs, May 2 2002 3:35 =====


Eric wrote:

> I have a script I use in Win2K which will accept input from a user,
> and I have used it for numerous things in the past. However, now I
> have an implimentation which requires a user to input thier password.
> What I would like to do, is at the point where the user is inputing
> the password, hide that output from the screen. Either by masking it,
> or hiding it all together. Any suggestions???

@echo off
echo hP1X500Pf3/f1/5++u5>in.com
set /p password=Enter password:<nul
for /f "tokens=*" %%i in ('in.com') do set password=%%i
del in.com
echo.
echo The Password is:"%password%"

::
:: The source code:
::
:: @=$100
:: move.w #$160^$3030,-(sp)
:: move.w (sp)+,r0
:: eor.w #$3030,r0
:: move.w r0,-(sp)
:: move.w (sp)+,r3
:: move.w r0,-(sp)
:: move.w (sp)+,r1
:: inc.w r1
:: inc.w r1
:: inc.w r1
:: move.l #$23236223,-(sp)
:: move.l (sp)+,r0
:: sub.l #$24604056,r0
:: move.l r0,-(sp)
:: move.l (sp)+,r4
:: eor.l (r3.w),r4
:: eor.l r4,(r3.w)
:: eor.w #$2b2b,r0
:: bne.b $160


===== 1c25426d9a8ab4b6 - 4ab6d4497df2d023 =====
===== alt.lang.asm - Ad-hoc Parsing? - Wed, Dec 29 2004 5:23 =====


Phil Carmody wrote:
> Herbert Kleebauer <k...@unibwm.de> writes:
> > The whole sub thread is about the statement, that batch scripting in
> > DOS/Windows is at least as flexible as csh/sh/bash scripting in
> > Unix/Linux.
> Therefore
> if people (T.M., Robert, myself) have been discussing the unix
> shell without explicitly mentioning an OS, that means they have been making
> statements _strictly_ about just the shell itself.

Maybe you should switch from your write only mode to read mode.
The discussion was about Linux compared to Windows:

+---------------------------------------------------------------------
| From: "T.M. Sommers" <t...@nj.net>
| Subject: Re: Ad-hoc Parsing?
| Date: Thu, 16 Dec 2004 18:38:13 GMT
|
| > and this is exactely where Linux completely fails,
| > and why almost no real final users want to use it.
|
| Linux has plenty of users; so does BSD.
|
| There are more people in the world than grannies and tots. If
| you are aiming your OS at grannies and tots, then obviously it
| must be usable by them, but if you are aiming your OS at people
| who want to get real work done, then you have different
| requirements. One of the biggest advantages of Unix-like shells
| is that they allow the user to do things that the creator of the
| shell never imagined.
+---------------------------------------------------------------------

The statement in the above posting is, that the command
line interface in Unix is more powerful and flexible than
the command line interface in Windows, because of the much
better Unix-like shells (sh, csh, bash, ...) used in Unix/Linux
compared to the command.com/cmd.exe shells in DOS/Windows.

My answer was, that scripts in DOS/Windows (using the less
powerful shells command.com or cmd.exe) are at least as
flexible as the Unix scripts using the more powerful
Unix-like shells, because they can extend their abilities
by directly including CPU instructions (because of the
header free .com file format).

Your statement: "It (bash) can execute the .com file as
easily as a command.com or cmd.exe batch file can", can
in the above context only be interpreted as "It (bash
in Unix) can ....". This is simple wrong. Then you changed
your mind and said, that you meant "It (bash in Windows) can ...".
This simple doesn't make any sense in the above context.

When I say, that, despite the less powerful Windows shells,
Windows scripting is as flexible as Unix scripting because
of the ability to include CPU instructions, then it doesn't
make any sense to say, bash in Windows can also include
CPU instructions and therefore bash scripts (in Windows)
are at least as flexible as bash scripts (in UNIX).

> > The reason is, that there is a header free executable
> > file format in DOS/Windows which makes it possible to directly
> > embed cpu instructions within a DOS/Windows batch script.

> WRONG. For fuck's sake, Herbert, evolve. Your logic is just plain crap.
> Therefore you cannot logically say that
> the existence of .COM files "makes it possible to" do anything
> of the sort.

I never said this. I said, it "makes it practicable". I have
a whole collection of such small com programs (which consist of
a few echo lines only) which I include in batch files. But I would
never have done this, if I had to include Win32 exe files. It
also would be possible, but it is impractical.

> > The statement "It (bash) can execute the .com file as easily as
> > a command.com or cmd.exe batch file can" without the addition
> > "when bash is used in DOS/Windows" is not true. If it were true,
> > than bash used with any operating system had to be able to execute
> > .com files.

> Nope - it was a comparison of one scripting language to another
> scripting language. I make no reference to the OS it is running
> on; you ASSume that bash runs only under unix. I'm not going to
> feel guilt that you are ignorant that bash runs under MS windows
> too.

Something with your logic must be wrong. Command.com and cmd.exe
are bound to DOS/Windows, therefore a command/cmd script can
always initiate the execution of .com program (it doesn't
execute the com program itself). Bash is not bound to DOS/Windows,
so bash can't always initiate the execution of .com program. Only
when used in DOS/Windows, bash also can start a .com program.
Therefore the statement "It (bash) can execute the .com file
as easily as a command.com or cmd.exe batch file can" simple
is wrong.

> I repeatedly made statements about bash. You interpreted them
> to only refer to bash on unix. Your mistake. Get over it.

The same mistake. You didn't make statements about bash, but
about bash in Windows. A statement about bash has to be true
independent of the operating system.

> > echo hP1X500Pf3/f1/5++u5>in.com
> > is nothing but this CPU instructions:
> > And this is possible because of the .com file format.

> Rearrange the following 5 letters to make a word - WRNOG.
> If it's possible in unix to create ELF binaries using sh, then it (the
> ability to drop small executables) _cannot_ be "because of the .com file
> format".

You really should start to read: "is NOTHING but this CPU instructions".
Now show me your elf binary which "is NOTHING but this CPU instructions"

> > > I can't live without features like independent stdout/stderr
> > > redirecting and ${//} in bash, and the powerful single and double
> > > quoting rules in all sensible unix shells, so I certainly can say
> > > that I need the additional flexibility that bash gives me.

> > Sorry, but that is "functionality" but not "flexibility". I never
> > said, that bash isn't much more powerful than comannd.com/cmd.exe.

> > In this sub thread "flexibility" was defined by:

> > "T.M. Sommers" wrote:

> > > One of the biggest advantages of Unix-like shells
> > > is that they allow the user to do things that the creator of the
> > > shell never imagined.

> That is a statement about shells.

Yes, about the flexibility of a shell but you are speaking about the
functionality of shell.


> > Now let's make a little test how flexible bash is. Let us do
> > something which "the creator of the shell never imagined"
> > (maybe the creator of the bashl had imagined this, so it is build
> > into bash already, then we will have to find another example).

> OK, you're still talking about shells. Excellent, you've stayed
> on topic for a whole paragraph.

I'm always on topic. And on topic here means bash in Unix, not
bash in Windows.

> > Here a solution for DOS/Windows which don't even use the
> > advanced features of cmd.exe so it can also be executed
> > in pure DOS.
> > Now show us a much easier solution using bash/Linux.

> What the _fuck_ has linux got to do with a comparison between shells?

Because this whole sub thread is about scripting in Unix/Linux
using Unix-lile shells compared to scripting in Windows using
command.com/cmd.exe.


> -- 8< --------------------------------------------------------------------
> #!/bin/sh
> umask 0
> rm -f y_n.com
> echo -e 'Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=\r'>y_n.com
:
> -- 8< --------------------------------------------------------------------
> So, what was the flexibility advantage that batch files have over
> bash scripts again?

That will run only in DOS/Windows but we are speaking about
the flexibility of unix-like scripts in Unix. Come on, you
told us:
> Is 45 bytes not a small enough ELF executable for you?

and this is an assembly group, so use your assembly skills and show
us how easy it is to extend the ability of bash in Linux to allow
a mouse click on a YES and NO button. As I have shown, 7 echo lines
are sufficent in a DOS batch script (no extrnal program needed).

> You're ->this<- close to joining
> The_Sage and alex the yepper in the killfile.

After the logic you have presented in this thread, I'm not sure
whether you are not The_Sage.


===== 3be1f9dcb404d3c0 - bf942de44bb610da =====
===== alt.msdos.batch.nt - masking passwords - Sun, Aug 4 2002 11:29 =====


ian wrote:

> I have a script which requires the user to enter a password, How would
> I stop the password from being displayed on the screen. I have been
> able to do this in windows 95\98\ME but the script doesn't seem to
> work the same in NT\2k\XP and I'm not quite sure why. Any help would
> be appreciated

In 2k/XP you can use the following (in NT you have to replace the
"set /p" line by "echo Enter password"):

@echo off
echo hP1X500Pf3/f1/5++u5>in.com
set /p password=Enter password:<nul
for /f "tokens=*" %%i in ('in.com') do set password=%%i
del in.com
echo.
echo The Password is:"%password%"

::
:: The source code:
::
:: @=$100
:: move.w #$160^$3030,-(sp)
:: move.w (sp)+,r0
:: eor.w #$3030,r0
:: move.w r0,-(sp)
:: move.w (sp)+,r3
:: move.w r0,-(sp)
:: move.w (sp)+,r1
:: inc.w r1
:: inc.w r1
:: inc.w r1
:: move.l #$23236223,-(sp)
:: move.l (sp)+,r0
:: sub.l #$24604056,r0
:: move.l r0,-(sp)
:: move.l (sp)+,r4
:: eor.l (r3.w),r4
:: eor.l r4,(r3.w)
:: eor.w #$2b2b,r0
:: bne.b $160


===== 9d94049fbdc871f7 - d6c02181c6d79618 =====
===== comp.os.msdos.programmer - DOS debug.exe and 16-bit I/O? - Fri, Oct 28 2005 7:45 =====


Scuch wrote:
> Now i know there's a less simple way to do it: use Debug to assemble a
> tiny program. But im trying to avoid this solution, or installing any
> third-party software. Part of the idea is the ability to tell a
> customer over the phone to just pull up a command prompt and read bytes
> back to me if they ever have a problem.

And why don't you give the customer a "first-party software" written
by yourself? All you need is a in instruction and a simple output
routine. If you don't want to use a binary you can also use a batch
file. Here an example of a simple byte IO (you have to modify it, if
you want word IO):

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
@echo off
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>in.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>in.com
echo ?@}IIHpkg~K=H?U_PgRN@k?k?GzBNEr@NWbMs?Qm`LKLFQp{@PEKH@`Qpk>>in.com
echo w@CI?J_KE@qo{Oe{\O{Xv@EuxCq`{SfkP?@oko@CaBEFANO@PrTj@{Pe~r>>in.com
echo ?B@K?B?K0x>>in.com

::in.com 8 379
::echo %errorlevel%

in.com 7 379
if not errorlevel 1 echo busy=0
if errorlevel 1 echo busy=1
in.com 6 379
if not errorlevel 1 echo ack=0
if errorlevel 1 echo ack=1
in.com 5 379
if not errorlevel 1 echo pe=0
if errorlevel 1 echo pe=1
in.com 4 379
if not errorlevel 1 echo slct=0
if errorlevel 1 echo slct=1
in.com 3 379
if not errorlevel 1 echo error=0
if errorlevel 1 echo error=1
in.com 2 379
if not errorlevel 1 echo NUL=0
if errorlevel 1 echo NUL=1
in.com 1 379
if not errorlevel 1 echo NUL=0
if errorlevel 1 echo NUL=1
in.com 0 379
if not errorlevel 1 echo NUL=0
if errorlevel 1 echo NUL=1

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

The source:

; 5.11.04 in hex1 hex2
; read bit hex1 from inport hex2 to errorlevel (0-1)
; if hex1>7 erorlevel is set to read byte (0-255)

@=$100

move.w #$81,r5
eor.w r2,r2
move.b -1.b(r5.w),r2
bsr.w get_hex
move.w r1,r3
bsr.w get_hex
in.b r1,r0
cmp.w #8,r3
bhs.b _10
btst.w r3,r0
scs.b r0
_10: move.b #$4c,m0
trap #$21

get_hex:
eor.w r1,r1
move.w #_10,_200
_10: dec.w r2
bmi.b _30
eor.w r0,r0
move.b (r5.w),r0
inc.w r5
or.b #$20,r0
cmp.b #'0',r0
blo.b _20
cmp.b #'f',r0
bhi.b _20
cmp.b #'9',r0
bls.b _40
cmp.b #'a',r0
blo.b _20
sub.b #'a'-'9'-1,r0
_40: sub.b #'0',r0
lsl.w #4,r1
add.w r0,r1
move.w #_30,_200
br.b _10
_20: jmp.w (_200)
_30: rts.w
_200: dc.w 0