RE: [Dev-C++] Help with application security (hiding strings in compiled binaries)

[Per W. <pw...@ia...>]

The problem with

  char array[] =3D {'a','b','c','\0');

is that if the compiler is smart, it will notice that it is a string
literal and add one to the program. This is especially true if the array
had been declared static.

If the compiler fails to notice it as a string literal, it will emit code
like:

array[0] =3D 'a';
array[1] =3D 'b';
array[2] =3D 'c';
array[3] =3D '\0';

and unless the compiler have other instructions that it will mix in during
the optimization pass, the characters will be stored at a regular offset
from each other.

If you are just going for obfuscation, you might store the difference
relative the previous character. One other alternative is to xor the
string with another string, and store the resulting string in the
application. One more xor pass will retrieve the original string.

Note that whatever you do, it will still be possible to retrieve the
access information - a man-in-the-middle might take over the port you
expect the database on, and then get all access information in clear text.
Some databases supports encrypted communication. For example MySQL may
tunnel the data through a ssh channel. For a modern processor, it
shouldn't take more than a second or two to perform the connect
negotiation and after the key exchange, the communication will use a very
efficient encryption requiring very little CPU.

If you want to go for encryption, you might look at openssl.

/Per W

On Sat, 16 Aug 2003, Ed Cottrell wrote:

> Hi -
>
> That's certainly an improvement. However, it still shows up somewhat
> predictably. It looks like this in a text editor (I doubt this will displ=
ay
> correctly):
>
>   =FA=FF=FFj=C6=85=A9=FA=FF=FFi=C6=85=AA=FA=FF=FFl=C6=85=AB=FA=FF=FFl=C6=
=85=AC=FA=FF=FF =C6=85
>      ^      ^      ^      ^      ^
>
> It's a little weird, but you can see the pretty regular repetition, there=
=2E
> It MIGHT be sufficient to my purposes to do it this way, but it's not
> ideal...
>
> Other ideas?
>
> -Ed
>
>
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf Of P.D. van
> Zelst
> Sent: Saturday, August 16, 2003 6:45 PM
> To: 'Ed Cottrell'; 'Michael D. Smith'; dev...@li...=
t
> Subject: RE: [Dev-C++] Help with application security (hiding strings in
> compiled binaries)
>
>
> Well, it appears that if you specify your passwords as separate character=
s
> in a character array, it won't turn up in the executable as a string
> literal. I just tested this, as I was curious myself... The following cod=
e
> will generate an executable with the string literal "jack" in it, but "ji=
ll"
> won't show up as a literal (at least, not on my compiler... GCC 3.2 [Dev-=
C++
> 4.9.8.2]):
>
> #include <iostream>
> using std::cout;
> using std::endl;
>
>
> int main()
> {
> =09char szUser[] =3D "jack";
> =09char szPass[] =3D { 'j', 'i', 'l', 'l', '\0'};
> =09cout << szUser << endl;
> =09cout << szPass << endl;
> =09return 0;
> }
>
>
> Hope this helps you somewhat,
>
>
> Paul
>
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf Of Ed Cottre=
ll
> Sent: Sunday, August 17, 2003 12:02 AM
> To: 'Michael D. Smith'; dev...@li...
> Subject: RE: [Dev-C++] Help with application security (hiding strings in
> compiled binaries)
>
>
> Hi Mike & others,
>
> I know I can't make it impossible to find, but I'd like it to be more
> difficult than it is. The user logging in to the database will have limit=
ed
> capabilities, of course, but one (the trickiest to secure) is SELECT
> capability, by necessity...
>
> I'm not sure how I could separate the logon program from the main program
> (and put it in a secured directory) without losing functionality; the end
> user HAS to be able to login to the database servers from the program
> itself, but without having access other than through the program's own
> controls. In other words, when he/she runs my app, he/she should then hav=
e
> limited access to the database, but without knowing the authentication us=
ed
> to get there. If the user is going to somehow invoke a separate login
> program, that requires yet another layer of security, right? The user wil=
l
> be accessing some of the data over the net, and I don't want just anybody=
 to
> run a login script... (NOTE: traffic sniffing isn't a concern with this d=
ata
> - no credit cards or anything; somebody logging in and getting lots at on=
ce,
> though, is).
>
> NOTE: I don't mind encrypting it, somehow; I'm just not thrilled about it=
,
> because it would result in definite penalties in file size, execution spe=
ed,
> and development time.
>
> How else can I make this more discrete?
>
> -Ed
>
> -----Original Message-----
> From: Michael D. Smith [mailto:for...@hi...]
> Sent: Friday, August 15, 2003 10:14 PM
> To: Ed Cottrell
> Subject: Re: [Dev-C++] Help with application security (hiding strings in
> compiled binaries)
>
>
>
> I've done a good bit of computer security work over the years, I first
> programmed a UNIVAC 9200 in 1969, but I'm just now learning C, so from th=
at
> perspective...
>
> The situation is that you can't make it impossible to the truly determine=
d.
> You might could make it take 200 people 3 years though, which is no doubt
> much, much, much better than "anyone" and "notepad"
>
> It depends on the specifics which of course you don't want to give for
> obvious reasons. The first thing that comes to my mind is you should ask
>
> yourself "why do people logging on have access to the logon program?" If
>
> you could stop that, that alone would go a long way towards making you mo=
re
> secure. See if you can't do something with the file/directory permissions
> to make that impossible.
>
> YOu could store it packed (as binary) but anyone can read that as well if
> it's in a known code. I'm not 100% sure but I think putting it in a
> "struct" does that in C. If not, there's certainly someway to convert it.
> They would have to be a "little"  (very little) more determined to crack =
it
> but it could still be done. Still it's better than "anyone" and "notepad.=
"
>
> Even though you don't like encoding, it certainly could work. There's a
> world of possibilities out there. Just be aware, a "good" code is going t=
o
> cost you in processing time. Maybe as much as 30 seconds per user. If
> you're already at, or close to capacity that could be a hit. Of course wi=
th
> processing speed doubling every few months "they say" you're not supposed
> to worry about that. Of course with everyone not worrying about that ...
> :)
>
> And of course the current hot programming thinking is OOP (object oriente=
d
> programming). For some reason, the way they push OOP these days leaves ou=
t
> the fact that it's purpose was/is security. But it too has security holes
> for those in the know. I guess they figure that if you don't know that's
>
> it's purpose, you don't make it your purpose to find the security holes.
>
> You give the users an object that only allows them to use your method
> (subroutine) to access/change the database or perhaps to logon to start
> with. Your subroutine of course only does access/changes that you approve
> of. I suspect this would involve rewriting the whole program which, if yo=
ur
> not interested in encoding, you're probably not interested in rewriting t=
he
> whole thing either. That too very much depends on your program being in a
> directory they don't have permission to access.
>
> By necessity, as I don't know much C, and don't have any specifics, I've
>
> been rather vague but if there's anything else I can do to help (yea
> right:) -- write anytime.
>
> Good luck.
>
> ms
>
>
>
>
>
> At 04:10 PM 8/15/03, you wrote:
> >Hi,
> >
> >I have an application that, as one of its primary features, connects to
>
> >numerous databases with semi-sensitive to highly sensitive info in
> >them. The end users of this will be employees of a large organization,
> >and they should not have ANY direct access to the databases,
> >themselves. So, rather than giving them a username and password, I want
>
> >to hard-code that into the application.
> >
> >This is currently being done like this (simplified pseudo code):
> >
> >     char myconnectionstring =3D
> > "DSN=3Dsomething;server=3Dmyserver;username=3Dmyname;password=3Dmypass"=
;
> >     MyConnectionFunction(myconnectionstring);
> >
> >The compiled file (binary), though, contains this info in plain text.
> >I.e., anybody can open it up in Notepad, find the usernames and
> >passwords, and go hack the databases. That won't work.
> >
> >So, how can I hide those strings in the compiled code, other than
> >building in some sort of encryption? Would building the passwords from
> individual
> >characters (ASCII values) work? Other ideas?
> >
> >Thanks!
> >
> >-Ed
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including Da=
ta
> Reports, E-commerce, Portals, and Forums are available now. Download toda=
y
> and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
> /01
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including Da=
ta
> Reports, E-commerce, Portals, and Forums are available now. Download toda=
y
> and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>