I want to add a page to an existing website with a list of practical system information about the server that's running the site. For example, which windows version, 32 or 64 bits, SQL Server version, some host variables, amount of RAM, disk space and whatever else. Basically, anything practical that could tell me more about the health of the server.
So, how do I get the most practical information through .NET?
Not important how it's going to be displayed but assume it's a list with three columns: Name of the setting, value for the setting and a description that tells what the setting is for... (The first two would already be enough, though, but for clarifications a description would be nice.)
One added complication, though: I need both 32-bits and 64-bits solutions...
Use WMI counters:
http://msdn.microsoft.com/en-us/library/bb404655.aspx
EDIT:
See this questions for examples
How can I check for available disk space?
have a look on this url
http://msdn.microsoft.com/en-us/library/system.environment.osversion.aspx
and Request.ServerVariables Collection
e.g.
Request.ServerVariables[""];
The best way to do this is using SNMP performance counters. This basically allows you to (through IIS) interact with system performance information.
Here is a list of performance counters
And here is a cool tutorial on how to use them
Related
I'm making a C# (winforms) app that I want user to be able to execute only for a defined number of times (say 100 times). I know its possible to add an xml or a text file to store a count but that would be easy to edit or "crack"... is their any way to embed the counter in the code or maybe any other way that might not be easy to crack? and that its also easy later to "update" the membership for another period of 100 executions?
Thanks in advance
There are lots of ways to store a variable. As you've noted, you can write it to a text or xml file. You could write it to the Registry. You could encrypt it and write it in a file somewhere.
Probably the most secure method is to write it on a server and have the application "call home" whenever it wants to run.
Preventing copying is a difficult balancing act - treat your legitimate customers too much like criminals and they'll leave you.
If you're talking about memberships, your application may be web connected. If that is the case, you could verify the instance against a web service on your server that holds and increments the count and issues a "OK/Not OK to run" reply.
If you don't want to do this, I have heard of an application that uses steganography to hide relevant details in certain files - you could hide your count in some of your image resources.
Create multiple files containing the counter or the number of times your app will run. Name these files with different file names and store it in different location so that it will be hard to locate,delete and crack by user. The reason why it is not just one file because if the user found one of your file and alter or delete it, you still have other files which contains the valid information about your app.
If your application is a commercial product it might be worth to have a look at security products from other commercial vendors like SafeNet.com, for example.
A few years ago I used the HASP HL hardlock for a project, which worked just fine.
They offer hardware dongles for software protection as well as software based protection (using authentication services over the internet), and combinations of both.
Their products allow for very fine grained control of what you want to allow your users, e.g. how many times an application may be started before it expires (which would be just what you want) or time-expiration, or feature packages, or any combination of it all.
The downside is, that they have very "healthy" licensing prices.
If this is worth it will depend on the size and price of your own application.
For simple copy-protection purposes, I would like to generate a small string or int value to (somewhat) uniquely identify the current computer. Ideally this value won't change after simple hardware peripheral changes, or even hopefully after a complete re-installation of Windows.
Most of the answers found here and elsewhere are unsatisfactory for three main reasons:
The code presented isn't easily portable to C#.
The hardware values suggested are often unusable/empty (e.g. the processor ID or even the hard drive serial number) or unstable (e.g. the MAC address).
The code involved requires elevated admin privileges.
I have searched through several posts and found a helpful article (How To Get Hardware Information), but since #3 is an important consideration in my case, I'm not sure what hardware info I can retrieve with just normal user privileges.
Regarding #2, I imagine the best solution is to simply append a few different values together, but which ones? Any help is greatly appreciated, especially if it includes or points to C# code. :D
I think you're going to have a hard time meeting this criteria because uniquely identifying the machine may be a functionality that is only intended for administrators. If this isn't the case now I'd imagine it will be as time goes on due to rising privacy concerns.
I was wondering how one would find the available memory slots vs taken slots on a motherboard in C#. With WMI I can find a total number of slots and also a list of memory sticks, but the information provided in both cases, specifically the latter, it's seemingly generic and changes depending on the motherboard.
Essentially I'm looking to create a list every slot on the board and which specific ones are taken and by what kind. I imagine this may be able to be done with WMI, but as said, I can't seem to get around the problem that "DeviceLocator" in Win32_PhysicalMemory is confusing and uncertain.
It takes a combination of using the information provided by Win32_PhysicalMemory with information such as the "Manufacturer" and "Product" fields in Win32_BaseBoard to create a set of known slots and compare the "DeviceLocator" field in Win32_PhysicalMemory against it. Not ideal, but it's the only solution that seems apparent.
Using Win32, you should be able to call GetSystemFirmwareTable to retrieve a specified firmware table from the firmware table provider (SMBIOS table). Though Pinvoke.NET give nothing for this unmanaged entry, you perhaps can search this way. You may find some help in System Management BIOS (SMBIOS) web site.
See this
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Where do programs save their secret license or install related information? I notice that often times when you uninstall a program, clear out appdata references, check registries to make sure there is no residue of any relevant information.
If you reinstall the trial program again, it seems to know it was installed before. I'm not looking to find a way to crack trial programs but actually need to implement something similar and can't find any good information on how to do this.
Registry
online
file in folder Windows with system like name
I even seen apps that hacked unused OS variables to store custom data in registry.
But the simplest method is to register a handler for a custom unused file type like .sof (if that is there, it was installed before) Edit 1 You have to register the handle to open a known executable on the system, not to your app. Because cleaners will detect if points to a no longer existing app location. As for storing additional params like date of trial expiry you can include them in the path as a param, like: cmd.exe -o 2010-02-09
I have handled this in two ways. First, in windows apps, I put in an encrypted Registry entry which is not in a standard location so that it is not easily found. This is a good solution if you don't mind people who either a) reformat often which removes all registry entries or b) use your software on a virtual machine which can be quickly reverted to a pre-trial state (and thus your trail can be used again quickly).
The better alternative is to have an online registry component which catches the MAC address of the machine which the trial is loaded on. Whenever the trial is reloaded, the software checks against a web service to see if the MAC address has been seen before. The only way around this is again using a Virtual Machine with the ability to change the MAC address. However, if you have a user that goes to this extreme, they'll use your trial regardless.
Probably the most foolproof way of licensing (when done right) is through something the user physically has - some kind of hardware dongle.
very hard to copy/duplicate
not dependent on network access
tamper-resistant (compared to software)
user-friendly (when working correctly)
licence count enforcement (can't easily plug 1 dongle into 10 machines at once)
Of course, it has also numerous disadvantages:
expensive to produce
hard to repair/replace
actually requires you to communicate with the dongle in a cryptographically secure way - any kind of if(dongle_ok()) { do_stuff() } is an invitation for crackers to patch that over to if (1) { do_stuff() }...
...which will require special drivers...
...maybe even a special interface (I still have a LPT dongle, but no LPT ports; USB<->LPT sucks)
don't even think of hooking it up to a virtual machine (although peripheral support is better in VMs nowadays)
support hell (is it connected? is it not broken? is the driver not broken? are the signatures/keys right and unexpired?)
fragile, esp. if it sticks out of the computer and/or has destructive anti-tamper mechanisms
may break communication with other peripherals (esp. those "pass-through" things were notorious for this)
For most programs, the disadvantages far outweigh the advantages; however, if you're making expensive, complex software (think "production plant control"), your clients are rather cavalier about licensing (in other words, "would buy a single copy (crack it if necessary) and run it on 50 machines if they could get away with it"), and lawsuits are impractical (take too long, you don't have much evidence, uncertain outcome), this may be useful. (I didn't say simple, did I?)
They save it wherever they can, secret files, secret registry keys. There are commercial products that offer this kind of protection, like asprotect, armadillo, etc.
Some products will utilize ADS (Alternate Data Streams) and hide the data in various places.
Others will leave behind "rootkits" cough SONY.
Also some will create special registry entries that cannot be delete easily, such as entries with NULLs in the name.
It sometimes depends on how scrupulous the developer is.
Could also try making the file or folder hidden - most users don't know to reveal hidden files and folders. Then you can put it anywhere really. C:/WINDOWS is sometimes a good choice because of that silly window that shows up when you click it for the first time that says "DANGER! DO NOT EDIT ANYTHING IN THIS FOLDER OR YOUR OS WILL MESS UP!" This will hide most anything from the lay man, but let's face the facts, you're not hiding anything from anyone that is active on stack overflow. :)
There are loads of profilers and static code analyzers out there for C# assemblies.
Just wonder if there are any methods to prevent being analyzed, because it does make me feel a bit nervous when being stripped.
I have searched all over the Internet and stackoverflow. There seems none for my wonder.
What I've got are only some even more scary titles like these (sorry, new user can't post hyper links, please google them):
"Assembly Manipulation and C#/VB.NET Code Injection"
"How To Inject a Managed .NET Assembly (DLL) Into Another Process"
Is it just me being too worried or what?
BTW, with C#, we are building a new winform client for a bank's customers to do online transactions. Should we not do this in the winform way or should we use some other language like Delphi, C++? Currently we have a winform client built with C++ Builder.
If by analyzed you mean someone decompiling the code and looking at it, then the Dotfucstor that ships with VS Pro and above is a simple (free) tool to help here. There is a fuller functionality (but paid for) version that can do more.
To prevent someone tampering with your deployed assmebliles, use Strong Names.
Where there's a will, there's a way, whether it's managed code or native assembly. The key is to keep the important information on the SERVER end and maintain control of that.
Just about any application can be "analysed and injected". Some more than others. That's why you NEVER TRUST USER INPUT. You fully validate your user's requests on the server end, making sure you're not vulnerable to buffer overruns, sql injection and other attack vectors.
Obfuscators can make .NET assemblies harder to analyze. Using a secure key to strong-name your assemblies can make it much harder to alter your code. But, like everything else in the digital world, somebody can exploit a vulnerability and get around whatever safeguards you put in place.
The first thing you need to decide against what you are trying to protect?
Obfuscators are useful only to protect "secret sauce" algorithms, but the attacker can simply extract the code and use it as black-box. In 99% of cases obfuscators are waste of money.
If the attacker has physical access there is not much you can do.
If the end user is running with administrative privileges then they will be able to attach a debugger, and modify your code, including target account details. My local friendly bank has given me a chip & pin reader that I have to enter the last n digits of the target account, which it hashes/encrypts with my bank card's Chip; I then enter the code from the device into the bank's web application which can checked at the bank's end as well. This mitigates "man in the middle" type attacks...
Security is only possible on systems you physically control access to, and even then not guaranteed, merely achievable. You must assume any code not executing on a system you control can and will be compromised. As Rowland Shaw stated, the best bet for a financial institution is some sort of physical token which effectively adds a offline unique component to all transactions that cannot be (easily) known ahead of time by an attacker operating from a compromised system. Even then you should be aware of the fact that if the users computer has been compromised and he logs in with his secure token from that point forward until the session ends the attacker is free to perform whatever actions the user has permission to, but at least in that case the user is more likely to notice the fraudulent activity.