[SDL] Communication between 2 SDL programs (Security?)
smirk at thebuicksix.com
Sun Aug 29 02:32:32 PDT 2004
On Aug 28, 2004, at 8:15 PM, xm at ca.inter.net wrote:
>> yeah truly, but what i meant is for instance if you had critical data
>> in your surfaces, someone could hack up their own sdl lib from source
>> would make it so whenever a surface was displayed, it would dump the
>> from that surface to a file.
>> Since the license garauntees that they should be able to relink your
>> app to
>> sdl, theyd be able to circumvent your security this way.
> Well, that would meen that someone would have to make changes within
> the computer
> either remotely or in front of it, and this falls outside the scope of
> what I can
> ever do.
> If the information is very sensitive, then the client using such
> program should
> have a network adminstrator capable of securing the network and should
> have an
> alarm system or other devices to stop an intruder to do anything with
> the computer.
> That is not my job.
> But, thanks I did not think about just changing the SDL lib itself to
> hack a program...
> Actually, any dynamic libraries are subject to that kind of security
I can't believe what you're saying. It's so ridiculous! It's just not
logical thought at all!
Possibility #1: You want to create an application that uses encryption
to prevent even the operating system kernel from getting at that
information, it will require special hardware.
Possibility #2: You want to create an application that just secures
data on a SECURE SYSTEM on a SECURE NETWORK (see your second paragraph)
then this really isn't any different than using ORDINARY ENCRYPTION.
You download the encrypted file, you decrypt it (on your secure
system,) and you view it (on your secure system.) There! Security!
What other possibilities are there? You clearly aren't doing either one
of these because one of them already exists and the other is largely a
matter of hardware.
That isn't the only contradiction of logic going on here (though
admittedly, this is somewhat related to the above contradiction.)
Possibility #1: You are trying to create software that a client can
download onto any public terminal and view encrypted documents with an
expectation of security based on whether or not the system can be
Possibility #2: You are trying to create software that a client can run
on machines he already trusts, which means he can just use ORDINARY
ENCRYPTION. As before, you download the encrypted file, you decrypt it
(on a trusted machine,) and you view it (on a trusted machine.)
Again, in paragraph #2, you forfeit your claim to protect data on an
UNTRUSTED MACHINE. What use is your software then? On a TRUSTED MACHINE
people already have a great deal of security using modern encryption.
These were a bit redundant - but I can't believe I didn't get my point
through already in previous emails! Call a doctor! There's something
wrong with you!
Paragraph 3 is total bullshit too! Dynamically linked libraries AREN'T
a SECURITY FLAW! Any hacker of ANY ABILITY WHATSOEVER will NOT have
been saved a great deal of time nor effort because the function names
have been spelled out for him - this only helps a SCRIPT KIDDIE. Again
I say!- if you think you're offering your "clients" ANY SECURITY AT ALL
by basically saying to all the script kiddies out there "Look, my
software is a bit too hard for you to crack now, but some time soon a
good hacker will crack it and post his programs for doing so on the
internet in windows executable form for you so you don't have to strain
yourself," you've got another thing coming.
When I was in highschool for my LTP (long-term project) I wrote an
encryption demonstration that discussed the history of cryptography and
its practical applications, and showed the exact inner workings of a
few really simple obfuscation algorithms (XOR comes to mind, but my
algorithms weren't THAT simple.) It was great for a highschool project,
and most script kiddies probably wouldn't have been able to crack them
- BUT IF I SOLD IT TO SOMEONE SAYING IT WAS A SECURE WAY TO ENCRYPT
THEIR DATA IT WOULD BE A BALD-FACED LIE.
> SDL mailing list
> SDL at libsdl.org
More information about the SDL