Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / April 2006

Tip: Looking for answers? Try searching our database.

copy protection / IP protection

Thread view: 
g - 18 Apr 2006 03:46 GMT
Hello,

I need to build a WAR/JAR that will need to fulfil the following
requirements:

1. The code will only work for a trial period (30 days)
2. The code can be unlocked with a key
3. Unlocking the code will watermark the WAR/JAR with a unique key

I do not want to reinvent the wheel and would love to hear from other
folks that have experience with this type of packaging. Are there any
off-the-shelf solutions?

Cheers,
Godfrey Hobbs

blog: http://blogs.ebusiness-apps.com/godfrey/
Luc The Perverse - 18 Apr 2006 05:14 GMT
> Hello,
>
[quoted text clipped - 8 lines]
> folks that have experience with this type of packaging. Are there any
> off-the-shelf solutions?

Keep in mind you will likely be limited by the system clock - your app won't
know if the time has been tampered with.

It wouldn't be hard to encrypt a single vital class and then have it loaded
with a class loader.

Keep in mind that marking the JAR file as "Activated" will leave the system
open to simply copying the activated JAR file.

I'm not familiar with off the shelf products for this - but I imagine that
trying to keep it strictly non platform dependant would inhibit your ability
to copy protect.  You might want to consider special cases for the most
likely platforms to be pirated.  Many windows Apps hide a special key deep
in the registry.

--
LTP

:)
Oliver Wong - 18 Apr 2006 20:27 GMT
>> Hello,
>>
[quoted text clipped - 11 lines]
> Keep in mind you will likely be limited by the system clock - your app
> won't know if the time has been tampered with.

   To mitigate against this, the app could store (perhaps within the
encrypted class file) the current time at reasonable intervals, and if it
detects "going backwards in time", to assume the user is doing something
illegal and act accordingly.

> It wouldn't be hard to encrypt a single vital class and then have it
> loaded with a class loader.

   Except to decrypt it, you'd have to store the key somewhere within the
JAR, and a sufficiently intelligent hacker could find that key and defeat
your system. This might not be too difficult since, for example, you could
use the Eclipse debugger to step through the JAR and see what's going on
(and the contents of all variables, for examples).

> Keep in mind that marking the JAR file as "Activated" will leave the
> system open to simply copying the activated JAR file.

   I think the OP already took this into consideration, which is why the
activation key should watermark the JAR (so that the company can track down
the source of the leak).

> I'm not familiar with off the shelf products for this.

   Me neither. I only have theoretical knowledge on the topic, nothing
practical. Sorry.

   - Oliver
Lasse Reichstein Nielsen - 18 Apr 2006 23:19 GMT
>     Except to decrypt it, you'd have to store the key somewhere within
>     the JAR, and a sufficiently intelligent hacker could find that key
>     and defeat your system.

A sufficiently intelligent hacker can defeat any system that can run
standalone once.

If the key is stored in the jar file, and it is digitally signed, then
the key itself could be used as the "brand" of an activated version.

The signed key file must then contain enough information to identify
it, and could also contain an expirery date (so the 30 day trial period
would just be a normal key that expires).

Again, a sufficiently intelligent hacker will be able to reverse
engineer the class that checks the signature (or does whatever check
or decryption that is not necessary to the functionality of the
program) and create a functionally identical one without that check.
It's the curse of any program that doesn't communicate with a server,
it's impossible to prevent it being cracked. That's why people usually
settle for "hard", not "impossible".

/L
Signature

Lasse Reichstein Nielsen  -  lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
 'Faith without judgement merely degrades the spirit divine.'

Roedy Green - 19 Apr 2006 00:04 GMT
>A sufficiently intelligent hacker can defeat any system that can run
>standalone once.

You can make cracking considerably harder if you insist on an online
connection at least to start the app.

That makes it much harder to do experiments without being detected,
and allows you to change the rules as often as you please.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Luc The Perverse - 19 Apr 2006 00:10 GMT
>>A sufficiently intelligent hacker can defeat any system that can run
>>standalone once.
[quoted text clipped - 4 lines]
> That makes it much harder to do experiments without being detected,
> and allows you to change the rules as often as you please.

As Microsoft has discovered and employed.

--
LTP

:)
James McGill - 19 Apr 2006 02:21 GMT
> As Microsoft has discovered and employed.

Hi!  We consider you and your employees to be thieves!  That said, we
also think we have enough market force to make you forget about that and
buy our product anyway!  
Roedy Green - 19 Apr 2006 03:15 GMT
On Tue, 18 Apr 2006 18:21:47 -0700, James McGill
<jmcgill@cs.arizona.edu> wrote, quoted or indirectly quoted someone
who said :

>Hi!  We consider you and your employees to be thieves!  That said, we
>also think we have enough market force to make you forget about that and
>buy our product anyway!  

First of all it is statistically most likely true that you and your
employees are thieves.  People don't buy software if they can steal
it. They don't consider it stealing since they don't deprive others of
use.

It is legit to prevent theft so long as you don't inconvenience
legitimate users.  Microsoft has gone to extreme lengths so antagonise
honest  users making backup/restore impossible without a full
reinstall from scratch (similarly for migrating an app to a different
drive, or upgrading a hard disk.)

Second, just because I have a lock on my door does not mean I believe
everyone who comes to it intends me harm.   Even if only one in 10,000
does, you still need the lock.  For software, you would not need the
lock if only 1 in 100 stole, since you are not actively harmed, just
deprived of potential revenue by a theft.

There is a ratio of about 15,000 to 1 downloads to shareware
registrations if the registration is purely voluntary, with no
hobbling.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

James McGill - 19 Apr 2006 03:33 GMT
> First of all it is statistically most likely true that you and your
> employees are thieves.  

Perhaps, but that doesn't make it a good opener for your sales pitch.
Luc The Perverse - 19 Apr 2006 04:06 GMT
>> First of all it is statistically most likely true that you and your
>> employees are thieves.
>
> Perhaps, but that doesn't make it a good opener for your sales pitch.

Well they have done a good job of marketing it.

And yes - most of us are thieves - and I stopped being a thief because I was
afraid of Microsoft and didn't like hacks and stuff.  It worked - and they
have probably directly gained from me.

--
LTP

:)
James McGill - 19 Apr 2006 04:14 GMT
> Well they have done a good job of marketing it.

Only the biggest players get away with it.  It's not a strategy that can
be generally adopted with any expectation of success.
Luc The Perverse - 19 Apr 2006 05:04 GMT
>> Well they have done a good job of marketing it.
>
> Only the biggest players get away with it.  It's not a strategy that can
> be generally adopted with any expectation of success.

Perhaps not, but the little guy has a hard enough time just getting people
to believe his/her product is worthwhile.   I hardly doubt that many people
would be returning the product if they found out it needed to be activated
after they had already paid money for it.

And if it is a shareware package as was suggested by the OP - the
registration/activation could be transparently integrated with purchasing.

--
LTP

:)
James McGill - 19 Apr 2006 05:25 GMT
> I hardly doubt that many people
> would be returning the product if they found out it needed to be
> activated
> after they had already paid money for it.

I'm a real world example of the problem.  I am a musician with a home
recording studio.  And I completely refuse to do business with certain
of the big players in the audio software business because their copy
protection schemes place me in the untenable position of putting more
importance on THEIR copyrights than on my OWN.  There are circumstances
with software licensing that I cannot enter into.  These companies have
their products being flagrantly distributed, after they have taken such
draconian measures as to alienate their own market.  The irony seems to
be toally lost on the vendors.
Luc The Perverse - 19 Apr 2006 05:56 GMT
>> I hardly doubt that many people
>> would be returning the product if they found out it needed to be
[quoted text clipped - 10 lines]
> draconian measures as to alienate their own market.  The irony seems to
> be toally lost on the vendors.

The cards are stacked against vendors, especially small time vendors who
rely on word of mouth.

It reminds me of the napster days when all the music pirates were chanting
that they wouldn't buy CDs from groups that didn't support file sharing.
Irony indeed!

--
LTP

:)
Roedy Green - 19 Apr 2006 00:50 GMT
On Tue, 18 Apr 2006 23:04:56 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :

>That makes it much harder to do experiments without being detected,
>and allows you to change the rules as often as you please.

It makes it harder for the hacker to do experiments and allows the
vendor to change the copy protection scheme as often as he pleases.

Aspect programming might be a way of weaving the copy protection
through everything so there is not one easy code point to defang.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

g - 19 Apr 2006 07:28 GMT
Hello,

I like the idea of using Aspect Orient programming: AOP.

I am also considering the following:

The trial software ships with a 1 in 4 chance of working incorrectly
(say an infinite loop 25% of the time!).  The only way to remove this 1
in 4 chance "feature" is by adding more code.

1 in 4 chance:
Say there are 1000 lines of code.  It may be possible to weave 1000
points that each one having a 1 in 4000 chance of breaking.  So the
code breaks everywhere not just in one place.

Basically the target software will sell for $200 bucks.  If it cost
more than $200 bucks to hack then most folks will realize it is in
there interest to pay the $200 bucks.

Cheers,
G

> On Tue, 18 Apr 2006 23:04:56 GMT, Roedy Green
> <my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
[quoted text clipped - 11 lines]
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green - 19 Apr 2006 07:37 GMT
>Basically the target software will sell for $200 bucks.  If it cost
>more than $200 bucks to hack then most folks will realize it is in
>there interest to pay the $200 bucks.

That's not how it works.  Someone hacks it just for fun and puts it up
for free download on various pirate sites.

My idea to solve this is to stop selling software and instead to rent
it. Then you can change it every day if you want, and the pirates have
a moving target.  By making people continually check in, you can keep
tabs on the size of the piracy problem and don't waste time on extreme
measures until they are needed.

I used a variant of this with a client who was very bad about paying
his bills. I had the password  set to automatically change about 2
months after I had installed a new custom version for them.  When they
paid, I told them the new password.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Luc The Perverse - 20 Apr 2006 01:39 GMT
> I used a variant of this with a client who was very bad about paying
> his bills. I had the password  set to automatically change about 2
> months after I had installed a new custom version for them.  When they
> paid, I told them the new password.

ROFL!

--
LTP

:)
James McGill - 19 Apr 2006 02:15 GMT
> >     Except to decrypt it, you'd have to store the key somewhere within
> >     the JAR, and a sufficiently intelligent hacker could find that key
> >     and defeat your system.
>
> A sufficiently intelligent hacker can defeat any system that can run
> standalone once.

Real copy protection involves punitive terms in the lease contract and a
stipulationt that no one shall have physical access to the system except
while accopmained by your representative.

Fortunately that scenario more or less ended when the mainframe/leased
datacenter stopped being the norm.  Unfortunately, we still find people
who seriously desire the benefits of that model, but have no way to
deploy such a thing.  

Now in the contemporary scenario, to have your cake and eat it too, you
must compromise.  You want to allow people to anonymously obtain and use
your software (have your cake).  You also want to limit their use
through some form of cryptographic protection scheme.  So you have to
give them a key.  Maybe you can go old-school, and give a field agent
some key that will boot the system, but will not be disclosed to the
customer.  Or maybe you can do it like Microsoft does and force the
system to call home and get a one-way hash based on hardware parameters
or something like that.  Or maybe you can use a dongle like ILok.  

If you don't do something like this, then you have to give the customer
the key (eat it too).  Sure, you might be able to hide it.  Very
intelligent attempts have been made, and failed.  The bottom line is,
either you give the customer the unlock key, and take the risk that it
will be discovered, or you keep the key, and take on the expense and
complexity of managing that relationship.  

In the old days, when the equipment was leased from Unisys or IBM, and
simply would not be operated without the contractor present, it might
have been possible to control distribution, at least to the extent you
could trust your employees. Likewise, in a military scenario, you can
control distribution, because you can make it a crime for which the last
person who knew or should have known that the disclosure would be made,
can be executed for treason or whatever.

I suppose there are less extreme cases for which you must make a
due-diligence effort to put some kind of controls in place, but I
personally do not prefer illusory security to no security.

An example.  I had a lock on the security screen door, the outer front
door to my house, which would sometimes not lock.  It looked like it
locked, but sometimes you could turn the inner barrel without a key.  
I found this to be inferior security to simply removing the lock.
Opinions vary on this, but I stand by mine.
Roedy Green - 19 Apr 2006 03:18 GMT
On Tue, 18 Apr 2006 18:15:11 -0700, James McGill
<jmcgill@cs.arizona.edu> wrote, quoted or indirectly quoted someone
who said :

> It looked like it
>locked, but sometimes you could turn the inner barrel without a key.  
>I found this to be inferior security to simply removing the lock.
>Opinions vary on this, but I stand by mine.

I can see someone deterred, discouraged by the dummy lock, not
bothering to try.  Under what circumstances would no lock at all be
superior to that?  Is the attacker supposed to presume there must then
be some much more serious device installed?

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

James McGill - 19 Apr 2006 03:35 GMT
> Under what circumstances would no lock at all be
> superior to that?  

I did not rest assured that the door appeared to be locked, even though
I knew the lock was defective.  It wasn't the only lock on the house,
otherwise it would have been *an emergency*.  As it happened, with the
lock removed, I did not have any excuse to pretend the door was locked,
but since it was a relatively minor risk, I could take a day or two
before going to the hardware store.

Had I left the defective lock on there, it might still be there.
Luc The Perverse - 19 Apr 2006 04:10 GMT
>> Under what circumstances would no lock at all be
>> superior to that?
[quoted text clipped - 7 lines]
>
> Had I left the defective lock on there, it might still be there.

I'm sorry but I think you are taking the simile a bit too far.

Some hacked copies of software are generally considered acceptable.
However, the security of a house being compromised seems a little more
serious

--
LTP

:)
James McGill - 19 Apr 2006 05:28 GMT
> I'm sorry but I think you are taking the simile a bit too far.
>
> Some hacked copies of software are generally considered acceptable.
> However, the security of a house being compromised seems a little
> more
> serious

I don't even know about that.  I lived for many years in a boarding
house that never had the front door locked.  The security was
encapsulated in the understanding that one of the large, angry, punkass
bikers that lived in the house would pretty much literally kill anybody
who didn't belong there.  People were coming and going constantly, but
you'd have to be a suicidal fool to try to rob the place.  
Bent C Dalager - 19 Apr 2006 09:24 GMT
>Real copy protection involves punitive terms in the lease contract and a
>stipulationt that no one shall have physical access to the system except
>while accopmained by your representative.

You can get real copy protection if you can control the hardware (and
the user can not control the hardware). While denying physical access
is one way of going about it, it is not the only one. For a while now,
dongles have been used (e.g. I/O port based or using CDs as dongles)
but they have generally been too passive to provide the same level of
protection.

You _can_ get that protection now by shipping your software on a smart
card. Put some of the most important or most sensitive algorithms on a
smart card, require your customer to have a card reader and even if he
copies the PC-based part of your software, he'll be missing all the
juicy bits. (The PC-based part will mostly be a customized Eclipse
distro or somesuch framwork anyway.)

Obviously, most people don't have smart card readers so this isn't
workable for consumer software yet. And it remains to be seen if
today's consumers are as put off by physical dongles as people used to
be. It is, nevertheless, a very effecient way of protecting your
software.

Eventually, smart card technology might get integrated on the media
itself, removing the hassle of an extra dongle. Of course, by this
time, such media might be competing against a market based on
downloading applications :-)

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Luc The Perverse - 20 Apr 2006 01:37 GMT
> You can get real copy protection if you can control the hardware (and
> the user can not control the hardware). While denying physical access
[quoted text clipped - 23 lines]
> Cheers
> Bent D

I think dongles suck.  Most people think dongles suck.  Dongles have a
terrible track record.

HD-DVDs have a unique approach - secure encryption that is never decoded on
the computer.  It has to travel encrypted to the monitor where it is
decoded.   This means we will need special video cards and special monitors.

I'm sure a similar approach could be made for computers, but there is a
problem when you need to take away the ability of the OS to see what code is
being run, what the registers are etc.  Virus checkers need to be able to
watch that stuff, system debuggers need to look.

What I'm afraid of is that Microsoft will use DRM to gain massive market
control, not afraid of being a black box.   They could have a zero profit
program to deploy tools for dongles and hardware based DRM with on chip
(Intel and AMD) systems.  Make creating DRM apps almost completely painless,
give people a way to upgrade their systems to run DRM code (a low voltage
PCI card DRM coprocessor, albeit inefficient would work)  History will
repeat itself, tens of millions (more?) of extra OS copies will be sold
because all the cool games and apps are being released DRM.   It will take
about 4 years for an opposition to mount and their influence will be
minimal.

--
LTP

:)
Roedy Green - 20 Apr 2006 02:02 GMT
On Wed, 19 Apr 2006 18:37:32 -0600, "Luc The Perverse"
<sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly
quoted someone who said :

> It has to travel encrypted to the monitor where it is
>decoded.   This means we will need special video cards and special monitors.

this sounds like a variant of my "dark room" idea. See
http://mindprod.com/jgloss/darkroom.html
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Luc The Perverse - 20 Apr 2006 03:56 GMT
> On Wed, 19 Apr 2006 18:37:32 -0600, "Luc The Perverse"
> <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly
[quoted text clipped - 6 lines]
> this sounds like a variant of my "dark room" idea. See
> http://mindprod.com/jgloss/darkroom.html

Wow!   I had thought about public key encryption with embedded keys on the
processor, but you have thought about it a lot more it would seem!

As RSA is vulnerable to quantum computing, I believe a standard like NTRU
will come forward.   (NTRU seems like the only reasonable competitor to RSA
which is not vulnerable to Quantum Computing.)   I have long since predicted
Microsoft will be buying NTRU, if another big company doesn't beat them to
it.   NTRU isn't doing anything with their patents except making me unable
to use their products in shareware that I might otherwise write.

--
LTP

:)
Roedy Green - 20 Apr 2006 06:52 GMT
On Wed, 19 Apr 2006 20:56:59 -0600, "Luc The Perverse"
<sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly
quoted someone who said :

>As RSA is vulnerable to quantum computing, I believe a standard like NTRU
>will come forward.

Imagine the havoc the day it is announced public key and many other
cryptographic systems are now vulnerable.   People will be glad they
used one  time pads for anything that has to stay secret.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Oliver Wong - 20 Apr 2006 15:40 GMT
> Imagine the havoc the day it is announced public key and many other
> cryptographic systems are now vulnerable.   People will be glad they
> used one  time pads for anything that has to stay secret.

   Except for those who encrypted their one time pads with their
private/public key pairs.

   - Oliver
Monique Y. Mudama - 20 Apr 2006 18:06 GMT
> On Wed, 19 Apr 2006 20:56:59 -0600, "Luc The Perverse"
><sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly
[quoted text clipped - 6 lines]
> cryptographic systems are now vulnerable.   People will be glad they
> used one  time pads for anything that has to stay secret.

All security methods are matters of degree.  They're all crackable.
So you have 4zillion bit encryption -- it doesn't help if the machine
on which you're typing the password has a keystroke sniffer.

Etc.

Signature

monique

Help us help you:
http://www.catb.org/~esr/faqs/smart-questions.html

Bent C Dalager - 20 Apr 2006 09:53 GMT
>HD-DVDs have a unique approach - secure encryption that is never decoded on
>the computer.  It has to travel encrypted to the monitor where it is
>decoded.   This means we will need special video cards and special monitors.

Once trusted computing has made its way through the entire hardware
chain, you will have this. The customer's computer will then take over
the function of the smart card in my description. Effectively, the
owner of the computer is denied access to his computer's internals and
so the software developer can trust that computer not to make
unauthorised copies of the software.

The major difference is that smart cards are here today while a fully
trusted hardware chain is a way off yet.

>I'm sure a similar approach could be made for computers, but there is a
>problem when you need to take away the ability of the OS to see what code is
>being run, what the registers are etc.  Virus checkers need to be able to
>watch that stuff, system debuggers need to look.

Virus checkers (well, the big ones) will have the certificates
necessary to be given permission to look so this isn't a technical
problem. The OS will be the most trusted software on the computer,
most likely, and so will be able to look around quite a bit. It won't
trust the user though, so the OS cannot be used to make unauthorised
copies of software.

Users won't need system debuggers.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Monique Y. Mudama - 20 Apr 2006 18:04 GMT
>>HD-DVDs have a unique approach - secure encryption that is never
>>decoded on the computer.  It has to travel encrypted to the monitor
[quoted text clipped - 10 lines]
> The major difference is that smart cards are here today while a
> fully trusted hardware chain is a way off yet.

The more I know about the direction computing is going, the more I
think that Luddites have a point.

Signature

monique

Help us help you:
http://www.catb.org/~esr/faqs/smart-questions.html

Bent C Dalager - 20 Apr 2006 19:49 GMT
>The more I know about the direction computing is going, the more I
>think that Luddites have a point.

It shall be interesting to see if the market will accept trusted
computing or if it will reject it in disgust. The current DRM struggle
might give some indication of this.

Once people realise that the "trust" in "trusted computing" really
means that your computer will be programmed not to trust you, perhaps
they will decide this is not for them.

And if trusting computing does successfully enter commercial
mainstream, it shall be interesting to see if non-trusted computing
(presumably mostly represented by open source projects), unfettered by
the barriers to entry represented by trusted computing, will outpace
it in terms of innovation and quality.

Cheers,
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Oliver Wong - 20 Apr 2006 20:23 GMT
> And if trusting computing does successfully enter commercial
> mainstream, it shall be interesting to see if non-trusted computing
> (presumably mostly represented by open source projects), unfettered by
> the barriers to entry represented by trusted computing, will outpace
> it in terms of innovation and quality.

   Note though that there exists some important figures in the open source
community who are not opposed to implementing DRM into their software (Linus
Torvald is one example, or so I've heard).

   - Oliver
Bent C Dalager - 20 Apr 2006 20:40 GMT
>> And if trusting computing does successfully enter commercial
>> mainstream, it shall be interesting to see if non-trusted computing
[quoted text clipped - 5 lines]
>community who are not opposed to implementing DRM into their software (Linus
>Torvald is one example, or so I've heard).

I am aware of this, but I don't believe it has much negative impact on
non-trusted competitiveness. If anything, it is likely to augment it
since it means Linux would remain a viable platform for both trusted
and non-trusted software and so there wouldn't necessarily be much
brain-drain from non-trusted to trusted development projects.

What impact this all will have on GNU software and developers'
interest in the GNU license (v3) remains to be seen of course. This
could go either way: trusted computing is likely to be a strongly
polarizing influence on the copyleft vs open source debate. A lot of
people are likely to jump off the fence on one side or the other.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Luc The Perverse - 20 Apr 2006 21:08 GMT
>> And if trusting computing does successfully enter commercial
>> mainstream, it shall be interesting to see if non-trusted computing
[quoted text clipped - 5 lines]
> community who are not opposed to implementing DRM into their software
> (Linus Torvald is one example, or so I've heard).

I don't doubt this.  But I do not think Linux supporting DRM will be quite
the same as Microsoft shoving it down everyone's throats.

--
LTP

:)
Luc The Perverse - 20 Apr 2006 21:07 GMT
> Virus checkers (well, the big ones) will have the certificates
> necessary to be given permission to look so this isn't a technical
> problem. The OS will be the most trusted software on the computer,
> most likely, and so will be able to look around quite a bit. It won't
> trust the user though, so the OS cannot be used to make unauthorised
> copies of software.

I'm sorry - I cannot imagine how this would work.

Now something I can imagine is a signing authority for software which
ensures that it is safe.  All DRM software has to be digitally signed by a
trusted source, OR it can be non DRM and be virus scanned.

--
LTP

:)
Bent C Dalager - 20 Apr 2006 21:44 GMT
>> Virus checkers (well, the big ones) will have the certificates
>> necessary to be given permission to look so this isn't a technical
[quoted text clipped - 7 lines]
>Now something I can imagine is a signing authority for software which
>ensures that it is safe.

Which, presumably, is how this will work :-)

Except it doesn't ensure that a piece of software is "safe", but that
it is "trusted".

>  All DRM software has to be digitally signed by a
>trusted source, OR it can be non DRM and be virus scanned.

I believe this confuses the issue somewhat.

There will not be much need for DRM software as such in a trusted
hardware chain. In stead, pieces of software are either trusted or
they are not. Non-trusted software will not be given access to data
marked as protected, while trusted software will.

A properly signed virus scanner will be trusted and so will be given
access to the data it needs to scan applications for viruses.

On Windows, it is likely that decisions of trust are mainly handled by
the OS (with wary hardware looking over its shoulder) and that trust
certificates etc. are organized and distributed in cooperation with
Microsoft.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Luc The Perverse - 20 Apr 2006 23:43 GMT
> A properly signed virus scanner will be trusted and so will be given
> access to the data it needs to scan applications for viruses.

I'm sorry but I guess I have to disagree with you.  Trusted software cannot
see each other, or else you will eventually have a corrupt application get
signed and extract runnable code from all products using the DRM.    I don't
think the OS will be able to see or interact directly with the program
either.   In exchange though, the software won't be able to directly
interact with the OS either (in the same way java byte code interacts with
the JVM), except that in this case the virtual machine is actually a
separate core on the processor.

The program wouldn't have to be deliberately corrupt, let's say that there
are 5000 encrypted DRM programs out there and one of them was owned by a
crappy garage company which goes out of business.  As their dying act they
make all of their code open source and publish it - but the original signed
encrypted copies still exist and can be purchased on eBay - so some hackers
buy it, and use the open source code to gain access to the black box in the
CPU by exploiting security holes in the product.  Then because the CPU will
give up everything as soon as the certificates match, they can purchase
every DRM protected piece of code out there and extracted the code, and
begin selling it illegally.  Once you have the disassembly after all, it is
pretty easy to make hacks - it happens all the time.   So I think, by
example, allowing signed authorities to see each other's data doesn't make
much sense.

I feel the same way about online transactions.  I purchase from newegg and
they are signed by a believed secure company called verisign.   However, I
would be seriously pissed if I found out that every company that has a
certificate with verisign could see my credit card and other info.  It's the
same scenario - just in reverse.  Companies will not pay to have their
software protected if it isn't going to be protected at all.

--
LTP

:)
Bent C Dalager - 21 Apr 2006 00:30 GMT
>> A properly signed virus scanner will be trusted and so will be given
>> access to the data it needs to scan applications for viruses.
>
>I'm sorry but I guess I have to disagree with you.  Trusted software cannot
>see each other, or else you will eventually have a corrupt application get
>signed and extract runnable code from all products using the DRM.

You will always have this risk. Trusted software can be buggy, as can
trusted hardware. The main risk is that some vendors (both software
and hardware) will deliberately build in back doors, as we see with
region free DVD players etc.

Anyway, chances are there will be several levels of trust that a piece
of software can have. They can go completely wild with this, of
course, but it's a safe bet that a music player will need much lower
level of trust than what a virus scanner will. The buggy music player
may only let the user copy music (perhaps) while a buggy virus scanner
can be a lot more problematic.

The level of trust required by the virus scanner makes it probable
that this functionality will primarily be part of the OS anyway.

>The program wouldn't have to be deliberately corrupt, let's say that there
>are 5000 encrypted DRM programs out there and one of them was owned by a
[quoted text clipped - 9 lines]
>example, allowing signed authorities to see each other's data doesn't make
>much sense.

When this was known to have happened, the certificates of the cracked
software would be revoked, making it problematic for the general
public to use it: Once they find a need to upgrade/patch their
computer (or just connect to the Internet), the OS will download the
revocation list and automatically reject the suspect software.
Legitimate purchasers will get it back in working order again on the
next product update. (Which may be tied to their CPU's certificate or
some other unique, personal identification.)

Warez groups could still use it to make non-protected versions of
older music/movies/software/etc but no new releases could be accessed
with the revoked certificates. Much warezed software would be
particularly useless since it wouldn't have the certificates necessary
to access a lot of media or hardware on an up-to-date system. And
there will be reasons for people to want their systems to be up to
date.

Also, Microsoft would be unlikely to give a crappy garage company the
licenses it needs to access other applications at its whim. Symantec
could get this, but Snakeoil Intl. wouldn't. Vulnerabilities would
tend to be less broad - perhaps affecting a media player or somesuch.

>I feel the same way about online transactions.  I purchase from newegg and
>they are signed by a believed secure company called verisign.   However, I
>would be seriously pissed if I found out that every company that has a
>certificate with verisign could see my credit card and other info.  It's the
>same scenario - just in reverse.  Companies will not pay to have their
>software protected if it isn't going to be protected at all.

It will be protected, but that's not really the point of the
software's certificate(s). The certificate is something that gives the
software privileges it otherwise would not have. If it wants to play
protected music, it may have certificates that allow it to do this. In
order to get this, it might have to negotiate with Sony or some
consortium for a certificate to read the media and with Microsoft for
a certificate that gives permission to stream it through the OS to
appropriate outputs.

Alternatively, if both the CD reader and the speakers are trusted and
the player software doesn't need to do anything fancy to the music, it
could just tell the OS to "stream media from CD to speakers" and it
would all happen through a trusted channel without any protected media
passing through the player software at all. This software may not need
any certificates since it isn't direcly touching anything that is
protected.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Roedy Green - 21 Apr 2006 02:45 GMT
>The level of trust required by the virus scanner makes it probable
>that this functionality will primarily be part of the OS anyway.

MS put the guts of defraggers in the OS.  Defragger manufacturers
compute on the UI and the ordering algorithms. But the tricky stuff is
all done by the OS.  It might even be that defraggers never even see
the contents of any files anymore.

You could handle virus scanners the same way.  The virus software just
provides the patterns to look for. or provides code that runs in a box
without access to any OS services or outside world contact, just a
boolean return.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Roedy Green - 21 Apr 2006 05:16 GMT
On Fri, 21 Apr 2006 01:45:12 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :

>MS put the guts of defraggers in the OS.  Defragger manufacturers
>compute on the UI

oops "compete" on the UI.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Luc The Perverse - 21 Apr 2006 06:06 GMT
>>The level of trust required by the virus scanner makes it probable
>>that this functionality will primarily be part of the OS anyway.
[quoted text clipped - 8 lines]
> without access to any OS services or outside world contact, just a
> boolean return.

It's the same thing - you allow programs to access directly or indirectly
the code inside the black box and it can be extracted in entirety.

I could make a function which uses a search function to decode a string.
In fact it would be pretty easy.  Make a fake virus scanner - Start with one
byte, if it is not found search for another byte, now build the byte string
backwards until you can't add any more characters, then build it forward
until you have reconstructed the unknown string - that string, in this
instance is the program, function or media desired.  It might be a little
more difficult if you get false positives, but I think that algorithm would
work.

--
LTP

:)
Roedy Green - 21 Apr 2006 21:05 GMT
On Thu, 20 Apr 2006 23:06:04 -0600, "Luc The Perverse"
<sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly
quoted someone who said :

>I could make a function which uses a search function to decode a string.
>In fact it would be pretty easy.  Make a fake virus scanner - Start with one
>byte, if it is not found search for another byte, now build the byte string
>backwards until you can't add any more characters, then build it forward
>until you have reconstructed the unknown string - that string, in this
>instance is the program, function or media desired

My idea though is to isolate that code so that even if it does snoop,
it can't tell anyone what it found. Normally the snoop for example
would hide the information  it found on disk somewhere, or squirrel it
away in RAM or CMOS, or emit a packet to the Internet. It would run in
a very restricted sandbox.

Since you are to die Mr. Bond, I can tell you my secret plan to
destroy planet earth...
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Chris Uppal - 21 Apr 2006 09:45 GMT
> [...] but it's a safe bet that a music player will need much lower
> level of trust than what a virus scanner will. The buggy music player
> may only let the user copy music (perhaps) while a buggy virus scanner
> can be a lot more problematic.

I don't see where virus scanners fit into this picture at all.  If all the
executable software is signed-and-sealed, what would the virus vector be ?

The only one /I/ can think of is the old evil-macro style of malware.  If there
are any applications which execute code which isn't machine code (which contain
script languages in some broad sense) then the scanner can look for infections
in their data files without special privileges.  If the data could contain
malware, but is not accessible with "normal" privileges then how did the
malware got into it in the first place ?

[re: cracked priveleged apps]
> When this was known to have happened, the certificates of the cracked
> software would be revoked, making it problematic for the general
> public to use it: Once they find a need to upgrade/patch their
> computer (or just connect to the Internet), the OS will download the
> revocation list and automatically reject the suspect software.

I can't really see this.  I think the kind of "computer" we are talking about
here would no longer be the general purpose computation device that we are used
to (and love), but an /appliance/.  It would have certain abilities built into
it, but would have little or no support for field update.  Certainly no support
for updates by the /user/.  This is the approach that MS are currently
experimenting on with X-Box.

   -- chris
Bent C Dalager - 21 Apr 2006 11:31 GMT
>I don't see where virus scanners fit into this picture at all.  If all the
>executable software is signed-and-sealed, what would the virus vector be ?

I am sure they will think of _something_ :-)

>The only one /I/ can think of is the old evil-macro style of malware.  If there
>are any applications which execute code which isn't machine code (which contain
>script languages in some broad sense) then the scanner can look for infections
>in their data files without special privileges.  If the data could contain
>malware, but is not accessible with "normal" privileges then how did the
>malware got into it in the first place ?

Some applications would presumably be able to process both protected
data and unprotected data from general sources (e.g. the
Internet). Let's say a trusted web browser that can play protected
music files and it can display any old JPG from the net. The JPG could
contain a buffer overflow exploit that compromises the web browser,
perhaps storing its virus code within the browser's configuration
data.

While you may find it difficult to compromise an application's binary
file without compromising the OS itself, this could certainly be
possible. Let's say that the browser you compromised turns out to be
an intregral part of the OS and that this effectively lets you access
application binaries through system calls. You might know of a
specific application whose certificate you have cracked by some means
or other and you can then modify this application to contain your
virus code.

>[re: cracked priveleged apps]
>> When this was known to have happened, the certificates of the cracked
[quoted text clipped - 9 lines]
>for updates by the /user/.  This is the approach that MS are currently
>experimenting on with X-Box.

I am not sure what you mean by "updates by the user".

I do not have an X-Box, but I do have a PSP and it is quite clear that
Sony is doing what it can to lock down the hardware and prevent me
from installing anything that is not Sony-approved. Bugs aside, this
is a strategy that could certainly work quite well. I won't be able to
do all that I would have liked to with the hardware, of course, but I
will be able to install new software on it so long as it has Sony's
approval. In this sense, the user can update it in the field.

It is likely that a trusted PC will be a little less strict than this
and that it will provide some sort of sandbox mode for untrusted
software, meaning that as a user I probably _could_ install anything I
wished. Of course, non-trusted software might not have the
capabilities that trusted software would, but them's the breaks.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Luc The Perverse - 21 Apr 2006 08:00 GMT
>>I don't see where virus scanners fit into this picture at all.  If all the
>>executable software is signed-and-sealed, what would the virus vector be ?
>
> I am sure they will think of _something_ :-)

Well sure!  You can scan the stuff going into the black box - just not the
box itself!

--
LTP

:)
Roedy Green - 21 Apr 2006 21:15 GMT
>>I don't see where virus scanners fit into this picture at all.  If all the
>>executable software is signed-and-sealed, what would the virus vector be ?
>
>I am sure they will think of _something_ :-)

During start up, your computer behaves identically to the way it did
in DOS days. That is one place it is quite vulnerable.  A floppy
accidentally booted from is God.

The key to the virus problem is digitally signing everything, and not
allowing low level access to an executable file, and never running
without checking that its signature has been previously verified.

A virus then has to infect prior to the exe being signed during
development.

That still leaves trojans of all forms.  Now we get to requiring all
developers to submit DNA (their public keys) to the feds so that
computers can makes sure software came from a reputable vendor and
they know who to sue if software causes damage. From a legal point of
view with not that much change to OSes, you could prove whose software
formatted the hard disk, or deleted or overwrote a given file, or
better still keep each vendor inside his own sandbox where he can't
even see the files or registry entries from other vendors.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Jeffrey H. Coffield - 22 Apr 2006 05:27 GMT
>>>I don't see where virus scanners fit into this picture at all.  If all the
>>>executable software is signed-and-sealed, what would the virus vector be ?
[quoted text clipped - 20 lines]
> better still keep each vendor inside his own sandbox where he can't
> even see the files or registry entries from other vendors.

I find your point of view interesting in light of the fact that you are
one of the best sources of programming information around. I have been
supporting business systems for 26 years on computers that have never
had anyone (including myself) figure out how to write a virus for
because the hardware simply does not allow any user program access to
any system memory.

For people who like conspiracy theories, which type of computer would a
hardware vendor want you to buy? One that does everything you need (I
have programs currently running with HTML/Javascript front ends that
were written in 1980 that still work because the business model hasn't
changed) or one that eventually gets so infected with viruses, worms,
spyware, etc. that you just buy a new computer?

Jeff Coffield
Luc The Perverse - 22 Apr 2006 06:54 GMT
> For people who like conspiracy theories, which type of computer would a
> hardware vendor want you to buy? One that does everything you need (I have
> programs currently running with HTML/Javascript front ends that were
> written in 1980 that still work because the business model hasn't changed)
> or one that eventually gets so infected with viruses, worms, spyware, etc.
> that you just buy a new computer?

If I may . . comment on a subset of your post ignoring your specific
question . . .   If not please disregard.

I assume you are alluding to Linux vs Windows or _insert believed superior
operating system here_ vs Windows.

The only thing I really have an objection to is - if you are buying a new
computer instead of just formatting/reinstalling your system that is a very
serious inefficiency - which you might want to address.    And it is
possible to run windows without getting viruses and spyware - typically it
is the user that is installing those things.   (I realize there are some
backdoors but it has never inhibited my ability to use a computer.   The
only virus I have ever gotten is as a result of my own idiocy.)

So maybe the question is - do you want an operating system which protects
you by binding your hands - or an operating system which allows you and your
programs free reign?   It's this free reign in the hands of novices that
causes problems.

--
LTP

:)
Jeffrey H. Coffield - 22 Apr 2006 19:11 GMT
> "Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com> wrote in message

> I assume you are alluding to Linux vs Windows or _insert believed superior
> operating system here_ vs Windows.
[quoted text clipped - 3 lines]
>
> :)

The operating system is OpenVMS. The anti virus capabilities however
come from the correct use of hardware virtual memory management. This
adds a cost to the processor which so far has prevented it's adoption in
end user desktop systems. This is changing as the cost of hardware comes
down. My point is that the solution to all this virus crap is to design
a system that can't get a virus in the first place. Not try to patch up
a flawed architecture with even more flawed software.

What I see as a motivating factor to find a solution to viruses is the
increased awareness by large companies of the vulnerability of servers
that hold personal information, particularly credit cards. The large
credit card companies are slowly taking a more and more firm approach to
security as they are the ones who eat it when a credit card is stolen.
The current security scan that is required not by law, but required by
the credit card companies to do credit card processing on a large scale
was over 11,000 network tests looking for holes. About 1/3 were IIS
holes, 1/3 were PHP holes and the rest were an amazing variety of ways
to trip a server. This caused us to move off Linux/Apache for the front
end to an all OpenVMS system front to back. After the move none of the
attempts were able to successful. Obviously this is only part of a total
solution to a secure environment as there are still DOS attacks that can
effectively take a system off the Internet, physical security of
backups, etc.

Jeff
Luc The Perverse - 23 Apr 2006 04:02 GMT
> The operating system is OpenVMS. The anti virus capabilities however come
> from the correct use of hardware virtual memory management. This adds a
[quoted text clipped - 3 lines]
> that can't get a virus in the first place. Not try to patch up a flawed
> architecture with even more flawed software.
*snip*

I find it hard to believe that the OS is bullet proof.

Let it become the de-facto standard - and someone will find a way to hack
it.   There has to be a buffer overflow somewhere, or a security flaw - some
way to run arbitrary code.  Just not enough people are trying.

--
LTP

:)
Jeffrey H. Coffield - 23 Apr 2006 06:16 GMT
>>The operating system is OpenVMS. The anti virus capabilities however come
>>from the correct use of hardware virtual memory management. This adds a
[quoted text clipped - 16 lines]
>
> :)

A buffer overflow or invalid page on a true hardware virtual memory
system is a hardware exception. In user mode, your program is basically
taken out and shot. An invalid page in kernel mode (which only the
operating system can be at) is an instant kernel crash. The system
reboots. No malicious code is inserted anywhere. Even Windows NT on an
Alpha had some of these abilities. I used a 3D graphics program that
caused a blue screen of death on a Pentium with NT by overwriting the
o/s. But on an Alpha running the same program, an exception was
generated and the program was halted.

OpenVMS has bugs and there are patches. Weak passwords are a problem on
any system. OpenVMS has been around for 30 years and is used in a large
number of banks, insurance companies and stock markets. They have been
prime targets for hacking because of the information they normally
contain. There are problems, just no viruses.

Jeff
Luc The Perverse - 23 Apr 2006 08:38 GMT
>>>The operating system is OpenVMS. The anti virus capabilities however come
>>>from the correct use of hardware virtual memory management. This adds a
[quoted text clipped - 30 lines]
> prime targets for hacking because of the information they normally
> contain. There are problems, just no viruses.

How is software support for it?    Should I consider running an OpenVMS box?

The name would seem to imply it is free.   AH!  It doesn't run on X86.   Wow
Itanium boxes on ebay have come down a lot.

You think it's worthwhile to learn?  I'll tell you one thing, I don't like
the idea of my box getting hacked.  But I have a hard enough time trying to
learn Linux.

--
LTP

:)
Jeffrey H. Coffield - 23 Apr 2006 16:29 GMT
> How is software support for it?    Should I consider running an OpenVMS box?
>
[quoted text clipped - 9 lines]
>
> :)

A short history of VMS:
http://www.reference.com/browse/wiki/Digital_Equipment_Corporation

Unix/Linux/Windoze are all still playing catchup with features available
20 to 25 years ago in VMS. OpenVMS is still too expensive to consider as
 a desktop contender but you get what you pay for. We are moving to
Java front ends for our software with the database and most of the
business logic on a OpenVMS server.

However, I feel this discussion is straying off from the Java topic. If
you would like more info, please contact me directly. For more info on
me see www.digitalsynergyinc.com.

Jeff Coffield
Roedy Green - 22 Apr 2006 07:50 GMT
On Sat, 22 Apr 2006 04:27:00 GMT, "Jeffrey H. Coffield"
<jeffrey@digitalsynergyinc.com> wrote, quoted or indirectly quoted
someone who said :

> I have been
>supporting business systems for 26 years on computers that have never
>had anyone (including myself) figure out how to write a virus for
>because the hardware simply does not allow any user program access to
>any system memory.

what are you referring to?
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Jeffrey H. Coffield - 22 Apr 2006 18:41 GMT
> On Sat, 22 Apr 2006 04:27:00 GMT, "Jeffrey H. Coffield"
> <jeffrey@digitalsynergyinc.com> wrote, quoted or indirectly quoted
[quoted text clipped - 7 lines]
>
> what are you referring to?
My current "PC" is an Alpha running OpenVMS. Alpha system, the previous
Vax systems the newer Itanium running OpenVMS do not allow user programs
to access system memory as they all implement virtual memory in
hardware. A virus has to be able to overwrite some part of the system to
infect it. There simply is no user mode address that corresponds to
system memory. There is no such thing as a buffer overflow allowing
access to memory not allocated to your user process. You would have to
write a device driver and have the system manager install it to gain
access to system memory. It is true that this hardware costs more that a
PC does, but when you factor in the time spent on trying to patch the
problem after the fact with anti virus software that is rendered
obsolete in a matter of hours, crashes etc., they are far cheaper.
System management on 14 systems that have a total of about 30,000
registered users takes me about 1-2 hours/month.

My point is that if a system is designed correctly from the start,
viruses etc. are not a problem. Included is the only OpenVMS virus
scanner (complete source code) I have ever seen.

$ WRITE SYS$OUTPUT "Starting OpenVMS virus scan..."
$ WAIT 00:01:00
$ WRITE SYS$OUTPUT "Virus scan complete. No viruses detected"
Jeffrey H. Coffield - 22 Apr 2006 19:18 GMT
Roedy Green wrote:

> On Sat, 22 Apr 2006 04:27:00 GMT, "Jeffrey H. Coffield"
> <jeffrey@digitalsynergyinc.com> wrote, quoted or indirectly quoted
[quoted text clipped - 6 lines]
>
> what are you referring to?

My current "PC" is an Alpha running OpenVMS. Alpha system, the previous
Vax systems the newer Itanium running OpenVMS do not allow user programs
to access system memory as they all implement virtual memory in
hardware. A virus has to be able to overwrite some part of the system to
infect it. There simply is no user mode address that corresponds to
system memory. There is no such thing as a buffer overflow allowing
access to memory not allocated to your user process. You would have to
write a device driver and have the system manager install it to gain
access to system memory. It is true that this hardware costs more that a
PC does, but when you factor in the time spent on trying to patch the
problem after the fact with anti virus software that is rendered
obsolete in a matter of hours, crashes etc., they are far cheaper.
System management on 14 systems that have a total of about 30,000
registered users takes me about 1-2 hours/month.

My point is that if a system is designed correctly from the start,
viruses etc. are not a problem. Included is the only OpenVMS virus
scanner (complete source code) I have ever seen.

 $ WRITE SYS$OUTPUT "Starting OpenVMS virus scan..."
 $ WAIT 00:01:00
 $ WRITE SYS$OUTPUT "Virus scan complete. No viruses detected"
Timo Stamm - 22 Apr 2006 20:13 GMT
Jeffrey H. Coffield schrieb:
> My point is that if a system is designed correctly from the start,
> viruses etc. are not a problem. Included is the only OpenVMS virus
[quoted text clipped - 3 lines]
> $ WAIT 00:01:00
> $ WRITE SYS$OUTPUT "Virus scan complete. No viruses detected"

Virus scanners for Mac OS X do basically the same. There are zero
viruses or worms in the wild for the platfowm.

But this is not because the system has hardware supported memory
protection or similar features. The installation is pretty secure per
default, but the real reason is market share. Black hats want consumer
machines to create botnets, so they attack the system with the largest
market share.

Timo
Oliver Wong - 25 Apr 2006 17:10 GMT
> A virus has to be able to overwrite some part of the system to infect it.
> There simply is no user mode address that corresponds to system memory.
[quoted text clipped - 3 lines]
> My point is that if a system is designed correctly from the start, viruses
> etc. are not a problem.

   Buffer overflow is a "vector of attack", and isn't directly related to
whether the system is "capable of" viruses or not. Some computer viruses
spread via buffer overflows, and some don't, just like some biological
viruses are airborne, and some need contact with flesh or blood.

   For it to be possible for viruses to exist on a system, all you need is
to allow for a program to generate executables, and the ability to overwrite
other files. If you cannot write a program which generates executables, you
cannot, for example, implement a compiler. If you CAN write a program which
generates executables, and you CAN overwrite other files, then to implement
a virus, all you have to do is write a program which reads in existing
executables, and overwrites them with a new executable which does the same
thing as the original executable, plus the contents of the original virus.

   So for example, let's say I, as a end user, install some virus on my
system. When I run it, the virus might try to infect executables that I
don't have write-access to (e.g. system tools); it'll fail. But then it
might later try to infect executables that I DO have write-access to (for
example, by local install of FireFox, or my mp3 player, or my Fibonacci
sequence generator that I wrote).

   I believe that as long as you have a computer which is Turing Complete,
you can have viruses on that computer. As a very informal proof, you could
imagine a sequence of bits on the tape which instructs the Turing Machine to
make more copies of that same sequence of bits elsewhere on the tape, for
example.

> Included is the only OpenVMS virus scanner (complete source code) I have
> ever seen.
>
> $ WRITE SYS$OUTPUT "Starting OpenVMS virus scan..."
> $ WAIT 00:01:00
> $ WRITE SYS$OUTPUT "Virus scan complete. No viruses detected"

   If I were to optimize this code, would it be safe to assume that the
bottleneck is in the "WAIT" statement, or should I profile to check that
maybe console I/O is particularly slow on this platform?

   - Oliver
Timo Stamm - 21 Apr 2006 12:04 GMT
Bent C Dalager schrieb:
>> The program wouldn't have to be deliberately corrupt, let's say that there
>> are 5000 encrypted DRM programs out there and one of them was owned by a
[quoted text clipped - 17 lines]
> Legitimate purchasers will get it back in working order again on the
> next product update.

What happens if someone finds an exploit in the software while the
company is in business?

Are the certificates revoked? That would very likely put them out of
business.

> Also, Microsoft would be unlikely to give a crappy garage company the
> licenses it needs to access other applications at its whim.

Do you know how most of the big players in IT started? Innovation comes
from the "crappy" garage companies. The industry will stagnate if you
hand the control over to the established companies.

Timo
Chris Uppal - 21 Apr 2006 12:41 GMT
> The industry will stagnate if you
> hand the control over to the established companies.

Agreed, but since when have big players in any industry refrained from actions
that bring them short-term advantage even at the cost of destroying the entire
industry ?

   -- chris
Timo Stamm - 21 Apr 2006 16:55 GMT
Chris Uppal schrieb:

>> The industry will stagnate if you
>> hand the control over to the established companies.
>
> Agreed, but since when have big players in any industry refrained from actions
> that bring them short-term advantage even at the cost of destroying the entire
> industry ?

That's capitalism. Garage companies are no different, they also strive
for short-term advantage, maybe even more than the big players.

Getting rid of competitors is good for a company, but it's bad for the
customers. Just think about Microsoft Visual Studio, which is available
without charge today, mainly because free IDEs like Eclipse are serious
competition. On a Windows Computer with a complete DRM chain, you would
probably be unable to run Eclipse.

Timo
Bent C Dalager - 21 Apr 2006 17:36 GMT
>Getting rid of competitors is good for a company, but it's bad for the
>customers. Just think about Microsoft Visual Studio, which is available
>without charge today, mainly because free IDEs like Eclipse are serious
>competition. On a Windows Computer with a complete DRM chain, you would
>probably be unable to run Eclipse.

I doubt it would be taken quite this far. More likely, every time you
launch Eclipse the OS will show you large animated scare-windows
saying things like "you are trying to start an untrusted application",
"this application may or may not be virus infected" etc.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Luc The Perverse - 21 Apr 2006 08:02 GMT
>>Getting rid of competitors is good for a company, but it's bad for the
>>customers. Just think about Microsoft Visual Studio, which is available
[quoted text clipped - 6 lines]
> saying things like "you are trying to start an untrusted application",
> "this application may or may not be virus infected" etc.

Microsoft tried something similar making several ISP's not work with their
windows 95 operating system mysteriously around the same time the MSN
service appeared.

--
LTP

:)
Bent C Dalager - 21 Apr 2006 14:26 GMT
>What happens if someone finds an exploit in the software while the
>company is in business?
>
>Are the certificates revoked? That would very likely put them out of
>business.

Legitimate customers would have their applications patched through
automatic update, probably before the revocation list is updated. This
should provide a seamless experience for the large majority of people.

>Do you know how most of the big players in IT started? Innovation comes
>from the "crappy" garage companies. The industry will stagnate if you
>hand the control over to the established companies.

This is why I said it should be interesting to see how non-trusted
software projects would fare in a new trusted world. Chances are these
are the projects where you will find the innovation and perhaps even
the quality, but this remains to be seen.

I expect that we are heading into a couple of decades of trial and
error where we will eventually find that wholesale market lockout of
non-approved developers is a really really bad idea. I may be wrong of
course - we will find that out in due time.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Luc The Perverse - 19 Apr 2006 00:09 GMT
>>> Hello,
>>>
[quoted text clipped - 25 lines]
> use the Eclipse debugger to step through the JAR and see what's going on
> (and the contents of all variables, for examples).

You will find this problem with ANY non hardware based solution.

I think the idea is to keep most people honest, not everyone.

I for one would not hesitate to change a registered = NO to registered = YES
in an INI file - but would draw the line at disassembly of the jar file ;)

--
LTP

:)
ducnbyu@aol.com - 18 Apr 2006 21:06 GMT
I googled and found this off the shelf.  Don't know if it meets your
needs.

http://www.chainkey.com/en/
Roedy Green - 19 Apr 2006 05:01 GMT
>1. The code will only work for a trial period (30 days)

see http://mindprod.com/jgloss/dongle.html
http://mindprod.com/jgloss/obfuscator.html

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

ldv@mail.com - 23 Apr 2006 06:39 GMT
> Hello,
>
[quoted text clipped - 8 lines]
> folks that have experience with this type of packaging. Are there any
> off-the-shelf solutions?

If your only target is Windows, consider the following approach:

1. Compile your Java app to native machine code with Excelsior JET
(www.excelsior-usa.com)

2. Use PC Guard (www.sofpro.com) or similar tool to copy protect the
resulting EXE.

(Excelsior JET is also available for Linux, but I have never researched
the availability of copy protection solutions for Linux.)

This way, you would get protection against both Java decompilers and
unauthorized copying.

For details, see also:

http://www.excelsior-usa.com/kb/000023.html
http://www.excelsior-usa.com/forum/index.php?topic=744

LDV


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.