News: Z-Net v1.2 Beta and Z-Band

Tuesday, May 21, 2013

As mentioned previously, I released the ZNI v1.2 Beta on IRC. Ever since then I've been waiting for bugs to pile up before I try fixing any of them. This left me with some time to fill. I want to remain interested in working on the project, but doing so is hard when theres nothing to do. So I decided to get a jump start on my Z-Band revamp early. I'll discuss this later.

While I was working on Z-Band, circumstance brought up the topic of security for ZNI again. People abusing/looking for holes in ZNIs protocol hasn't been a problem yet, even now. But I don't want it to ever be. I've tried and failed to learn about implimenting encryption for the protocol messages 2 times before. The problem seemed to be that when encrypting messages, sometimes the characters for "\r", "\n", and "\0" would come up and pose problems. It seems to me that other people don't have these issues and can send those characters over IRC just fine. I don't know how though. Encryption among many things, I'm just not comfortable with, to the point of not even beginning to know how to solve an issue like that. While I have since discarded it, growing fed up with that issue halting progress, I decided to use a character substitution method for those characters. It wasn't a pretty work around, but it did work. I was finally able to move forward.

I soon realized though that encrypting the protocol messages alone wouldn't solve all my security concerns. I guess this is something I couldn't realized until I got to this point. After a lot of thinking I begin to realize what it is I truly wanted to protect. It's not the contents of the messages. It's the validity of the messages, and that's it. What I mean is, it doesn't matter that people know you selected a certain game or whatever if they can see the protocol messages. All I'm concerned with is for people not using ZNI to not be able to generate their own protocol messages, and potentially disrupt legitimate users. My original idea was that I had to hide the protocol messages to conceal their format to accomplish this goal. But I don't.

After more thinking I realized I needed a signature style setup instead. A signature setup being a encrypted code that marks the message as being a valid ZNI message. It took a bit of thinking with my newb brain when it comes to this stuff, but I figured out how I want to do the signature. I won't go into any details about it, but I had to go through several revisions before I felt it was good enough for my goals.

Any security measures I'd take wouldn't be perfect. Even if I wasn't a newb to all of this stuff. But I'm confident enough that my work is good enough for now. Average users won't be able to disrupt things by faking protocol messages. Real hackers, well, who knows. They're slowed down at the least.

I'll need to test things a little more, privately, before releasing this next Beta. I hope it goes well though.

Onto Z-Band. As I mentioned, I decided to work on Z-Band more while I was waiting for ZNI bug reports to pile up. Over the years I've revised the code many times as my skill has grown. But I've never been all that close to 100% happy with it. Z-Band doesn't support every game or version of ZSNES. I have to add such support manually. And with the code the way it was, doing so was a chore as well as messy. I've been wanting to revamp the code to a more generalized core function that requires minimal code additions to add new support. It's kind of difficult to generalize code when different games/emus require different code, but I've mostly done it! Again I won't go into details about the code itself. But after accomplishing that, I decided to test how easy it was to add new games.

Since the latest revamp, I only really had Super Mario Kart working. I worked on other games years ago, like SF2, GWED, and Tetris Attack (I thought I worked on Bust-a-Move but I remembered wrong), but those games weren't working with the new code. After a bit of work I added support to SF2 to the new generalized function. Then support for GWED to it as well. Tetris Attack however was the first game I could easily add due to the work on supporting GWED. It really was quite easy.

Now at 4 supported games, I wanted to see how well this generalized code revamp would work with completely brand new games. So I went at it, and easily added support for 4 more games, each taking maybe 15-30m, if even that long! I won't mention the 4 new games though. I'll save some news for later! =) And I just may not want to support them for some as of yet unknown reason.

Now with 8 games supported, I'm quite happy with the state of Z-Band's client side code for now. Progress with the client side code further puts a need on the server code needing advancment. I still don't feel like working on it though. I really want to leave this project for someone else. But doing that creates a roadblock in ever seeing this released.

So I decided to try an old idea I had for the Z-Band server. A IRC bot. It's not pretty, but it can do something. I already had the code posting results to the channel, for testing. It wasn't much to have this pointing to a IRC bot instead. A IRC bot only needs to confirm and log match results really. I'm quite comfortable with mIRC scripting, so its easy to create a basic bot with it for this. As is, this would just be used for tourneys, and require an official. The official would just review the log and announce round winners and pairings himself. I'm not to happy with this setup. Requiring to much manual attention and adjustment to me kind of seems to defeat the purpose of Z-Band.

As things are with Z-Band now, I'll have think about things more, and make things less manual, one step at a time. But the more I do, the more I'm working on some sort of server code, which I don't like. mIRC scripting or not. I want to stick with client code and that's it.

I don't like the idea of just supporting tourneys though. Z-Band was thought of for the purpose of rankings. I don't like the idea of handling rankings with a IRC bot though. Tourneys are fine, as the IRC bot no longer needs to be there afterwards. But rankings require the bot to be there almost 24/7. And is no different then the issue of requiring a central server, which the ZNI code attempts to resolve. While I am connected almost all of the time, I don't want it to be required for me to always be so in order Z-Band or ZNI to function. For now though, I might have to. Just to see the project move forward. And just require for people to understand that rankings would only change if my bot is present, it may be offline randomly, and they will just have to live with it.

What things I decide on to move forward, I have no idea. Atm I just know I'd prefer to have a php server, but I don't want to maintain it. A IRC bot would be easier for me, but I'd rather not maintain it either. And I know I need a server, period. For the ZNI website/forums, Z-Band php server, a IRC bot, or whatever.

As exhausting as these Z-Band dilemmas are, I'm still happy with the progress with the client code! =)