I need a windows installer that can install my program only X number of times. Say 10 or 20 or a defined number I set. Then the installer ceases to operate or can give a message to contact my company.
Ed
There are several solutions.
One solution that is quite common is to require online authentication for the program for each new install.
Solutions that may be viable in some situation:
Self modifying executable. Just let the installer modify itself and reduce some counter. But it is easily defeatable by making multiple copies of the executable.
If you want to limit the installer only on one computer add some registry key and check that. Also easily defeatable
In my opinion the best way to doing this is using a hardware block/dongle. They're awful for the user, but they work in limiting access. The other advantage to these blocks, is that you can install the software on numerous pcs, but the software can only run on the pcs with plugged in usb keys.
Another solution to have some form of an encrypted file/db, that whenever an installation is flagged as complete, it adds a value. When the number of values reaches X, then setup won't work anymore
EDIT
the real issue is that most applications are installed using a dvd/cd, in order to limit the number of installations, you need to be able to write back to the dvd. I don't think this is feasible in most cases.
Related
How do applications like CloneDVD2 or AnyDVD know that the free phase is over, even if the application was uninstalled and then re-installed? Those applications don't require the user to login so that they could identify the user again.
Also on deinstalling them a window pops up asking whether the "registration files" should be kept or not. Even if they are not kept, the re-installed application knows the demo-time is over.
How is that technically realized?
Could be everything...
You might reverse the algorithm to find out.
But to name an example:
It's possible to generate a hash, based on unique hardware identifiers, of your hardware configuration and send that over the internet to a database.
If your hash exists over there, the software knows you ran it before.
An other option is leaving tracking information inside of your OS. So the checkbox: delete register information, isn't deleting everything.
To test:
1) Switch GPU or CPU :P
2) Format & Reinstall computer
I have a classroom with ~20 PCs. One for the teacher and all others are for students. They all have pre-installed licensed Windows 7 Home Premium (cause reasons) and reinstall OS to another is not an option :( Also they all are in same work-group (in one net).
Is there any tools (like Active Directory \ VNC \ "Microsoft Garage Mouse without Borders" etc.) which can do exactly the same operations at exactly the same time on all students computers from the "main" teacher-pc? For example: I start this "magic" program in small window, it connects to all PCs (if it can), then I move my mouse inside it to the left and all mouses on all PCs moved the same way. Press Start - it will open Start on all student-PCs. It's some kind of botnet program (I suppose), but it will help a lot.
VNC not good, cause you must reconnect every time and do the same operations x19 times - eh...
AD as I read didn't support Home Premium (or I misunderstood?) - eh again.
If there is no such tool\tools, what kind of OS (may be some Linux distributives) can do such thing?
Well,
Let me take this in three different perspectives.
1) Sharing the screen. There comes a hardware called as screen splitter (Use the one which requires power adapter)
Pros : scalable witout using Netowrking., No lag.
Cons : View only mode, Students cannot perform any action.
2) Sharing the desktop
As you have already mentioned, there are tools like teamviewer (Internet/LAN), VNC (LAN) which can be used. They require network access hence the connection might drop at time.
Pros: Students have simultaneous access to their machine
Cons: Connection may be an issue
3)Only sharing the resources
I dont think this is of your use but Active directory in windows and LDAP or LTSP on Linux is something which helps achieve resource sharing but doesnt help in desktop sharing.
IMO: You have to either go by 1 or 2. Both at the same time cannot be achieved with a legacy.
EDIT: My asnwer is considering you as a teacher and not sys admin. In the later case, tasks might be different which can be handled in various other ways.
Can we find if our software has been copied in an OS image (windows) and then deployed in another machine. The hardware details do change but it may be due to hardware upgrade or change.
Is there anything at software level which indicates that the OS image has been installed.
P.S the OS install date doesnt change after image deployment.It shows the date of original OS installation date and time and not that of the imaged one.
For example i tried to detect this using service tag,uuid and os install date changes . I thought the hardware and software details combined would result in correct detection. But the os install date dint change and hardware details changed or showed junk value during hardware upgrade . My software will be installed in the os . Then OS will be imaged. I want to detect the imaged installation
If your software is connected to the Internet this is relatively easy to solve. You arrange to 'call home': send occasional packets to a known server address containing enough information to identify the instance.
For this purpose UDP packets serve quite well. You include information about the build of your software, the operating system it is running on, some simple hardware details such as how much memory and disk, the IP address and the MAC address. From the packets logged by your server you will easily be able to tell an original instance from a clone, or an original with updated hardware in almost every instance. You may also be able to obtain highly distinctive information by a detailed inspection of hardware if you have sufficient privilege.
Please note that Windows does exactly this. If an activated copy is found running on a machine that is sufficiently different then it must be re-activated. The definition of 'sufficiently different' is not made public.
Just to be clear, what I'm describing is a heuristic, not an algorithm. I'll assume the original installation creates a GUID, and that a clone carries the same GUID. When you receive packets from installations with the same GUID containing enough information, in practice you will be able to tell the original from the clone in virtually every case. Two clones may start identical but very soon something will diverge: a network IP address, disk free space, active devices.
This may not fill all the requirements of the original question but it will work (it already does) and it's better than nothing.
Generate a GUID each time the computer boots, and include both the current GUID and the history of GUIDs previously generated each time you report to the server.
If a machine's report has a GUID missing, then you know the machine has been cloned and at least one new instance should be generated. You can determine when the cloning took place by looking for the last GUID that is remembered by both instances.
To determine which instance to consider "the same machine" as the original, if this matters, look for changes in the MAC address or computer name. If there is exactly one instance where neither of these have changed since the machine was cloned, that can be assumed to be the original. (If there are multiple instances with the same MAC address, something is badly wrong; bring it to the attention of the system administrators and let them sort it out.)
If none of the current instances has a matching MAC address and computer name, this might mean that the original machine has not been powered back up yet but will be eventually, or that it has been destroyed, or that it is permanently offline and only being used as a template. It could also mean that, by coincidence, the computer name and/or MAC address were changed after the machine was cloned but before the next report.
How best to deal with this depends on the context, but in most cases it would probably be sensible to show the original machine as a separate instance, even if you haven't had a report from it since the cloning took place, and let the system administrator manually delete it if appropriate.
On certain programs you can run them on a demo period for say 'ten tasks' or '5 hours' before you need to decide to purchase them to keep using them, but if you delete and uninstall the program then reinstall it, it knows that its been previously installed and wont let you run the demo again.
How does it do this ? When you download it does it send a identifiing number (ip ?) to the cdn to let it know youve downloaded it before, or when the program itself installed does it check to see traces of previous installation ?
Most "demo" software does this by a feature borrowed from malware: Incomplete deinstallation. A file or registry key belonging to the software is not removed on deinstallation. On reinstallation the software sees the remainder and can act on it.
Often-used hiding places for such a remainder were the system directory (before UAC arrived), but many register some class GUID - nobody I know of has a real overview of which classes in the registry are or are not genuine.
There are many ways this can be implemented.
The easiest way to implement (and also the easiest way to bypass)
On first run, create a registry (or text file) entry somewhere
Add 1 to the counter every time the task (or the app) is run
Do not include this file/registry in the installer app (so it will persist after uninstallation)
If at any time the count is too high, notify the user that the trial has expired.
Using image diff tools this method is pretty easy to identify and overcome.
The hardest method to overcome or bypass is to use a server. On the first run, generate a hash code based on the users computer name, drive serial number, etc, and post this to your server. The server then tracks this as a unique installation, and allows the app to run. Each time you run the app, you update the server. This way, the user cannot find the breadcrumbs and delete them, since they are on your server. The down side, is that this method will require an Internet connection.
There are probably much more sophisticated methods to achieve this result, but the above are both implementations I've run across.
My software drops breadcrumbs within the users system which is used to check for previous installations. This is a little harder to get around (assuming you don't know what you are looking for, or where) than an internet check against your IP. As you can always spoof your connection information, or just disconnect from the internet while installing.
I'm stuck trying to debug a problem which only occurs on my machine. It doesn't exhibit on any of the other devs' systems, nor on our production test server. I've tried pretty much everything I can think of short of completely wiping my hard disk and starting from scratch, or sneaking into the office in the middle of the night to swap my computer with someone else's.
This brings to mind the titular question, then: short of those drastic measures, what do you do when trying to resolve issues that no one else has? I'm open to advice that's general or specific.
[Not sure if this should be CW or not.]
Have you attached a debugger to the program to find the exact point of failure? That is what I would do first.
Sometimes third party software can be the root cause of these sorts of issues. Things like Anti-virus software install low-level filesystem and network drivers that can cause random intermittent failures. You can try killing all processes that aren't base OS services and your app.
Depending on your OS there are different tools that you can use to see what's going on under the covers. E.g. on Windows you can use Process Monitor to see what Registry keys it opens, what DLLs get loaded, etc. You can run this on your machine and on the success machines and compare to see if perhaps some required module is missing .
But seriously, use a debugger. That's what they are there for.
Two things:
I start with the obvious: What's different on your box? More memory? Odball PCI card? Different Microsoft APIs or service packs?
For oddball random software and/or OS crashes:
Check your system for heat issues.
Check your RAM for bad bits.
In this situation, I would try to check out the code and cleanly rebuild it from a different directory to make sure that there are no miscellaneous files in your working directory that are causing a problem.
If you are doing work against a database, I would also try tearing down the database and reconstructing it, possibly using a dump from another developer's machine.
Check the versions of any external third party software - database version, OS version, even software patches.
Look at the configuration on someone else's machine who doesn't have the problem and compare.
Get another developer to sit at your workstation and try to reproduce the problem and also go to their workstation and try it. True story - a fellow developer had a bug that he could only reproduce on his machine...it turns out that he was doing something slightly different in the GUI that no one else was doing (tabbing to a button and then hitting enter, everyone else just hit enter). It never occurred to him that other people might just hit enter to submit, because that "didn't make sense" to him.