You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In light of the recent exponential interest in this project @Endermanch and I have been working closely to help determine the best plan of action going forward.
My intention for this repository is to be a bit of a shared code base (if not eventually a shared library) that will do a significant part of the "heavy-lifting" for generating keys.
One of my personal requirements for this code is to take a Linux first approach, we start small and work our way up, if platform specific needs arise, we will handle them one at a time.
Thank you for your patience with us as we sort though everything and compare notes on our projects, we'll get things going shortly, the warm and positive repose from the community is all very overwhelming.
Update: 2023/06/11
In doing research to the extent of which products use PIDGEN/DPCDLL/LICDLL (and derivatives) I think its a wise decision to use some type of database to manage all this information.
I've started using an sqlite 3 db and intend to write a script that generate a keys.json file from it in the near future.
A SQL file (db dump) that can populate the database will be provided in the repo
[1] NB: One of my personal gripes with how we're handling keys is that private keys must be recalculated from the inverse (-Ky) of the public key or it is currently unusable to us. And while with modern machines this is more or less trivial to do, it doesn't feel right to me. There is a better way that is currently used by another keygen called mskey4in1 and I find it imperative that I replicate whatever algorithm the programmer there used first.
Edit: 2023/05/31 - figured it out! progress!
The problem (and main blocker) here is that collectively those currently involved with this project are somewhat novices at Elliptic Cryptography, both your patience is requested and anyone with hints/tips/tricks that may be of assistance is more than welcome to get in touch with us.
The text was updated successfully, but these errors were encountered:
In light of the recent exponential interest in this project @Endermanch and I have been working closely to help determine the best plan of action going forward.
My intention for this repository is to be a bit of a shared code base (if not eventually a shared library) that will do a significant part of the "heavy-lifting" for generating keys.
The components of which will be as followed:
An additional project related to this is the Telephone Activation utility which will ultimately be included in this repository: (See #1 )
confid.cpp
keys.json
filelibumskt
/umskt.dll
keys.json
)One of my personal requirements for this code is to take a Linux first approach, we start small and work our way up, if platform specific needs arise, we will handle them one at a time.
Thank you for your patience with us as we sort though everything and compare notes on our projects, we'll get things going shortly, the warm and positive repose from the community is all very overwhelming.
Update: 2023/06/11
In doing research to the extent of which products use PIDGEN/DPCDLL/LICDLL (and derivatives) I think its a wise decision to use some type of database to manage all this information.
I've started using an sqlite 3 db and intend to write a script that generate a
keys.json
file from it in the near future.A SQL file (db dump) that can populate the database will be provided in the repo
[1] NB: One of my personal gripes with how we're handling keys is that private keys must be recalculated from the inverse (-Ky) of the public key or it is currently unusable to us. And while with modern machines this is more or less trivial to do, it doesn't feel right to me. There is a better way that is currently used by another keygen calledmskey4in1
and I find it imperative that I replicate whatever algorithm the programmer there used first.Edit: 2023/05/31 - figured it out! progress!The problem (and main blocker) here is that collectively those currently involved with this project are somewhat novices at Elliptic Cryptography,both your patience is requested and anyone with hints/tips/tricks that may be of assistance is more than welcome to get in touch with us.The text was updated successfully, but these errors were encountered: