Suggeston: Better wincmd.key protection

Here you can propose new features, make suggestions etc.

Moderators: Hacker, petermad, Stefan2, white

AndrewCreator
Member
Member
Posts: 122
Joined: 2011-10-10, 23:25 UTC

Post by *AndrewCreator »

ghisler(Author), oh, I see. Could you tell whether $15 can be paid throw softkey.ru shop?
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50549
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

Currently not, but we can certainly arrange something if it should be necessary.
Author of Total Commander
https://www.ghisler.com
AndrewCreator
Member
Member
Posts: 122
Joined: 2011-10-10, 23:25 UTC

Post by *AndrewCreator »

Ok, thank you.
User avatar
l3x0r
Junior Member
Junior Member
Posts: 6
Joined: 2008-12-07, 02:50 UTC

:mrgreen:

Post by *l3x0r »

I have an idea that can solve this security problem, permanently.:idea:
An option for the user to bind the key to the local system used and to delete the original one or to move-it in a safe place. Such remaining key can not be stolen and administrators can access the original key for reuse and assume responsibility for its protection without having to worry about remaining key on the system.
Furthermore, if the generation of new keys is done online, the binding can be counted so that Christian can know if a user license is used on too many systems.
The idea would be a generated program code that combines the original key and the hash of the current system and would be placed on a site to download a personalized key or a direct generation to eliminate the use of a server; but then control is lost and no longer under surveillance if you understand me. :twisted:
But, mandatory, it must be only optionally to keep the portability and so both sides are reconciled. 8)
User avatar
l3x0r
Junior Member
Junior Member
Posts: 6
Joined: 2008-12-07, 02:50 UTC

Post by *l3x0r »

And by the way, in my opinion, the "registry key" is a disaster in case of errors or reinstallation, but "bonded key" can be restored from a backup for use only in the original system. And in this situation is safe in case of fraud or theft/hacking.
Thanks for a wonderful program you have made​​. Keep up the good work and let him become a real shell in the near future
User avatar
Sir_SiLvA
Power Member
Power Member
Posts: 3379
Joined: 2003-05-06, 11:46 UTC

Re: :mrgreen:

Post by *Sir_SiLvA »

l3x0r wrote:Furthermore, if the generation of new keys is done online, the binding can be counted so that Christian can know if a user license is used on too many systems.
What is "using on too many systems" :?:
Im using TC portable on countless systems....
Still your system is overkill - the way its now is easy enough for a 2man company :D
Hoecker sie sind raus!
User avatar
l3x0r
Junior Member
Junior Member
Posts: 6
Joined: 2008-12-07, 02:50 UTC

last idea and the desire final view

Post by *l3x0r »

Here is how i wish to make selection of how the program behave.
  • Installed Unprotected - Default
    Installed Protected - Binded
    Portable Unprotected - All files, settings and temps on the program folder.
I know that I wrote too much, but I think it's important for the proper development of the program to expose as well as possible the point of ours view as users even if some of us are programmers. :oops:
User avatar
l3x0r
Junior Member
Junior Member
Posts: 6
Joined: 2008-12-07, 02:50 UTC

8823

Post by *l3x0r »

Sir_SiLvA wrote:What is "using on too many systems" :?:
My ex:
I have a #***** 3 User licence for my pc/laptop/portable and i want to bind two of them for the safety but if the program detects that i binded my licente to another 2 -3 or 10 computers is ok because i can have that number or so, but if is detects over 100 computers is hard to think they all are mine.
Perhaps there are keys over #***** 100, but then you wonder if there is over 2000 uses, this is normal. if not then there is a problem
Im using TC portable on countless systems....
And this is way i stated to allow the portable licence active with all its implications.
Still your system is overkill - the way its now is easy enough for a 2man company :D
My "system", at least, local part of it, can be done very easy and offer a minimum security for the investment. It is about the local generation of encrypted keys with original key as source and use it instead of the original. This can be done with a simple algorithm, Personally, I use this method in some programs, and because the original key is removed from the disk, even I can not recreate the original key from an encrypted one, even though I know the encryption algorithm.
:arrow: This move will not stop the creation of patches or cracks but will protect the legit keys and I think this is all about.
AndrewCreator
Member
Member
Posts: 122
Joined: 2011-10-10, 23:25 UTC

Post by *AndrewCreator »

l3x0r, could you provide a bit more implementation details on your suggested solution?
Soumyanon
Junior Member
Junior Member
Posts: 2
Joined: 2009-01-19, 22:19 UTC

Post by *Soumyanon »

Why not attach the key as alternate stream to the executable or a certain (maybe random) dll. This means that the key is harder to find and goes lost if the file is emailed, downloaded or moved to an NON-NTFS filesystem. Also many packers don't respect the alternate stream and 'forget' to pack these as well.

Downside is that you can't use the program on FAT-formatted drives, but in those cases one can always fall back to an ordinary key file, which ofcourse does not have the additional protection. As an additional measure, you could encrypt the file on a way that there are two ways to open it:
- manually using a password
- automatically using a key stored in the users registry
When the program runs from an USB-stick for the first time on a new pc, it finds the keyfile and asks for the password and whether the pc is 'trusted' and should be able to open the key automatically. In other words:
  • the keyfile as it is now (using the async-encrypted key) will be encrypted with a random key (1) using a synchronous method.
  • the random key (1) is encrypted using a plaintext password as key (2) and appended to the file.
  • On each 'trusted' computer the random key (1) is encrypted again with another random key (2) which is stored in the registry for easy (automatic) decryption of the first random key (1) and in turn the keyfile.
  • Another option is similar to the last, except that the random key (2) is then stored in the roaming profile or Active Directory OR the key is generated from information uniquely available to the user. Such as the users private key on his or her EFS-certificate. This ensures the key can be automatically decrypted on every machine in the domain or forest the user has access to.
If the machine random key (2) is tagged with the machine-name and optionally an users description, the keyfile can be edited by the user to remove machines which are no longer trusted.

The later option could also be used with a centralized keyfile stored on a TC-server. However, I often work on machines that are not connected to the internet. So I don't like the idea of the TC-server as solitary way to keep the program active.
Post Reply