Can I keep PASSWORDS in the EXE file??

[Guy Doucet]

I am writing an application with admin functions which will require a
password. I want the users to be able to change their passwords. If
however I save these passwords into a DAT file or other data file,
someone could delete it and there would have to be another way in to the
admin functions. Is it common practice to write the passwords in the EXE
file itself, locating the password just after a known location, then
search for the location and rewrite the password as necessary. For
instance:

sPASS = "This is a dummy string 12345"

I would look for "This is a dummy string" and then write the password in
the next 5 spaces or something like that.

Are there even better ways to save passwords?? I'm planning for the
possibility that this software may be distributed to several people.

Guy Doucet

[Jog26]

> Is it common practice to write the passwords in the EXE
>file itself, locating the password just after a known location, then
>search for the location and rewrite the password as necessary.

I don't know if it's common practice or not. What you are proposing will work
using a text editor to change just that part of the .exe, but if I were to do
it that way, I'd make it a little more subtle than what you suggested, even
encoding it such that the .exe might store the password "mypassword" as
"5gh1jjkwfg", etc.

Dd

[ChianWiz]

This is very interesting.

Storing the passwords in the exe file is quite unsafe as all the strings
are usually bundled together in the file. This means that the potential
"hacker" can look around those strings to spot anything unusual. Even the
"5gh1jjkwfg" will stick up like a sore thumb, especially if unicode is
used.

An alternative could be xoring (encryption) the bits of your passwords,
which word result in some really cryptic characters beyond the alphabet
domain. The key for the xor bits could be something fixed, like the name of
your app. Then some calculation to that could be done (modulous?) to ranfer
it to some bits to generate the key. This will mean that even the key is
not stored inside the exe file itself.

Another one may be storing the characters of the passwords as integers,
with some calculation done to it. This will make it look quite innocent in
the exe file.

Of course, storage on a file is still possible, esp if the file is
encrypted. To detect amendments etc, a checksum could be used. One method
is to store the encrypted checksum inside the system registry. The point is
that there are just too many entries that it's quite hard to spot the
correct one.

To foil deletion of the password file, have a special encrypted admin
password inside the registry and request that if the password file is
deleted. It'll really result in some surprise.

BTW, all the above only works if you're not against hardcore "hackers" who
would stay all night with a decompiler to see how your program works. For
maximum security try self-modifying code or handcode some of the routines
in a assemby - make it tricky.

For more information on this kind of stuff, look up on how game programmers
protect their games to be bullet-proof (unable to add extra life etc).

--
CKL

"I imagine. Therefore I can build it."
http://web.singnet.com.sg/~chianwiz

Jog26 <jo...@aol.com> wrote in article
<19980227050...@ladder02.news.aol.com>...

[Ray Humphrey]

In article <34F627D5...@ait.acl.ca>, Guy Doucet <gdo...@ait.acl.ca> wrote:
>I am writing an application with admin functions which will require a
>password. I want the users to be able to change their passwords. If
>however I save these passwords into a DAT file or other data file,
>someone could delete it and there would have to be another way in to the

>admin functions. Is it common practice to write the passwords in the EXE

>file itself, locating the password just after a known location, then

>search for the location and rewrite the password as necessary. For
>instance:
>
>sPASS = "This is a dummy string 12345"
>
>I would look for "This is a dummy string" and then write the password in
>the next 5 spaces or something like that.
>
>Are there even better ways to save passwords?? I'm planning for the
>possibility that this software may be distributed to several people.
>
>Guy Doucet
>

You might consider appending the password to the end of the EXE file. That
way, you always know where it is. You would need to append the initial
password to the EXE prior to using it. Some ideas below:

To initially set password:
OPEN pgmName$ FOR BINARY AS #1
SEEK #1, LOF(1) + 1
PUT #1, , PassWord$
CLOSE #1

To get password:
OPEN pgmName$ FOR BINARY AS #1
GET #1, LOF(1) - (LEN(PassWord%) -1), PassWord$
CLOSE #1

To change password:
OPEN pgmName$ FOR BINARY AS #1
GET #1, LOF(1) - (LEN(PassWord%) -1), PassWord$
IF CurrentPassword$ = PassWord$ THEN
PUT #1, LOF(1) - (LEN(PassWord%) -1) , NewPassWord$
END IF

Ray

[Brent P. Newhall]

On Fri, 27 Feb 98 15:58:53 GMT, NOSPAM....@aracnet.com (Ray
Humphrey) wrote thusly:

>In article <34F627D5...@ait.acl.ca>, Guy Doucet <gdo...@ait.acl.ca> wrote:
>>I am writing an application with admin functions which will require a
>>password. I want the users to be able to change their passwords. If
>>however I save these passwords into a DAT file or other data file,
>>someone could delete it and there would have to be another way in to the
>>admin functions. Is it common practice to write the passwords in the EXE
>>file itself, locating the password just after a known location, then
>>search for the location and rewrite the password as necessary. For
>>instance:
>>
>>sPASS = "This is a dummy string 12345"
>>
>>I would look for "This is a dummy string" and then write the password in
>>the next 5 spaces or something like that.
>>
>>Are there even better ways to save passwords?? I'm planning for the
>>possibility that this software may be distributed to several people.
>>
>>Guy Doucet
>>
>You might consider appending the password to the end of the EXE file. That
>way, you always know where it is. You would need to append the initial
>password to the EXE prior to using it. Some ideas below:
>

[snip: Code to accomplish this]

Question: Would this change the way the .exe executes? Does having
extra data in the executable itself chage the execution?

Brent P. Newhall
------------------------------------------------------------------------
"Every person you meet is better at something than you are." -- Robert
Cook

[Ray Humphrey]

Not as far as I know. I have been using this method for a couple of years
without any problems. In fact, some of my programs read and write data
to/from the end of the file quite often, without problems. I would sure be
interested if someone knows of a reason this should not be done.
Ray

[Michael Righi]

NO. Appending any information to the end of an executable will NOT
alter the way it works. Before appending any information however, you
should first append the EOF character to signal the end of file.

Reading and Writing to the end of the executable however can be
a very slow process if the exe is large and your code isn't very clean.

Concerning your "dummy string", use random ascii values. This will
prevent anybody from using a hex editor and discovering exactly where
you password is hidden. (Ex. "__fl#4fG" as opposed to "The password
is:")

And a final note, you should encrypt the password stored in the exe.
The encryption doesn't have to be the strongest, possibly just even an
ascii value shift, but atleast some level of encryption that will keep
someone using a hex editor from noticing an unusual string of characters
in plain english at the end of your exe.

Good luck.
-Michael Righi
mich...@nb.net

[Ray Humphrey]

I'm not too sure about appending the EOF character first. Depending on what
you subsequently do with the file, (edit, copy, etc.), it could cause a
problem. I've never had a problem with it the way I do it. Maybe I'll
experiment some with it. It might be good if the file was copied, that it
would drop the appended data (passwords, etc.). Hmmm.

[Nathan Shadle]

How would one go about writing to the end of an EXE file? And would it be
read in the same way as you would read in an ASCII file?

Ray Humphrey wrote in message <6d8dsu$edc$1...@spitting-spider.aracnet.com>...

>In article <34f793ab...@news.gmu.edu>, jem...@geocities.com (Brent P.

[Ray Humphrey]

Samples are repeated below:

To initially set password:
OPEN pgmName$ FOR BINARY AS #1
SEEK #1, LOF(1) + 1
PUT #1, , PassWord$
CLOSE #1

To get password:
OPEN pgmName$ FOR BINARY AS #1
GET #1, LOF(1) - (LEN(PassWord%) -1), PassWord$
CLOSE #1

To change password:
OPEN pgmName$ FOR BINARY AS #1
GET #1, LOF(1) - (LEN(PassWord%) -1), PassWord$
IF CurrentPassword$ = PassWord$ THEN
PUT #1, LOF(1) - (LEN(PassWord%) -1) , NewPassWord$
END IF

In article <6da4vk$9...@wizard.bsu.edu>, "Nathan Shadle"

[William R. Behymer]

The only effect I can think of which the user might experience is that
anti-virus programs which record and monitor file sizes, etc. might
interpret the change in the EXE as a virus infection.

Bill

--
======================================================================
William R. Behymer Internet: wbeh...@iglou.com
West Chester, OH Compuserve: wbehymer

[Peter Lindgren]

William R. Behymer wrote:

[Adding password information appended to the compiled .exe file]

> Ray Humphrey wrote:
> > Not as far as I know. I have been using this method for a couple of years
> > without any problems. In fact, some of my programs read and write data
> > to/from the end of the file quite often, without problems. I would sure be
> > interested if someone knows of a reason this should not be done.
> > Ray
>
> The only effect I can think of which the user might experience is that
> anti-virus programs which record and monitor file sizes, etc. might
> interpret the change in the EXE as a virus infection.

If the anti-virus program has had a chance to scan the directory
between .exe creation and password add-on, they might think so.

Perhaps some anti-virus programs check the .exe info and compares
it with the file system's info on the file length? Differs between
different anti-virus programs?

/Peter
--
Peter Lindgren Bachelor of Computer Engineering
Norrsken Konsult, Mölndal, Sweden +46 - (0)31 27 17 09
norrsken...@vaxjo.mail.telia.com +46 - (0)70 545 95 50

[Ray Humphrey]

In article <34F95B...@vaxjo.mail.telia.com>,

norrsken...@vaxjo.mail.telia.com wrote:
>William R. Behymer wrote:
>
>[Adding password information appended to the compiled .exe file]
>
>> Ray Humphrey wrote:
>> > Not as far as I know. I have been using this method for a couple of years
>> > without any problems. In fact, some of my programs read and write data
>> > to/from the end of the file quite often, without problems. I would sure be
>> > interested if someone knows of a reason this should not be done.
>> > Ray
>>
>> The only effect I can think of which the user might experience is that
>> anti-virus programs which record and monitor file sizes, etc. might
>> interpret the change in the EXE as a virus infection.
>
>If the anti-virus program has had a chance to scan the directory
>between .exe creation and password add-on, they might think so.
>
>Perhaps some anti-virus programs check the .exe info and compares
>it with the file system's info on the file length? Differs between
>different anti-virus programs?
>
>/Peter

If the default data is placed at the end of the EXE file BEFORE it is ever
released or run, then the file size never changes - just the content of it.
Ray