Here is a funny hypothetical metaphor.
You people started speaking in parbals so I did one too.
Suppose I was 20,000 feet up and jumped out of a plane just to hit the ground. Does it matter what languaged I used?
Printable View
Here is a funny hypothetical metaphor.
You people started speaking in parbals so I did one too.
Suppose I was 20,000 feet up and jumped out of a plane just to hit the ground. Does it matter what languaged I used?
Not unless it was *you* that were jumping.
Yes I did, and I am working on it. Getting something that IS secure (at least as secure as any natively compiled C++ program) but does NOT reveal some of the details I actually use [and especially does not release NDA material] is proving to be more time consuming than I planned.Quote:
Originally Posted by Joeman
For those who are interested in the technique, look at http://etutorials.org/Programming/.N...CLR+Execution/
It nicely explains how to replace both the JIT compiler and the class loader.
With this a program (such as the sample I am working on) can function according to the following process
1) Write conventional .NET code in the language of your choice to create a managed assembly (.dll)
2) Use a translator/encryptor so that the byte patterns are NOT standard MSIL. This will completely block the use of any existing tool as the file is NOT MSIL.
3) Write a custom CLR Loader and JIT Compiler that knows about your encrypted/translated format.
4) When you run the program, the memory pages are locked down so that other "normal" processes do not have "READ" Permission and the Custom Loader/JIT compiler is used to process the assembly.
The result is that MSIL never exists.
A minor variation on this aproach IS commercially available. You can purchase a license for a "Custom IL" that only your program will use.
The commercial alternative is NOT cheap. But if you have a legitimate concern that someone reverse engineering your code may cause you serious financial problems, then it is certainly a viable way to go...
That depends on two primary factors:Quote:
Originally Posted by Joeman
1) Are you jumping with someone (who intends to survive)
2) Do you have any "Last Wishes".
If both of the conditions above are met, then you should probably use a language the other person understands..... ;) :D
Have to know the language you speak, to both, get you to stop, and also, contact your next-of-kin...
very funny answers, but really when you go "splat" was the last few words you spoke mean anything? Now if someone show this happen, now that would be a horrible incident. It would mean nothing to the person the went "splat". Isn't that obvious? lol. He can't recall the moment.
Ok on the serious side.
Interpretation for coders
This is to if your code is used by people that are living and your dead. Does what they do with your code matter to you now that you can't think/process anything? If you answer is yes it does, try thinking/processing nothing which is just impossible. Even when you sleep, your brain is processing.
My point is vb6 may seem old to you and isn't a wise ideal to use because it isn't supported and/or old, others may not even care about this. I don't because of 2 things:
1. vb6 still runs fine
2. it meets my needs just fine
While I understand you're trying to covert msil to a non-standard encrypted version, that only masks the real problem and that is msil does exist. If you can protect it, perhaps it is good enough, but why won't .net simply compile with no jit strings attached and let the distributor decide if he wants to use msil so he won't be forced to use it. This is what vb5 and vb6 done from my understanding. This is what I want/need in the .net. For performance issues, I could make work arounds. If the workarouds can't be done, that is a different story.
If you really want vb6 to fade away, you have to give people another language they find equivalent and the .net can be it if, and only if, these are met:
1. It is the same speed or faster
2. Compilable to native
3. Able to turn off error checking for performance
4. have 100% equivalent win32 apis built in the .net
5. be a very well known language used for their needs.
These are what is stopping vb6 users to go to the .net successfully in my opinion.
If I had to program in the .net, I would find it rude and offensive to have to call out of my own development environment(.net framework) to do something I needed/wanted to accomplish if that language recommends to stay in the development environment.
As I have said (to WizBbang) if it works for you, and you understand the support situation, then there is no problem. Where I have a problem is where people (including you as in the replies above) make statements without having any facts to back them up.Quote:
Originally Posted by Joeman
I fail to see how that is a problem. A recent Gartner Group study indicated that the ration of MSIL to Native code in commercial programs is rapidly increasing. Without it, you simply can not do things like distribute a single version of your program and have it run as an x86, x86, or IA64 executable. Even within those families the JIT capability allows the program to use the optimal instructions automatically.Quote:
and that (the problem) is msil does exist.
If you were programming back in the 1980's you would remember all of the problems dealing with mathematical programs that had to run on DX (hardware floating point) and SX (software only floating point). It was a bloody nightmare deciding to pick one (limiting your audience with HW, or limiting your performance (always using SW) or using an "auto-detect" mechanism which ran slower on both platforms since the decision was made at every floating point operation.
Having an intermediate language (FYI "IL" is an industry standard, "MSIL" is microsofts specific implementation of that standard), completely eliminates this as the generated executable code (by the JIT) would always be optimal for the platform is was running on.
In the following comments the terms "nobody" and "anybody" include everyone I have dealt with in the past 7 years, including some of the worlds best VB programmers (one who helped form the language), VB user groups), etc...Quote:
If you really want vb6 to fade away, you have to give people another language they find equivalent and the .net can be it if, and only if, these are met:
1. It is the same speed or faster
2. Compilable to native
3. Able to turn off error checking for performance
4. have 100% equivalent win32 apis built in the .net
5. be a very well known language used for their needs.
These are what is stopping vb6 users to go to the .net successfully in my opinion.
1) Nobody has shown me a requirements document and a VB (4,5,6) implementation of that document that could not be implemented in .NET with equivilant performance.
2) If performance is not an issue, and there are security mechanisms for those cases (which I still believe to be fairly rare) where the incremental ease in reverse engineering matter, then there is no problem.
3) See #1. If the performance can be met WITH the safety checks (realize that over 80% of successful attacks are because of buffer overruns, stack faults, or other items that can not occur with the checks that .NEt provide), then this is a non-issue; unless you like to make your programs easier to infect...
4) This means that programming on Mac, Linux, Mainframes are all "useless"...They dont have "100% equivalent win32 apis". So far I have not found a case where a direct call to Win32API has been a necessity in implementing a program, but if I ever do, then PInvoke provides 100% identical functionallity to VB6 "declare".
(emphasis added)Quote:
If I had to program in the .net, I would find it rude and offensive to have to call out of my own development environment(.net framework) to do something I needed/wanted to accomplish if that language recommends to stay in the development environment.
You never have to use the supplied libraries. If you want/need a specialized implementation you can always write it. If you want/need to access something from a different environment, you can. Of course this is just adding work for the vast majority of cases where the provided (extensive) library provides all of the functionallity..
To be fair, for this comparison to work.. It depends on the type of parachute you used...Quote:
Originally Posted by Joeman
1) A old one, that the manufacturs will no longer maintain, and cannot supply replacement parts/repair when it breaks.
or
2) A new one, that the manufacturs have plenty of parts & staff to repair/modify it according to your specific needs..
In the comparison here it's not how fast you get back to ground, Its how safely you get down..
Its no good if the chute leaves you in a free fall until your a few meters from death and then sudenly decides to open fully, You land with out breaking any bones, but will you trust it next time ???
However a chute that opens when needed, and lets you land safely and in control, will be trusted for a long time (even perhaps with out service & repairs). Yes it took you longer to get down, but you got there safely...
--edit--
As i pressed submit i remembered a bumper sticker quote, if the parachute is not there when you need it, you'll probably never need it again .. ;)
Your question was why, to which one answer is performance. And that is still being explored.Quote:
Originally Posted by TheCPUWizard
I'm guessing you are referring to the GUI. That is, as long as the program appears responsive to the user, then are you saying it doesn't matter if code is still being executed behind the scenes? To some extent, I would agree, but only when the lag is short enough such that the user isn't continuing to stack more and more jobs, believing the others have finished. There's only so much of that which can be managed before problems arise. Also, there are plenty of cases where the user is watching the progress of some time intensive operation. This can be by means of a progress indicator, or by the presentation of the results, such as rendering hi-res graphics. The performance really matters in these scenarios, especially when the program is targeted for wide distribution, and is just one out of a number of solutions which the user might choose. I cannot count the number of poorly written programs I used only once. Upon finding out how bad/slow they were, I promptly uninstalled them. Thank goodness for free demos!Quote:
Originally Posted by TheCPUWizard
It probably matters less when most of your work is for clients who've paid for custom stuff. It's not like they have so many choices, time/money to waste, so I'd have to guess they are less likely to request a refund and go someplace else.
Again I believe one of the differences between yourself and others is the specific market. It seems you have clients who pay loads of cash for a solution, where others will be selling (or trying to) X copies of a $50 program on the Internet. In the latter case, there are untold numbers of horridly bad, free software and shareware out there, which in the view of the consumer are your competition (even though they aren't worth the time to download). So it becomes vitally important to maximize performance, protect against crackers/hackers, minimize file size, etc.
LOLQuote:
Originally Posted by GremlinSA
Or, the chute with a satisfaction guarantee. Or the one which states: "opens upon impact".
Very interesting. In earlier posts, when the conversation was about security, there were strong suggestions that those wanting to secure a .net app could just use obfuscation and/or ngen, and it was claimed to be good enough (I'm paraphrasing here, and referring to posts by more than one person, so I don't have to go back and try to find them).Quote:
Originally Posted by TheCPUWizard
This is very revealing. So it isn't so easy (or cheap) to really protect .net code after all. This makes me wonder how many people following this thread are now cringing, because they have been using obfuscation and ngen, believing their code is plenty secure. For you to say the commercial product isn't cheap suggests to me that the price has more zeros than most of us can afford.Quote:
Originally Posted by TheCPUWizard
By "commercial", do you mean software for the home user?Quote:
Originally Posted by TheCPUWizard
If you have rewritten my second example in .net, please do post the performance outcomes.Quote:
Originally Posted by TheCPUWizard
Anyway, Gremmy is working on it, so we'll see one way or the other.
I was actually just using a GUI event as a simple example and was considering the TOTAL time it took to completely perform an action. If the user clicks the button, looks at the screen and sees the result (100mS-250mS) then anything faster does not matter. An exeption might be a game function where the number of "clicks" in a second might impact the "attack" or other aspect.Quote:
Originally Posted by WizBang
No doubt there is alot of garbage out there. But if you remember the early days of C++, there were many C++ programs that were slower than their C counterparts. The primary reason was that developers did not know how to properly use the new paradigm. It crequired a completely different thought process and resulted in a radically different program structure. The exact same is true when comparing a native to managed program.Quote:
The performance really matters in these scenarios, especially when the program is targeted for wide distribution, and is just one out of a number of solutions which the user might choose. I cannot count the number of poorly written programs I used only once. Upon finding out how bad/slow they were, I promptly uninstalled them. Thank goodness for free demos!
This is one of the reasons why I do not engage in "write the same code" exercises. It is the wrong approach. I will gladly engage in any "competition" where given a functional spcification (what the customer needs the program to accomplish) is used to implement a program specifically developed fom the very ground up to accomplish the goal, using the best features of the environment.
They are much more likely to file a lawsuit than to request a refund is the project specifications aqre not met. :eek: They will have lost not only the money they paid, but often months of time where they coukld not accomplish their goal. Also with the "many sales small dollar" model, there is the possibility that a percentage of saqles will result in a request for a refund. With "full custom - one shot" it is an all or nothingQuote:
It probably matters less when most of your work is for clients who've paid for custom stuff. It's not like they have so many choices, time/money to waste, so I'd have to guess they are less likely to request a refund and go someplace else.
AlthoughI rarely get down to the $50/copy region, some of my products are designed for mutiple sales.Quote:
Again I believe one of the differences between yourself and others is the specific market. It seems you have clients who pay loads of cash for a solution, where others will be selling (or trying to) X copies of a $50 program on the Internet. In the latter case, there are untold numbers of horridly bad, free software and shareware out there, which in the view of the consumer are your competition (even though they aren't worth the time to download). So it becomes vitally important to maximize performance, protect against crackers/hackers, minimize file size, etc.
Even a very small program (done well in any environment) takes about 1 man-month. This includes the coding, debuging, documentation, beta-testing, etc. The average cost for this is about $15K-$20K (Salary, Office Expense, etc). This means that a minimum sale of at least 300 copies just to recover costs. To make a decent return on investment, that number becomes about $500 copies. Wtih the heavy saturation in that market place, I have seen a number of excellent programs that never gained enough traction to become a sustainable product.
Again, business models differ,and I am well aware that these numbers do not apply to everyone, especially someone who is writing their softare as a side-line.
Restricting security to "avoiding duplication" or "theft of intellectual property"....Quote:
Originally Posted by WizBang
It is a matter of degree of security. Obsfucation makes the code harder to read, and introduces lots of mis-directions (code injected specifically to make the algorythm's intent harder to understant).
For ANY program, at Time0 a thief has no knowledge of the internals, given sufficient time a qualified thief will that 100% knowledge and undrstanding. The difference between the models is the shape of the curve in between.
And this is where the topic becomes very subjective.
Obsfucation puts the code on the same plain as a moderately optimized C++ program. For many that is sufficient. When you talk with security experts (again about theft/duplication and NOT about unauthorized alteration, the two topics MUST be seperated), the criteria that is used is always impact vs. cost.Quote:
This is very revealing. So it isn't so easy (or cheap) to really protect .net code after all. This makes me wonder how many people following this thread are now cringing, because they have been using obfuscation and ngen, believing their code is plenty secure. For you to say the commercial product isn't cheap suggests to me that the price has more zeros than most of us can afford.
Consider a (hypthetical) program that you develop. You are going to sell it for $100 (easy number). Your marketing plan calls for you to sell 500 copies over the next three months, then 50 copies a month for the remainder of the year. That is 950 copies at $100/copy or $95,000.
Statistically, during the very initial phase, thieves will not be aware of your product, so it will take some time before they consider stealing the implementation. Lets say two months. (So far nothing has involved the platform that program uses..)
Situation #1
The code is difficult to understand and takes 3 months to analyze. It then takes a month to "repackage" the code so it has a different look and feel to avoid an immediate lawsuit. When released to the market it takes away 25% of your sales. This is a net impact of 75 copies that you would have sold ($7,500)
Situation #2
The code is easier to understand and only takes 1 month. This increases the impact to 100 copies ($10,000).
...back to common effects.... When there are multiple programs that claim to achieve the same goals, there is an increase in awareness (potential customers). A significant factor in customers deciding (assuming all other things equal) is the reputation of the vendor. For small vendors, this is usually measured by feedback on download sites, number of downloads, and length of time the program has been available (longer=better).
Because of this effect, the customer base increases by 20%, of which your company gains 50%. In the first situation, this condition exists for 6 months, in the second it exists for 8 months. This results in an increase of 60 sales for the first situation vs. 80 sales for the second.
This results in net impacts of 15 sales vs. 20 sales. The total difference in your income is $500. In other words a 6% difference in revenue. It is a very rare marketing plan that can even predict actual revenues to within 10% for a mass market product concept.
While I do NOT do business in this space myself, I have been a supporter of "Fresh Minds" for about 20 years. This is a regional (New York) organization that guides people in developing a business or product. Of the people who have acutally launched low price software products (selling price < $250), the ones who did the appropriate research and analysis has mostly been successful, while the ones who just thought they had a good idea rarely succeed....
The study was of companies that developed "boxed" software, and did not indicate the targt audience. This would severely limit the number of "shareware" type vendors, but would include the companies that develop software you see on the shelves retailing for well undr $100...Quote:
Originally Posted by WizBang
As I stated before, I do not believe in "rewrite the code" approaches. Give me a specification for a (simple) actually useful program, and I will gladly take it in.Quote:
If you have rewritten my second example in .net, please do post the performance outcomes.
Anyway, Gremmy is working on it, so we'll see one way or the other.
Also, I very rarely do any GDI type work. The few products which require it, I tend to outsource the work. [I am a lousy graphic artist, so even if I write "great" code, it still looks like S$#$".
I am looking forward to Gremmy's results....