Re: Trusting and testing unknown (or unfamiliar) executables
- From: "Skybuck Flying" <spam@xxxxxxxxxxx>
- Date: Thu, 19 Jan 2006 22:18:14 +0100
Let's see.
Well at least all windows api's can be replaced by an intermediate dll which
could perform extra safety checks on the data/structures that are passed via
the api before passing them onto the original window dll's...
As you point out a program could wait to do something malicious at a later
time... so the intermediate dll's would need to check and ask the user
everytime if something is allowed to be sure it's not malicious... for
example... overwriting a file... or creating a new file... all have to be
confirmed by the user... could the program later do damage by simply writing
to a file ? maybe.... one thing which comes to mind is creating a huge file
filling up the harddisk space... or taking up all memory, however taking up
all memory is less bad, they user can simply shut it down or restart... and
a big file could be deleted as long as the user knowns where the file is...
So maybe the intermediate dll's could also maintain a list to see what files
where created and where etc... which could be displayed by a seperate
monitor gui.
Finally you mention completely bypassing the windows kernel by using
assembler instructions at ring zero... I never really programmed in
assembler... let alone windows 32 assembler so I can't help you here with
any ideas... I think I have never seen such a code which bypasses windows
completely ? Do you have any examples or links to examples which do that ?
;)
Finally you mention "trust". I generally agree with you that knowing
something about the programmer(s) and company is good for confidence in
there software.
However.. currently you are searching personal contact with me lol, so it
seems targetted at me... which makes me a bit suspicious :)
So the point is normally the programmer(s)/company won't know that it's
me... so the chance that they want to hurt or damage me or my pc is lower ;)
Finally I end with a comment :)
"Trust can be abused/misused/exploited" :):):)
The moral of the story as they say in the x-files "Trust no one" lol :)
Ok one more little thingy:
Can you tell a little bit more about what your applications do just out of
curiosity...
What I understand so far is that it has something to do with serial com
ports, and measuring power line distribution etc... devices etc... a bit
vague... what kind of devices ? can you give some examples ? or maybe it's
for testing some home-made circuitry ?
Bye,
Skybuck ;)
"Paul E. Schoen" <pstech@xxxxxxxxx> wrote in message
news:11svumfp7mts1d4@xxxxxxxxxxxxxxxxxxxxx
> In a separate post by Skybuck, I was informed that he did not trust my
> executable, and so would not run it. Putting myself in his sandals, I
> wondered if I would run an executable he or someone else offered.
>
> This is a good point. I can assure you that there is nothing malicious in
> the software, but is there any way for you to know? Even if there is
nothing
> intentional, it might be possible for some newbie code that causes a
system
> crash. My system locks up sometimes, but it does not seem to be related to
> the Ortmaster executable (except when actively programming). Just last
> night, after having tried some things with Test1, I was doing something in
> Word, when I had a partial lockup and found a "Danger-Stack Overflow" in
the
> IDE. I was running low on memory/disk space. I also saw that some icons in
> my QuickLaunch toolbar (and Desktop), such as Calculator, had changed to
the
> default document icon. I was surprised when a reboot did not fix them.
That
> is a matter for another discussion.
>
> The point is, how can one trust any executable? As far as I know, virus
> protection and Spybot, etc only scan for known viruses and alert for major
> changes in the Registry. They may also trap obviously catastrophic actions
> such as formatting a hard drive or overwriting or deleting a critical
system
> file. But how can one protect against inadvertant (or intentional) damage
> from unknown (or even unfamiliar) software. I managed to destroy several
> important Delphi help files just by trying to customize my help. I was
able
> to restore them from the distribution CD, but apparently this trusted
> application was able to destroy an important function without warning.
>
> I would like to know if there is a way to "wrap" an unknown executable in
> another "testing" executable, that would flag any suspicious activity,
> including any file deletion or modification, and any attempt to execute
> Ring0 assembly code which bypasses the usual Windows protection traps. As
> the unknown program runs, the user/tester could OK any normal file
> operations, and eventually the program would run unhindered. Of course, a
> truly malicious program could have an internal timer that would wait until
> much later to do something malicious, or even check to see when it wasn't
> being watched.
>
> As for trusting something to be not intentionally damaging, I would think
> that the amount of information available about the author would suffice.
You
> are welcome to browse through my website and you can find an immense
anount
> of personal and professional information about me, and you can google my
> name and find my web page. An author of malicious code would try every
trick
> to hide his or her identity. I have made my executable and associated
files
> available at www.Ortmaster.com as a way for existing and potential
customers
> to evaluate my software. The manual and helpfile are also there, and more
> info on my (very narrow niche) application are also included. If you are
> curious about testing of power line distribution protective devices and
> other high power things that can go *bang* in a big way, especially if not
> properly protected, you may learn more about it. I even wrote a slightly
> humorous article called "Taming The Big Bang", about circuit breaker
> testing. But that is for another group.
>
> Helpful comments appreciated!
>
> --
> Paul E. Schoen, President
> P S Technology, Inc.
> Cockeysville, MD
> www.pstech-inc.com
>
>
.
- Follow-Ups:
- Re: Trusting and testing unknown (or unfamiliar) executables
- From: Paul E. Schoen
- Re: Trusting and testing unknown (or unfamiliar) executables
- References:
- Trusting and testing unknown (or unfamiliar) executables
- From: Paul E. Schoen
- Trusting and testing unknown (or unfamiliar) executables
- Prev by Date: Re: Timestamped mileposts for code speed optimization
- Next by Date: Re: Trusting and testing unknown (or unfamiliar) executables
- Previous by thread: Trusting and testing unknown (or unfamiliar) executables
- Next by thread: Re: Trusting and testing unknown (or unfamiliar) executables
- Index(es):