Tuesday, April 1, 2014

Plans with Hax

I would like to inform you about some of my future plans for Hax.

I know this might impose problems due to possible high expectations and disappointment when some things do not work out. However, I want to give you some motivation to stay with the project, or even participate on some of my plans. I have not yet decided how exactly to proceed with Hax after the initial alpha release. Before I do, I need some feedback from users. However, I already considered and thought about areas in Hax where improvements are necessary or desired. Here they are.

NAT, firewalls and proxies

The family of networking components in Hax definitely needs to grow. Currently, Hax only supports global network addresses, where any two interconnected machines must not have the same address. This is of course difficult to achieve when the number of interconnected networks gets higher. NAT devices would solve the issue by allowing to use internal address spaces on local networks and one single public, globally unique address for the whole network. Implementing NAT is an absolute must in my opinion. Also, when it comes to network security and hacking, the concepts of firewalls for filtering network traffic and proxies for forwarding network traffic are important as well.

Backbone

I would like to start an internet backbone for Hax. This would include an authority for assigning top-level network address ranges on user request. Along with the range, an access point would be provided, allowing the user to connect his data center to a backbone router. This way, local networks of users could be interconnected easily. This would of course require me to set up a server running the backbone data center, having to hire a virtual private server or dedicated server from a hosting company. Or find someone in the Hax community willing to provide a server for this.

Network protocols and tools

Of course, communicating using raw data, like Hax currently supports, is quite low-level. There are a lot of network protocols in real life, some of which are very useful and not present in Hax so far. The most common ones are TCP, IMCP, FTP, SMTP, HTTP, and there are many more. Implementing these would allow to implement tools such as ping, traceroute, ftp client and server, mail client and server, web client and server etc. Implementation of a connection-oriented protocol similar to TCP would significantly simplify implementations of protocols and tools from real life. Hax currently only supports connection-less networking, with a workaround to emulate conection-oriented network protocols, implemented on the application level, rather than the system level like in real life.

Hacking missions

This one comes hand in hand with the backbone. If I was to create some default hacking missions, I would certainly want to publish them onto a data center connected to the backbone. They could of course be included locally in the distribution like the tutorials, but then anyone could look into the source code to cheat. However, I rely more on the community for this one, ideally hosting their missions on their own servers. Or, with the backbone established, they might also be published there.

Awards, banks, money, economy

This is a very difficult topic. Logically, if you have missions, you need awards. Awards usually mean money. For money, you need to keep it in banks. And you have to be able to use it for something. I am a bit of a loss on how to approach this subject, but I know it will have to be addressed at some time.

Domains and name servers

I put this as the last item as it is quite a complex topic. It might greatly affect performance and might also require some changes to the lowest level of the Hax framework. I will not go further on the matter as I myself have not properly analysed it yet. A simple enhancement in this direction would be to introduce a local name-to-address mapping on the system level (similar to the HOSTS file on Windows). This does of course not solve the matter, it only provides a means to improve user experience in that a user could specify his own custom aliases for network addresses.

Getting as close to reality as possible

There are many other things to do. What I would like to achieve is a community-driven approach to development. The community decides which features to implement next. The main areas of potential growth are networking, operating system, applications and hacking missions. A lot can be done, but I also want all the enhancements to be considered useful by the community. Ideas for new topics are of course also welcome.

No comments:

Post a Comment