I have a program that is using a configuration file.
I would like to tie the configuration file to the PC, so copying the file on another PC with the same configuration won't work.
I know that Windows Activation Mecanism is monitoring hardware to detect changes and that it can tolerates some minor changes to the hardware.
Is there any library that can help me doing that?
My other option is to use WMI to get Hardware configuration and to program my own tolerance mecanism.
Thanks a lot,
Nicolas
Microsoft Software Licensing and Protection Services has functionality to bind a license to hardware. It might be worth looking into. Here's a blog posting that might be of interest to you as well.
If you wish to restrict the use of data to a particular PC you'll have to implement this yourself, or find a third-party solution that can do this. There are no general Windows API's that offer this functionality.
You'll need to define what you currently call a "machine."
If I replace the CPU, memory, and hard drive, is it still the same computer? Network adaptor, video card?
What defines a machine?
There are many, many licensing libraries out there to do this for you, but almost all are for pay (because, ostensibly, you'd only ever want to protect commercial software this way). Check out what RSA, Verisign, and even microsoft have to offer. The windows API does not expose this, ostensibly to prevent hacking.
Alternately, do it yourself. It's not hard to do, the difficult part is defining what you believe a machine to be.
If you decide to track 5 things (HD, Network card, Video card, motherboard, memory sticks) and you allow 3 changes before requiring a new license, then users can duplicate the hard drive, take out two of the above, put them in a new machine, replace them with new parts in the old machine and run your program on the two separate PCs.
So it does require some thought.
-Adam
If the machine has a network card you could always check its mac address. This is supposed to be unique and checking it as part of the program's startup routine should guarantee that it only works in one machine at a time... even if you remove the network card and put it another machine it will then only work in that machine. This will prevent network card upgrades though.
Maybe you could just keep something in the registry? Like the last modification timestamp for this file - if there's no entry in the registry or the timestamps do not match then fall back to defaults - would that work? (there's more then one way to skin a cat ;) )
Related
Suppose for an application which will never receive internet connection during its lifetime, how can you prevent the piracy of the software?
There cannot be a single product key requirement during installation because, once installed legitimately anybody can copy the installation and re-distribute it.
So every time the application runs it should check for something and crash if the check fails.
Now what could it possibly check?
Initially I thought keeping an encrypted binary file will do the job, but as answered here, that seems a negligible prevention.
Any hacker can modify the executable so that instead of crashing when the check fails it should continue running.
So no matter how difficult the check is, the cracked application will always run.
Now I cannot see any possible solution to this problem.
PS: I am a single independent developer who is developing productivity software with very low charge. Seeing this question I believe I just have to let it go. Sigh....
EDIT: I would like to thank all the contributors in this discussion in letting me know the grim reality...
What I understand now is that you are indirectly submitting the source code of your application in the form of the target executable. Its source code can be modified by anybody using a debugger, thus ANY method of preventing piracy through source code of your application is useless. The only possible solution to this problem is to keep your legitimate customers happy by providing them services (apart from the software) and keep your price below their expectations.
I was think of solving this problem for past 3 days and now all seems worthwhile but still learnt a lot in this process, which I wouldn't have otherwise...
I ha
The only standalone thing I've seen that is semi-effective is hardware keys that come with the boxed software. They used to attach to a parallel port or a serial port and get checked when you started the program.
AutoCad and similar programs used to do this, but it is a BIG PAIN for your customers. Any time it doesn't read it, or a key goes bad, customer productivity suffers. It hurts your legitimate customers far more than those who end up pirating it anyway, and a sufficiently motivated pirate can make a VM that will overcome this. Modern versions of this use USB.
My recommendation is to trust people. Upon install, make them click a "I promise I paid for this" button and be done with it. If they click "I didn't pay for this" show them a small paragraph about how to help keep good software coming and prevent customer-harming DRM schemes by simply contributing to the success of good software authors.
You could generate a unique copy for each user, create a database, and check it agents copies you find online if you like playing the biggest game of wack-a-mole ever.
I've been looking into centralising my computer game saves to make it easier to backup and restore as well as putting them up on the cloud via dropbox but there in so may places that it makes it quite difficult. I noticed the Windows 7 and Vista now support Symbolic links so I've been playing around with that but I was wonder the follow:
Is it possible (code example or a point in the right direction) for an application (vb.net or C++) to spoof a file or folder?
E.g. Application A (a game like Diablo III or Civilization V) attempts to read or right from file A (the game save), application B (the save repository) detects this read/write request and pipes the request through itself preforming the request on file B (the actual game save in another location). Application A is in no way altered and treats the file normally.
Note: I realise there are many simple ways of preforming the same task in essence such as monitoring the use of Application A or periodically checking file A and copying it if it has been altered since the last check etc but all these methods have draw backs and less interested in making it work than if it is possible.
It is entirely possible to do this through a file system filter driver. For information about these, take a look here:
http://msdn.microsoft.com/en-us/windows/hardware/gg462968
Filter drivers can hook into CreateFile operations and redirect the create to a different place if you want, but they are much harder to write as compared to normal applications. They run in kernel mode and must obey the limitations of drivers.
You can "fake" special folders, like control panel does, but I don't think you can create anything accessible/writeable (in an easy way). I might be wrong though. I had the same idea once too (as a compatibility step for some company stuff), but couldn't find anything supporting an easy way to do it. It seems like it might be easier to be done on Unix systems (but that's obviously no option here). Also, I wouldn't expect any nice or easy solutions for .net.
Only approach I could think about right now, would be highjacking the according API calls (e.g. FileOpen) to reroute/manipipulate them (similar to what root kits do), but I wouldn't say that's a good idea, considering it might be detected as possible malware or cheats by things like punkbuster or antivirus solutions.
Yes or no depending on (using your terms) the level of abstraction that Application A is using.
If Application A is performing a CreateFile wto start access and passing a fixed filesystem path then Application B would need to emulate a file system and do so in the kernel.
On the other hand if Application A were to user HTTP with RESTful URLs then the HTTP server could answer all requests from files or by dynamically creating the content.
So the question can only be answered in specific by knowing the details of Application A.
I'm looking to create a "driver" I guess for a custom file system on physical disk for Windows. I don't exactly know the best way to explain it, but the device already has proper drivers and everything like that for Windows to communicate with it, but what I want to happen is for the user to be able to plug the device in to their PC, have it show up in My Computer, and give them full support for browsing the device.
I realize it's probably a little scary thinking about someone who doesn't know the basics of doing something like this even asking the question, but I already have classes and everything constructed for reading it within my own app... I just want everything to be more centralized and without more work from the end user. Does anyone have a good guide for creating a project like this?
The closest thing I know of to what I understand from your description is an installable file system, like the Ext2 installable file system that allows Windows computers to work with
Linux originating ext2 (and to a certain degree ext3) filesystems.
Maybe that can serve as a starting point for your investigations.
As an alternative approach there's the Shell extension which is a lot less complicated than the IFS. The now-defunct GMail shell extension used that approach, and even though it's become nonfunctional due to changes in GMail, it can still serve as inspiration.
Your options are:
Create a kernel mode file system driver. 9-12 months of work for experienced developer.
Use a framework and do everything in user mode. A couple of weeks of work to get the prototype working. The only drawback of this approach is that it's slower, than kernel-mode driver. You can play with Dokan mentioned above, or you can use our Callback File System for commercial-grade development.
I think you need to look through the Windows Driver Kit documentation (and related subjects) to figure out exactly what you're looking to create.
If you're intending to rely on the drivers that already exist, i.e. you don't need to actually execute your code in kernel land to communicate with it, I would recommend you take a look at FUSE for windows Dokan
If you indeed need to run in kernel space, and communicate directly with the hardware, you probably want to download windows DDK (driver development kit). Keep in mind that drivers for communicating with a block device and filesystems are separated, and it sound like you're talking about the filesystem itself. I believe that anything you run in kernel space will not have access to the c++ runtime, which means you can only use a subset of c++ for kernel drivers.
I'm developing a small windows app using c++ and i would like to get some kind of fingerprint of the software/hardware on a pc so that i can allow the app to be run only on certain pc's.
I am aware that the app can be cracked but i'm really interested in implementing something like this.
Any ideas how could i achieve this?
It basically depends on how tight you want to couple your software to the underlying hardware. For example you could get some hardware information from the registry, read out the MAC address from the LAN card, retrieve the gfx manufacturer, the CPU id, etc. and hash all these data.
You could then use this hash as a challenge code which is sent to your company. The customer then receives the signed (with your private key) version of this hash.
Upon start up your application is able to check if the signature of the hash is good or bad (i.e. has been signed by your company).
This not only binds your software to a certain hardware configuration, but also forces the crackers to patch your application (because they would need to patch the public key from your executable and replace it in order to write a keygen). Many people consider twice installing a crack obtained from various sources in contrast to just entering a valid serial copied from a keygen.
Edit:
In order to check the signature of the hash, anything from RSA over DSA to ECC can be used. I can recommend Crypto++ or libTomCrypt for that.
There's no reliable way known to do this in a vanilla PC; people have been trying for years. The problem is that you might change any component at any time, including the CPU and the BIOS ROMs. The closest people have come is using a cryptographically protected "dongle" but that has proven both to be unsatisfactory in operation, and not very secure.
If you come up with something, patent it; it would be very valuable.
As the others have said there is nothing perfect for what you want. I made a half-hearted attempt for a similar issue and ended up with a mix of drive volume ID (not good because it can be reformatted) and the OS key (from windows).
In the end I didn't spend much time on it as if people really want to crack your software they'll probably be able to do it. I left the dinky licensing "protection", but it is pretty poor.
Spend the time/effort on making them want to buy it by making it outstanding.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm an MFC programmer. I just had my first taste of Vista (on a VPC... Yup, I'm late). I should be evaluating things in depth in the coming days. On taking a casual look, I noticed two major changes:
The shell is new
User Access Control
Event Viewer has changed (would like more info on this)
What other new features should I look out for from a programmer's point of view?
There's a significant set of changes depending on what sort of software you write.
It's never a bad idea to check out the Windows Logo Certification (for Vista). There's a link to the Software technical requirements here. It always gives you a bit of an idea what to avoid doing (and what to design for).
In my opinion, Vista mostly started to enforce [existing] Logo certification requirements, in particular:
Don't write to HKLM
Don't save application data under the Program Files directory
Don't assume administrative permissions
Do save data to the user's application data directory
Regarding User Access Control (new to Vista), It's also a good idea to get across Manifest files. The best thing I could find on them is this blog entry here.
Windows Drivers are under higher scrutiny under Windows Vista and pretty much require certification IMHO.
The TCP/IP stack was rewritten and so too the audio subsystem (and multimedia streaming etc). Obviously advances in graphics, plus the inclusion of DirectX 10 and usual rollout of an updated Media Player, etc.
Sorry, I also forgot to mention that Microsoft replaced ActiveSync (for Windows Mobile) with a completely new framework in Vista.
Vista is much more strict about enforcing rules that you were supposed to follow for XP anyway.
For example, you're not supposed to do anything that requires write access to your program's install folder. In XP a lot of programmers got away with breaking that because so many users run as adminstrator, but Vista will actually enforce it. A bunch of folders did move around ("Users" instead of "Documents and Settings", my Documents is different, etc), but if you're using the correct methods to retrieve those paths rather than assuming they're always in the same place you'll be fine.
Perhaps wikipedia's Features new to Windows Vista and possibly Features removed from Windows Vista will be of use to you.
Processes and resources have "integrity levels". A process is only able to access resources at or under its own integrity level.
If you ever do any work with IE extensions this will become a PITA when you want to access something and discover that everything has a higher integrity level than IE in protected mode (default).
Well, from a programmer's point of view, WPF is "built in" to the system. That means that if you target an app to the 3.0 version of the .NET Framework, it should be able to install on Vista without a .NET Framework Install.
DirectX 10 is also new in Vista, but I assume if you didn't know that, you probably won't be programming against it.
Search is pervasive. Numerous kernel improvements. SuperFetch (friggin' awesome if you have enough RAM). IMO Vista goes to sleep and wakes up a LOT easier and more reliably than XP ever did. I/O priority -- now apps like AntiVirus and search indexers can request lower priority for disk access than they did in XP or before. That makes the user experience much more enjoyable when something's indexing the drive or a scan is running. All in all, Vista is good stuff IF you have gobs and gobs of memory to throw at it. I run Vista x64 with 4GB of RAM, and I actually like it.
The audio subsystem has been redeveloped, so if you do anything audio related it is worth checking very carefully if everything still works.
Although many of the older API calls still work, some may not work as expected.
As a simple example, sound devices have much longer and more descriptive names than in XP, but if you continue to use the older APIs then you may find these longer names are truncated.
Oh, yeah. There's a completely different driver model where much of the code is kicked out of kernel space and back into userland, to prevent poor drivers from trampling over the system. So if you do any driver work it's almost like starting over from scratch.
1- Machine with Vista have usually more Ram, this is a good news for you :)
2- Path to "Program files" are splitted in 2 : \Program Files (x86)\ and \Program Files\
3- My Document has changed
VIRTUALIZATION is also an interesting and necessary feature of vista.