A common feature request for professional software is to prevent abuse of published applications. For licensing or security reasons, you may be requested to "lock" the execution of programs, maybe tools or services.
A common feature request for professional software is to prevent abuse of published applications. For licensing or security reasons, you may be requested to "lock" the execution of programs, maybe tools or services.
mORMot can use Asymmetric Cryptography to ensure that only allowed users could run some executables, optionally with dedicated settings, on a given computer.
This works with Delphi (from Delphi 5 and up) and FPC, and is full Open-Source.
http://blog.synopse.info/post/2017/03/18/Application-Locking-using-Asymmetric-Encryption
mORMot can use Asymmetric Cryptography to ensure that only allowed users could run some executables, optionally with dedicated settings, on a given computer.
This works with Delphi (from Delphi 5 and up) and FPC, and is full Open-Source.
http://blog.synopse.info/post/2017/03/18/Application-Locking-using-Asymmetric-Encryption
ok, if I understand well, a hacker have to change the "applock.public" key in the application and provide it's own encryption of user1@pc1.public to bypass the system, right ?
ReplyDeletePaul TOTH In fact, not exactly: applock.public is used for signature verification, not encryption.
ReplyDeleteBut you are right: applock.public shouldn't be replaced - this is why the executable should be signed. And without the .json content, the application should refuse to start...
....except for the need for supressing debug and reverse engeneering. With unprotected exe one can replace the system with some stub.
ReplyDeleteArioch The Just like other means of protection. You can also encrypt and/or crc the public constant and check it in several places in the code. But the fact that you receive some information, encrypted from the support, allows to put some additional lock external to the exe. Also note that reverse engineering is always possible. The fact that you use open code and known algorithms is a plus...
ReplyDeleteSee, mORMot is in many aspects described as a universe of its own, kind of turnkey solution. This time new mORMot featue is kind of hyped to be a solution "to prevent abuse of published applications. For licensing or security reasons, you may be requested to "lock" the execution of program"
ReplyDeleteI jsut pointed that it does not prevent it. Yep, it can be used to replace TLockBox or like that. And perhaps it work even better with selcted choice of ciphers than Lockbox would ever do.
While it is without a doubt a useful and probably interesting snippet - from personal experience, i think i was making a similar thing using Win32 CryptoAPI though, and it took me about a week - i need a very narrow funciton, notsomething general, but i also had to learn some quirks of CryptoAPI i never worked with before - it is now where close to "lock the program".
This "check the encrypted license document" thing is a "no trespassing" banner on the unlocked door, but nothing like a lock yet.
From the docs: "to safely ensure that only allowed users could run some executables, optionally with dedicated settings, on a given computer.". Sorry, i can not buy that "safely ensure".
Also, i find it very vague what is "a given computer". What if i take two system build from the same components, install Windows and your app on one of them, and then just clone the HDD? or i would not even clone it, but merely install the same Windows version and setting on the hardware-wise identical computer?
In my case CryptoAPI gave it for granted that program is associated with a given Windows installation, and it also meant that cloneing HDD would circumvent that protection with ease. It was known and accepted, and even kind of enforced over me by bosses. Wit hyour documentation that "safely ensures" no less than "preventing abuse of published applications" i can am afraid i see that part of the technical documentation more of marketing buzzwording, sorry.
"The location of those local user@host.* files is by default the executable folder, but may be specified via the aSearchFolder parameter - especially if this folder is read-only (e.g. due to Windows UAC), or if you use some custom GUI for the user interactivity;"
ReplyDeleteI'd say that most users - and individuals and enterprice office workers - would have problems with that. Both from inexperience and lack of Admin grants.
If you can ditch Win2000 and below and support XP+ then i think it better be some another folder.
If you're interested to develop the unctionality from that funcito nonword, mail me, we may try to exchange some ideas some potential usecases. OTOH if you just "scratched your itch" and published the building block, that other devels might learn from or integrate into their own scheme, then it is normal for FLOSS "take it or leave it" case and you don't have to extend functionality just because maybe someone somewhere would need it. Justthen i think your descryption of the functionality in docs and in forums was way too glorious. It is merely a one brick in the wall yet to be built.
...and there is much left to do. Like for example perhaps automatic blocking of the funcitonality, including perhaps patching OnXXXX form event handlers to destroy their actual code with "raise exception ELicense" stub or anything.
See, i do not question the quality or usefulness of his specific piece, i just challenge the description of it, as overly glorified, in my perception it is more of a tech demo, at least for now. The starting point to start building the "solution to prevent...." yet nothing more.
Arioch The Sorry if you find it too glorious, but you are right: this is the first step of a working system. I've removed the "safely" adverb, for accuracy.
ReplyDeleteIt will give you several aspects not obvious to develop in a cross platform way: asymmetric cryptography and DPAPI for instance. A brick to build upon... Just like other aspects of any framework. And it is not an alternative to LockBox, but complementary system. Its value is mainly how asymmetric keys are used.
About computer identification, if you clone the hard drive the windows dpapi won't work with the local secret file, so it will create a new public and secret. If you clone a full VM then Windows DPAPI will use a new key so the executable will accept the same .unlock key - but it sounds like a feature to me.
ReplyDelete