top of page

Updated: Feb 7


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!


Frontend pressure sensor presentation
The Modux team test the pressure sensor


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.


Overlaying subtitles onto video game compilations
Subtitles overlaid onto various video game footage

 Asher then used Python Automation to post the video to Tiktok through Chrome, utilising Python Flask to create a graphical user interface (GUI).



GUI to generate content
Asher's 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.


analytics from tiktok showing reached audience
Tiktok analytics

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.



Unity 3D particle simulation
Random initialisation of the particles

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.


Unity 3D simulation of particle behaviour
Simulation showing clustering and orbiting

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.


Build pipeline
Build pipeline

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.



Spider diagram
Issues with Parson

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.



Plugin features
Parson with plugin

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.


Privacy preserving DNS database structure
Privacy preserving DNS database structure

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.



icarsoft consumer diagnostic scanner
The consumer diagnostic scanner


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.



C# softwear tool
Software tool showing RPM data


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. 





Modux is always on the lookout for opportunities to create innovative solutions which lead to tangible improvements, and as part of our ongoing partnership with Network Rail we have recently developed technologies to improve the day-to-day safety and efficiency of railway stations.


Members of the Modux R&D team were at Preston Train Station last week to support the demonstration of a new prototype handheld baton we developed, which aims to improve platform train dispatch.


Current issues with indicator systems


In some stations both the TRTS (Train Ready To Start) and RA (Right Away) systems are located at a distance from each other on the platform, causing significant delays to dispatch times, as staff have to enable each indicator system before a train service can safely depart. Network Rail identified significant safety and timing issues at platforms. They found that in order to operate the final ‘Right Away’ indicator to the train driver, the dispatcher had to turn their back on the stairwell, as well as the train and any last-minute passengers, to walk up to 30 seconds to the other side of the platform to reach it.


The Modux team were tasked with investigating the options of a wireless solution for a handheld dispatch plunger which would enable the use of both the TRTS and RA indicator systems.


New technology solution


To meet the requirements, our new technology solution needed to be:


• fully portable,

• easily integrated with the existing TRTS and RA equipment,

• able to operate wirelessly and securely,

• simple to use, requiring minimal staff training and handling,

• compatible with both new and retrofitted equipment boxes.


The Modux R&D team developed a technology system to fit within the traditional handheld baton currently used by Network Rail dispatch staff, with a portable wireless device and internal rechargeable batteries.



The prototype handheld baton we developed

The system we developed allows for parallel operation of the current physical dispatch buttons alongside the new wireless procedure.


In order to prevent the accidental triggering of signals from the handheld baton, the device we developed features buttons on opposing sides that have to be depressed simultaneously for a period of time to issue dispatch signals.


The Modux solution enables dispatch staff to better position themselves on the platform from both a safety and passenger service perspective; staff can use the portable device with improved visibility of the train and platform whilst also remaining available to assist the public - ultimately allowing for a safer and faster dispatch.


Live Testing at Preston Station


Throughout the day at Preston Train Station the Modux team was on hand to support the live testing of the new technology, alongside the Power Box Signallers and the local Signalling and Telecommunications team.


Following the live tests, the opportunity arose to trial the technology on platform three to dispatch a live train, allowing the teams to see the new system working successfully in a busy public setting.





It was a great result for all involved. The technology consistently achieved excellent results, and allowed for seamless communication between the portable wireless device and the TRTS and RA equipment. According to Network Rail’s Tony Berryman the Modux solution “exceeded expectations”.


The prototype will continue to be developed in partnership with Network Rail in the coming weeks, so stay tuned for more updates!



The Modux team ski trip

After a busy year of work, the Modux team earned a well-earned break and headed off to Tignes in the French Alps for a week of skiing and team building.


Since the majority of the team work remotely, this was a great opportunity to get the team together in person.


The mornings were spent exploring the ski runs of Tignes. The more experienced skiers in the group enjoyed going off-piste to the Hidden Valley, while others in the group stayed closer to the resort and learned to ski on the beginner slopes.


The Modux team ski trip

For most of the week, skiing conditions were ideal with blue skies and plenty of fresh powder. While one day was a total white-out, that didn't put off some the more committed skiers.


After energetic mornings on the slopes, the group was welcomed back to the chalet with fresh cakes and spent the evenings playing Codenames, Linkee and other board games.


The Modux team playing board games apres ski


bottom of page