Quick comments on hax

[Guillaume Loetscher]

Hi,

Just a small comments about your games.

First, I managed to launch it from Debian 7. I just installed "openjdk-7-jre", and that's all. Good job on this (as I saw countless java software developped on Windows that were not working on Linux and vice-versa).

I spent a few minutes trying to launched Hax from the base directory, before checking the "tutorial" folder, reading the README, and understanding that I've to chdir to the "tutorial" folder, and launch "hax.sh" from there. It's not that hard to understand, but IMO, that's not very convenient. Most users will see "hax.bat" or "hax.sh" and will try to fire them directly from the main folder, which will fail. Maybe updating the "Getting started" page to mention to place yourself in "tutorial" folder, before firing "hax.sh" ?

Finally, I found the SHIFT + LEFT ARROW / RIGHT ARROW not convenient at all to recall your last commands. Why don't you keep the Linux way (UP / DOWN arrow) for that ?

Keep it up !

[Hax Simulator]

Hello,

thank you very much for your input.

As for the first issue, I definitely get your point and agree with you. Furthermore, the next version will have a campaign included, so there will basically be two folders where to start Hax from. Thus, I will reorganize the folders a bit, so that from the root directory you will be launching the tutorial. I will also add a mention of the necessity to start Hax from the folder where the data center configuration (dc.groovy) lies, on the "Getting started" page and also the tutorial itself.

As for the second issue, yes, it needs getting used to (I myself had problems with it too). The keyboard shortcuts are out-of-the-box functionality of the DragonConsole component I am using for the consoles, and the component does not support their configuration or a change using simple inheritance (for the Java -literate, the history of commands is stored in a private field rather than a protected one). As I generally didn't want to modify the code of third party components I used, I left it as it is. However, since I know what you are talking about, and I also found another problem (during development of the campaign), that the out-of-the-box length of the command history is too small, I will try to address these things in the next release. I think the license of the component allows to modify it under some conditions, but I must look into it in detail.

Cheers

[Guillaume Loetscher]

Your game / simulation is for now only focused on command line. As a linux sysadmin, and a gamer who like hacking game, I'm ok with that, but this implies that the command line interface utilization has to be smooth.

To be honest, if we talk about just the "game" aspect, it sounds to be kind of hardcore. There's other hacking games which are GUI based, and that are more simple to handle (Uplink / Onlink as an example). Right now, bash, sh, or even Windows terminal are all using up and down arrow to recall history command. If you stick to the "command-line" only, I don't think that changing the shortcut used by a lot of users is a good move.

[Guillaume Loetscher]

Got some time to finish the tutorial number 1. Here's some comments about it :

• It said that you can't use the '..' file other than alone (cd ../home for example is not working). Is this a constraint that will be removed in the future ? Because using the '..' file in complex path is something very common on linux.
• Why asking for the ">" character to advance in the tutorial ? Maybe a simple "blank" entry is enough to advance to the next step of the tutorial ?
• This is more a wish than a comment, but having the auto-completion called with the TAB key would be awesome (again, very common on linux systems).

Cheers !

[Guillaume Loetscher]

Comment for tutorial two :

• I'm will be very picky here, but the "ifconfig" command used to know which IP configuration your ethernet interface has, is now deprecated on all recent Linux distributions. I don't know how close you want to stay to linux commands, but if so, you could use the "ip" command instead.

[Hax Simulator]

"Command line" : I will definitely stick to command line. First, I have no skills, abilities and artist feeling to create the graphics themselves. Second, I don't want to get stuck on focusing on the GUI aspect too much, like it usually ends up with such projects. And third, the project that inspired me to a great extent (the one I am right now reimplementing the campaign of) was also console-based, but nonetheless very captivating. However, the core of Hax is not limited to the console. The interface of simulated devices is a simple input and output of byte streams. So, if someone created a protocol for graphical input/output, wrote an operating system communicating using that protocol, and a GUI that could handle input and output in that protocol, Hax would become graphics-based. But it is really no priority for me. If someone wants graphics, they can go play Uplink, Onlink, Kite (when it comes out) or others.

".." : HaxOS is a prototype OS. It lacks a lot of features - multiuser, permissions, file attributes, some basic file operations, support for multiple network interfaces and harddrives, and I could go on and on. In that list you could also find complex file paths using "..". Although HaxOS is on my list of areas to be further developed and enhanced, that list contains many more items, and I do not have them all prioritized. Like I mentioned, my dream about Hax is a community-driven mode of development, with me providing the hardware and firmware framework/api, and the community providing the software running on the framework (roughly expressed). I plan not to focus too much on the software side in the beginning, hoping to build up a community of people interested in developing software for the Hax platform, including OSes. However, as my hope is probably in vain and the dream will remain a dream, I guess I will eventually end up improving HaxOS or writing a better OS for Hax machines myself. I just do not know when that will be.

">" : It is just how I started doing the tutorials. If I find the time, I will look back on the tutorial framework and see if I can change it to a blank. You are right that a blank would be more convenient here.

"auto-completion" : Basically, the same applies as for the answer to the ".." issue, as this is again a feature of the OS. Furthermore, this will remain impossible to do until I start modifying the DragonConsole component, as it does not support sending special characters (like Tab) down to the emulated keyboard device of the Hax framework. So do not expect this anytime soon.

"ifconfig" : I might drop the ifconfig command in favor of a "net addr" command. I don't want to mention or use "ip" anywhere in Hax right now, as the networking in Hax does not implement the actual IP protocol (although it has some things in common). So instead of e.g. "IP address", I am using "network address" throughout the project. As for the command set, although HaxOS is modeled after Linux, it definitely is not my intent to constrain it to Linux commands only.

Cheers

[Guillaume Loetscher]

Just a small note : my comments may sound very picky / annoying, but I just wrote them as they were coming.

Of course, some of them are too big to be implemented, and as you are so far the only developer, you have to pick your battles. I totally get that, and respect it.

Also, even if I'm interested by what you are trying to build here, I can't help you, as my knowledge in Java is null (I only have a decent programming level in Python).

I'll try to find some time to finish the other tutorials.

Cheers.

[Hax Simulator]

I am definitely NOT annoyed by your comments.. :)
User feedback is exactly what I need and I am thankful for any of it. So just keep it coming if you got the time.
As a side note, Hax programs are written in Groovy, not pure Java. Groovy is a scripting language much like Python. If you're interested and have the time, try to look around a bit on their site, they even have a comparison with Python there.
Cheers

[Guillaume Loetscher]

Hi,

I don't have particular comments on tutorial 4. Initially, I had written a few lines, pointing every time you have become distant to the "real world" (switches that "route", switches that broadcast, discovery of the destination network address not done by the client, etc...)

But the end of the tutorial is quite clear, and says explicitely that you are not copying real-world, but adapting it to your needs, so I'll not bother you with those comments. My only concern is that, you are apparently implementing something between the real-world (IPv4 addresses, routing, CIDR, etc..) and something new (switches that broadcast, no OSI level 3). So, those who knows how real-world network is working can be suprised by how it's working in Hax.

My only question will be : will it be possible to assign router configuration using CIDR notation ?

Cheers

[Guillaume Loetscher]

Just finished the tutorial 5, it was cool. I can definitely see some space for a "build your own hacker" adventure, where you buy some new and more powerful hadware, some software to help breaking security, etc...

You have build something interesting here, I'll definitely keep watching the future version.

Keep it up !

[Seyi Oluwasanmi]

Hello Hax,

I've just played through all the tutorials, and my first question for tutorial one; 

Is it possible to see the folders in a directory? The tutorial made mention of viewing files in a directory with the 'ls' command, but it made no mention of viewing folders.

Secondly, is it possible for you to include a help command for both the telnet interface, and the home(command prompt like) interface?

And finally, do you plan on incorporating any aspects of multiplayer into this game at all?

Cheers

P.S I'm excited for the next version; Can't wait to try out some campaign missions.

[Hax Simulator]

@Guillaume:
As for switches, I think the way they work is quite similar to the real world. I just might not have used the correct terminology in the tutorial.
Switches in Hax do not actually route. They simply select the outgoing network interface for a packet based on its destination address and a mapping table. If the address is not found in the mapping table, they do what I called broadcast, but I guess the correct term would be flooding.
In fact, the difference that is there I guess, is that even routers themselves do not route. They also simply select the outgoing network interface for a packet based on its destination address and a mapping table. The difference is that the mapping table is static, and can contain various subnets.
Another difference is the absence of some of the real world OSI layers you mentioned. However, it is not level 3 (network), but layer 2 (data link). Hax has no MAC addresses, no ARP implementation etc. LAN networking in Hax is done using layer 3. Also, no data fragmentation occurs in Hax, data is always sent as a complete chunk. I decided not to implement these things to keep it small and simple. In my opinion, many of these things are just a result of historical development and exist only because of historical and economical reasons. But of course (and I will again repeat myself), all of that could be implemented if the need and will arise.
As for CIDR, I'll put it on the todo list (I think I should publish it somewhere...), but certainly not in the upcoming version.
Cheers

[Hax Simulator]

@Seyi
Hello, welcome to the group. I'll try to answer your questions:

- files and folders: the 'ls' command as it is in the 0.9a version only lists files. e.g., if you have files /home/test/1.txt and /home/test/2.txt, then issuing "ls /home" will not give "test" (as probably expected), but "test/1.txt test/2.txt" as a result. This will be changed in the upcoming version, where the 'ls' command will work as expected. I have to however mention that the file system of HaxOS is rather primitive. Internally, folders themselves are not physically stored, only files are. A simple map structure is used for this, and the files are indexed with their full path name.

- help command was added to my todo list, but don't expect it in the upcoming version yet

- multiplayer: it is already there. What you can do is to interconnect two instances of the program running on potentionally different computers. You can define any network interface on any machine of your datacenter to be published. The published interfaces in two different data centers can then be linked. They then act just as if a wire was between them. All of this is fairly simple yet, I plan to extend and improve it a bit, and then I'll post a detailed description of the feature. As I wrote in one of my blog posts, it would be ideal to host a public datacenter for people to connect to, but I don't see that anywhere in the new future. Lest someone from the community is found who is willing to do it.

Cheers