This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - ACagliano
1
« on: July 26, 2022, 09:47:11 pm »
UpdateHASHLIB is now on version 9.1, which brings the following feature additions and changes: (1) CBC-MAC is removed (2) An implementation of sha256-hmac is added (3) PBKDF2 is implemented (4) The API for hashes is revised. sha256_init/update/final have been replaced with hash_init/update/final and the init function takes an algorithm specifier. For example, `hash_init(&sha_ctx, SHA256);`. Once this is done, you can simply call hash_update/final on the context struct itself and the caller knows which algorithm to pass to. (5) The entire function set has been changed for more clarity. Yes, it's nice to have functions inside of a library identify the library they are from (ie: hashlib_Function) but I decided the new function nomenclature is more clear: // HWRNG (pools entropy from bus noise to sufficient entropy for a u32 per u32 returned)
csrand_init(), csrand_get(), csrand_fill()
// hashing
hash_init(), hash_update(), hash_final(), hash_mgf1()
// hmac
hmac_init(), hmac_update(), hmac_final(), hmac_pbkdf2()
// encryption
aes_init(), aes_encrypt(), aes_decrypt(), rsa_encrypt()
// misc
digest_tostring() // convert a byte-digest to a hex string
digest_compare() // timing-resistant buffer comparison
There is a compiler-time #define you can set if you are a more advanced user and want more backend access to the library functions. The flag is HASHLIB_ENABLE_ADVANCED_MODE. Those functions are: // ECB mode is not cryptographically secure (many-time pad vulnerability), but blockwise ECB mode constructors can be built into more secure cipher modes.
aes_ecb_unsafe_encrypt()
aes_ecb_unsafe_decrypt()
// direct access to the OAEP v2.2 encoder for RSA
oaep_encode()
oaep_decode()
// direct access to the PSS v1.5 encoder for digital signatures. This was added for working with SSL certificates but that was removed from the library when I decided that functionality was beyond the scope of the library. I felt like it would be more apt that an SSL library layer on top of HASHLIB rather than be built into it. HASHLIB is an encryption/hashing lib, not a protocol lib.
pss_encode()
// direct access to the modular exponentiation function hashlib uses, written by jacobly.
powmod()
In addition to this API change, HASHLIB also implemented two new internal features meant to provide some resistance to side-channel attack. Granted, that is hard on a calculator because the platform isn't really designed to resist that type of attack to begin with and you can only do so much in algorithm design, but the following steps help. NOTE: When using the extra functions in advanced mode, there is no guarantee those functions implement the following security mechanisms. Be aware of this when implementing. (1) Purge of the stack frame before returning control from any function that places intermediary encryption data on the stack. Code: https://github.com/acagliano/hashlib/blob/stable/hashlib.asm#L170(2) Temporary disable of system interrupts while performing sensitive computations such as hashing, encryption, and more. This serves to resist attempts to map the device memory via any connectivity system that uses system interrupt to operate. Interrupt status is saved, interrupts are disabled, then the interrupt status is restored. Code exists in many forms depending upon caller circumstance, but variations begin here: https://github.com/acagliano/hashlib/blob/stable/hashlib.asm#L44Any tips or suggestions for additional security, comments, questions, or concerns welcome.
2
« on: July 22, 2022, 10:32:39 pm »
Update 0.0.112This 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. (7) Module icons are now part of the ship metadata that is transferred with the "load ship" packet, not part of the assets pack that is sent separately. 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
3
« on: October 22, 2021, 09:50:28 pm »
yes, I post this on all three main forumsHASHLIB is a Libload-compatible library, I designed for use with the CE C toolchain [toolchain by MateoC (and others)]. It provides a fully-functional API for communicating securely with a remote host using NIST-standard encryption. HASHLIB provides the following: - A secure PRNG that produces ~96 bits of entropy per 32-bit integer generated and passes all Dieharders regardless of sample size.
- The SHA-256 cryptographic hash, as well as CBC-MAC authentication tags.
- An implementation of Advanced Encryption Standard (AES), for 128, 192, and 256 bit keys.
- An encrypt-only implementation of RSA for modulus size 1024<=modulus<=2048.
- Implementations of PKCS padding schemes for RSA and AES
- An implementation of SSL digital signature verification using RSA with SHA-256.
- A buffer comparison function resistant to timing attacks.
Special thanks to beckadamtheinventor for help with SHA-256, jacobly for help debugging the SPRNG and writing the modular exponentiation function for RSA, and to Zeroko for walking me through generating entropy on a calculator. Feel free to download and test against commonly used cryptography libraries and report back on compatibility or lack thereof. https://github.com/acagliano/hashlib/releases/tag/v7-RC1
4
« on: October 22, 2021, 09:37:09 pm »
How about OnlyTechs?
Jokes aside this is exciting. With the decreasing popularity of the forums in general and the waning interest in calculator programming (likely caused by the advent in mobile platforms), unifying the calculator community is in our best interests, not only to work together to facilitate interest, but also to show a more united front against TI's repeated efforts to hamper the community (sorry, this continues to piss me off). And not to be buttering people up, but the Omni, Cemetech, and CW forums couldn't be run by better people. I am excited to see how this works itself out.
The question I do have is the nature of the merger. Is Cemetech absorbing Omni and their designs becoming the same, with the staff teams merging? I would perhaps recommend considering a focus-based linking between the various forums, with omnimaga perhaps becoming a subdomain of cemetech that focuses on gaming, like it does, with the cemetech main site focusing on general utilities and programming aid/assistance, and other forums adapting their own specialty if they later merge. Be careful about a merger that spreads resources as well as veteran and new membership in a way that is hard to compartmentalize.
5
« on: February 24, 2021, 09:10:37 pm »
Well, me and beck are currently working on HASHLIB. It's a LibLoad compatible library that does general checksums, CRC, SHA-1, and SHA-256. That's already released, but it was done by me in C and converted to asm... Me and beckadamtheinventor (mostly him -- he's better with assembly) are re-implementing the existing routines in assembly to make them faster and smaller. https://www.cemetech.net/downloads/files/2123/x2282We also plan to implement a lightweight version of RSA, using an asymmetric 256-bit keypair. I've already implemented it in a python test server, now it needs to be done calc side so we can test. Essentially, the calculator would create a private key and a public key, and send that to a remote host. The remote host would do the same, sending its own public key back to the initiating calculator. Both local and remote hosts would dump the other host's pubkey into a buffer, and proceed to communicate over this psuedo-RSA framework. I say "pseudo" because RSA needs a minimum of 1024 bits to be considered secure, but this is a calculator after all... It remains to be seen if we can feasibly pull this off without a great deal of speed-loss in transferring data.
6
« on: February 01, 2021, 12:25:31 am »
Updates
CLIENT
A few mostly silent updates have pushed our latest version to 0.0.99. This latest version has a few small tweaks.
1) Firstly, the program now implements a minor change to the SRLDRVCE implementation that is believed to fix issues with Windows... The fix was actually within the SRL/USB driver packages, so you will need to update those as well.
2) The text input routine now wraps if you overflow the first line. It should do so without text shadow or graphical glitches but if any occur please report back.
SERVER
1) A few bugs in TrekFilter resolved... TrekFilter now properly handles packets with invalid characters. commandblockguy assisted me in testing throwing some invalid packets at it. It's not 100% bullet-proof, but it does a darn good job, being the first project in Python I did solo, as well as the first ever firewall-type thing I've made.
2) Client disconnect is mostly stable now... Rather than having the client send a Disconnect packet to trigger the user to disconnect, we simply detect the bridge disconnecting, trigger a custom exception that clears the socket and deletes the client from the dict. This also allows TrekFilter to interact similarly without triggering exceptions. Let me tell ya'll, I have come to love the `raise` command :p.
WEB DECK
1) The User Info and Interface tabs are combined into one tab, "Info and UI". This page contains your user information and lets you edit it, but it also can display your player stats, ship stats, and provides links to two tools, the model uploader and the asset pack maker.
2) The asset pack maker tool deploys convimg to assist users in generating their own asset packs, using the procedures outlined by convimg. You can upload replacement sprites of the same size or direct the tool to use the default. When every sprite is assigned to either custom or default, you can then build your appvar. The Web Deck implements lib-yaml to generate a well-formed YAML, and then runs convimg. This feature has been lightly tested, but to all potential users, feel free to have at it.
3) The ship model uploader tool is similar to the asset helper, in that it allows you to upload your own custom model to define your ship appearance. For now, I will ask people to not use this tool, as there is no size limiter yet. That is part of the purpose of the new 3D Modeling Contest I started in the Graphics section of this forum--to ascertain a good limiting size. The page also implements WebGL to render any existing model you may have uploaded onto the page for quick viewing. That render IS actually the file upload button.
Also, for anyone interested in testing out existing features, please note that in order to access the Web Deck, you must register first with the server using your calculator. This is a feature meant to prevent stray accounts from people who do not intend to play. I may ease that in the future for certain extenuating circumstances, but as of now it stands.
Also also, anyone who previously made an account on the system will need to do so again... during a config change, I deleted the accounts directories. Sorry.
Also also also, 3d frame compositing is planned to happen server side, with the server implementing opengl or pyglet to generate a frame for each client, a compressed RLET sprite, that is then rendered to the client through the standard graphx calls. As of right now that, as well as collision, are the main things that needs to be done before we are ready to start putting out actual playable releases rather than feature showcases.
Also also also also, for those unaware, the client-server will implement an auto-update functionality allowing clients to be served, and then subsequently install and reload, newer versions of the game upon connecting to the server without dealing with the hasstle of doing it manually.
7
« on: December 03, 2020, 01:11:11 pm »
UpdatesA few more 0.0.99-pre updates, and server updates: 1. Client now has support for unpacking assets sent by the server (aspects of terrain and player ship sprites will be sent to clients on the fly the first time they are needed, and cached on the calculator until the calc disconnects). The sprites will be zx7 compressed (but not RLET, since RLET sprites dont support Scaling and Clipping as of yet). When they arrive on the calculator, they will be decompressed to a malloc'd block of memory, then copied there, the pointer to which is stored in either a terrain cache or a player cache. 2. Client server-join procedure is streamlined and debugged. Client does not enter main loop until all parts of the join process succeed. First the client must see that the bridge is up, and that the request to connect to a server succeeded. Second the server must accept the client's version string (if your client is outdated but acceptable, you can still log in and an alert will print to log). Lastly, login must be successful. Once all of these succeed, you will enter the main game loop. 3. TrekFilter has seen some enhancements. It now runs in two modes, exclude mode and normal mode. In normal mode you must specify, in a JSON array within a file called "packet_whitelist.json", all the packet types you want the filter to inspect. In exclude mode, you are doing the same thing in a file called "packet_excludelist.json", except this time is a an array of all packets to exclude from inspection. The filter is distributed in exclude mode, for heightened security. 4. TrekFilter now logs repeat offenses to a file called "trek-f2b.log" in the filter's root directory. I have created a template file, "trek-f2b.conf" which is a Fail2Ban configuration file. I tested it with the command fail2ban-regex, and it appears to work properly. I welcome people to test it in deployment, as I am on the server currently. Details on TrekFilter can be found here: http://titrek.us/components/downloads/usersguide.php#Customizing%20TrekFilter
8
« on: November 30, 2020, 11:44:41 pm »
Updates! Updates! Updates!Version 0.0.99pre is still under development, but here is a few highlights for development so far. 1. Packets for MODULE_STATE_CHANGE, ENGINE_MAXIMUMS, and SETSPEED are now implemented at least in part. They don't check for certain statuses that might prevent the actions yet, but they do update, relay their responses to their calc, and have the effects propagate to your on-calc GUI. 2. The engine/speed configuration interface is now implemented. Accessed by pressing [Log]. You can scroll between your available engines, move sliders around to change your speed, then press [Sto] to engage your new speed. 3. With Debug Mode enabled in the client settings, the calculator now prints the Control Code and size of every packet it receives to the log widget. 4. Server-side, TrekFilter is now formally implemented into the service. TrekFilter is a custom firewall I made for the service, programmed to understand its protocol better than a system firewall could, and able to interact with your system firewall through the use of custom fail2ban jails. Here a screenshot showing new (and some old) progress. 
9
« on: November 23, 2020, 11:16:45 pm »
That's pretty cool  Security is important, I'm glad you're thinking it through now.
You think that's cool wait till you see what I scrapped the older security mechanisms in favor of... Will there be a way to reload the certificate without restarting the service? Possibly? I'm not 100% sure how to do that... and restarting the service is simple enough. I'm assuming there is a way to recover this as well in the back-end if the user forgets it?
Nope, because this security system has been (at least for now) removed. See the Update notes. UPDATE: Version 0.0.98 released- First Public Release with the Multi-Line log/chat widget, and 2-way chat ability. - Battery icons on the module stats overview tabs now indicate POWER_OK or POWER_WARN - "Particles" system implemented... displays some effects on the screen if certain conditions are true. - ---- First particle implemented - "Cracked screen" effect appears when the ship integrity is low. - And last but not least: Self-Contained, Custom, Service-Level Packet FilterThis particular bit of the server is not yet implemented, as it's still under development, but when complete, will wrap the packet receive portions of the server in a packet filter specifically designed to "speak" the TI-Trek protocol. The filter receives the connection descriptor, the `addr` info of the packet, and the data, as well as a format string, indicating the lengths and types of specific packet segments. First the filter checks the blacklist, immediately closing the connection to an IP that is on it. Then the filter performs a sanity check, looking for data that should not belong in certain parts of the packet (such as special characters in the usernames), and last but not least, it performs a threshold check, seeking how many times an offender has triggered the filter. If that number is over a specified hitcount, the offender is blacklisted. Blacklisted users are written to a fail2ban-compatible logfile every time they try to connect, post-blacklist. The filter also has the ability to search for extra modules and actions written by end users. Modules (checks) go in the `filter/modules/` directory; Actions go in `filter/actions/`. The "method" and "failaction" keys specify the check name and the response to a True response from the check. For a custom check/action, the value of that key is the name of the file to look for, and the code should be in `main():`. To see the current progress on that, check out the link below. Code for finding and loading the module provided by beckadamtheinventor. https://github.com/acagliano/titrek-server/blob/master/trek_filter.py
10
« on: September 27, 2020, 10:33:01 pm »
Thanks guys! Update - v0.0.95Planned to make this the full combat beta, but some security enhancements to the server and the whole setup make it necessary to release a client and bridge update before then. NEW FEATURE - Client-Side Server ListAs of right now, the server to connect to (through the bridge) is no longer controlled by the bridge's config file... it's controlled by the calculator itself.  Slot 1 is set by default and cannot be edited. Slots 2-10 are blank and can be edited (so that the game can connect to other hosted instances of the server). The client adds 2 new packets, CONNECT and DISCONNECT. Connect: Instructs the bridge to open a tcp socket to the server or host name following the control code in the serial packet. Disconnect: Instructs the bridge to close the current socket. * So long as the calculator does not unplug or disconnect from the bridge, you can connect/disconnect/reconnect without needing to restart the bridge. * * Special thanks to commandblockguy for implementing this change. * NEW FEATURE - On-Calc Mini-LogThe calculator has a 4-line mini-log, with each log-line buffered to 50 characters. This log can display errors, info, debug messages, and server broadcasts. The widget has variable height based on how many of the 4 lines it needs to display, and also remains on the screen for a configurable time. Default is 100 ticks. Any time a new message is written to the log, the clock resets.  And here is the new Settings interface to change the log timeout:  NEW FEATURE - Server Supports SSLThis may have been posted in this thread earlier, but the server is written with an optional SSL context. This can be enabled in the server config. The actual handling of certificates and renewal is not something the server does, so anyone hosting an SSL instance will need to handle ensuring their SSL config is up to date. The SSL path is also configurable, it just needs to be readable by whatever user is running this service. *As of right now, the bridge does not support SSL, so any SSL servers will be unable to be connected to.*NEW FEATURE - Verification-Based AuthenticationAs an attempt to dissuade connections to this service that are not from the calculator, such as random port probes or script kiddies, the server now implements a code-based verification system. When a user registers an account, an 8-digit code is generated and written to the user's account file, as well as sent to the calculator for display. You will be required to log into the web deck and input your verification code before you will be able to log in to the game server. This will allow us to filter unsolicited connections, as well as remove any anomalous user accounts created.
11
« on: September 10, 2020, 12:23:21 am »
A few teasers from the upcoming 0.0.94 release. 1) Custom graphics packs supported. To indicate that the graphics pack is custom made (so the client doesn't do a normal version check), you use the following settings in convimg, in addition to the normal ones. lut-entries: true
header-string: "\xff\xff"
Special thanks goes to MateoC for implementing the `lut-entries` option in convimg... it simply moves the offsets LUT into the appvar itself, rather than leaving it defined in the program. This allows the program to load any array of sprites as assets. You will still have to keep the same sprite order, however. Refer to the link I posted previously for details. 2) The splash screen has been completely reworked.  The menu interface is cleaner, and the networking status is indicated by icon now, instead of by text. A green USB icon indicates that the serial device is ready, a red icon indicates some error. If we implement nanotube, or internetce support, an icon will indicate if the program is preferring that connection. 3) The program now alerts you on the splash screen if your graphics version is incompatible.  The incompatible graphics is triggered in one of two ways: a) You are using a default sprite pack and the version header does not match the one set within the program's `reqd_version` array. b) You are using a custom sprite pack (version string 0xff, 0xff), and the number of sprites in the LUT does not match the number of sprites in the program build. Either of these being the case causes the above alert to show up, and the "Play Game" menu option to just return you to the main menu. All splash screen and error/alert icons are built directly into the program to ensure they are available... the asset pack only supplies stuff used for the game.
12
« on: June 09, 2020, 01:50:20 pm »
I posted this to Cemetech and now am here and will also on Codewalrus. I would even propose calling TI's bluff on something. Write TI a letter, signed by a EVERY major calc development community - Cemetech, Omnimaga, Codewalrus (unity is important on this), informing them that if they do not revise their decision on C/asm, and implement exam security in a way that is conducive to teaching, learning, and doing programming, we the community will be designing, releasing and marketing our own calculator to compete with them. And if they do not walk it back.. actually follow through.
There is no action legally they could take to prevent this: it would be our own hardware and programming, no copying of names, symbols, anything. Free market, people can compete with whoever they want.
13
« on: June 08, 2020, 05:43:56 pm »
UPDATEProject TI-Trek has now been successfully compiled with full USB support... using srldrvce. Due to wonkiness in CEmu's usb support, it is no longer possible to test networking on the emulator (the lib cannot initialize the driver properly). I will need to move to on-unit testing for the remainder of client-side development of this project. I have gotten written the ntwk_Login(), ntwk_Register(), and ntwk_Disconnect routines, which are the first aspects of gameplay that will be tested. While I have been hard at work on client-side things, commandblockguy has been working on a USB=>IP bridge similar to the one Kerm devised for gCn over DirectUSB. And last but not least, beckadamtheinventor has been hard at work developing the server side of things... from map generation to control codes and saving/loading data. For those interested, the server is written in Python, runs on port TCP 1701 (the registry number of the Enterprise), and uses json for long-term storage. It stores connection descriptors to an array of Client objects, which also contain the IP address, username, and some more information about the connected user. The game will implement semi-accurate space physics. When the map generates, the server pre-generates some paths for celestial bodies using formulas for things like gravity and inertia. Those objects will follow those paths every tick, scaled to the time-rate of the game. In addition to fluidity in space (meaning planets, starbases, etc will not be in exactly the same spot every time you look for them), other objects will pose a threat... black holes will exist and end your journey very fast. Stars will tick their life cycle and then die in a manner determined by their size. Major celestial events, such as star death or planet destruction will result in a path-adjustment for entities within gravitational range of the changed section. Also, after discussion with beck, another feature will be added to the game, called a synthesizer. This component will allow you to interact with materials you own on a molecular level to enhance them in certain ways. For example, say you place a piece of tempered steel into the synthesizer. You can then select from reserves of any type of element, and the properties they enhance/detract from will most reflect their actual chemical properties (toughness, deflection, malliability, heat resistance, etc). Say you choose to combine the tempered steel with a type of element that increases toughness but decreases heat resistance. You would wind up with steel (hull plating, for instance) that provides a boost against projectiles and physical impact, but is damaged more by heat sources, phasers, and the like. You could also, for instance, infuse your hull plating with a mineral that enhances magnetism, which in turn enhances your shield deflection. And if you attempt to combine unstable materials, you could, for example, wind up inflicting feedback damage to an attacking enemy, but also winding up with vastly increased damage to your own ship. For anyone wishing to have a look at the code-base so far (yes, it will need some optimization), here it is. I will say, in my opinion, at least the network handling is remarkably well-organized... for what I usually do. https://github.com/acagliano/titrek-calc
14
« on: October 01, 2019, 05:39:01 pm »
UPDATEProgress has been made on the User Interface for TI-Trek. Here are some screenshots: The Main Systems module overview screen The Tactical Systems module overview screen The module configuration/info popup, accessible by pressing [Enter] on chosen module Some changes to the power system setup also. Module efficiency (how well it performs its task) will be a function of module battery charge (current power level * 100 / max power storage) multiplied by power draw setting (set power draw / base power draw). Power draw meaning how much power a module will take from its source (core, auxiliary, or internal reserve) every power cycle. Each module will also have a maximum draw, which is the maximum amount of power a module may be set to draw before the module incurs a damage penalty every power cycle. For instance, if the module's max draw is 8 and you have it set to 10, the module will take 2 points of damage every time it draws power. This means you can set a module to use as much power as you want, to super-boost it, but keep in mind the higher you set this, the faster the module takes damage.
15
« on: September 01, 2019, 10:57:42 am »
Placeboware... basically every antivirus software ever made :p
Back to the question, TI-Basic does not have the capacity to scan a program, even by name. So yes, they're just trolly, cool-looking things, that in reality do nothing.
My Blast File Integrity Software program does actually scan programs and appvars for user-contributed strings of malicious code, and retains checksums and file sizes to see if a file has changed, but this is more akin to a file integrity software than a malware scan. It's also written in C, which compiles into assembly, hence why it CAN do this.
Aside, considering the current impossibility of getting a "virus" on your calculator, all of these programs, including mine, are completely superficial. However, as the capabilities of these things improve, a time may arise when they may be at least partially useful.
|
Show Posts