I am currently working on an application which will audit computers, and one of the things that it is mandatory for this app to achieve is to get the license key from the install of OEM windows and Retail Office, in order to retain this information for future purposes, such as re-installation and move from one machine to another (this part is more for office).
The requirement here is specifically NOT to use any apps that already find keys, this is a BIG no no for the project.
The goal is to have a comprehensive audit of the user's PC:
hardware info, software installed, user account name, pc name, domain currently used, workgroup, antivirus used, running processes, startup processes, and LICENSE KEYS. And it has to be custom tailored for this specific purpose, so retail apps are instantly out of the question.
Now I am very confident I can do everything myself. Frankly, I already did 50% of this. Where I am stuck is finding where the license keys are stored within windows.. It has been eluding me for a week now.. Internet searching only refers me to sites that offer the easy and lazy option of using a pre-made key finder.
Initially I thought that these would be somehow squirreled away in the registry, but a plaintext search of my own personal Office key returned a great big nothing. Which leaves me to wonder if these keys are stored in the registry, are they perhaps in there as HEX? Or encrypted?
Or if not, where could they be stored?
The literally used keys are not stored on the computer.
However the registry contains a value which is based on the original key. There is software (which you stated is "a big no no") which you can use to calculate the original key based on these values.
If you want to do this yourself then you might want to take a look at bytes 34 through 42 from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\DigitalProductId (for windows). Office uses something similar.
Related
I know that in Windows, the GUID is used by the Windows Installer to check for already installed products under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ and other product-relevant information is stored using the compressed GUID in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\.
Yet a google search to figure out what the compressed GUID actually is and why both forms are being used for saving product-specific data in the registry database only revealed algorithms for converting from one form to another.
Apparently, the compressed GUID is calculated from merely changing the order of the characters in a specific way, giving me more confusion about why this is the compressed form and why it is used this way.
Additionally, some sources appear to refer to the GUID as the product code of the software product, and others specifically use the term product code as a synonym for the compressed GUID.
I do not have much knowledge of the inner workings of Windows and its installers, but hope that someone can enlighten me with the information I was unable to find. I apologize in advance for my mediocre English.
Not sure what you are doing, or why this is a problem for your scenario. However, the GUIDs you mention - the rearranged GUIDs with the braces and dashes removed - are actually referred to as Packed GUIDs. Then there are also Compressed GUIDs that are just 23 characters long that are primarily used to create Darwin descriptors - which are combinations of the product code GUID, a feature name, and a component code GUID. They are used for MSI's advertisement features. This is according to Bob Baker's book "Getting Started with InstallShield Developer and Windows Installer Setups".
As far as I recall the packed GUIDs are apparently used to make registry searches more efficient. I am unfamiliar with the exact technical details involved. Perhaps Bob or Rob of WiX can elaborate.
I have to run, not really an answer, I will look at it again later. Please elaborate your question with more details on what the problem actually is. As a summary it seems the collective comments suggest that this GUID concept is due to registry space saving, searching efficiency and obfuscation.
My advice (if I understand correctly): do not attempt to read packed or compressed GUIDs from the registry directly - rather go via the MSI API (COM / Win32) - which should have the features you need to do almost anything with MSI.
Some Links:
MSIEXEC -Embedding
MSI API Links (quite similar links):
Is MsiOpenProduct the correct way to read properties from an installed product?
Wix upgrade goes into maintenance mode and never does upgrade
how to find out which products are installed - newer product are already installed MSI windows
Is there an alternative to GUID when using msiexec to uninstall an application?
The packed guid is reportedly used to save space in the registry. It is used for component Ids, so once you start getting a million components on the system I assume they were worried about the extra space usage. It's also possible it was used to prevent people trawling the registry to look for Windows Installer items instead of using the APIs. It's an undocumented implementation detail, and if too many people got into habit of using the registry instead of using the APIs there would be issues if that implementation changed. So treat this as interesting information, not something to use in an application.
Darwin Descriptors are different - they are just an encoding of product code, component id, and feature name. They occur in various places where that combination of data is useful for loading COM servers, starting programs etc. Again, it's undocumented, but if you wanted to untangle them you could LoadLibrary on msi.dll and find and call MsiDecomposeDescriptorW with the right parameters.
Is it possible to get a file's UID (owner) on Windows? I tried to use FileInfo.Sys(), but it only works on Linux. I'm really stumped on this one and can't figure out how to get the UID.
The first problem is that file systems native to Windows which supports file/directory ownership do not have the concept of "owner UID" simply because Windows users have no UIDs either.
The security of the Windows NT line or kernels is implemented using the so-called "access control lists" (ACLs), and security principals (such as users) are identified using the so-called "security identifiers" (SIDs). A SID is a variable-length multi-field data structure usually passed around as a byte array.
Another complication is that a file on an ACL-enabled Windows file system might have no owner at all (and no ACL attached to it as well); this is rare but possible.
So... If the part of explanation stating "there's no such thing as the entry owner's UID on Windows filesystem" is OK for you, this is all there is to it.
If not, and you actually wanted to ask "how do I get security information for an entry on a Windows filesystem?", the question gets more complicated.
AFAIK the stock standard library shipped with Go does not have the necessary wrappers around the relevant bits of the Win32 API. So to implement this, you'll need to either wrap them yourself (it's not that hard, after all) or try to find a helper package.
Just thought I'd run this idea past far more experienced heads.
I've made a desktop application in java 8. It is a niche app that will be sold via a single website. The market is individuals in a specific work environment who would not be "tech-savvy", and who are either on or chasing a 6-figure salary. My client, the publisher/vendor anticipates sales of maybe (don't laugh) 50-100 per year... so it's very niche. The retail price of the software, because of the low volume and niche setting, is to be around $100. So it's just a pet project that maybe helps to fund the family holiday at the end of the year.
The target customers will be on a high enough salary to not worry about paying the premium for the software (tax deduction anyway), which will directly enhance their ability to make more money, but they also have a reputation for having few scruples, and would generally not care about casually copying the software and giving it to their work mates.
The software will not be able to connect to the internet, so it's stand-alone, isolated.
So I need a copy protection scheme that is simple, not onerous to the end user and, due to it's target market and low volume, doesn't need to be "hacker-proof".
So this is what I've come up with:
Vendor has a "password" generator, that uses a simple algorithm, an
adaptation of the Luhn formula, that is capable of a few million
unique 8-char strings, out of a total possible pool of a few hundred
billion. So a valid password would be very hard to guess. Software
downloaded, generated password emailed to customer.
Software checks the "password" for validity, using a checksum-related
scheme. If valid, software is unlocked, and an invisible file is created somewhere generic on the hard drive, which flags that the software install is valid.
A different invisible file is written to the parent folder of the
software, which contains the provided original password. This is storage for passwords that have already been used, and are therefore invalid.
Next time the software is launched, it checks for the existence of
the validated-flag-file-- if it exists, then the software launches,
otherwise it asks the user to contact the vendor for a new password.
Whenever a user needs to type in a new password, the software checks the "invalidated passwords" file. If the user types in the original password, the software won't launch, because it's invalidated. But the file also needs to exist in the parent folder, so it cant be deleted either.
The idea is that if a casual user copies the software either by itself, or with its parent folder the software wont work on another machine, even if they have the original password, but if they are legitimate (registered user who needs a copy for working at home etc) then they can contact the vendor for a new valid password, that will then work on the new copy.
Hope that makes sense.
Comments, suggestions?
Full disclaimer: I work for Link Data Security and is your competitor, but this doesn't stop me from giving a few advises, as badly made protection damage the whole copy-protection community.
First of all you need to look into how hackers crack your program and try to deffend against their usual attacks. That would be debugging, changing your code when testing for validation, copy of key/validation-file and many more. This is the things I can remember from the top of my head. There will always come new cracking methods, due to hackers being very creative people.
If I was you I would try to run my program in a sandboxed enviroment, see what it does. Then make sure that files created or such doesn't help the hacker to find a good way to hack your protection.
Next time the software is launched, it checks for the existence of the validated-flag-file-- if it exists, then the software launches, otherwise it asks the user to contact the vendor for a new password.
From your description of your program I find it worrying that copy/move of your validated-flag-file to a new computer seems to break the copy protection. Also finding invisible files is the first thing a new hacker will learn, so this is the same as no protection.
A colleague of mine wrote a tutorial on what to take into consideration when making copy-protection, maybe this will help you on your way to being a copy-protection expert: All About Copy Protection
I've built a program via MS Access 2007 that I distribute via Microsoft Access Runtime. My clients do not have Access. Recently I've received multiple request for the application to be available for Mac. The volume of requests is low enough that it's not economical to rebuild the entire program in another language.
What would be the most economical method of allowing users to use the software on a Mac?
Is LibreOffice or Wine an option in this case, or is the only option for the user to purchase Windows and use a virtual environment?
LibreOffice Base: Extremely unlikely. Even if you were to get Base to connect to the Access tables it almost certainly would not be able to use the Access forms, reports, macros, VBA code, etc..
Wine: Worth a try, but I wouldn't be at all surprised if there were issues, quite possibly serious ones. According to the WineHQ page here, Access 2010 gets a "Bronze" compatibility rating, meaning
Application works, but it has some issues, even for normal use; a game may not redraw properly or display fonts in wrong colours, be much slower than it should etc.
That same page lists "Visual Basic" as one of the things that did not work under Wine when it was last tested.
If I were you I would give the latest version of Wine a quick try to see if things have improved but I wouldn't spend more than a couple of hours tinkering with it. I suspect that a Virtual Machine running an actual copy of Windows is probably the only real option in this case.
I have written a software which I would like to bind to mac. Is there any specific algorithm to bind mac address with my software? Thank you for help !
Edit:
I want to provide serial number according to user's mac address.
The comment above is right - the MAC address is widely used for node-locking, but it is a poor choice as it is easily changed in OS.
A more secure approach is to use a combination of hardware and software system parameters, such as hard disk ID, system name, user OS login name, CPU ID etc.. The selection available will depend on the specific OS and programming language you use.
However, to avoid problems down the road, I'd suggest you think about the following:
How do you obtain the system parameters? If you ask the user to provide them there is opportunity for human error, such as entering a '1' for an 'l' or a '0' for an 'O'. Then the license won't work and the user will be inconvenienced.
What if the parameter you lock to changes, say if the user upgrades their system by changing a piece of hardware? Will it break your system and need the user to request a new license from you?
What if the user wants to move their license to another system, or to a new machine? Can your licensing system allow this without making it easy for the user to run one license on both the old and new systems?
These are the kinds of issues that cause home-built licensing systems to annoy legitimate users, and not be very secure against would-be hackers.
Commercial licensing systems should of course have dealt with these and other issues already.
Write MAC Adress into a kind of license file.
On startup read the MAC-Adress and compare it with configured.
If not equal --> stop with error.
To create a unique serial number out of a mac address you have to apply an algorithm to macaddress. There are some comercial tools for that for you professionally.
Some thoughts to licensing can be found here and here
I take it you're looking to achieve some sort of node-locking of your app to a specific device. If so, you might be disappointed to learn that the MAC address is not always a persistent value on a device. In fact, some devices have multiple MAC addresses, so it's not a particularly reliable value to use when looking to find a persistent hardware ID to bind to.
Our solution for Node-Locking Licenses to a device at LicenseSpring (we specialize in this sort of stuff) is that we generate a device fingerprint by hashing the serial numbers of some of the hardware we read on the device (such as the CPUID + BaseboardID + SystemDiskID). When the end user retrieves the license key, they use that hash along with the license key to perform a license check, which is computed on the fly. The license key is set to only be usable on a finite number of devices, so if another device tries to use the license key, they will compute a different hardwareID and be blocked.
So long as you're hashing those serial numbers in the same way, you won't run into any trouble...
You CAN store information in the key itself, such as product info / device info etc.
but I would also advise against that. Mainly because there's only so much info that can fit into a key, and then it makes it quite easy to reverse engineer.
Instead, I'd suggest you use the server response from the online license check to send back license entitlements as well as signing the server response, and use that to control the state of your application.