Updates

Registration process changes, security model partially upgraded.

I have been doing a bit of improvement work on some aspects of the account management for this game. I have decided to move the initial account registration off of the calculator onto the Web Deck. When this change is complete (it's in progress now), attempting to log in to an account that does not exist will no longer allow you to register from your device, it will prompt you to visit the server's frontend to create your account. This is done to facilitate the follow upgraded security model. Trust me, ya'll don't want to know how bad it was before.

1) Firstly, registration on the Web Deck is now protected by recaptcha. Login does not have it.

2) Secondly, the server generates you a login "key" that will, when used from a calculator, grant it access to your account. This key is generated from your username and hashed password, using PBKDF2 (SHA256 mode), with 1000 iterations and a 16-byte salt (using PHP's built-in hash_pbkdf2() method). That resulting key is then hashed using PHP's password_hash() (bcrypt) which is saved as your "public key", and the private key (output of pbkdf2) is written into a TI application variable, which you can download from the web deck and send to any device you want to allow access to your account.

2b) It so follows that any changes to your account password invalidate any existing key files that you are using.

3) I have...after much experimentation and failure...finally figured out how to prevent Apache from allowing hot links of certain file types. I used this to protect all database files accessed by the website, as well as all .8xv and .bin files from being directly downloaded. As for why I struggled so much with it... let's just say that some of the "this is how to do it" you see on the Internet are so very wrong.

4) I may add some form of obfuscation to exchanging the login key with the server, if I can figure out how to do that.
Edit: For now, the key is exchanged with the Trek server using Blowfish (which I've added to hashlib)
The server generates a secret when you connect and sends it to the client and that is used to create the blowfish key. I may swap that out for something else when I get a bit better at this stuff.

Project Feature Question

Figure I'll put this here and let people sound off.
Regarding TI-Trek's ability to support custom assets players upload, both for terrain and for UI elements, which method of handling this would people prefer?

1) As is -- players can use the Web Deck to upload custom sprites to replace the defaults, then have a replacement graphics appvar generated that they send to their device in place of the default one. This requires end users do much of the work of keeping their graphics up to date.

2) The UI elements are served by the server as binary data and streamed to the client after successful login. Where a user has a custom sprite defined, that is served instead of the default one. Those sprites are cached into an appvar that is retained on the calculator. However, whereas in #1 the appvar would be in convimg's format, this appvar would be in a slightly different format for each sprite ( <sprite_short_name><sprite_data_size><gfx_sprite_t>). Names would correspond to their identifier on the server, allowing individual assets to be updated if need be. Data size would also be included to allow the client to seek to the correct sprite in the file. Users do not need to maintain the graphics files themselves at all, the server and client handshake on each sprite to ensure it is up to date.

Update 0.0.103

Fully automated graphics and client self-updating is now supported. When you connect, first the client version you are using is hashed and that hash is compared with the hash of the binary used by the server. If they differ, your client will be updated to the one hosted by the server. (Aside: this means that if a different server requires an earlier version, you still need to do nothing... it will be downgraded automatically).

Once you log in, the same process occurs for the graphics (this occurs post-login because some users may have custom graphics).

Of course in both cases, the integrity and completeness of the download is verified by hashing it, and if the hash matches, the client is reloaded or the graphics are initialized, otherwise the server is asked to begin the transfer again.

Update 0.0.110 now live

This update brings a number of features, improvements, and enhancements.

1. Firstly, on the server side. The website--http://titrek.us and the Web Deck got a face lift.

2. Secondly, the user-generated keyfile now uses a 256-bit salt, instead of a 128-bit salt.

3. The Server List interface is now altered. No longer do you have to input new servers manually to a list. The Server List is now a cycle-through interface, where the number of available servers is determined by how many distinct keyfiles you have present on your device. In this way, you can have multiple keys for one server, or keys for more than one server, and there is no longer a hard-limit of 10.

4. The hostname metadata is now included in the keyfile. This means a user will not have to enter in the server ip to connect to themselves. Assuming the hostname for the TI-Trek instance is the same as the host generating the keys, the hostname the key is attached to will be right in the keyfile. It is read out and sent to the bridge when connecting.



Also it's worth note that I sort of upgraded my CEmu pipe branch to a more recent branch, and upon realizing I could no longer use it for testing (and screenshotting) because the USB device fails to initialize, I re-installed the pipe branch, but I cannot get libpng-apng to work yet. Haven't quite given up on it yet, but for now, no animated pngs.

Update 0.0.112
This update is still under development.

I have recently undertaken a complete rewrite of the core of this project. This was done for a number of purposes. Firstly, the game was already coming it at ~37kb in size, and with much of the functionality still to go, that was quite large. Secondly, I wanted to reorganize some of the code. I also wanted to respond to some of Mateo's criticisms of my exorbitant use of global variables in the code by removing them where possible. There are a few other changes as well.

(0) The current size of the build, with much of the old functionality re-written, is at ~16.5k, which is currently half the old size.
(1) Fontlibc is now utilized, as well as a custom font.
(2) Better console implementation. It's a chunk of memory that writes in and cycles out as needed rather than an array of static "slots" for console entries as it was previously. This also means that there is no character limit per log line apart from what the buffer can hold.
(3) Network fallthrough initialization. There are constructors for TCP (currently a null placeholder), Serial, and CEmu pipe mode. The network devices are tried in that order, defaulting to the first successful initialization, or erroring out if all of them fail.
(4) Code uses the latest serial and usb drivers, meaning things should work on Windows.
(5) The progress indicator for client updates is now a loadbar, not some text.
(6) The splash screen and server selection is completely revamped. Splash screen network-up icon indicates the device that is connected, be it an Ethernet cable for TCP, a USB icon for serial, or a pipe for pipes. The server selection screen no longer requires the user to input server IP's... that information is now metadata within the keyfile generated by the server.

Feast your eyes on some screenshots:




And lastly, courtesy of beckadamtheinventor:


The rewrite branch of TI-Trek can be found here: https://github.com/acagliano/titrek-calc/tree/rewrite

This is really cool.

Updates

Real life has been getting in the way of development of many of my projects, but there have been some recent updates.

Firstly please join me in welcoming TKB Studios to the dev team. They've been presently assisting with implementation of graphics rendering server side while we formulate a final map format and while I continue the rewrite of the server and client. Be advised that the updates are not yet live.
In his short time with us, TKB has managed to produce a dummy map and do a few rendering tests, using as a stand-in for astronomical textures, a certain billionare's face.


On the backend, the RSA and AES keylength are no longer user-controllable. Both use the maximum keylength supported by CryptX: 2048 bits for RSA and 256 bits for AES. The cipher mode used by the server for credential encryption is now GCM.
https://github.com/acagliano/titrek-server/blob/rewrite/core/clients.py#L165

Additionally the server now uses TInyAuth for user authentication.
https://github.com/acagliano/titrek-server/blob/rewrite/core/clients.py#L175C4-L190C47

I will need to figure out how to handle re-implementing the web-deck since authentication now passes through TInyAuth. This may be the time to implement an actual OAuth handler for web-based access to services that would otherwise use TInyAuth from the calc.

Additionally, I have begun work on setting up defaults for ship modules.
https://github.com/acagliano/titrek-server/tree/rewrite/data/init

Curious if this is still beeing worked on? Seems really cool! The pictures on your posts are dead links now...

It is, but progress is on hold awaiting lwIP completion. Now that that is about to see a public beta, I'll probably move this project along a bit.