Twice today people were worried about securing their work.
One very probably inadvertantly left passwords in plain text in
the compiled program. Here is a simple method to hide your
passwords.

Compiled or not, this is not going to look like a password:

usr = CDec(19199683 * 4) & CDec(16739357 * 5) & CDec(88870 * 931 + 519)


Yet that is the type of things you have to do to hide your passwords
in amongst other executable code. And, you don't have to do it all in one place
either, you can assign the first part early on, then concatenate the second
and later parts while you are initializing your app.

But, eventually you have to make a comparison:

If pw = Condense(usr) then ... ' Passed flag set

And that is what the hacker is going to look for. If he can adjust the file
so that one expression appears True, then he's done, and no one needs
a password. Your defense against that is to break that one comparison into
a few different tests, and plant them in different parts of your code:

Passed = Passed And (Left$(pw, 3) = Left$(Condense(usr), 3))

and

Passed = Passed And ( Right$(Condense(usr), 3) = Right$(pw,3) )

Or

Partial = ( Condense(usr) = pw )
And elsewhere:
Passed = Passed And Partial


And so forth, such that all of them have to pass in order for Passed
to remain True. In addition, you might want to use 3 or 4 different
indicators to force the hacker to look up more than just one memory
reference. With just one indicator the hacker can go though and adjust
file code such that Passed ends up True at the end of all those code
sections. If you have 2 or 3 such tests, he has to adjust the file 2 or 3
times, but if you add 2 or 3 indicators, he has to comb the entire code
for 2 or 3 memory references and adjust all those....

You want to expend a little effort to make him do considerably more work.
The more work required, the more chances you have that he will just give up.
That is what you count on to protect your investment, that the work required
to hack the program is just too much for all but the criminally insane!

So, what about that hidden password? Run it through this short routine to
see what you get....


Private Function Condense$(ByVal Text$)
Dim pos&
Condense = Space$(Len(Text) \ 2)
For pos = 1 To Len(Text) \ 2
Mid(Condense, pos, 1) = Chr$(Val(Mid(Text, pos * 2 - 1, 2)))
Next
End Function


It's not National Defense caliber, but it is pretty easy to implement....

Have fun!
LFS

What is the KB?: http://support.microsoft.com/default.aspx?scid=fh;en-us;kbinfo
RTFM? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbstartpage.asp
Where's the archive?: http://groups.google.com/advanced_group_search?q=group:microsoft.public.vb.*&hl=en&safe=off&num=50

Re: Hide those passwords! by Peter

Peter
Wed Jul 30 00:41:56 CDT 2003

Hi Larry,

Sage advice.

However, I want to point out that this code:
Left$(Condense(usr), 3))

will display the entire password string when run under a debugger. The
reason is that you're passing the entire string into Left$.

I suspect you understand that, but from your post, I don't think it was
clear that threat was there. In general too, I think it's best to avoid
String compares altogether. You can use Byte arrays for the comparison,
which avoids loading Strings into memory where they're easily spotted.

Also, code to test for the presence of debuggers is helpful - either
terminate the debugger or don't do a comparison if detected.

Something as simple as calling the IsDebuggerPresent API can prove helpful.

Best,
Pete



Re: Hide those passwords! by Larry

Larry
Wed Jul 30 01:05:51 CDT 2003

"Peter Young" <youngpa@attbi.no.com.spam.please> wrote
>
> Sage advice.
>
> However, I want to point out that this code:
> Left$(Condense(usr), 3))
>
> will display the entire password string when run under a debugger. The
> reason is that you're passing the entire string into Left$.

> I suspect you understand that, but from your post, I don't think it was
> clear that threat was there. In general too, I think it's best to avoid
> String compares altogether. You can use Byte arrays for the comparison,
> which avoids loading Strings into memory where they're easily spotted.
>
> Also, code to test for the presence of debuggers is helpful - either
> terminate the debugger or don't do a comparison if detected.
>
> Something as simple as calling the IsDebuggerPresent API can prove helpful.


You've enriched my understanding there. Testing for a debugger most
certainly does sound like a good idea for yet another indicator of trouble....

LFS






Re: Hide those passwords! by Stone

Stone
Wed Jul 30 07:28:54 CDT 2003

STUPID ME!!
The password strings ARE in the EXE...

For Hello is was searching for "Hello" and it is missing... but guess what,
00 "H" 00 "e" 00 "l" 00 "l' 00 is plain as day... just with nulls in
between
the letters...

So much for a stupid password design...
-stone






Re: Hide those passwords! by Jeff

Jeff
Wed Jul 30 07:56:46 CDT 2003


"Stone" <x@y.com> wrote in message
news:aSOVa.10248$W93.2971857@news4.srv.hcvlny.cv.net...

> STUPID ME!!
> The password strings ARE in the EXE...
>
> For Hello is was searching for "Hello" and it is missing... but guess
what,
> 00 "H" 00 "e" 00 "l" 00 "l' 00 is plain as day... just with nulls in
> between the letters...

Welcome to the world of Unicode.



Re: Hide those passwords! by Ben

Ben
Wed Jul 30 15:42:03 CDT 2003

What about testing for other processes that are running - and say that the
license agreement bit of the program has to be done when no other processes
are running, that would enable you to make sure a spy process wasn't
running. Or would they just disassemble the program and run it in machine
code line by line?

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:e6%23wkBmVDHA.1928@TK2MSFTNGP12.phx.gbl...
> "Peter Young" <youngpa@attbi.no.com.spam.please> wrote
> >
> > Sage advice.
> >
> > However, I want to point out that this code:
> > Left$(Condense(usr), 3))
> >
> > will display the entire password string when run under a debugger. The
> > reason is that you're passing the entire string into Left$.
>
> > I suspect you understand that, but from your post, I don't think it was
> > clear that threat was there. In general too, I think it's best to avoid
> > String compares altogether. You can use Byte arrays for the comparison,
> > which avoids loading Strings into memory where they're easily spotted.
> >
> > Also, code to test for the presence of debuggers is helpful - either
> > terminate the debugger or don't do a comparison if detected.
> >
> > Something as simple as calling the IsDebuggerPresent API can prove
helpful.
>
>
> You've enriched my understanding there. Testing for a debugger most
> certainly does sound like a good idea for yet another indicator of
trouble....
>
> LFS
>
>
>
>
>



Re: Hide those passwords! by Jim

Jim
Wed Jul 30 16:02:06 CDT 2003

http://www.sysinternals.com/ntw2k/utilities.shtml

Sysinternals has some very useful utilities that can parse
executables for both Ansi and Unicode strings. Specifically,
look under Miscellaneous on the above link, and more
specifically, look at the tools under the Miscellaneous Link
under the Miscellaneous subheading.

--
Jim Carlock
http://www.microcosmotalk.com
Feel free to post back to the newsgroup!


"Stone" <x@y.com> wrote in message
news:aSOVa.10248$W93.2971857@news4.srv.hcvlny.cv.net...
> STUPID ME!!
> The password strings ARE in the EXE...
>
> For Hello is was searching for "Hello" and it is missing... but guess
what,
> 00 "H" 00 "e" 00 "l" 00 "l' 00 is plain as day... just with nulls in
> between
> the letters...
>
> So much for a stupid password design...
> -stone
>
>
>
>
>



Re: Hide those passwords! by Larry

Larry
Wed Jul 30 17:13:37 CDT 2003

"Ben Taylor" <ben_taylor_g1@yahoo.co.uk> wrote
> What about testing for other processes that are running - and say that the
> license agreement bit of the program has to be done when no other processes
> are running, that would enable you to make sure a spy process wasn't
> running. Or would they just disassemble the program and run it in machine
> code line by line?

It would have to be more specific than that, using Win2K, I have 15 processes
running when there is nothing but the desktop showing....

(It used to be like 19 by default, but I've trimmed it down by cutting off a
few unused services)

LFS




Re: Hide those passwords! by Ben

Ben
Thu Jul 31 02:41:04 CDT 2003

Yes, true... but they're all things
like 'services.exe', 'winlogon.exe', 'smss.exe', standard
things that are probably running on every computer. Maybe
a lookup table of all these such processes could be kept?

>-----Original Message-----
>"Ben Taylor" <ben_taylor_g1@yahoo.co.uk> wrote
>> What about testing for other processes that are
running - and say that the
>> license agreement bit of the program has to be done
when no other processes
>> are running, that would enable you to make sure a spy
process wasn't
>> running. Or would they just disassemble the program and
run it in machine
>> code line by line?
>
>It would have to be more specific than that, using Win2K,
I have 15 processes
>running when there is nothing but the desktop showing....
>
>(It used to be like 19 by default, but I've trimmed it
down by cutting off a
>few unused services)
>
>LFS
>
>
>
>.
>

Re: Hide those passwords! by Peter

Peter
Thu Jul 31 11:32:08 CDT 2003

It's too easy to call your debugger 'services.exe' to get around that. Not
only that, but you risk irritating your users with such a requirement.


"Ben Taylor" <ben_taylor_g1@yahoo.co.uk> wrote in message
news:0a3d01c35737$18e98200$a301280a@phx.gbl...
> Yes, true... but they're all things
> like 'services.exe', 'winlogon.exe', 'smss.exe', standard
> things that are probably running on every computer. Maybe
> a lookup table of all these such processes could be kept?
>
> >-----Original Message-----
> >"Ben Taylor" <ben_taylor_g1@yahoo.co.uk> wrote
> >> What about testing for other processes that are
> running - and say that the
> >> license agreement bit of the program has to be done
> when no other processes
> >> are running, that would enable you to make sure a spy
> process wasn't
> >> running. Or would they just disassemble the program and
> run it in machine
> >> code line by line?
> >
> >It would have to be more specific than that, using Win2K,
> I have 15 processes
> >running when there is nothing but the desktop showing....
> >
> >(It used to be like 19 by default, but I've trimmed it
> down by cutting off a
> >few unused services)
> >
> >LFS
> >
> >
> >
> >.
> >



Re: Hide those passwords! by Ben

Ben
Thu Jul 31 12:46:47 CDT 2003

I was more thinking along the lines of doing some rudimentary spying on what
is going on in the processes, in the same way that spyware operates?
How you do this and whether it would be faesible I don't know - just a
thought


"Peter Young" <youngpa@attbi.no.com.spam.please> wrote in message
news:OQ1K4E4VDHA.3376@tk2msftngp13.phx.gbl...
> It's too easy to call your debugger 'services.exe' to get around that. Not
> only that, but you risk irritating your users with such a requirement.
>
>
> "Ben Taylor" <ben_taylor_g1@yahoo.co.uk> wrote in message
> news:0a3d01c35737$18e98200$a301280a@phx.gbl...
> > Yes, true... but they're all things
> > like 'services.exe', 'winlogon.exe', 'smss.exe', standard
> > things that are probably running on every computer. Maybe
> > a lookup table of all these such processes could be kept?
> >
> > >-----Original Message-----
> > >"Ben Taylor" <ben_taylor_g1@yahoo.co.uk> wrote
> > >> What about testing for other processes that are
> > running - and say that the
> > >> license agreement bit of the program has to be done
> > when no other processes
> > >> are running, that would enable you to make sure a spy
> > process wasn't
> > >> running. Or would they just disassemble the program and
> > run it in machine
> > >> code line by line?
> > >
> > >It would have to be more specific than that, using Win2K,
> > I have 15 processes
> > >running when there is nothing but the desktop showing....
> > >
> > >(It used to be like 19 by default, but I've trimmed it
> > down by cutting off a
> > >few unused services)
> > >
> > >LFS
> > >
> > >
> > >
> > >.
> > >
>
>