The first week of January saw the return of Hack Week where the Modux team spent the week creating and demonstrating their own projects, driven by their individual interests and skills - a great way to showcase any hidden talents! The team gathered at the Bristol office to present and demo their ideas; in this post we’re going to look at a few of the Hack Week projects from the tech team:
Leo’s Pressure Sensor
Leo chose a project to increase his knowledge of computer hardware, and combined it with his love for climbing - the perfect challenge. Leo’s idea was to create a thin pressure sensor that could be placed within a climbing shoe to measure the force output during movement. In order for it to connect wirelessly to a device he would attempt to transmit the data from the force sensor over Bluetooth.
Bluetooth Arduino module
To create the initial device, Leo had to learn the basics of computer hardware by wiring an Arduino with a Bluetooth module. He had to learn how to write Arduino code to communicate with the device over Bluetooth and transfer it to the Arduino. After checking that the device was transmitting the necessary data, Leo then wrote the Bluetooth client and API for communication with the device, finishing with frontend code to display the data graphically.
Despite not previously knowing the basics of computer hardware, Leo found the most challenging part of his project was working with serial ports to try and connect to the Bluetooth module through the frontend application.
A working prototype
Within the space of three days and with a lot of new ground covered – including accessing data from serial ports on a windows device and writing a basic UI using Flutter - Leo had a working project.
The frontend application was working to display a graph with the information from the pressure sensor, whilst simultaneously being transferred wirelessly over Bluetooth. The
Modux team got to try out the sensor at the presentation stage. Thumb wars broke out in a bid to achieve the highest number!
Tom’s dynamic port knocking tool
Port knocking is a technique used to protect computer network services from unauthorised access by malicious attackers. If an attacker identifies the static sequence, they can replicate the knocking pattern and gain unauthorised access. This predictability makes the security provided by port knocking less effective.
Tom's aim during Hack Week was to implement port knocking using a time-based one-time password (OTP), ensuring that the port knocking sequence would be dynamic by using a temporary and time-sensitive code.
Port knocking is primarily for Unix systems but Tom was developing on a Windows system. In order to get a Linux development environment, he used VSCode to remote into an Ubuntu virtual machine for the development of the project. This was the first time he had used VSCode remoting with a compiled language.
Tom pushed his knowledge as he hadn’t done any programming in C++ since university but needless to say he got the project off the ground using TOTP for port knocking sequences.
Asher’s automatic content generator
With an interest in the psychology behind viewer retention for online videos, Modux Intern, Asher, chose to explore the generation of automatic videos, experimenting with a combination of techniques to see which would reach the largest audience.
Reddit’s top stories and text-to-speech
Asher's strategy was to first select high-scoring peer-reviewed posts from Reddit’s top 50 of the hour, to ensure that viewers on his Tiktok page would be shown interesting stories that they would be more likely to watch.
After scanning Reddit to scrape the top stories of the day, he combined the title and story on one string, and then split them according to punctuation for a list of sentences.
Tiktok speech API, Whisper transcriber & Python Automation
He converted his chosen story into an audio file using Tiktok’s speech API, then learned how to transcribe the audio file using OpenAI’s Whisper transcriber to gain timestamps of each word and sentence. He then used both the transcripts and timestamps to create a subtitled video.
To maintain viewer engagement, Asher generated a text-to-speech version of the story and created subtitles for the video, placing these in the centre of the screen to ensure they were noticed. He overlaid these stories onto easy-to-watch video game footage compilations, such as Minecraft and Subway Surfers, to add an engaging visual element to his videos.
Asher then used Python Automation to post the video to Tiktok through Chrome, utilising Python Flask to create a graphical user interface (GUI).
Tiktok success
After working out how to implement the Tiktok API within Python, Asher fulfilled his aim of automatically generating viral content. His combination of engagement techniques ensured the viewer retention was high, which meant it was picked up by the Tiktok algorithm. He managed to achieve a reached audience number of roughly 4500, within an overall viewing figure of around 5500.
Kate’s particle life simulation
For her Hack Week project, Kate wanted to create a program which would simulate the life-like behaviour of particles obeying the simple rules of attraction and repulsion. This theme touched on her own interest in particle physics from an atomic to solar system level. Having identified a lack of available online source code for 3D particle behaviour simulations, Kate aimed to create her own simulation and source code to increase both her knowledge of coding and her skill-set, through the use of the Unity Real-Time Development Platform.
Kate started by researching existing 2D simulations and then implemented the physics and logic into 3D through the Unity Game Engine, using trial and error with variable starting conditions and some parameter tuning of the system. She had to learn how to create prefabs on the Unity platform and then to add scripts to prefab objects, alongside manipulating these objects to implement collisions.
Kate’s process was to randomly initialise four types of particles in a fixed place, with each type having a different repulsion and attraction range. In each frame, each particle calculated the force imposed on it by every other particle. One of the difficulties was programming the particle to move around smoothly, without jitter, and tuning parameters so that particles were most likely to cluster and orbit with each other.
Kate started with the rule of repulsion - where the particles settle to static; she then added attractive forces which caused the simulated particles to move around in a natural orbiting manner. Kate tried looping the faces of the bounding box containing the particles so that if a particle moved out of the box from the left face it would appear in the same relative position on the right face, ensuring continuation of opposite faces. To fix issues with particle vibration, and after some trial and error with translation in Unity, Kate chose to use forces. She found that applying a force to an object made it move, but also calculated the mass and drag of the object, which resulted in a smoother motion of particles in the finished simulation.
Thomas L’s project to improve Parson
In their day-to-day work, penetration testers on the Modux team use an in-house configuration file analysis tool called Parson during configuration reviews. Parson can parse and automatically detect issues from a range of network device configuration files. Recently the team have experienced issues with Parson during penetration tests, where time is critical, requiring ad-hoc development and problem-solving sessions to bring Parson to a useful state for the test.
Modux Consultant Thomas intended to spend his Hack Week improving the reliability of Parson, and to explore future directions to allow the tool a more agile workflow.
As one of the developers of Parson, Thomas was keen to ensure that Parson remained a relevant, reliable and useful tool for Modux’s penetration testers. With his experience of the codebase, Thomas knew that spending his Hack Week on rewrites and behind-the-scenes improvements would be very useful in highlighting some problematic areas of the code.
Build pipelines & plugins
Thomas first step was to set up an automated build pipeline, and implement a plugin system that would allow faster feature additions and add transparency to the issue extraction process. Thomas is normally the end user of a build pipeline, rather than a designer, so this was a new role for him. However, as he was already familiar with the codebase, implementing the plugin feature was not too daunting, despite the major changes to the behind-the-scenes logic.
Thomas then started researching build pipelines – how they work, how they are written, and potential security concerns with using them. Build pipelines were entirely new to Thomas; he had to learn how they function and how they are written. He found out that there were many options for where to host and run the pipelines, and that each one is configured in a slightly different way – to compare the options, he weighed up each available choice before deciding on the most suitable.
After settling on GitHub to host the pipeline (along with the Parson repo itself), he experimented with a sample project and set up a GitHub Action to automate the build process and make the finished binaries available to download from the web. Once this was working, he was able to transfer the pipeline over to the Parson repo, and suddenly the latest Parson build was available for download for anyone in the Modux team!
Next, Thomas wanted to find a better solution to the way Parson currently implemented findings analysis. He decided on a format for his plugins that would best answer the issues.
The last two days of Hack Week were spent in development using Visual Studio, implementing his plugins and ensuring they would function as expected in the wider context of Parson. By the end of the week, he had three functional plugins, with additional plugins only a JSON file away.
Automated Builds
Thomas completed his project and the Builds are now fully automated and available for the team to download. In addition, an experimental branch of Parson utilising his plugins feature is functional for a subset of issues.
Thomas B’s project to create a DNS for a public Mesh Network
Modux Security Consultant Thomas B spent his Hack Week exploring the creation of a Domain Name System (DNS) for use in a low powered public mesh network.
DNS is most commonly used to translate easy-to-use domain names into IP addresses, but is also used for sharing other specific information such as the identity of mail exchange servers, domain aliases, and text.
Mesh networking
Mesh networking is a domain Thomas finds interesting, as Mesh network nodes and topology can often change as devices join, leave, and move around the environment. Mesh networks are built using low power devices and are commonly limited in communication speed, which means it isn’t always possible to directly use existing software and network protocols present on traditional networks.
Thomas aimed to create a DNS system called MeshDNS, usable in a public mesh network to aid host and service discovery by providing a queryable database containing domain names, host mesh addresses, and public keys. Before embarking on the project, Thomas had to consider various factors including how it would perform on a slow network, possible network topology changes and privacy issues.
Thomas’ plan was to create a system which would function with a primary server that would generate and distribute an encrypted DNS database to untrusted replica database servers. Clients who sought to make queries would be able to do so by querying the primary server. If the primary server was inaccessible, clients could alternatively direct their queries to the replica servers. Crucially, the contents of the database would not be revealed to the replica database and records would only be decrypted using a specific form of the query as a key.
Creating a DNS Database
Thomas began by designing and implementing the cryptographic elements of the DNS database that could be shared and queried. He then experimented with the radios using the Meshtastic software, but before he could start implementing his own applications to run over the mesh network, he had to implement a transport layer. This allowed messages to be sent with lengths beyond the Meshtastic 228-byte limit and provided additional features to improve the reliability of communication.
Thomas used a couple of ESP32 radio chips flashed with Meshtastic firmware. The devices use LoRa for device-to-device communication and the Meshtastic protocol provides mesh networking functionality like routing and addressing. He used the Meshtastic Python API libraries to interface with the devices over a serial connection, ensuring all of the software created during the project was written in Python.
Working DNS for Mesh networks
With some background knowledge of mesh networking but no practical experience, the project was certainly a challenge for Thomas, but he persevered, and by the end of the week had successfully created a transport layer Python library that functions as a foundational component for other applications. Thomas also achieved a partial implementation of the DNS application, including a set of Python client functions and the primary server implementation.
Danny’s project for CAN BUS reverse engineering
Recently the team have been tasked with reverse engineering a number of legacy protocols. Often they do not have direct access to the systems, but can access the lines running the traffic. Once traffic has been captured, it is a slow process of analysing and correlating to events. In some instances, data packets can be replayed back to devices. Recently the team came across a CAN BUS network, and realised the current available tools aren’t great for reversing.
Setup
The easiest target for the week was Danny’s car, although he was soon regretting choosing the project after a few hours spent outside in the cold. Most modern cars are fitted with an OBDII port. This is a vehicle standard, and allows diagnostic equipment to be connected to the car to receive error codes, vehicle information and diagnostic data. The OBDII port specification includes a number of different protocols – one of which is CAN BUS.
Accessing the vehicle data
Danny connected a consumer diagnostic scanner to the car, and received the CAN BUS data from the vehicle. After 60 seconds, he had received 300,000 CAN frames! With the advantage of knowing how some values were decoded, he was then able to write some tooling to capture, filter and analyse the CAN data. Eventually, he was able to demonstrate he could receive basic metrics, such as speed, RPM and the VIN number.
Tooling
Danny developed the software in C#. It allows capture of CANBUS traffic. Captured data can be searched across multiple decoding of the bytes values, including:
- little/big endian
- single or multiple byte values
- integer, double, ASCII
Searches can go across multiple CAN frames with the same CAN ID - for instances where CAN frames are sent sequentially.
CAN frames can be replayed, or single frames can be modified and replayed.
Tool release
The tool is still very much in beta. The ambition is to improve the interface and test on some more real-world problems before releasing a beta version.