DF-41 mod for OrbiterSim simulation


hydrogenpi

Junior Member
Registered Member
Not sure how many people ever heard of or played the OrbiterSim spaceflight simulation... its way more realistic than the cartoony KSP (Kerbal Space Program) and I been using it ever since the good old days, but it hasn't really caught up in terms of graphics and cannot compare visually with Space Engine with procedurally generates a static universe or entire Hubble volumes of galaxies, stars, planets... however they always had a good SDK and I sometimes dabble a bit in Visual Studio/C++ and wanted to see if I can create a mod for the DF-41 add-on...

The 3d model will be done in 3ds max and then the programming of the mod in Visual Studio... now that I'm working from home I have a lot more freetime to spare.

There are not a lot of good information on the performance and specs of the DF-41, can anyone point me to references and resources that could shed more light on this weapon system? Like what parameters for its flight path, entry angles, how the MIRV system works and how evades incoming defenses etc It would be usefully in incorporating that in creating a mod/addon since OrbiterSim is very realistic and the better the input the better the output... even Apollo moon landing mission can be simulated on it including emulating and virtualization the Apollo Guidance Computer and DSKY system itself!

Please, Log in or Register to view URLs content!
Please, Log in or Register to view URLs content!


Orbitersim and its SDK are free... 3ds max is a paid product by AutoDesk but they offer free 30 day trials and if just to view 3d objects they have a free viewer called FBX Review

Please, Log in or Register to view URLs content!

If interested you can check out the model with the free viewer
Please, Log in or Register to view URLs content!

1586398539054.png


1586399228664.png

 
Last edited:

hydrogenpi

Junior Member
Registered Member
  • Thread Starter Thread Starter
  • #2
So you see in movies like WarGames and Salt and and Crimson Tide and whatnot about launching nuclear missiles and needing to authenticate the code before launching? I'm trying to set up some form of authenication progress that the player will have to enter into the game via a virtual keyboard /interface of some sort before the missile will start the firing sequence...

This will likely involve not only a baked in authentication mechanism in the game (Unreal Engine) but also a standalone key generator to produce the keys that the system will then validate against.

So I'm thinking when attempting to launch the DF-41 the player will be presented with a 25-character long string of alphanumeric codes that are randomly generated on the fly by the games built-in authenticator and this is presented to the player as the Challenge Code.

Player then sends the challenge code to CCP central command (in this case a third party who has access to a the keygen or key generator application be it a windows binary or hosted on some html5 website) providing the challenge code as the input and the key generator will generate the authentication code as output.

The authentication code is also a 25-character long string of alphanumeric characters but it is generated using a combination of several different things. One is the current date/time value of the clock (YYYYMMDDHHMM) of the system running/hosting the key gen application. A second component is an initial hardcoded CONSTANT (CONST) "seed value" number (integer based) that is embedded in both the keygen application and the games authenticator during/at initial compile-time. And of course a third component would be the provided challenge code. All three components, (date/time), Seed value, Challenge code, are concatenated into a combined string value, and then this long string is ran through a secure one-way hash function such as SHA512 hash... the hash can also have variable rounds, so as long as during compile time the authenticator and the keygen agree on the number of rounds of iterations (hashing and then hashing it again and again) then the more hashes the more secure it would be against brute force attacks.

After the final round of hash is finished (assuming the hash round iteration is greater than 1) then that output string is encypted using PGP function (the keygen's public key is already stored in the game's authenticator program and vice versa) by the keygen applications with that of the authenticator's public key so that only the authenicator itself can decrypt and unscramble the string that will be sent from the keygen back to the authenticator (no plaintext is ever sent)

Once the launch codes are sent back to the DF-41 authenicator device it uses the PGP part to decrypt the auth code back to plaintext. Since it already has the private key of itself hardcoded into the application this does not require user/gamer to input any PGP password. Once the final authentication code is plaintext form is inputted into the authentication field of the authenticator it will run a series of checks to see if it is valid. (The PGP part adds an additional layer of security because even if the attacker figured out the algorithm and method to calculate the auth code from the challenge code and built its own keygen of sorts, will be useless unless they also have access to the public key of the authenticator because without that it won't be encrypted and won't be a properly formatted string/code.)

Namely, no more than 5 minutes should have passed from the time the authenicator presented the user with the challenge code to the time the user enters the auth code. Since the authenticator was the one who originally generated the random 25-character long string of alphanumeric codes for the intial challenge code it can compute the auth code by running it against the seed value and the challenge code itself and then that of the system date/time in YYYYMMDDHHMM format. Since there is a five minute tolerance on either side, this means it will need to run 10 different calculations, each for a different minute value integer of time component. It compared the auth code it recieved against the 10 different values that it calculated and if it matches any one of them then the nuke is unlocked and ready to fire, if not, then it disables the nuke after three failed attempts.
 

subotai1

Junior Member
Registered Member
...Since the authenticator was the one who originally generated the random 25-character long string of alphanumeric codes for the intial challenge code it can compute the auth code by running it against the seed value and the challenge code itself and then that of the system date/time in YYYYMMDDHHMM format....
You're over thinking and making it too hard. That's not even done in reality. Seed and Salt values are actually significant weak points and are not random. Highly suggest looking up how SSL Certificates are created ->signed -> stored -> compared -> invalidated and so on. And keep in mind that the modern equivalent of the one time pad is still the most secure code.
 

hydrogenpi

Junior Member
Registered Member
  • Thread Starter Thread Starter
  • #4
You're over thinking and making it too hard. That's not even done in reality. Seed and Salt values are actually significant weak points and are not random. Highly suggest looking up how SSL Certificates are created ->signed -> stored -> compared -> invalidated and so on. And keep in mind that the modern equivalent of the one time pad is still the most secure code.

yes, a variation of the OTP is what they use on for example the nuclear submarines
it is mathematically proven OTP cannot be cracked even by quantum computers since the passcode is basically the same length as the entire message length
there are no true random number generators, even random.org has a device collection fluctations in the atmosphere, and most security applications require user to move mouse and type keyboard to generate some more entropy in the random process.

OrbiterSim allows planetary level of N-body simulations (no relativistic stuff since modern rockets don't go near lightspeed c) but the graphics in orbitersim is outdated engine back in 2016 and even then it was not state of the art. Unreal Engine 4.25 is the best general purpose gaming engine and one can easily import assets from 3ds max, maya, blender etc but afaik it doesn't natively support large scale gravity simulation of large bodies... you cannot have a map that big it has to be partitioned into chuniks

So to get a good DF41 simulator that has great graphics and accurate missile trajectories would require somehow connecting the two... like a lot of people were flying the old DOS precision simulator 744 for its systems accuracy and then graphics tied to the FSX for the good looks... using simconnect api or something along those lines.

Otherwise the best I could do is probably create the DF41 as a drive-able vehicle somewhere in a small simulated island (Fiery Cross) in the South China Sea and have it launch the icbm and then explode it a couple miles away as a sort of demo sandbox testings to see the nuke effects since the map wouldn't be big enough to do the whole multistage separation and the MIRV thing...



Please, Log in or Register to view URLs content!
 

adiru

Junior Member
Registered Member
Made some progress on the DF-41 so far, next step is to implement the code authentication process prior to nuclear launch...

 

adiru

Junior Member
Registered Member
Unreal 4.x uses c++ so I finished the code for the authentication portion, need to make a interface/gui so that the user can recieve the challenge code and input the correct corresponding authentication code prior to the DF-41 platform proceeding with nuclear launch process.. I've written the code and implemented it in a 2D DEFCON strategy game that is also sourced in C++ as proof of concept that this works...

Finally I need to do the missile as three stage and then create the nuclear effects when the warheads get MIRV'd and each go off...



Eventually my goal is to recreate the Ferry Cross in the South China Sea, have the DF-41 be able to launch a nukes to any place in the world.... with a target list of cities that the user can choose... after he successfully provided authentication... on android app...





Please, Log in or Register to view URLs content!
Please, Log in or Register to view URLs content!



Please, Log in or Register to view URLs content!
who happens to be a moderator on /r/sino gave me some tips on the warhead was too pointy and I need to redo the mesh/model of the warhead inside of the launcher tube thingy....
 

Attachments

Last edited:

QianXuesen

Just Hatched
Registered Member

Added the ability for dome cap to seperate from the main missile tube body since it was suggested to me by ZeEa5KPul that the dome doesn't open up like a door hinge but in fact seperates completely.


Looking into how can do explosions/smoke in true 3D volumetric format... right now it will have to be use simulated with particle system effects...



I think I got the authentication portion fully working in-game now. It will be a 3-D "physical" authenticator device as opposed to just a 2-D widget or HUD interface and eventually have all the keys clickable with settings like using this for player to set dynamically in-game the heading/bearing of the rocket after launch, how many MIRV as payload, select city/location as target, etc etc but for now it serves as a functional authentication component, since the launch code would ostensibly have to come from XiDaDa in order for the nukes to fly....
 

Top