By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,473 Members | 1,274 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,473 IT Pros & Developers. It's quick & easy.

Is VB.NET Code Secure?

P: n/a
Hi Everyone!

I'm new to .NET but I'm a experienced VB programmer (since VB 4) and wanting
to move to VB.NET from VB 6.

But as I read about .NET, I came across that compiled VB.NET code is stored
in MSIL (instead of binary) which is easily decryptable by the "hackers" to
reverse engineer your VB.NET application.

Is this true?

Thanks in advance!

Don
Nov 20 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
* "Don Wash" <do*@wash.com> scripsit:
I'm new to .NET but I'm a experienced VB programmer (since VB 4) and wanting
to move to VB.NET from VB 6.

But as I read about .NET, I came across that compiled VB.NET code is stored
in MSIL (instead of binary) which is easily decryptable by the "hackers" to
reverse engineer your VB.NET application.

Is this true?


Yes.

Nevertheless, you can make their work harder by obfuscating the
code. You will find some links here:

<URL:http://www.cetus-links.org/oo_dotnet.html#oo_dotnet_utilities_tools>

Notice that VS.NET 2003 includes the Light Version of Preemptive's
obfuscator.

BTW: Do you really think that somebody wants to have a look at
the code of /your/ application? What I want to say: Reverse
Engineering often doesn't make much sense, it's "interesting" if there
are some complicated algorithms implemented, but not for most normal
apps.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #2

P: n/a
Thanks for the links Herfried,

Yes, I do think when you are developing a software with your own unique
aglorithm (or even simple applications) competitors can just look up your
code and get the idea where you've scarificied hours and hours of good night
sleep to get the aglorithm and get the app up and running. This is also the
case for simple applications. That's something I don't want :P and I'm sure
most developers will agree with me.

Do you think .NET will become binary in the future?

Don
P.S. This VB.NET newsgroup is damn fast!!! I love it!

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2h************@uni-berlin.de...
* "Don Wash" <do*@wash.com> scripsit:
I'm new to .NET but I'm a experienced VB programmer (since VB 4) and wanting to move to VB.NET from VB 6.

But as I read about .NET, I came across that compiled VB.NET code is stored in MSIL (instead of binary) which is easily decryptable by the "hackers" to reverse engineer your VB.NET application.

Is this true?


Yes.

Nevertheless, you can make their work harder by obfuscating the
code. You will find some links here:

<URL:http://www.cetus-links.org/oo_dotnet.html#oo_dotnet_utilities_tools>

Notice that VS.NET 2003 includes the Light Version of Preemptive's
obfuscator.

BTW: Do you really think that somebody wants to have a look at
the code of /your/ application? What I want to say: Reverse
Engineering often doesn't make much sense, it's "interesting" if there
are some complicated algorithms implemented, but not for most normal
apps.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 20 '05 #3

P: n/a
* "Don Wash" <do*@wash.com> scripsit:
Yes, I do think when you are developing a software with your own unique
aglorithm (or even simple applications) competitors can just look up your
code and get the idea where you've scarificied hours and hours of good night
sleep to get the aglorithm and get the app up and running. This is also the
case for simple applications. That's something I don't want :P and I'm sure
most developers will agree with me.

Do you think .NET will become binary in the future?
No, that's against the concept of .NET. As mentioned before, I would
obfuscate the application, so it's harder to understand the
reconstructed source code.
P.S. This VB.NET newsgroup is damn fast!!! I love it!


A lot of traffic here... ;-).

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #4

P: n/a
But we can get the setup to "compile" the app at installation so after that
the app is as secure as a regular executable?

Thanks

Regards

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2h************@uni-berlin.de...
* "Don Wash" <do*@wash.com> scripsit:
Yes, I do think when you are developing a software with your own unique
aglorithm (or even simple applications) competitors can just look up your code and get the idea where you've scarificied hours and hours of good night sleep to get the aglorithm and get the app up and running. This is also the case for simple applications. That's something I don't want :P and I'm sure most developers will agree with me.

Do you think .NET will become binary in the future?


No, that's against the concept of .NET. As mentioned before, I would
obfuscate the application, so it's harder to understand the
reconstructed source code.
P.S. This VB.NET newsgroup is damn fast!!! I love it!


A lot of traffic here... ;-).

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 20 '05 #5

P: n/a
I wanted to follow up with Herfried on this one. He makes a valid point
about the reverse engineering. Would they actually want to? In most cases
code would be reverse engineered, the "hacker" would look at it and be like
"wtf is this?" Why? Because 1, variable names are not retained with most
decompilers (all I'm pretty sure, as it is a tokenized compiler) So, it may
or may not make much sense.

Second of all, people will look at it and be like "well I can do this better
here." Long story short, it doesn't really happen that much. At least from
what I've seen.

I've decompiled programs before, but mainly to debug an existing application
and notify the author. However, I wouldn't recommend writing oh lets say an
encryption algorithm without obfusicating (hell, I would go to a binary
format instead.)

HTH,
CJ'

"Don Wash" <do*@wash.com> wrote in message
news:OJ**************@TK2MSFTNGP11.phx.gbl...
Thanks for the links Herfried,

Yes, I do think when you are developing a software with your own unique
aglorithm (or even simple applications) competitors can just look up your
code and get the idea where you've scarificied hours and hours of good night sleep to get the aglorithm and get the app up and running. This is also the case for simple applications. That's something I don't want :P and I'm sure most developers will agree with me.

Do you think .NET will become binary in the future?

Don
P.S. This VB.NET newsgroup is damn fast!!! I love it!

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2h************@uni-berlin.de...
* "Don Wash" <do*@wash.com> scripsit:
I'm new to .NET but I'm a experienced VB programmer (since VB 4) and wanting to move to VB.NET from VB 6.

But as I read about .NET, I came across that compiled VB.NET code is stored in MSIL (instead of binary) which is easily decryptable by the
"hackers"
to reverse engineer your VB.NET application.

Is this true?


Yes.

Nevertheless, you can make their work harder by obfuscating the
code. You will find some links here:

<URL:http://www.cetus-links.org/oo_dotnet.html#oo_dotnet_utilities_tools>
Notice that VS.NET 2003 includes the Light Version of Preemptive's
obfuscator.

BTW: Do you really think that somebody wants to have a look at
the code of /your/ application? What I want to say: Reverse
Engineering often doesn't make much sense, it's "interesting" if there
are some complicated algorithms implemented, but not for most normal
apps.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>


Nov 20 '05 #6

P: n/a
"Don Wash" <do*@wash.com> schrieb
But as I read about .NET, I came across that compiled VB.NET code is
stored in MSIL (instead of binary) which is easily decryptable by the
"hackers" to reverse engineer your VB.NET application.

Is this true?


In addition to Herfried..
I think, if somebody is /really/ interested in your code, he will also
decompile assembler code, so the only 100% safe way is not to distribute the
application.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

Nov 20 '05 #7

P: n/a
>
In addition to Herfried..
I think, if somebody is /really/ interested in your code, he will also
decompile assembler code, so the only 100% safe way is not to distribute the application.

Same idea here, are you going to serverside webapplications Armin?

Cor
Nov 20 '05 #8

P: n/a
Don,
You do realize, as Armin stated, that any one who wanted to get your code,
will!

Independent of if it is written in ASM, C++, VB4, VB6, VB.NET or C#!

All computer languages have tools available that can reverse engineer them,
included compiled programs.

I don't have the link handy, my understanding is that the question is not so
much that we need to compile to binary machine code (which is easily
de-compiled or dis-assembled anyway). But the need is for digital
certificates & encryping the assembly, so it cannot be looked by opening the
file, yet can still be looked at to actual execute.

Hope this helps
Jay

"Don Wash" <do*@wash.com> wrote in message
news:OJ**************@TK2MSFTNGP11.phx.gbl...
Thanks for the links Herfried,

Yes, I do think when you are developing a software with your own unique
aglorithm (or even simple applications) competitors can just look up your
code and get the idea where you've scarificied hours and hours of good night sleep to get the aglorithm and get the app up and running. This is also the case for simple applications. That's something I don't want :P and I'm sure most developers will agree with me.

Do you think .NET will become binary in the future?

Don
P.S. This VB.NET newsgroup is damn fast!!! I love it!

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2h************@uni-berlin.de...
* "Don Wash" <do*@wash.com> scripsit:
I'm new to .NET but I'm a experienced VB programmer (since VB 4) and wanting to move to VB.NET from VB 6.

But as I read about .NET, I came across that compiled VB.NET code is stored in MSIL (instead of binary) which is easily decryptable by the
"hackers"
to reverse engineer your VB.NET application.

Is this true?


Yes.

Nevertheless, you can make their work harder by obfuscating the
code. You will find some links here:

<URL:http://www.cetus-links.org/oo_dotnet.html#oo_dotnet_utilities_tools>
Notice that VS.NET 2003 includes the Light Version of Preemptive's
obfuscator.

BTW: Do you really think that somebody wants to have a look at
the code of /your/ application? What I want to say: Reverse
Engineering often doesn't make much sense, it's "interesting" if there
are some complicated algorithms implemented, but not for most normal
apps.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>


Nov 20 '05 #9

P: n/a
An idea like that would have to be implemented at kernel level would it not?
Encrypting the compiled program so that it couldn't be read? But then how
would it be decrypted. The OS right?

That would be a pretty interesting implementation. =)
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Ok**************@TK2MSFTNGP09.phx.gbl...
Don,
You do realize, as Armin stated, that any one who wanted to get your code,
will!

Independent of if it is written in ASM, C++, VB4, VB6, VB.NET or C#!

All computer languages have tools available that can reverse engineer them, included compiled programs.

I don't have the link handy, my understanding is that the question is not so much that we need to compile to binary machine code (which is easily
de-compiled or dis-assembled anyway). But the need is for digital
certificates & encryping the assembly, so it cannot be looked by opening the file, yet can still be looked at to actual execute.

Hope this helps
Jay

"Don Wash" <do*@wash.com> wrote in message
news:OJ**************@TK2MSFTNGP11.phx.gbl...
Thanks for the links Herfried,

Yes, I do think when you are developing a software with your own unique
aglorithm (or even simple applications) competitors can just look up your
code and get the idea where you've scarificied hours and hours of good

night
sleep to get the aglorithm and get the app up and running. This is also

the
case for simple applications. That's something I don't want :P and I'm

sure
most developers will agree with me.

Do you think .NET will become binary in the future?

Don
P.S. This VB.NET newsgroup is damn fast!!! I love it!

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2h************@uni-berlin.de...
* "Don Wash" <do*@wash.com> scripsit:
> I'm new to .NET but I'm a experienced VB programmer (since VB 4) and

wanting
> to move to VB.NET from VB 6.
>
> But as I read about .NET, I came across that compiled VB.NET code is

stored
> in MSIL (instead of binary) which is easily decryptable by the

"hackers"
to
> reverse engineer your VB.NET application.
>
> Is this true?

Yes.

Nevertheless, you can make their work harder by obfuscating the
code. You will find some links here:

<URL:http://www.cetus-links.org/oo_dotnet.html#oo_dotnet_utilities_tools>
Notice that VS.NET 2003 includes the Light Version of Preemptive's
obfuscator.

BTW: Do you really think that somebody wants to have a look at
the code of /your/ application? What I want to say: Reverse
Engineering often doesn't make much sense, it's "interesting" if there
are some complicated algorithms implemented, but not for most normal
apps.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>



Nov 20 '05 #10

P: n/a
Hi CJ,

It stays always impossible to prevent decompiling completly, at
processor(s) level all the instructions are standard whatever firmware you
place between it.

However mostly it will cost an enormous amount of time, while the result is
unussable, with the exception when there are a real intresting things as
Herfried already stated.

Just my 2 eurocents

Cor
Nov 20 '05 #11

P: n/a
CJ,
Yes it would be implemented at the kernel or the CLR level.

I want to saw Eric Gunnerson discussed this in the C# newsgroup, however I
just don't have the link handy right now.

Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
news:us**************@TK2MSFTNGP10.phx.gbl...
An idea like that would have to be implemented at kernel level would it not? Encrypting the compiled program so that it couldn't be read? But then how
would it be decrypted. The OS right?

That would be a pretty interesting implementation. =)
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Ok**************@TK2MSFTNGP09.phx.gbl...
Don,
You do realize, as Armin stated, that any one who wanted to get your code,
will!

Independent of if it is written in ASM, C++, VB4, VB6, VB.NET or C#!

All computer languages have tools available that can reverse engineer them,
included compiled programs.

I don't have the link handy, my understanding is that the question is not so
much that we need to compile to binary machine code (which is easily
de-compiled or dis-assembled anyway). But the need is for digital
certificates & encryping the assembly, so it cannot be looked by opening

the
file, yet can still be looked at to actual execute.

Hope this helps
Jay

"Don Wash" <do*@wash.com> wrote in message
news:OJ**************@TK2MSFTNGP11.phx.gbl...
Thanks for the links Herfried,

Yes, I do think when you are developing a software with your own unique aglorithm (or even simple applications) competitors can just look up

your code and get the idea where you've scarificied hours and hours of good

night
sleep to get the aglorithm and get the app up and running. This is also the
case for simple applications. That's something I don't want :P and
I'm
sure
most developers will agree with me.

Do you think .NET will become binary in the future?

Don
P.S. This VB.NET newsgroup is damn fast!!! I love it!

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2h************@uni-berlin.de...
> * "Don Wash" <do*@wash.com> scripsit:
> > I'm new to .NET but I'm a experienced VB programmer (since VB 4)

and wanting
> > to move to VB.NET from VB 6.
> >
> > But as I read about .NET, I came across that compiled VB.NET code is stored
> > in MSIL (instead of binary) which is easily decryptable by the

"hackers"
to
> > reverse engineer your VB.NET application.
> >
> > Is this true?
>
> Yes.
>
> Nevertheless, you can make their work harder by obfuscating the
> code. You will find some links here:
>
>

<URL:http://www.cetus-links.org/oo_dotnet.html#oo_dotnet_utilities_tools>
>
> Notice that VS.NET 2003 includes the Light Version of Preemptive's
> obfuscator.
>
> BTW: Do you really think that somebody wants to have a look at
> the code of /your/ application? What I want to say: Reverse
> Engineering often doesn't make much sense, it's "interesting" if there > are some complicated algorithms implemented, but not for most normal
> apps.
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>



Nov 20 '05 #12

P: n/a
Oh that eric... always stirring up trouble. =)

I think that would be really interesting.. you know how VB Package and
Deployment Wizard had the serial algorithm. You would almost have to have
the same thing at the CLR level in order to decrypt it. That way, you would
have to get a key from Microsoft (kinda like authenticode) to be
decrypted....

Hmmm.. don't know how well that would work...
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uJ*************@tk2msftngp13.phx.gbl...
CJ,
Yes it would be implemented at the kernel or the CLR level.

I want to saw Eric Gunnerson discussed this in the C# newsgroup, however I
just don't have the link handy right now.

Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
news:us**************@TK2MSFTNGP10.phx.gbl...
An idea like that would have to be implemented at kernel level would it not?
Encrypting the compiled program so that it couldn't be read? But then how
would it be decrypted. The OS right?

That would be a pretty interesting implementation. =)
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message news:Ok**************@TK2MSFTNGP09.phx.gbl...
Don,
You do realize, as Armin stated, that any one who wanted to get your code, will!

Independent of if it is written in ASM, C++, VB4, VB6, VB.NET or C#!

All computer languages have tools available that can reverse engineer

them,
included compiled programs.

I don't have the link handy, my understanding is that the question is not
so
much that we need to compile to binary machine code (which is easily
de-compiled or dis-assembled anyway). But the need is for digital
certificates & encryping the assembly, so it cannot be looked by opening the
file, yet can still be looked at to actual execute.

Hope this helps
Jay

"Don Wash" <do*@wash.com> wrote in message
news:OJ**************@TK2MSFTNGP11.phx.gbl...
> Thanks for the links Herfried,
>
> Yes, I do think when you are developing a software with your own

unique > aglorithm (or even simple applications) competitors can just look up

your
> code and get the idea where you've scarificied hours and hours of
good night
> sleep to get the aglorithm and get the app up and running. This is

also the
> case for simple applications. That's something I don't want :P and I'm sure
> most developers will agree with me.
>
> Do you think .NET will become binary in the future?
>
> Don
> P.S. This VB.NET newsgroup is damn fast!!! I love it!
>
> "Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message > news:2h************@uni-berlin.de...
> > * "Don Wash" <do*@wash.com> scripsit:
> > > I'm new to .NET but I'm a experienced VB programmer (since VB 4) and > wanting
> > > to move to VB.NET from VB 6.
> > >
> > > But as I read about .NET, I came across that compiled VB.NET code is
> stored
> > > in MSIL (instead of binary) which is easily decryptable by the
"hackers"
> to
> > > reverse engineer your VB.NET application.
> > >
> > > Is this true?
> >
> > Yes.
> >
> > Nevertheless, you can make their work harder by obfuscating the
> > code. You will find some links here:
> >
> >
<URL:http://www.cetus-links.org/oo_dotnet.html#oo_dotnet_utilities_tools> > >
> > Notice that VS.NET 2003 includes the Light Version of Preemptive's
> > obfuscator.
> >
> > BTW: Do you really think that somebody wants to have a look at
> > the code of /your/ application? What I want to say: Reverse
> > Engineering often doesn't make much sense, it's "interesting" if there > > are some complicated algorithms implemented, but not for most

normal > > apps.
> >
> > --
> > Herfried K. Wagner [MVP]
> > <URL:http://dotnet.mvps.org/>
>
>



Nov 20 '05 #13

P: n/a
"Cor Ligthert" <no**********@planet.nl> schrieb

In addition to Herfried..
I think, if somebody is /really/ interested in your code, he will
also decompile assembler code, so the only 100% safe way is not to
distribute

the
application.

Same idea here, are you going to serverside webapplications Armin?


What??
--
Armin

Nov 20 '05 #14

P: n/a
> > Same idea here, are you going to serverside webapplications Armin?


What??


I assume you understand it, however to answer seriously, a user cannot reach
(normally I am not talking about hackers) the code from a serverside
webapplication, and therefore he cannot decompile it.

The first sentence (Same idea here) was serious from me, the second only to
prickle you.

:-)

Cor
Nov 20 '05 #15

P: n/a
> Reverse Engineering often doesn't make much sense, it's
"interesting" if there are some complicated algorithms implemented,
but not for most normal apps

There is also the other unfortunate aspect of .NET apps being so
easily reverse engineered. That is that if you're app becomes
popular it's a breeze to have all security checks removed from your
latest version that you'll slaved over and distributed free of
charge, even if it is uninteresting code. I think that is what most
people are worried about.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Nov 20 '05 #16

P: n/a
* "John" <jo**@nospam.infovis.co.uk> scripsit:
But we can get the setup to "compile" the app at installation so after that
the app is as secure as a regular executable?


You can run "ngen.exe" in setup, but still the MSIL image will be
required to do that and to run the app.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #17

P: n/a
* "Cor Ligthert" <no**********@planet.nl> scripsit:
Same idea here, are you going to serverside webapplications Armin?


What??


I assume you understand it, however to answer seriously, a user cannot reach
(normally I am not talking about hackers) the code from a serverside
webapplication, and therefore he cannot decompile it.


That's what I recommend too, but often there is no permanent internet
connection available. If I want to deploy an application that uses a
unique algorithm, I would have to provide a web service that works >
99,999 percent of time and most people won't be able to use if because
of lack of internet connections or secuurity policies.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #18

P: n/a
You've mad a good point Jimi.

Don

"Jimi" <ji************@yahoo-dot-ca.no-spam.invalid> wrote in message
news:40********@Usenet.com...
Reverse Engineering often doesn't make much sense, it's

"interesting" if there are some complicated algorithms implemented,
but not for most normal apps

There is also the other unfortunate aspect of .NET apps being so
easily reverse engineered. That is that if you're app becomes
popular it's a breeze to have all security checks removed from your
latest version that you'll slaved over and distributed free of
charge, even if it is uninteresting code. I think that is what most
people are worried about.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Nov 20 '05 #19

P: n/a
Thank you for all the replies!

I'm overwhelmed by the number of replies in such short time and I apologize
for not being able to respond to all the people who replied.

I'll cap it all for everyone; Yep I think it's important for the complied
code to be protected for obvious reasons. While MSIL maybe easily decrypted,
I'll use obfuscators (that can also convert variable names as well) to
protect my code. And I also hope that MS will include built-in full versions
of obfuscators (or better method to protect MSIL code) in the future :)

Cheers all!
Don

"Don Wash" <do*@wash.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Hi Everyone!

I'm new to .NET but I'm a experienced VB programmer (since VB 4) and wanting to move to VB.NET from VB 6.

But as I read about .NET, I came across that compiled VB.NET code is stored in MSIL (instead of binary) which is easily decryptable by the "hackers" to reverse engineer your VB.NET application.

Is this true?

Thanks in advance!

Don

Nov 20 '05 #20

P: n/a
Ayup, that IS the point that MSFT seems to want us to ignore.

--
http://www.standards.com/; See Howard Kaikow's web site.
"Don Wash" <do*@wash.com> wrote in message
news:Os**************@TK2MSFTNGP12.phx.gbl...
You've mad a good point Jimi.

Don

"Jimi" <ji************@yahoo-dot-ca.no-spam.invalid> wrote in message
news:40********@Usenet.com...
Reverse Engineering often doesn't make much sense, it's

"interesting" if there are some complicated algorithms implemented,
but not for most normal apps

There is also the other unfortunate aspect of .NET apps being so
easily reverse engineered. That is that if you're app becomes
popular it's a breeze to have all security checks removed from your
latest version that you'll slaved over and distributed free of
charge, even if it is uninteresting code. I think that is what most
people are worried about.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com


Nov 20 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.