|
This is like locking the door to your house. Does it prevent somebody from knocking the door down with a bulldozer? No. It prevents them from getting EASY access to your house. A determined hacker can always crack your code - any code that can be run on the machine can be decompiled. You can encrypt your application, but the way that works is only the EXE file is encrypted - when the code is loaded into memory, it's decrypted and therefore understandable.
Your goal is to make it *not worth my time* to try to decompile your application. You need to make it so the official licensed version of your application is easier to get than the cracked version. Like locking the door to the house - you're not going to make it impossible to crack, just make it so difficult that it's easier to get the legit version. That way the only ones who will crack your app are the people who do that kind of thing for fun, and it won't hurt your app sales. Does anybody download the cracked Angry Birds? NO, because the licensed version is free.
|
|
|
|
|
Jasmine2501 wrote: official licensed version of your application is easier to get than the cracked version.
you are right.why don't i thought like that. 
|
|
|
|
|
You are learning. We all have to learn these things. Someone told me many years ago, and I told you today. Isn't it wonderful to be a human being? 
|
|
|
|
|
Hi,
First of all, I do not know if this is the correct forum. If not, please re-direct me.
I am re-designing a successfull application for XP to run under Win7 and 8. The previous incarnation runs under XP. The application at hand is a Cash Register/Production Application, not at all connected to the internet, just to a small local network. the general requirement is that a User signs in to an app running on a terminal, in order to register a fact of production, or a transaction with a customer. Any Opening,reading Writing or Closing happens under Program Control.
Under XP all machines run in non password Admin Mode. I see nothing wrong with it, but microsoft considers it a bad idea. (conversely, weare not aware of even one security related issue over the past 7 year).
I cannot think of even One feature of the 'Windows Development Cycle since 'windows XP' that has benefitted me.
The Read/Write/Modify set of permissions do not realy cut it. An employee must perform a transaction on the till, which requires a right to modify the Till Contents. he is however not allowed to do that at will. (Set the Contents to Zero, bring the takings home, and claim 'No Trade' for that day)
'Switch User' is definitely not a way to go. It is too slow, and All Users have to start from the same screen anyways.
The Microsoft model seems to be based on the 'country hopping traveling sales man', and the sharing of a computer between different people doing different things, like writing letters or spreadsheets, stored on the company server. The precursor to Azure(which I will NEVER assign my customers to)
In my application Internet security requirements are non existent.
I am now preparing a new design using the NET Framework.
I do not use any significant graphics, (other than Diaolg Boxes) DB Acces attempts account to about 1000 per week. on average over each of my users.
Anyone who can help?
Regards
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: I am re-designing a successfull application for XP to run under Win7 and 8
Presumably based on business reasons.
Bram van Kampen wrote: 'Switch User' is definitely not a way to go.
If you want the terminal to act like a kiosk then research techniques for doing exactly that.
Other than that the app, not the OS, should control acccess to business functionality.
|
|
|
|
|
Well,
Your remark sounds sarcastic.
We aim just at the oposite. Version 2.00 was written in MFC 42,
the Re-Design affords that Version 3.00 will be written in C#. Virtually Nothing written in MFC/CPP will translate line by line to V3.00 code. We hope for a smooth technology change, with minimum Interface change.
In your argument, what is a Kiosk, and how does it exist under windows security.
Bram
Bram van Kampen
|
|
|
|
|
A Kiosk is a physical thing - A small structure, often open on one or more sides, used as a newsstand or booth. Sometimes a kiosk is running computer software, such as navigation maps at a large park or mall, or to apply for a job at Wal-Mart. They have unique security concerns because anyone can walk up and interact with the machine. It is not a technology.
I don't think his comment is sarcasm. I think you're skipping the first step of application design - asking yourself what really needs to be done, from a requirements perspective. For example, you say the new application is built in C# - WHY? Did you examine the requirements and the proposed architecture and conclude that C# is the best language to build this app with? OR, do you have a company policy that all new development will be in C#? Have you determined that maintaining the current app is not cost-effective? It sounds like you've decided to re-build this app in C# for no compelling reason at all.
|
|
|
|
|
The concept you need to implement is called "roles" and it's pretty much the way security is done these days in most places. You create roles, like "cashier" or "shift manager" or "store manager" and you assign specific permissions to those roles - you never assign permissions directly to a user. When you add roles to a user, it determines what is available for them in the app. Due to your requirement that "switch user" will not be used, you can not use Windows Active Directory roles, which is a VERY secure way of doing this. You will have to roll your own (couldn't resist) roles system.
|
|
|
|
|
I understand that when you install the .NET framework, having copied all the assemblies into the Global Assembly Cache, they are then NGENed into native code. This is why it takes a while.
This makes a lot of sense, so I've never understood why the architects of .NET didn't provide support like this for our applications. On some of the larger systems I work on they are noticably sluggish when they start up and I experimented once, signing and putting the assemblies into the GAC, then NGENing them and they were considerably faster on start up.
So why not have a system whereby the first time you run an application the native image that is created (albeit on a line by line basis) is cached somewhere with a link to the original assembly? I appreciate that somethings couldn't be done like this (stuff from emit for instance) but the vast majority of the time JITting is something which really doesn't have to happen every time an application is run.
Anyone got any thoughts on this matter?
Regards,
Rob Philpott.
|
|
|
|
|
If you wanted to, you could do this yourself by running ngen.exe.
|
|
|
|
|
Yes, but that would require sticking your application in the GAC which is hardly appropriate.
Regards,
Rob Philpott.
|
|
|
|
|
I'm pretty sure it doesn't Rob, unless things have significantly changed since this[^].
|
|
|
|
|
Maybe I've remembered it wrong. Will investigate.
Regards,
Rob Philpott.
|
|
|
|
|
Let me know what you find. I've never tried to do this myself, so I'm working on the "in theory there's no reason why not" approach.
|
|
|
|
|
Yes, seems I was off on one. Reading around, if you've given your assemblies a strong name then you get little performance from NGENing them unless they are in the GAC due to some validation which is done, but its absolutely not compulsory.
So I took one of my dumb console apps which does something and just tried to NGEN it and it didn't complain.
Coming back to the original point. If you're going to design a system with an intermediate language and CLR and all that, I still would have thought that building a standard way whereby the assemblies get Jitted just once would be in the list of original requirements. Computers rarely change their instruction sets, so why just keep doing it over and over again?
There are lots of whys like that in this field...
Regards,
Rob Philpott.
|
|
|
|
|
The implication there is that all the code has been JITted. Depending on application complexity, it's entirely possible that you only follow certain paths through the code on certain runs - thus causing problems if you were to just emit the ngen of the single pass. You could only really do this if all paths were hit during the process - otherwise there's no real need for you JITting and you could just ngen up front.
|
|
|
|
|
Rob Philpott wrote: I experimented once, signing and putting the assemblies into the GAC, then
NGENing them and they were considerably faster on start up.
Because for most systems what the code does on start up is vastly more significant.
Rob Philpott wrote: is cached somewhere with a link to the original assembly?
Sounds like a security hole just waiting to be exploited.
Precompilation caching would need to be done by using a signature/hash which would then be compared to the existing cached entity. That with the name would provide the link.
|
|
|
|
|
i am using Db Name Called ECO and there no table having with the name "services".
i am using windows authentication in web.config file.
please help me out to sort out this problem.
even i tried by giving all permissions but no luck
i am getting below error
The SELECT permission was denied on the object 'services', database 'mssqlsystemresource', schema 'sys'.
Invalid object name 'SqlQueryNotificationService-98253c68-5c04-44ef-9939-b8ee242c7b34'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: The SELECT permission was denied on the object 'services', database 'mssqlsystemresource', schema 'sys'.
Invalid object name 'SqlQueryNotificationService-98253c68-5c04-44ef-9939-b8ee242c7b34'.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
|
|
|
|
|
Which version of SQL Server?
When does it happen - when you connect to the database, when you do the first query, somewhen later, ...?
Can you connect to the SQL Server with e.g. SQL Server management Studio and execute some queries?
|
|
|
|
|
i am using MS Sql Server 2008 R2 it is happening when i connect the server(when Run the application).
but i am able to connect SQL Server management Studio and able execute queries
|
|
|
|
|
I have query regarding LdapSessionOptions.SecureSocketLayer property in context of LDAP authentication.
I have run this code for Ldap Port 636 ie for SSL LDAP.obviously SecureSocketLayer has to be true in this case.
My query is that if Ldap Port is 389(ie apart from 636), will the value of SecureSocketLayer be ignored, or we will have to set the property to false explicitly.
(as of now I am not able to test for this case, so putting the query.)
LdapConnection con = new LdapConnection(new LdapDirectoryIdentifier(ldapHost, int.Parse(LdapPort)));
this.CurrentLdapCertPath = ldapCertPathPassed;
con.SessionOptions.SecureSocketLayer = true;
con.SessionOptions.VerifyServerCertificate = new VerifyServerCertificateCallback(ServerCallback);
con.Bind(new NetworkCredential(UserId, Password));
|
|
|
|
|
Ladies and Gentlemen,
i have had something rear its ugly head today and I frankly do NOT for the life of me understand how this can be. After spending a couple of hours PROVING to myself (I am not always easily convinced) that what I am see is real, I scoured the net to the best of my googling abilities and came up empty. So I lay this at your feet hoping someone here has an answer.
Naturally, I am on the customer site with a hard deadline and more than just my reputation at stake! I will spot you that I am NOT the most experienced Windows developer on this plant, but I have been around the block a few times.
Here is my story.
I have created a WPF application that is very much multi-threaded. In fact it is highly dependent on these threads. There are 5 main threads: 1) UI; 2) TCP/IP server; 3) GPIB client; 4) main application; and 5) the main application interface.
When the app starts, MainWindow runs as with most WPF type apps. In the constructor I create some little class to do this and that and I instantiated each of the objects for the 4 main threads (obviously I am in the UI thread). Once the constructor is done the app drops into the normal sort of WPF wait for something to happen kind of thing. Meanwhile my other threads are busy handling comms, reading files and a variety of other things. When a particular msg arrives via TCP/IP the MainWindow is notified and he throws up a Window being used as a dialog. nothing fancy, just var dlg = new myWindow(); dlg.ShowDialog();
Here is where it gets REALLY weird! Every thread in the app stops! Freezes. Goes out to lunch! Describe how you wish. But they freeze. When the dialog is dismissed everybody goes about their business like nothing happened. Of course the reeks havoc on comm threads.
Anybody and ANY ideas why this is happening?? And more to the point what the remedy is?
Oh, I create my background threads using:
Task.Factory.StartNew(() =>
{
_pxiHandler.MainLoop();
}, TaskCreationOptions.LongRunning);
TIA,
Doug
I am a Traveler
of both Time and Space
|
|
|
|
|
I suspect your background threads are running on a TaskScheduler which is tied to the Dispatcher of the UI thread. Try passing TaskScheduler.Default to the Task.Factory.StartNew method:
Task.Factory.StartNew(_pxiHandler.MainLoop,
CancellationToken.None,
TaskCreationOptions.LongRunning,
TaskScheduler.Default);
Obviously you'll need to make sure that any UI access or collection modification is posted to the UI thread.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard, thank you. Very much! An excellent suggestion! However after a sleepless night (anybody know why stuff like this always happens on site during acceptance testing?) a good friend this morning showed me error of my ways. You, see, the only problem was I have a wretched case of idiotitis. In my zeal to explore the nooks and crannies of this Windows world I made the decision that a nice clean way to allow objects to get information from other objects was exposé an event and delegate. Seemed reasonable to me at the time. Having spent most of my life in a world where objects on different threads have REAL boundaries I assumed that if some object from another thread registered a handler that naturally when that handler was invoked from thread 2 that the event would interrupt thread 1 it would process the event and thread 2 would go merrily on its way. Nope. Thread 2 runs the event handler. Well when the thread that is minding your comms is now suddenly executing code in MainWindow which consists of putting up a dialog guess who isn't watching his comms.
Error of my ways #2 has to do with where one starts threads, which is the point you are making. I was informed that launching critical long running tasks from the MainWindow code was not a very good idea. Suggestion was to move them to the App class and override OnStartup. Which I have now done. That does create several questions but I will save them for another day.
Error of my ways #3 was to foolishly mentally assign characteristics to objects in threads as I would to a process of lightweight thread in other operating systems. Not a good analogy.
Sorry for the length but somebody out there will make the same boo-boo someday.
Thank you again,
Doug
I am a Traveler
of both Time and Space
|
|
|
|
|
Hi All
Can Anyone Tell The Difference between MVC/MVC3 and MVC4
-- modified 5-Apr-13 7:17am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
