Automotive Security: File Fight | Introduction
Alright, we have been over quite an amount of sections within the automotive security realm. if you are following this series then you have most likely finished the following articles.
Automotive Security: A General Talk
Automotive Security: Getting Started
Automotive Security: The CAN Bus
Automotive Security: Going Over FlexRay
Automotive Security: Reversing CAN
All of these articles follow along with each other and try to give you a good amount of base knowledge for what you may need. I want to make a note and say that this has been quite fun, it's actually been super cool to write and work on so I definitely hope you're having fun with this series! While we are here and before I introduce you to this article, I would like to mention that I am working on a book called Racing the binary — decoding the Roadways which is a book that talks purely on automotive cyber security and its newer foundations! By the time you are reading this- I may have released the book already or am at least halfway done with it. Anyway, let's get into it!
In today’s world, cars as we have already noted are quite digital, they use custom operating systems, custom protocols, custom networks and systems, custom configurations, and even custom firmware now. With this also comes the need to make files much more relevant and also may need or require the use of new modern file formats that can fit the specifications and needs of those systems. In today’s module, we will be going over file formats that are commonly used in cars, why we need to get into them, and how we can possibly build our own parsers and frameworks to parse them.
Below is a list of the sections in this module that also explain what those sections are and why they are important. Note that like most sections, I will be trying to keep this article under 60 minutes and will also try to make sure that everything ties in with the other modules. If you have not yet read those articles, I definitely suggest that you do unless you are already experienced enough for this module!
File Fight | Why The Files And What The Fight → This section will aim to go over why the files even exist, what type of files exist, why some regular files can not exist, and also will try to explain what the big fight is and the deal is with files in cars. Here we may also go over more technical systems and scenarios that break down where cars are going to be going. This is going to be quite the deeper section.
File Fight | Common Network Based Formats → A section that talks about file formats that are included typically with specific networks and protocols used within vehicles.
File Fight | Diagnostic and Telematics File Formats → A section that talks more about the technical versions of these files and goes into telematics within vehicles and why it's important.
File Fight | Exercising A Nerdy Brain → This section will get our brains to exercise and build our own systems using the Go programming language to work with specific file formats.
File Fight | Electric Vehicle Specific Formats → The automotive security module plans to target really all cars, but the bigger question is do EV cars have their own file formats? This section will answer that perfectly.
File Fight | Ending Note → This section breaks down into a few other sub-sections which will conclude and summarize this article, drop some resources for you, and tell you a little bit about the author who is educating!
File Fight | Terms && Definitions
Before we start this article, I have provided a list of terms and definitions that can help you better understand some things we will be discussing in this article.
GPX → Also known as GPS Exchange Format is a file format that is typically used within GPS systems to log specific geographical sets of data.
KML → Also known as keyhole markup language is a type of file format and language based on XML to store specific data using a specific set of unique tags.
BIN → Also known as Binary
CSV (Comma Separated Values)
Now that we do not have much more to get into, let's talk about it and see what all the fuss is about!
File Fight | Why The Files And What's The Fight?
Alright, so as you can imagine, like every other system — each car and each vehicle may need to use some form of file to transact or store specific information. This information can be used for various purposes whether or not its a more technical format and system-specific format or if it's just some logging format used generally by systems, but that is what this module is for! So, let's go over some file formats and unique systems that may be using specific file formats. We should also properly introduce this section with the simple fact that just because one car uses file formats does not mean that we are going to 100% see these files within the storage of the vehicle. So, I have broken this section down into a few sections that can help us with the direct file formats.
File Fight → Firmware Related Files: A section that goes over how firmware works and is stored in vehicles.
File Fight → Telemetry and GPS Files: A section that will go over some specific file formats and data types as well as where they are recorded and why.
File Fight → Network Based Files: This section will go deeper into the realms of files within cars and step up to the networking part of automobiles. I highly suggest that you also read the CAN protocol article that talks about this though since we will mainly be talking about data of these files.
File Fight → The Fight Between Forensics And Hackers: A section that will talk about the primary file fighting between hackers and forensics experts. Here we will also go over diagnostics services and other systems used in cars.
File Fight → Why File Forensics Is Important → A section that goes deeper into the realms of where file forensics is important for investigators.
File Fight → File Forensics As A Hacker → Where digital forensics fields such as file forensics will come in handy to you as a hacker!
Note: You may have noticed that some sections are repeated, this is because this section only goes over why and what files are used but not exactly how these files work which we will get into in deeper sections later on. This is just to get you familiar with the general idea of files within vehicles.
Firmware Related Files
In order for vehicles to properly update and install or even store firmware, you may notice that these files are all held in some binary format which is the following range of files.
Bin/Binary → Binary files are the most common for firmware because they allow the vehicle to easily execute the firmware. Not to mention, they are much easier to store data in and can become quite a pain to work with if you are just making the computer compile the raw source haha ( directly anyway ).
HEX/Intel HEX → These file formats are binary without being fully binary to put it lightly. These formats basically represent binary data in hexadecimal form which is typically used for programming microcontrollers. But they are not used in the same way straight binary files are, instead they are used as an intermediary for transportation of binary data. There are multiple reasons why this is used but it primarily is for how easy it is to convert to binary and the compatibility it has between specific systems as well as its wide adaptability!
Image Files → Image files are used in about every form of firmware and are used for firmware updates which are provided as unique binary images as they are directly called. Basically, they will contain all of the necessary files and information data that is needed for updating the specific Electrical Control Unit (ECU).
These formats are by far the most commonly used file formats due to not only how well known and well worked with they are but also how much data and instructions they can provide within a singular file! While we all know exactly why firmware exists within systems, what exactly do these files provide other than data storage? Well, to answer that question I have listed 3 reasons as to why they may be used within vehicles.
OTA ( Over The Air ) Updates → OTA Updates are where these files seriously come into help. As we have mentioned throughout this series, the primary point of it anyway is that security within vehicles is important, and well so is the firmware within vehicles. When a security researcher finds a massive vulnerability in the vehicle's firmware, then the developers and manufacturer need to patch that. Using OTA updates they can easily deliver the files remotely and deploy the updates without the end user or driver requiring a specific shop!
Data Collection & General Analysis → We will get into this a bit more later in this section: but sometimes a manufacturer may need to access firmware-related files because they store specific information on them that may be helpful in the case of an investigation.
General Backups → As you might imagine, sometimes the newest patch of software may contain a bug that can corrupt itself, so it is important that a car may be able to roll back ( pun intended ) to the previous version of the firmware. Important firmware files will be stored redundantly across multiple ECUs to ensure systems can back up that data and are also more reliable in case something may go wrong.
Of course, these are all general points, and all have their own unique implementation that may also depend on the manufacturer who is working with those files and the way they want to work with their firmware!
Telemetry And Global Positioning System (GPS) File Formats
Ah yes, the big reason modern cars are such a debate to people. As we will figure out deeper later, cars and general automobiles love to store direct information and they love to store a ton of it! This can be anything from general telemetry to GPS records and even network records! Below I have listed a few file formats and where they are used as well as why they are used :D!
GPX (GPS Exchange Format) → Geez, this file format is by far one of the most used file formats within any form of transportation system whether it is cars to drones to even planes, they are used. The reason they are used is because they are very easy and quick to store data as well as very lightweight file formats. GPX file formats are pretty much a widely adopted XML-based file format used for storing GPS data, unique waypoints, tracks, and even routes. These files are extremely and widely used amongst a TON of software bits!
CSV (Comma Separated Values) → This is a file format we are all used to and are all very commonly worked with. But here is something you have to think about, where do these come in handy with automobiles? When it comes to modern-day vehicles that need to store specific information such as the basic telemetry data of the vehicle then well CSV comes in handy because it can easily store that data in a more tabled format which can be used by programs much more efficiently.
KML ( Keyhole Markup language ) → This file format is a much different file format and comes in its own unique form. This file format is typically used within vehicles to visualize geographical data fed from a GPS and is often which is actually used for more than just standard mapping applications. Sure, while this format is commonly known to be used in applications such as Google Earth, this format may also be used in many other geographical applications or scenarios! Ain't that crazy? Heck, someone might even use this file format may even be used for someone to hide a rock and pinpoint it ( geocaching )! This file format is extremely important to look into because it holds a ton of helpful information! Again we will get more into these later.
There are also many other different formats that are used to gather this information such as extra modified JSON files, XML-based file formats, and other file formats that can all have their own reasons for use cases. The one thing people have confusion about is if you are trying to track down a vehicle and somehow get access to the data maybe say stored on a remote server then they can just openly read the data from the vehicle. Let's bring up a better example of an argument that was spawned during my IoT research. I have mentioned this in many other articles but when talking to a few researchers about AppleTV research, I noticed that Apple has two completely proprietary file formats which are PLIST and BPLIST which is known as Property List File Format and Binary Property List Format. The reason the binary files were made was not just because it was used for data compression and an easier way to transfer but also because it was a bit more secure even if someone could easily write their own tool to find all the data in the file.
Network-Based Files — FIBEX and Bus Logs
This series has gotten you pretty used to the idea of networks within vehicles going over protocols such as LIN, CAN, FlexRay, MOST, I2C, and other protocols alike. However, we have barely scraped the surface of how data is logged within those protocols. For the context of this article, I would only like to touch on one network-based file format that logs the data within CAN which is known as a CAN LOG format. But first, there is another file before the logs we can talk about which is known as a FIBEX file format.
The FIBEX file format is quite the well-known file format which is typically used to describe the specific communication networks and even Electrical Control Units (ECUs) within the vehicle! This file basically helps by providing a major structured representation of the network architectural design within the vehicle! This file format is not important fully to a hacker unless if they are going so much deeper into manipulating the protocols, spoofing or emulating ECUs, or trying to manipulate the signals and analyze them. Now we move onto a much deeper side of things and that is CANLOGS.
CanLOGS are file formats used within vehicles that have or utilize the Controller Area Network automotive networking protocol. This data is logged within the network primarily for the factor of storing information about the vehicle's sensors and specific actions that are made within the network. I often see that people mistake these log files for some form of network capture and while that is kind of a sort of try, it is not a direct packet capture file (PCAP) as some people may be guessing. This is because file formats such as PCAP and PCAP-NG all share a different file structure for storing packet data and network captures while CANLOGS are CAN-specific formats. You might also see as the goal of today's article is that CANLOG files are used for diagnosis and debugging the internal network behavior of the vehicle which can be used even as far down as security analytics.
File Fight → The Fight Between Forensics And Hackers
Alright, this is where this section really pulls the rest of this all together. So we have a problem where there is this ongoing battle between hackers and digital forensics experts. You know how game hackers and game developers always have this ongoing war where its I found a way around your anti-cheat then the defender responds with a new form of defense that can patch that? Well, this is the same for forensics experts and hackers. First, let's get something into account. When we are researching a real physical vehicle and we are looking to find some form of information about the internals of the vehicle, maybe some information or so on from there, you may want to actually get around specific mechanisms such as encoding schemes, defensive mechanisms that prevent accessing or even reading files and so on from there. All of these mechanisms are down to the hacker vs the defender. But we already know this happens, what if instead this time it is directly the forensics experts and hackers? What do we mean by this? Well, as again we already mentioned that hackers have to find a way around defensive mechanisms to be able to gain access to the files, but when they're done and win the war it's not time for hackers to step into play and be able to hide or take advantage of the unique file formats hidden within vehicles. This is where hackers fight the digital forensics expert. In a broader spectrum, let's say that a vehicle has been crashed and faulted for no reason ( on the outside ). Digital forensics experts may come into play to investigate and pull apart systems like the EDR ( Event Data Recorder ). An EDR is a type of device that kind of acts like a modern-day black box as it records information about a vehicle and freezes it in the event of a crash and typically only when the event happens ( crash ). This system is helpful to digital forensics experts because it provides them with as much information as they possibly can have about a crash ( depending on the manufacturer ). When this type of event happens, digital forensics experts may also take a peek at the automobile network log and replay it on a mock simulation system to see exactly what was happening during the event. A real starter to the intermediate learner with digital forensics might not spot anything, however, a forensics expert might just spot some fishy behavior. You know how some hackers can exploit systems by simply uploading an image and getting the server to load that image and basically trick it to load malicious code injected into that image? This happens through the process of steganography where hiding data in plainsite becomes a literal phrase. In this case, specifically, hackers can also hide and inject malicious messages or sets of data within CAN traffic if they have access to that data or system such as a hacker being able to slip a small controller in the OBD2 port ( again super rare case but just an example ). Because of this form of injection as well as many techniques hackers may use to hide data or information within a network as well as hide specific sets of data within a vehicle's systems through their files, this then starts the war between hackers and digital forensics experts.
File Fight → Why File Forensics Is Important
Now let's talk about the bigger question here, why exactly is file forensics important in general, especially in the field of automotive? Well, truthfully speaking, there are a ton of applications where file forensics may come in handy but the primary reason for it is during an investigation where you typically need to get extra information about a system. Remember how we talked about how some forensics experts may need to check specific files and systems for all this information in the event of a criminal investigation? Well, this also falls into the same world with files where all the information can be hidden within the binary data of the file or even be hidden inside of a file within a file (file inception). So this is where it comes important mainly to forensics experts who are always trying to grab some form of information. But what about hackers and why does it apply to automotive cyber security experts or even hackers? Good question!
File Fight → File Forensics As A Hacker
When it comes to general cyber security, especially when it comes to attacking systems; you do not expect to be met with the deep underground world of file forensics. But, despite you not coming across it every day, it definitely is there. You as a hacker may even be able to use it on your roadpath to automotive cybersecurity! Below I have listed some decent points on both sides of the fence showing you exactly where file forensics comes in handy as a hacker and as a defender!
Criminal Investigations and Incident Response: These are the two primary factors that kill for file forensics. As you may know, general forensics mixes well with file forensics. For example, when a criminal is caught and found they may need to investigate hundreds of systems, scan hundreds of files and especially if they are a sophisticated hacker — scan different types of networks and past history logs. File forensics plays a major role when it comes to the agencies and different investigative groups gather more information on where the person or criminal has been. An even better example. Say a person is trafficking some form of money that's fake cash to a MAJOR drug deal going down. When the drug deal happens, the vehicle may have stored unique information about where the driver went between a specific time frame and the paths it took using the GPS systems within the vehicle. The second that a criminal is put in handcuffs and an investigation begins, they may have automotive forensics experts go and hunt down for any information revolving around the paths or locations of where the criminal ways by pulling data from the automobiles tracking and GPS systems. They may even be able to uncover more unique digital traces such as car theft and hit-and-runs! All of this information however is going to involve some file formats such as traffic log files, vehicular interactions, driver behavior if it's a more advanced vehicle, and more! Because of this information and the knowledge about file formats in vehicles, criminal investigators may be able to catch and understand more about a system.
Reverse Engineering And Exploitation → The primary use case for wanting to get information from specific files on a vehicle may be to analyze the network and the information within. For example, say you are trying to exploit the infotainment system in some shape or form which has proprietary storage file formats which store data that is used within the software or system. For example, some infotainment systems may be using their own binary storage format that has not been released or yet reverse-engineered by the public and are used to communicate specific settings. If a hacker can say reverse engineer this file format then they may have direct into every endpoint and system within the firmware and may even give you information on the firmware. Another piece is where that will actually help is the reverse engineering and understanding of firmware. When it comes to vehicles, sometimes you may need to exploit or reverse engineer some firmware in order to get your hands dirty with the physical exploration of specific systems and may even need it to uncover specific vulnerabilities within the network that can be exploited remotely. Through file forensics or general digital forensics, you will be able to find a ton of ins and outs or could give the data within the automobile. For example, say an automobile has some smart IoT device and box in it. If I can gain access to the vehicle's smart TV or IoT device it may contain information that can easily be accessed giving me information such as the serial number on the device.
Those two good points should already give you a base as to where everything with file forensics can go and I imagine you can actually work with the logic taught in this series to help you assume what else file forensics has a role in. But that's enough for the introduction to this series, how about we actually get deeper into the grand scheme of things?
File Fight | Common Network-Based Formats
As we have already mentioned, the CANLog format is a common file format used to log network activity on a CAN BUS. But we did not go so deep into it in terms of exactly how it works and we even went into injection or steganography with CAN before even going into it! So this section aims to tackle this file format! So, let's get into it! For starters, I have dissected this section into its own sub-sections so we can go through this in a more unique manner. They have been listed below!
File Fight — The Standard CANLOG (.log) file format → A section that goes over the network log format for CAN and how it works as well as how to replay log files using specific sniffers and capturing utilities.
File Fight — ASC Logs And Conversions → A section that goes over CAN ASC logs which are a much different file format. We will also tackle converting these files using ASC2LOG which is a utility that can convert these unique file formats into CAN LOG files!
File Fight — CAN Steganography → A section that goes over how hackers can hide data within CAN networks and then understand specific methods.
So, without anything else to say let's go ahead and dig into it!
File Fight — The Standard CANLOG (.log) file format
Since we are going to be talking about CAN logs I would like to show an example document. This document is from the official BlockHarbor Hackathon and CTF that is being hosted by them! I highly suggest that you check out their automotive and vehicle security CTF as it has even inspired me to host my own CTF directed at automotive security! Not to mention they have some amazing courses! Below is an example of this document!
(1687357867.810228) vcan0 000002A6#058D5DC482CD506A
(1687357867.810326) vcan0 00000623#3099FB505B659088
(1687357867.810430) vcan0 000007C2#A02CF88898345E5E
(1687357867.810553) vcan0 00000273#0E236BA203406DD1
(1687357867.810653) vcan0 000001E4#345BF53334909C4C
(1687357867.810754) vcan0 00000366#953A8282F0AD4C65
(1687357867.810862) vcan0 0000068B#F8FD7063DB00C89B
(1687357867.810978) vcan0 0000005D#8775CDF1A67F4AF1
(1687357867.811075) vcan0 000003C9#C090DF6ED9569D04
(1687357867.811170) vcan0 000000C6#A8E2FC649BFAD8C0
(1687357867.811272) vcan0 00000471#4510180B6FEE7600
(1687357867.811383) vcan0 0000009E#385352BBD6A7CEE2
(1687357867.811497) vcan0 00000395#518819DBD9A37539
(1687357867.811596) vcan0 000006FD#A95DA4CF3C975175
(1687357867.811697) vcan0 00000691#6A7EA81F442ED8B7
(1687357867.811792) vcan0 00000418#94C5636D547A6006
(1687357867.811894) vcan0 000003C4#68216723BA6B5CF8
(1687357867.811999) vcan0 000006CE#E591F7BA5F7FE1E3
(1687357867.812117) vcan0 0000044A#40D1DED2BEEA93E7
(1687357867.812218) vcan0 00000501#8CC4F7C5A90BFC03
(1687357867.812251) vcan0 0000000B#9DA974D86D64473E
(1687357867.812376) vcan0 0000048F#410564B5CBC6F8EEI would like to actually get into something. So while CANLOG files are logging the network and its direct activity, there are many different ways protocols and network activity can also be logged and monitored. For example, take the following file formats and their use cases.
CSV: CSV is a commonly but not super commonly used format for logging CAN traffic and can be used to organize the data in a table-like manner which can help when formatting or even replaying traffic or storing the traffic.
PCAP: PCAP also known as Packet CAPture files are capture files that hold packet information inside of them and they are not CAN specific but are used familiarly with general network sniffing and analysis. When someone says the term “pcap” they are typically referring to that of a file that holds the recorded packets from a given network activity capture. Some people will take these formats and then interface with them and try to decode these packets via wireshark, but wireshark does not have good support ( even to this day ) with CAN.
ASC: ASC also known as the ASCII format is another format that is quite big and is typically used for a much more compact representation of the CAN network logs. These files can be easily converted using utilities such as ASC2LOG which is a utility to convert ASC files to CANLOG file formats which then can be used to be replayed in tools like can sniffer.
There are other file formats that are used but they are not used commonly and we should be primarily focusing on those formats today. So, that being said, let's go ahead and see how can-log files work and why they are so unique.
So as mentioned before, can-log files are there to just log the network activity on an active or inactive CAN bus which can help digital forensics experts in an investigation or can help cyber security researchers capture specific functionalities and investigate new methods for plausible research in the field! Here is the breakdown of an average can-log file. For this section, we will be using the file we showed above.
Timestamp: Every single can-log file has some form of timestamp which is the direct and exact pinpointed and recorded time a packet was picked up by the network and logged. This timestamp is represented using quite the specific precision which is either in milliseconds or microseconds which can actually determine the smallest time increment that can be captured! This helps quite a lot as it can give us the direct time a packet or action was triggered on the network giving us much more accuracy during our investigation! Our first timestamp is noted in the file as the one shown below.
(1687357867.810228)Interface: Another thing a can-log may store is the interface in which the data was captured or sniffed, this is the part of the log that can help us identify what part of it will actually be talked about. But let's think about this for a second. It may be worth noting that when we replay this log, by default the sniffing tool we will be using will try to find an interface on the system with that exact name, and if not it will exit. So, if we do not name our interface that name we may need to specify it to the tool before we listen on it. In this case, our interface is specified as vcan0 which stands for Virtual Controller Area Network #0 which is the first interface on the network.
Arbitrary ID: The arbitrary ID is the ID of the packet data that we are looking at, in the real definition it is — a value that is chosen or assigned without any specific pattern, logic, or significance. It is often selected without adhering to a predefined structure or rule. In various contexts, an arbitrary ID is used as a unique identifier for an object, entity, or data record. So, when we look at our can-log we can see that our ID comes before our hex data which is separated by a hash. So in the row below
(1687357867.810228) vcan0 000002A6#058D5DC482CD506AOur arbitrary ID is 000002A6 and then as you can imagine, after that is the next and final field within a can dump log.
Data Field: Our final set of data is or form of data within the row of the can-log is the data being written to the network which is in as you guessed, hex form. So in our can-log, we have the following data in the first row.
05 8D 5D C4 82 CD 50 6AAll of this information is extremely helpful to us when we are trying to replay logs and search for specific information. This information that is held within the log seems small, well of course right now it is! But we need a simple program that can replay this and give us more in the case of a simulator. So, I imagine if you are following this series then you have the can-utils suite installed and setup! If not, I suggest looking at the reversing CAN article and the section that talks about setting it all up!
The section below is actually going to show us how we can use a tool in can-utils to be able to replay and view these files!
Using cansniffer & canplayer in the can-utils suite
So in this sub-sub-section haha, we will be working with the file above and working on replaying this file and being able to view the activity and see what it's doing. Keep in mind that in more complex networks we will see more different protocols and systems as well as many different levels of noise and a much longer dump! But in today’s case, we are only going to be learning the basics. Anyway, I have listed two tools both of which we will be using.
can-sniffer: This tool, apart from the can-utils suite is a tool that allows us to sniff data off of a virtual controller area network interface (VCAN) and other various devices such as standard CAN interfaces. We use this tool frequently to analyze the way a network is operating within a vehicle or even to analyze specific data during the simulation and in this case today replayed files!
canplayer: canplayer is a unique tool because instead of actually listening for traffic directly or sending it, it will actually re-create and replay packets based on a log file we give it from a network. This tool and tools alike really come in handy when we can not always recreate specific data. For example, if we did not want to keep a simulator running then we could always record the trigger or simultaneous trigger of every event possible and then just replay the traffic log on the simulator as if we are almost directly replaying the inputs we sent over the network.
Both of these tools are super easy and helpful in our case since we need to first listen on the device's network and go from there and replay our packets. So, let's get to it!
Step 1 → Assuming you have all of the proper information and you have your log file as well as your virtual interfaces setup, we can go ahead and start listening on the device using can-sniffer. To do so, let's enter the following command.
sudo cansniffer -c vcan0the -c argument will indicate color-changing bytes within the stream, we technically do not need this but it can become helpful in larger and more noisy environments. When you run this you should see something like the screenshot below!
This indicates obviously that our interface is working and that the tool is waiting for packets to be displayed. So, let's go ahead and give it something to output!
Step 2 → Now that we have our listener running on the network we can go ahead and start replaying our signals and packets! In order to do this we can use the canplayer command like so.
sudo canplayer -I dump.canlog Note that given the interface that was shown in the log shows vcan0 we do not need to specify an interface since the interface will be assumed if canplayer can find that the interface is active on our network which in our case is because our interface name is vcan0 it will go ahead and listen. If not then the utility will output and throw an error. In the case that it does this for you, you can fix this simply by tossing the tool into what interface you want to use. Below is an example where we tell the canplayer utility to use caninterface0
sudo canplayer -I candump.log caninterface0 When we run this tool and put our windows side to side, we will see the following output from cansniffer!
Cool! We have now actually replayed our data. Sometimes, you may notice that when replaying quick logs of data cansniffer will actually just delete it when it sees that it's the same traffic. In this demonstration, I used a while true loop in bash to constantly execute the command but the issue with it is that even if that is being replayed over and over, cansniffer does not see anything changing so it just decides to discard the output by default. In the case where we wanted to inspect the packets, we can pop open wireshark.
Using Wireshark: Wireshark is by far one of the most powerful protocols and network sniffing but- kinda fails when sniffing automotive protocols. Due to the weird implementation of automotive protocols and the lack of support for them across operating systems and just general systems, it can actually be quite a pain and is quite frustrating when it comes to working with wireshark. However, if you do just want to see that data is flowing, using wireshark is as easy as ever. Simply start up wireshark and click on the virtual CAN interface or the CAN even Serial Link (SL) CAN devise you are using. Then replay the packets. The example below shows sniffing data using wireshark.
Notice how little information wireshark will give? That is a big problem with it, while it does give you a decent amount of information and gives you the same information that cansniffer would, it does not exactly keep track of changing bytes within a stream, add extra layer parsing options to make it direct and so on from there. So, cansniffer amongst other tools is most likely a better alternative for working with protocol capturing.
Now let's talk about something a bit different. By now you should have a decent understanding of how CAN works within the logging system and formats as well as how sniffing and replaying tools work and how the formats are logged. But there are two more aspects that we are missing to CAN and the first one being the most important is being able to explain and get through ASC (ASCII) log files. Typically these files might be a bit more common because they are an ASCII representation of the network data that was logged instead of a direct log parsed result from a capturing system! This kind of log however is not going to be able to easily be replayed using canplayer until we can use a unique tool to parse ASC files. This unique little utility is called ASC2LOG which is a ASCII → CANLOG file translator that can basically convert files quite easily! The below-demonstrating line is a line in ASC format.
0.0118 2 208 Rx d 8 18 B8 32 00 4C 32 32 32We can convert this using the following command if we throw it inside of a file.
asc2log -I sample.asc -O conv.canlog -vBecause we used the verbose option, we may get the line that is shown below.
decimal place 4, e.g. '0118'This data is basically lasting you know what it is parsing! But, that being said, the ASC format is also something that is important to pay attention to because you may come across these files in the wild and not just in vehicles! Alright, now let's talk about something a bit more interesting and go into the deeper side of this file.
This entire time this file was pulled from a CTF, but not just any CTF, a CTF revolving around steganography! Wait really? Yeah! Hahah! This file is actually injected with some form of secret- but what kind of secret?
File Fight — CAN Steganography
This is where things start to become a bit more complex than you might imagine. I am sure you are used to hearing the word steganography thrown around and typically when you Google the term it's always about some image format or specific binary file formats but you barely hear anyone talk about injecting networks. This is because it is quite hard to actually hide data in networks especially networks like automotive networks. So, that being said, let's go over a few ideas of how an attacker may be able to inject a file and what they might be able to gain from it! Below I have listed three forms of steganography that exist within CANLOG steganography!
Bit Stuffing → Bit stuffing is a bit of a unique technique where you are basically encoding patterns within the bit patterns within the log. As you may also imagine, this technique takes advantage of the bit-stuffing process used within CAN. Basically, if you have not heard of this — in order for the protocol to maintain an absolute synchronization state, a zero bit is inserted after every five consecutive bits within the given data stream. This mechanism can actually create a pattern that can be manipulated to encode specific information! So, how does this technique work? Well, a sender basically deliberately crafts messages that alter the bit-stuffing pattern to represent the data that they want to hide. A better example of this is that a sender could arrange messages in a way that five consecutive bits correspond to a binary 0 while the absence of such a pattern indicates a binary 1! However, this is quite difficult as it requires quite well-handled control over the message content to affect the bit stuffing and even control over the synchronization between the party ( sender & receiver ). The primary issue with this is just the timing aspect of everything.
Time-Based Steganography → As you can imagine, like the bit stuffing method, this method also has its challenges due to it being a time-based form. But let's not jump to the conclusion. This method exploits the message timing system within CAN to encode specific information. By being able to even slightly manipulate the inter-frame spacing between messages, the attacker could transmit the hidden data. The issue with this is that the idea of time-based steganography depends on a ton of factors and one of the biggest ones is going to be precise timing control which in itself has its own challenges because of external factors like message timing and even network loads and so on from there. All in all, this can be very complex and frustrating if you have not practiced it nearly enough!
Payload Manipulation → This is by far one of the easier ones to work with and is actually pretty common in general steganography for hiding data within file formats and images! So, for example, whenever you see an image and then look at its payload and see a message like hello world , then the data hello world was injected using payload manipulation. This method is basically altering specific bytes within the payloads of CAN messages which can be used to encode hidden information. The idea or general goal of this method s to evade detection during standard analysis while still allowing the intended recipient to recover the hidden data. A goods example of this is say specific bits or bytes in a CAN message payload can be replaced or modified to represent hidden binary information — in general practice, the modifications may be carefully chosen so as not to disrupt the general functionality of the message or the systems within but to instead hide data within the message. There are some challenges with this but it is much easier to work with than a few of the other methods.
There are some reasons someone may also want to use other and much more complex methods but these are some good examples for now and we may go into them in another module. But for now, let's just stick to the basis. Now you might be asking — Why would someone want to hide data within a network like this? Well, it can be for two primary reasons which are listed below.
1 — They Woke Up And Chose Violence: The kind of person that wants to do this might just be wanting to transfer or send messages in a very very unique way and just decided — instead of images I am just going to hide this data in a network because that's what I enjoy doing!
2 — They Have A Malicious Intent: Another reason these methods might be used is to sneak commands and other various exploits to specific ECUs ( to put it lightly ). For example, when working with the bit stuffing method, someone might want to modify the occurrences of stuffed bits in a way that does not directly trigger errors within the system but can convey a specific binary command to a targeted ECu which can become quite the problem. Or say for example they want to use the timing-based method to alter the timing intervals of messages related to critical systems such as breaks or steering to cause direct damage to the network or the vehicle with even the smallest lag within the network. Either way, the idea and end goal is to just inject data that blends seamlessly with legitimate CAN network traffic similar to how some hackers will inject images with data.
But now that we have an understanding of the network-based files within a vehicle- it's time to move on to bigger ideas and more unique systems!
File Fight | Diagnostic and Telematics File Formats
Within the world of vehicles and modern systems comes a break for surveillance and privacy which some call an evasion of privacy. What exactly is this evasion of privacy everyone is rambling about? That is the very system that tracks and logs data within the vehicle you are driving and logs them with data going from the smallest and most unique timestamp to the most direct and absolute location. But what exactly are these files and how they can be seen? So, this question hits a bit harder than most as it is a bit more difficult to answer. This is because the way automobiles may be logging the data within a vehicle as well as tracking it may vary and these all depend on various factors such as the few ones listed below.
Type Of System → Most automobiles today do not use their own proprietary systems in and out of the car, which means some GPS systems are all third party, in turn, meaning data is stored on a remote server or is stored locally on the vehicle and accessed using that application. Some third-party systems may be using their own proprietary file format and may also be out there with their own fully made and unique file format built on another file format! This confusion is why it may be hard to go over some genuine files. However, some providers may not do this despite being third-party because they view it as a problem in the future in the case an investigation has to happen on a vehicle and specific developers or mechanics can not fully log or understand the data within the file format due to it again being locked down. Talking on that more we also have systems that are purely the company's own and may not be used for general information. Do you know how some manufacturers make you take your vehicles to dealer-specific shops? Well, this may be because most mechanics do not have direct information on specific data and logging systems and in this case can be the same with geo and digital tracking data and storage formats. Some companies in the end just like being secure and do not want everyone in the world to learn how to parse data.
Vehicle → Obviously some vehicles may be using the same system but may also be using a completely different implementation or even a completely different file format that said the third-party system also supports. This can lead to confusion and can be quite confusing for some hackers when it comes to parsing and logging files but this is also another good reason why the question of “what these files are” can be a bit more difficult to answer.
But let's cut the excuses, we are here to learn about the most commonly known and well-used tracking file formats so, can we please go over them already? Of course. Let's go ahead and list the file formats in their own sub-sub-sections that will actually go a bit deeper into context as to how they are used within vehicles. Below is a section that goes over the most commonly used file formats within vehicles and their descriptions of the sections.
GPX (Global Positioning Exchange) → This file format as we already talked about is used quite frequently within vehicles and most transportation and monitoring systems. This section will go over the file format and its general structure.
KML (Keyhole Markup Language) → This is another file that we will be going over a bit deeper in detail and explaining what exactly these files do and why they are used within vehicles as well as getting a general structure.
Concluding Sections → This section concludes the whole point between the two points and why they are used within vehicles.
Note: I chose not to go over CSV files since those are pretty easy to just google and understand and most people already can put together why those files are used within vehicles and what they are used for as well as how easy they are to parse.
Now, without much more to say or go over, let's hop into this section!
Global Positioning Exchange Files Within Vehicles
The GPX file format is one of the most widely used formats for logging and tracking data. These are used in anything from drones and vehicles to simple monitoring and device trackers even something as small as a little wrist tracker. You can imagine that anything with a GPS-like system will be using these file formats. These file formats might be of interest to digital forensics experts because they may possibly store driving sessions and routes that can be helpful in locating or understanding where a criminal may have been. But what is the problem with these file formats and how do they work? One thing I want to address that is a “problem” is just the fact that the GPX file format is generally a file format but is also considered to be a standard as each company and depending on its use may have a similar structure but not the same tags. For example, let's look at some basic file demonstrations of the GPX file format. The below file is from topografix which shows a basic implementation of a GPX file.
<?xml version="1.0"?>
<gpx
version="1.0"
creator="ExpertGPS 1.1 - https://www.topografix.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.topografix.com/GPX/1/0"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">
<time>2002-02-27T17:18:33Z</time>
<bounds minlat="42.401051" minlon="-71.126602" maxlat="42.468655" maxlon="-71.102973"/>
<wpt lat="42.438878" lon="-71.119277">
<ele>44.586548</ele>
<time>2001-11-28T21:05:28Z</time>
<name>5066</name>
<desc>
<![CDATA[5066]]>
</desc>
<sym>Crossing</sym>
<type>
<![CDATA[Crossing]]>
</type>
</wpt>
<rte>
<name>BELLEVUE</name>
<desc>
<![CDATA[Bike Loop Bellevue]]>
</desc>
<number>1</number>
<rtept lat="42.430950" lon="-71.107628">
<ele>23.469600</ele>
<time>2001-06-02T00:18:15Z</time>
<name>BELLEVUE</name>
<cmt>BELLEVUE</cmt>
<desc>
<![CDATA[Bellevue Parking Lot]]>
</desc>
<sym>Parking Area</sym>
<type>
<![CDATA[Parking]]>
</type>
</rtept>
</rte>
</gpx>Note all the different fields that this system has now let's look at a simple tracking system used within a specific vehicle which will not be named for the benefit of this article haha!
<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="xxx_XXXXxxx#$@#4 Navigation System">
<metadata>
<name>RoadTripRoundClockCycle-34</name>
<time>2023-08-18T10:00:00Z</time>
</metadata>
<trk>
<name>Driving Route</name>
<trkseg>
<trkpt lat="37.7749" lon="-122.4194">
<ele>5</ele>
<time>2023-08-18T10:00:00Z</time>
</trkpt>
<trkpt lat="34.0522" lon="-118.2437">
<ele>50</ele>
<time>2023-08-18T12:30:00Z</time>
</trkpt>
</trkseg>
</trk>
</gpx>Notice the difference between the two files? While the general systems and ideas of a GPX file stay the same, the direct implementation will differ based on the brand, device, device data, storage type, reason, and more!
However notice how all of them do some form of tracking of the direction, lat and long. The lat and long aspect of GPX files are pretty normal and can be tracked throughout average GPX files, what does this mean exactly? Well, this means that in the worst-case scenario, you can build a program that can automate parsing lat and long tags or class names within the XML document and plug them directly in from the first starting point on a map to the second and third and so on from there basically drawing a direct path to where they are! This is something I actually always try to mention. You will hear people always talk about how files are unique and how GPX files and routes can not always be parsed and while that is partially true, there are a ton of cheap and hacky ways around these systems and exactly what a digital forensics expert might actually be working with or want to work with anyway! Now without a doubt, experts are going to already have enterprise technologies dedicated to file-specific formats and tracking information, but let's see how these documents work and are generally constructed!
Tagging and Information
The header of a GPX file is pretty easy to read as it contains the following tags.
gpx → This defines the root element that will wrap the GPX document
metadata → like most XML-based documents, you come across a metadata section that defines the metadata about the GPX file which can be branched off into tags such as name, desc ( description ), author, and the time of the file
time → Represents a timestamp indicating when the data was logged or created
keywords → Keywords related to the GPX data
bounds → This usually specifies the minimum and maximum latitude and longitude values in the GPX data.
extension → Allows for adding custom XML elements for additional data which a ton of brands do.
wpt → This is short for the term waypoint and defines a direct or specific point within a geographical region.
ele → This is short for elevation which represents the height within sea level of a given point within a geographical location.
name → Typically represents the name of the waypoint
cmt → Comment that is associated with the waypoint
desc → A short description ( if supported ) of the waypoint
src → Source of the data for the given waypoint
link → Hyperlink associated with the waypoint
sym → Symbol that is associated with the waypoint
type → type of category for the waypoint
rte → representing a route or a collection of waypoints that can form a unique path.
rtept → a point within a route rte =route → pt = point
trk → represents a track, a collection of segments forming a path
trkseg → segment within a given track
trkpt —> a track point or point within a track
speed → speed of vehicle or transport at the time of print
There are various other tags, but all of this data are some good general ideas of what can be implemented and what may be typical to see within a GPX file. So let's think about this a bit more wilder.
Keyhole Markup Language — A Weirder Format
The Keyhole markup language is a much more unique file format and is another XML-based file format that can be used to represent geographical data similar to GPX files. Instead, KML files are used to visualize the geographical data in a much more hierarchical manner which can be used to create more unique maps and points of interest (PoI). Now, these files may typically be found within GIS systems or Geographic Information Systems which are commonly used within vehicle systems for real-time location tracking and navigational applications! These files are also more of interest because of the direct data they display and the way that they can be displayed as well as how easily they can be generated. For example, take the following file format that defines a few different points and coordinates that are all comma separated within one point.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Placemark>
<name>KML DOCU - DEMONSTRATIVE CALL</name>
<description>Drive 1</description>
<Point>
<coordinates>-122.0822035425683,37.42228990140251,0</coordinates>
</Point>
</Placemark>
</kml>Within this file, the above coordinates correspond to a point in San Francisco, with a longitude of -122.0822035425683 and a latitude of 37.42228990140251.
KML files are pretty easy to understand and also pull apart on a deeper level because they are just that- simple. Below is the list of tags that are typically included with KML files.
<Placemark>: Represents a point, line, or polygon feature within the map
<LineString>: Represents a series of connected line segments
<Polygon>: Represents a closed shape with a defined boundary
<Folder>: Organizes elements into a logical grouping
<Document>: The root element containing other KML elements
There are also other unique tags such as extendedData which allows you to extend data within the document and extend the information. These types of files are even more direct because there are a ton of modern-day parsers for these file formats and are also a ton of systems even for vehicles that can easily parse and track where a vehicle has been by drawing a direct path to the vehicle itself.
Concluding Sections
We have only gone over two basic file types out of the many that are used within vehicles, but the easiest way to conclude this section is that every car and automotive manufacturer may use different file formats and even if they use the same then they are bound to be using completely different and possibly by a sliver slightly the same implementation. But it is important to understand these systems because you can easily work with them and at least understand where they come in handy. But now we reach a much deeper section. I have mentioned this in another article, but the first thing with automotive cyber security is to make sure that you have a good base and practice when it comes to using tools and understanding your surroundings! Well, this article is going to get you a bit more used to working with these files as a teaser for the next article on tooling and professional development. Thats right! Our next section will talk about using the Go programming language to map out data within files logged from vehicles!
File Fight | Exercising A Nerdy Brain
Exercising A Nerdy Brain | Problem → This will be the starting point for building a program where we will come into play and what we need to do!
Exercising A Nerdy Brain | Design → This is where the program’s design will be discussed, what we need to do, what we are going to do, what language we are going to use ( spoiler: Go ), and how we will set everything up.
Exercising A Nerdy Brain | Base Development → A section that will talk about the programmatic base behind the program which will define constants and basic layouts.
Exercising A Nerdy Brain | Primary Development → A section that will go over primary development and the general idea.
Exercising A Nerdy Brain | Finishing Touches → A section where we will add finishing touches to the project.
Exercising A Nerdy Brain | Testing → Testing the code is quite important!
Exercising A Nerdy Brain | Investigative Conclusion → A formal conclusion to our investigation, Was the driver at fault?!
Exercising A Nerdy Brain | More To Add → This section will go over what we should have added to the program and also give you some good ideas.
Alright! So let’s get into this 😎
Note: For this section, you will need prior experience within the Go programming language and will also need a small understanding of HTML and JS since we will be building a specific program to automate all of this. Even if you do not have skill, I encourage you to follow along
Exercising A Nerdy Brain | Problem
A local kid has just crashed his vehicle which oddly enough was tied to a drone that was being flown via the car’s internal communication systems. When we come across a crashed vehicle, we extract a GPS system that has two primary files that are known as GPX files, but both of them are completely different. The first file seems to show the flight coordinates recorded from the drone and then the second file shows the vehicle’s approximate location when driving! So, as an investigator, we need to find the direct location of where the vehicle and the drone were when they crashed and be able to properly map out and figure out if this was an accident or if this was intentional. But, before we do that, we need to first find a way to uniquely identify these files. The reason we need to figure this out and run the investigation is because the owner claims that it was not his drone and that something had been faulted in the car!
Exercising A Nerdy Brain | Design
Our problem is quite complex, so one might think! But here is the thing, When we went to the crash site we were able to extract the two separate files that were stored on the vehicle’s communication system. These two files can be traced down a bit more. Below I have listed the two files we will be using.
First File: This demonstrated file is from a sample flight which was recorded as a GPX file. This file will demonstrate the drone and the data from the diagnostics. Pay attention to the data in the file.
<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="Airdata.com"
xsi:schemaLocation="https://app.airdata.com/gpx_files/GPX/1/1 https://app.airdata.com/gpx_files/GPX/1/1/gpx.xsd https://app.airdata.com/gpx_files/xmlschemas/GpxExtensions/v3 https://app.airdata.com/gpx_files/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd https://app.airdata.com/gpx_files/xmlschemas/TrackPointExtension/v1 https://app.airdata.com/gpx_files/xmlschemas/TrackPointExtension/v1/TrackPointExtensionv1.xsd"
xmlns="http://www.topografix.com/GPX/1/1"
xmlns:gpxtpx="http://app.airdata.com/gpx_files/xmlschemas/TrackPointExtension/v1"
xmlns:gpxx="http://app.airdata.com/gpx_files/xmlschemas/GpxExtensions/v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trk>
<name>Oct-9th-2021-05-31PM-Flight-Airdata</name>
<trkseg>
<trkpt lon="-118.371087230394" lat="33.8823536761505">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.100Z</time>
</trkpt>
<trkpt lon="-118.371087226488" lat="33.8823536802802">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.200Z</time>
</trkpt>
<trkpt lon="-118.371087222268" lat="33.882353683485">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.300Z</time>
</trkpt>
<trkpt lon="-118.371087218589" lat="33.8823536854912">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.400Z</time>
</trkpt>
<trkpt lon="-118.371087169113" lat="33.8823536081401">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.500Z</time>
</trkpt>
<trkpt lon="-118.371087166765" lat="33.8823535567269">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.600Z</time>
</trkpt>
<trkpt lon="-118.37108717486" lat="33.8823535232591">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.700Z</time>
</trkpt>
<trkpt lon="-118.371087225817" lat="33.8823535580753">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.800Z</time>
</trkpt>
<trkpt lon="-118.371087269045" lat="33.8823535786783">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.900Z</time>
</trkpt>
<trkpt lon="-118.371087343484" lat="33.8823535710702">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.000Z</time>
</trkpt>
<trkpt lon="-118.371087353003" lat="33.8823535414391">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.100Z</time>
</trkpt>
<trkpt lon="-118.371087350222" lat="33.8823535299683">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.200Z</time>
</trkpt>
<trkpt lon="-118.371087347111" lat="33.8823535216632">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.300Z</time>
</trkpt>
<trkpt lon="-118.371087288487" lat="33.8823535407356">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.400Z</time>
</trkpt>
<trkpt lon="-118.371087293182" lat="33.8823535308998">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.500Z</time>
</trkpt>
</trkseg>
</trk>
</gpx>Second File → Our second file is a much simpler field and a much different file that might be easier to parse. The file is represented in the code block below.
<?xml version="1.0" encoding="UTF-8"?>
<gpx xmlns="http://www.topografix.com/GPX/1/1">
<trk>
<name>Driver Track Record | Dual DJI Flight Session - #29</name>
<desc>TrackRecord</desc>
<trkseg>
<trkpt lat="33.882768" lon="-118.372773">
<time>2021-10-10T00:31:35.100Z</time>
<speed>15.5</speed>
</trkpt>
<trkpt lat=" 33.882650" lon="-118.372738">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.200Z</time>
<speed>15.6</speed>
</trkpt>
<trkpt lat="33.882596" lon="-118.372700">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.300Z</time>
<speed>15.9</speed>
</trkpt> <trkpt lat="33.882478" lon="-118.372652">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.600Z</time>
<speed>16.5</speed>
</trkpt>
<trkpt lat="33.882360" lon="-118.372587">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.800Z</time>
<speed>19.0</speed>
</trkpt> <trkpt lat="33.882284" lon="-118.372550">
<ele>5.2</ele>
<time>2021-10-10T00:31:36.200Z</time>
<speed>20.5</speed>
</trkpt> <trkpt lat="33.882180" lon="-118.372569">
<ele>5.2</ele>
<time>2021-10-10T00:31:36.500Z</time>
<speed>0.0</speed>
</trkpt>
</trkseg>
</trk>
</gpx>Do you notice something within these two files? Before we write and develop our program, our first issue should be understanding the general file structure and how they change, well These files have a weirder structure but all use a similar tag to represent rounds in the file which are held under the trk/track and trkseg/track segment points and tags. These are actually a lot easier than we think to start building. So, let's go ahead and lay out our program and its design. There is also other information you should actually take a look at (hint: what's the time?)
Step 1→ Parsing Files: We understand that each file uses the track segment and track tags within the GPX data, so we know that the only tags we actually need to look for are that kind of file. Parsing the files will be our next step in the process.
Step 2 → Logging Data: We also want to ensure that when we do parse the files the data is dumped to a proper structure to hold our unmarshaled XML data.
Step 3 → Visualization of data → This is going to be a multi-split design choice but here is how we are going to visualize the data. We understand that working by manually inputting millions of coordinates in Google Maps is just not actually going to be worthwhile and at that point, we might as well map it out ourselves. So, we need another way to visualize it. Lucky for us Golang has a library known as staticmaps which will allow us to generate map images where we can also plot points at specific locations. The issue with this is that it makes a request to an API on the backend and if there are too many coordinates then the server will return a 400 Bad Request HTTP error. This can be problematic, okay but what else do we have? We could write a simple application in HTML and JavaScript that uses a mapping library such as a leaflet to generate our maps! Cool, we have our library choice! But now how are we going to integrate Golang with JS/HTML? We could use a ton of libraries and build our own server and management system but we won't actually do that, what we are going to do is take the XML data and convert it to JSON which will then be stored in a file that an HTML document will load onto a map to place pointers and markers on the map. We could just generate an HTML snippet, but the issue with this is the file will become WAY too large to load onto a live local server, so it would be best for us to just load through a JSON file at this moment!
Step 5 → Programmatic Finalization: At this point, the program is about done and I will gladly walk you through the modifications I made to the program, the naming system I had also included, the rules and code systems I ended up using for this script. The point of this article is to just walk you through building a tool I made for this specific scenario!
Exercising A Nerdy Brain | Base Development
Alright, we have now reached a section for our development side of things, so let’s get to it. This section will be separated into a few good hefty parts that will help you understand the structure of this program.
Note: At the time of writing, I have already released my own version of this tool on my GitHub page known as GPHunter! You can view it here under the SkyPenguin-Labs Github!
Alright, first, let’s go ahead and get some basic channels or sub-sections down so you know where this is going.
Base Development | Directory & Tech Dec → Before we get into developing our system, we need to first ensure that we have a good idea or structure of where our files should go. This section will explain this in deeper detail. We will also be talking about the programming language and technical aspects.
Base Development | Starting Off → This section will describe all exportable variables or type structures for the script that we will be using.
Base Development | The Web Server → The first thing we need to ensure is that we can build a stable web server for hosting our information and that data can be properly read.
Base Development | Building The Parser → The next thing on the list is to build a parser for our program, the parser that will parse any and all files that have a track section in them.
Base Development | Finishing The Program → A section that will finish off the program by using arguments, flags, settings, and basic script info so a user can use it properly.
Now let’s get into the development of this system!
Base Development | Directory
So, similar to every other project you would develop, it is important that we define our general directory. So to start this off let’s just go ahead and see what our directory looks like!
As you can see, this file already has some good sections in it! So let’s go ahead and pick each file apart and the directories!
Primary Files → The primary files that are listed within this program and realm of things are going to be our main files, these files are the files that we will be running through Golang’s compiler and will also use to create modules within our project. The main.go file will not have much in it since most of the calls are all made behind the scenes.
Demo Data → The Demodata directory is filled with the example data that we need to parse from the investigation. I threw another file in there but the primary two that we showed or will be looking at are the FlightDemo.gpx and the Secdec.gpx file which are the files again that were shown above when going over the files we found from our supposed investigation.
Server → This directory will contain two files, one file is actively modified by the program that we are choosing to design known as cords.json . This file will record and store the coordinates of the parsed files or files since this program only supports one-at-a-time parsing. The second file utilizes the JSON file that we write data to as it is a small HTML document with a little bit of Javascript in it to make sure that the coordinates and map can all be generated given the data. This is a pretty small web server and is nothing fancy at all.
Modules → This is the core of our project as it contains every helper, exported function, exported data structure, and every parsing and error logging within the script. All in all, this breaks up into multiple different files based on a topic. Below is a list of their topics and what they store.
→ GPX Titled: Golang source code files that have the GPX name in them are either dedicated to storing or unmarshalling/decoding GPX data that the file is going to be using.
→ Color Titled → Color titled scripts utilize specific converters to output color, I will actually give you a cool tool here that may help you in the future.
→ Loggers, Updaters & Flags → All of these files revolve around the program’s internal error handling or functions like parsing files or exporting data such as writing the parsed data to a file.
→ Server ( Misspelled when created, too many energy drinks ): Files that have any indication of server or router in them will be directed towards handling or holding functions that are helpful to the program’s server. Note and remember that we chose not to generate files but instead wanted to handle our own file generation then having the user run an HTML file was too much. So, we can create our own.
Choosing The Language For Development
For the project, if it was not obvious enough, I decided to go with Go ( pun intended ). This is because the Go programming language is extremely versatile and fast and extremely nice for anything networking or data manipulation as it is a very fast and well-supported language. Not to mention, it gives you access to so many more standard libraries than Python in itself would or has! So, that is why I decided to go with Go :)
Base Development | Starting Off
So we are going to need a few things for our program which will all pose their own unique benefit to the program. Below is a list of titles and subjects all of which will be dedicated to data our program will need.
Script Data → Our script data will be defined to load specific files, output specific designs or colors and even define paths that this project relies on. In this case, we have a few sets of data that are script-related and the one thing that comes to mind is the factor that our script will be using flags to input files, so we also need to store this somewhere. Arguments will be stored in a structure, a banner will be its own individual variable and we will then have our last piece of data which is the server directory. Since our mock-up HTTP server needs to locate the files it needs to serve, we will need to define the core path of where the files are located.
Elemental Data → Our script takes GPX data and then takes the values within the GPX data and converts it to JSON. In order for us to properly unmarshal GPX data, we need to predefine some basic structures for tags that we need to parse and then momentarily store the result.
Server Paths → Since our server is an individual HTTP server and there is its own file for this, we need to make sure our router understands what file we are trying to load when a given URL is reached. For this, we can define a map that will map a URL path to a possible file name that the server can then locate and serve using the native HTTP response reader and writer.
Base Development | The Web Server
The web server is the reason this entire project can properly exist, Remember our goal is to not just parse a file and grab the coordinates but instead plug them into a server that can map out the points given a unique or specific location! Our web server can be dissected into a few points and parts.
Primary Handle → This web server is quite simple and does not need anything too fancy, but we need to create some handle where the server can be handled on a thread in specific situations. For example, if the user manages to use CTRL+C, we can tell the thread to exit or instead kill the server.
Router → The router part of this program is going to be the routing system for this server and will also be the request handler. If the server comes across a GET request, it will take the requested URL path and compare it to a map that is supported within the server that we pre-define. The router will then take the given file and serve it using the response writer.
Base Development | Building The Parser
The parser is going to be the more unique part of our program as without this, there is not even a possibility of us continuing our investigation. Our parser will be the file parser that will parse given GPX data. Our parser can be broken down into one primary part.
Parsing → The idea of our parser is to take two fields within a GPX file and only dump the data pertaining to that field or tag. In this case, we are going to be parsing tags trkseg and trkpt for each point under a track segment. This is quite easy and does not require any additional design stages. For example, when we go ahead and load the GPX file that was provided to the user, we need to just grab those tags from the file. So, our parser will primarily open and read the file then attempt to take data from the GPX file and parse it accordingly. But we are missing one more step which is actually interesting. For this section, we have defined that our web server will be pulling data from a JSON file that will hold all of the track information. Well, we need to put the JSON in the file somehow. So, our parser will be doing this. In order for our parser to properly do this, we can create a converter that will basically convert the GPX data to a JSON representation within a structure and then finally write it to a file that the server depends on. Note that given the tool or library we use to write to the file, every time a new file is loaded into the program (GPX) to be parsed, the cord.json file will entirely be rewritten with new data in it for each “session”.
Base Development | Finishing The Program
Before we can go ahead and run our program, we need to define a few steps that will actually finish our program off which includes the primary entry point and functions for the program to run. Since this is quite vast and includes different topics, I dropped a list below.
Flags → Command line flags will be our best friend here since we need the user to specify a specific file they want to load into the program. We are not going to be using any specific program but instead will be creating our own flags system from scratch.
Banners → Banners are just typical output for cool and unique designs
Logging → Some color output is going to be preferred when we write our program. So, I have built a very simple HTML to ANSI escape sequence translator which takes a given HTML code ffffff and will then convert it to the proper RGB format within an ANSI escape sequence.
Exercising A Nerdy Brain | Base Development & Starting Off
Dang, we moved quite fast, didn’t we? Haha! That’s how it goes around here :D. Anyway, now that we have a decent understanding of how the program is designed and what we need to do for specific topics; we can go ahead and develop the program! So this section will start by covering the base within the program. Since the base development idea was to just get you used to how the program will be structured, I felt why not add the starting off section as an example to building that part of the program which was mostly defined in the base development section. I have broken this section up into multiple different sections!
Authors Note: Jesus, I am hitting around 8 energy drinks and 48 hours of no sleep, literally, purely no sleep. I can not remember what the sweet ol’ glory of dreaming even feels like. As I am writing this, please do not be me and make this mistake because I honestly wish I could turn this all the way back.
File Structures: The file structures are going to be our type structures that represent an XML structure of code since GPX is based on XML. The structures are shown below.
type GPX struct {
XMLName xml.Name `xml:"http://www.topografix.com/GPX/1/1 gpx"`
Trks []Trk `xml:"trk"`
}type Trk struct {
Name string `xml:"name"`
Desc string `xml:"desc"`
Trksegs []Trkseg `xml:"trkseg"`
}type Trkseg struct {
Trkpts []Trkpt `xml:"trkpt"`
}type Trkpt struct {
Lat string `xml:"lat,attr"`
Lon string `xml:"lon,attr"`
Ele string `xml:"ele"`
Time string `xml:"time"`
Speed string `xml:"speed"`
Course string `xml:"course"`
CustomElements []CustomElement `xml:",any"`
}type CustomElement struct {
XMLName xml.Name
Text string `xml:",chardata"`
}→ GPX: This structure will define the general GPX structure to marshal the data into or unmarshal in other cases. Notice that this holds an array of a Trk struct that maps to some default values that a track segment might have within a GPX file. Note that as we have mentioned, the implementation of GPX will change but you will see how we handle this later.
→ Trk: Within Trk which a track contains some basic information such as the name of the section and a general description. Following that is an array of something known as the tracks segment or Trkseg . This will help us define the track segments that we need to parse.
→ Trkseg: This is where the fun comes in handy. So for every single track within the file lies some sort of track segment and within that segment comes the track points which again depending on the implementation will all have their own unique values. We can go about handling this by creating a variable within the track segment to hold a list Trkpt which is a data structure that holds information about the point.
→ Trkpt: This defines the track point and all of its information within the track segment. Each point has some basic information that is commonly used within the style or implementation of GPX such as time and ele . These fields are easy to parse, but again, where the fun comes in. You may notice that we include a custom elements array which is basically any or all tags. The reason we use this is that in the future if the file implementation is not using speed or even general tags to label information, we could use general algorithms to help with the parsing of the information within the tag and ensure that the tag data is something we can use for further parsing.
These are just some of the basic elements that we will be using for our GPX parser. But keep in mind that we need to also make sure that we can work with JSON data basically writing our own structures for holding the converted data. The code below shows this!
type JSONTrack struct {
Name string `json:"name"`
Desc string `json:"description"`
Points []JSONTrackPoint `json:"points"`
}type JSONTrackPoint struct {
Latitude string `json:"latitude"`
Longitude string `json:"longitude"`
Elevation string `json:"elevation"`
Timestamp string `json:"timestamp"`
Speed string `json:"speed"`
Course string `json:"course"`
}Notice that this information is much shorter because when we parse the GPX files we can just condense the information into one or two general structures! This is the data we will be using to convert the GPX data!
Primary Development | Web Server
Alright, I know, the reorganization is fluffing horrible, but f it we ball! I highly suggest that you actually get done with other segments of this article first before hoping back to this but this is just to show you what the server will look like.
As mentioned before, the server relies on one primary HTML document which looks like the one below.
Index.html → This file will contain all the proper javascript code we need to work with our server.
<!DOCTYPE html>
<html>
<head>
<title>GPX Map</title>
<link rel="stylesheet" href="https://unpkg.com/leaflet@1.7.1/dist/leaflet.css" />
<link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.5.1/dist/MarkerCluster.css" />
<link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.5.1/dist/MarkerCluster.Default.css" />
<script src="https://unpkg.com/leaflet@1.7.1/dist/leaflet.js"></script>
<script src="https://unpkg.com/leaflet.markercluster@1.5.1/dist/leaflet.markercluster.js"></script>
</head>
<body>
<div id="map" style="height: 1000px;"></div>
</body>
</html>
<script>const map = L.map("map").setView([33.8823536761505, -118.371087230394], 12);
L.tileLayer("https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png", {
attribution: "NULL",
}).addTo(map);fetch("cords.json")
.then((response) => response.json())
.then((tracks) => {
const Clute = L.markerClusterGroup(); tracks.forEach((track) => {
track.points.forEach((point) => {
const marker = L.marker([parseFloat(point.latitude), parseFloat(point.longitude)], { title: point.title });
marker.bindPopup(point.title);
Clute.addLayer(marker);
}); const latLngs = track.points.map((point) => L.latLng(parseFloat(point.latitude), parseFloat(point.longitude)));
const polyline = L.polyline(latLngs, { color: "blue" }).addTo(map);
}); map.addLayer(Clute);
});
</script>This file is actually quite simple and should be easy to explain. The biggest part of this file is just the Javascript that is used. Now, the original plan for this was to make sure that we could generate a static map image of the possible location of every vehicle or transport system from the parsed GPX file. However, after further discovery and testing, multiple static mapping libraries would just return an error code when making a request to the service due to the data being parsed and points on the map being too much. So here we are actually working with a library named leaflet which makes it super easy for us to set a map view! Below is a dissection of each part of the Javascript.
Top Section: The top layer of the file or document defines the variables and direct map initialization! This is shown and explained below.
const map = L.map("map").setView([33.8823536761505, -118.371087230394], 12);
L.tileLayer("https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png", {
attribution: "NULL",
}).addTo(map);Notice that we define a map and tell it to set the view. Our first argument is a set of latitude and longitude values that can be the default map view where the direct zoom point of the map is 12, defined as our second argument. We then set the title layers and information for the general attributions.
End Section: The end section of the file is purely reliant on a file that the program we are in the midst of developing will create known as cords.json which looks something similar to the one below.
[
{
"name": "Driver Track Record | Dual DJI Flight Session - #29",
"description": "TrackRecord",
"points": [
{
"latitude": "33.882768",
"longitude": "-118.372773",
"elevation": "",
"timestamp": "2021-10-10T00:31:35.100Z",
"speed": "15.5",
"course": ""
},
{
"latitude": " 33.882650",
"longitude": "-118.372738",
"elevation": "5.2",
"timestamp": "2021-10-10T00:31:35.200Z",
"speed": "15.6",
"course": ""
},
{
"latitude": "33.882596",
"longitude": "-118.372700",
"elevation": "5.2",
"timestamp": "2021-10-10T00:31:35.300Z",
"speed": "15.9",
"course": ""
},
{
"latitude": "33.882478",
"longitude": "-118.372652",
"elevation": "5.2",
"timestamp": "2021-10-10T00:31:35.600Z",
"speed": "16.5",
"course": ""
},
{
"latitude": "33.882360",
"longitude": "-118.372587",
"elevation": "5.2",
"timestamp": "2021-10-10T00:31:35.800Z",
"speed": "19.0",
"course": ""
},
{
"latitude": "33.882284",
"longitude": "-118.372550",
"elevation": "5.2",
"timestamp": "2021-10-10T00:31:36.200Z",
"speed": "20.5",
"course": ""
},
{
"latitude": "33.882180",
"longitude": "-118.372569",
"elevation": "5.2",
"timestamp": "2021-10-10T00:31:36.500Z",
"speed": "0.0",
"course": ""
}
]
}
]The middle section will open the file and iterate over the branches and specific track and record data! The section is listed below.
fetch("cords.json")
.then((response) => response.json())
.then((tracks) => {
const Clute = L.markerClusterGroup(); tracks.forEach((track) => {
track.points.forEach((point) => {
const marker = L.marker([parseFloat(point.latitude), parseFloat(point.longitude)], { title: point.title });
marker.bindPopup(point.title);
Clute.addLayer(marker);
}); const latLngs = track.points.map((point) => L.latLng(parseFloat(point.latitude), parseFloat(point.longitude)));
const polyline = L.polyline(latLngs, { color: "blue" }).addTo(map);
}); map.addLayer(Clute);
});Notice how we open a file, get the proper JSON data, and then start to point and plot data! The foreach loops exist to loop over the number of tracks especially to grab the points within the track and then it will calculate the necessary data to add the marker and parse the data from strings to float using parseFloat() . Now running this program with the demonstrative data should pose a similar output.
Now that we have a good understanding of how our systems work and stuff, we should at least get something more advanced down. Given that we run this in our browser, it means the file is static and we will need to refresh and have someone run the index manually every single time the program is run. What we want to do is make a program that can do this properly and handle everything from the ground up. So, we can build a simple server. Below is the source code to the server which is followed by a smaller demonstration and explanation within the code. All code sections are separated by file.
GPHunter_Color.go: The code below generates and demonstrates the idea of converting HTML color codes to ANSI escape sequences.
package GP_Hunterimport (
"fmt"
"log"
"strconv"
)func HTMLToAnsi(outln bool, code string) string {
if len(code) >= 6 {
r, _ := strconv.ParseUint(code[0:2], 16, 0)
g, _ := strconv.ParseUint(code[2:4], 16, 0)
b, _ := strconv.ParseUint(code[4:6], 16, 0)
if outln {
fmt.Printf("\033[38;2;%d;%d;%dm", r, g, b)
return ""
} else {
return fmt.Sprintf(`\033[38;2;%d;%d;%dm`, r, g, b)
}
} else {
log.Fatal("[Information] Developer Error: Sorry but code needs to be at least 6 characters long (r, g, b)")
}
return ""
}If you want to know how it works, I have pasted a document for the HTML color code conversion and how it works below.
Color Code Conversion | HTML → ANSI
Introduction
Most of us have used terminal or ANSI escape codes at least once in our lives and we have also at least wanted to make something all nice and wonderful. The painful thing about trying to make something colorful, especially in consoles is that not only do you have to deal with color mining but you also have to use specific libraries for specific colors. In the case of today’s article part of my 5–10 Minute Studies series, we will be understanding how color codes work on a very basic level. We will then end the article by using the Go programming language to create a color converter.
Base
This article will not be going that deep so we do not need a base to the article or rather it is not required. However, it is good to go over the major factors of this article before doing a base design. This article will use the Go programming language and anyone who has never written in Go but is a programmer could easily understand everything that is happening within the program we will be creating. When it comes down to color codes, the color translator will be extremely basic and will not be writing much.
HTML Color Codes
Most computer programmers have often spent time in web development, and through those times they have probably dealt with color pickers to pick an HTML color code like b5263e . However, some people fail to realize how these color pickers work, how they translate, and how they work. In computer graphics, color codes or color is typically represented using RGB(A [Alpha]) values. RGB stands for Red, Green, and Blue are all easy to pick out. Standard HTML color codes are represented as a six-digit hex code that represents the amount of RGB in a given color. Each pair of these digits in the code represents the amount of one of those values or colors which typically range from 00 (minimum) to FF (maximum). These color codes are basically another way of representing colors and are mostly used with computer graphics. Since the RGB value consists of three numbers that represent the amount of RGB in a color we can actually better dissect this and formulate our own code.
Dissecting a color code
Let us look at the basic color codes within a CSS file. The color code that is spotted for the dashboard is 50E3C2 . Based on computer science we can actually pull apart this value and dissect it into an array of hex like so.
0x50, 0xE3, 0xC2These values translate to
80, 227, 194which correspond to the color values in their respective placements like so.
R = 80
G = 227
B = 194This is a quite simple conversion and can give us a basic understanding of how we can already build our program. So, now that we can understand how to split this value, we can also look at the layout now of our program.
Our program is supposed to take a code like 50E3C2 and convert it to the proper escape sequence, based on our logical understanding, how can we better lay out how this program will work? Remember that programs are nothing more than applying conceptual logic of a specific topic, this should be easy to map out.
Parsing the code: In order to convert everything we need to be able to do an operation to grab the RGB values of the code and then apply them to a ANSI escape code. In order to do that, we need to write a function that will split the code by two placements each time. For example, say we have a string of color codes like the one above. We need to split it by two each time we parse a new value
|50 |E3 |C2 = 0x50, 0xE3, 0xC2 = DEC(80), DEC(227), DEC(194)
[0:2] -> [2:4] -> [4:6]
| R | G | B = RGB -> ParseNow that we have parsed the color codes or represented a general structure we can now go on converting the code values. In most programming languages we would also want to throw this into an unsigned integer since 0x50 or 0xE3 and so on from there are all unsigned integer data types ( according to CompSCI anyway). Note that we do use DEC to represent the decimal values of those hex values shown above.
Creating an escape sequence: Now that we have our RGB values we need to construct the perfect escape sequence to properly set this code in the correct spot and output the RGB values with it. Given the setup top, our RGB values now consist of 80, 227, 194 which means that we can already construct our sequence to be something like \033[38;2;80;227;194m which will set the foreground color to the corresponding RGB values we set. Now how exactly does this value work? Let's break it down some more. For those who are new an ANSI escape sequence is a set of characters that will instruct a command line interface to change specific display characteristics such as its foreground color, background color, side panel, design frame, and more. These sequences allow for specific animations and sets of effects to occur within the terminal. We just formatted an escape sequence that will convert the foreground color of the terminal to a reddish pink. When looking at this escape sequence we can break it down to the following 24-bit RGB explanation.
→ 38;2 This value specifies that the terminal will set the foreground color whereas the 2 will also specify that the color will be using 24-bit RGB values ( the end goal here ).
→ 80: Our first RGB value otherwise specifies the red value of the color. We translate or get 80 from our decimal conversion or hexadecimal conversion. In the case of 80, we can infer that the percentage of red in the color is 31.4% which can be calculated using the formula % = (value / total) * 100% which in our case looks like
Percentage = (80 / 255) * 100%
= 0.3137 * 100%
≈ 31.37%This means again our value is approximately 31.37% but we can also say or use 31.4% to represent the percentage given that is it approximately and not a direct.
→ 227 : This is our first value that will specify the green value of the color (G) which can correspond to 89.4% of the maximum value (FF) which equals 255.
→ 194 : This is our third and final value represented as B which is blue in RGB. This is approximately 76.1% of 255.
→ m : Think of this like an EOC ( End of Code ) sequence which tells the end of the escape sequence.
This is pretty basic, right? It seems like it is complicated but if you do this same practice on different codes you can better understand how this works and get a good feel for it. Now we can move on to developing our program.
Writing the translator
Our translator is quite easy, let’s walk through the code step by step. Remember, we need a function that can grab input from the user or something where we can allow the user to specify the code they want to translate. Then we can also write a simple function to convert and return these values.
Main function: Given this is the Go programming language we need to get user input through the main function or the entry point of the program.
package main
import (
"fmt"
"strconv"
)
func main() {
var hexCode string
fmt.Println("Enter a hex color code (without the # symbol):")
fmt.Scanln(&hexCode)
}As you can see our main function basically prints a message to enter the hex code and then will scan the line for user input.
RGB conversion function: Now as we discussed before we can easily create a function to return the RGB values of the code.
func ParseRGB(code string) (hexR, HexG, HexB uint64) {hexR, _ = strconv.ParseUint(code[0:2], 16, 0)
HexG, _ = strconv.ParseUint(code[2:4], 16, 0)
HexB, _ = strconv.ParseUint(code[4:6], 16, 0)
return hexR, HexG, HexB
}This function uses a string conversion function to convert the code to an unsigned 64-bit integer. This value does exactly what we talked about before, split the value by two for each value of the color. It then returns the function.
Update our main function: Now we need to update our main function to handle the code above.
func main() {
var hexCode string
fmt.Println("Enter a hex color code (without the # symbol):")
fmt.Scanln(&hexCode)
r, g, b := ParseRGB(hexCode)
ansiEscape := fmt.Sprintf(`\033[38;2;%d;%d;%dm`, r, g, b)
fmt.Printf(" (RGB) R: %d\n", r)
fmt.Printf(" (RGB) G: %d\n", g)
fmt.Printf(" (RGB) B: %d\n", b)
fmt.Printf("\nHex code #%s translates to ANSI escape code %s\n", hexCode, ansiEscape)
}Now you can see that our program takes user input for a single HTML color code, splits the values, and appends those values to a markup ANSI escape sequence that can be printed to the screen. When we run the function we get the following.
Awesome it works! Now what else do we do? We can now take the escape sequence we formatted in the program in other programs such as the SkyLine banner below! Note that we are expecting a reddish-pink color to be outputted on the screen, however, some terminals and operating systems may see or work with these a bit differently.
Awesome! Our color conversion utility works!
Conclusion && Summary
Color codes can be a tedious thing to work with if you do not understand them properly or know programs that can auto-convert it, sometimes you may even need to write your own program that can take these values and auto-parse them or load them into escape sequences. This is where programming really shines where with just the right tweaks, you can easily create your own color conversion library! In this article we first talked about how color codes worked and also introduced you to this series, we then talked about dissecting and creating ANSI escape sequences to match those codes and finally made a generator to automate the process. The generator is not the most effective and it is extremely simple and basic, but it gets you to understand the process of color code conversion!
File Fight — Back to the files and their code/systems
GPHunter_Server.go: Inside the server file lies all the code for the server and its request/response handling!
package GP_Hunterimport (
"context"
"fmt"
"net/http"
"os"
"os/signal"
"syscall"
"time"
)var SupportedPaths = map[string]string{
"/": "Primary.html",
"/cords.json/": "cords.json",
"/cords.json": "cords.json",
}// Start the server up right away
func StartServer() {
watch := time.Now()
server := &http.Server{
Addr: ":5429",
}
go func() {
http.HandleFunc("/", func(writer http.ResponseWriter, requeststream *http.Request) {
switch requeststream.Method {
case "GET":
if newpath, ok := SupportedPaths[requeststream.URL.Path]; ok {
http.ServeFile(writer, requeststream, ServerDirectory+newpath)
} else {
fmt.Println("Failed path - " + requeststream.URL.Path)
}
// this does not need to be changed so lets keep it
default:
fmt.Println(HTMLToAnsi(true, "eb3446") + "[FATAL INFO] INVALID REQUEST - SEC FAIL")
fmt.Println(HTMLToAnsi(true, "eb3446") + "[FATAL INFO] Server uptime> " + fmt.Sprint(time.Since(watch)))
fmt.Println(HTMLToAnsi(true, "eb3446") + "[FATAL INFO] Hosted at > " + server.Addr)
}
})
fmt.Println(HTMLToAnsi(true, "7734eb") + "[Information] Started Server On Port > " + server.Addr)
server.ListenAndServe()
}()
go func() {
wait := make(chan os.Signal, 1)
signal.Notify(wait, syscall.SIGINT, syscall.SIGKILL)
<-wait
context, x := context.WithTimeout(
context.Background(),
1*time.Second)
defer x()
if x := server.Shutdown(context); x != nil {
panic(x)
} else {
fmt.Println(HTMLToAnsi(true, "7734eb") + "[Information] Shutting down....CTRL+C")
fmt.Println(HTMLToAnsi(true, "7734eb") + "[Information] Server uptime> " + fmt.Sprint(time.Since(watch)))
fmt.Println(HTMLToAnsi(true, "7734eb") + "[Information] Hosted at > " + server.Addr)
os.Exit(0)
}
}()
}Below you will spot a list of sections that will talk about the file’s unique sides.
Variables: The first thing you notice is a map of file paths that the server may be using to fetch the proper location. This is because when a user goes to make a request, we want to make sure we can map out a specific file and tell the server to serve the file or respond with that file based on the endpoint. Now you may be asking, why are we going ahead and parsing or passing the json file? Well, the same falls for images. The HTML will fetch the JSON file on the server and make a GET request for that resource. Even if our users are not directly going to be interacting with it we need to add it to the map since the inner HTML or JS actually will make a default request to the web server.
Anonymous Call 1 → Within the function to start the server we use an anonymous function call within the Go programming language which is also started on a thread called with go func(){...}() . The first function will take the server data and handle it properly and accordingly by serving it and defining a handler to handle the proper requests to the server. Note that the only form of requests allowed are GET and anything else will result in an error. You may also see us using the HTML color converter which is helping us better formulate and highlight our output.
Anonymous Call 2 → This is the second anonymous and threaded function call within the primary function for the server. This is the shutdown and wait for script or document which will start a threaded listener to listen for keyboard or syscall signals from the operating system. The primary call we listen for in this case is going to be the hangup call or CTRL+C!
All of these parts are extremely important and are an amazing gateway into the scripts!
Primary Development | The Parser
I know this article has gone on long enough but I feel like I need to keep speeding this up so bear with me. The following code is the code that is placed inside of the file GPHunter_GPXParse.go which will define the parser for our GPX files.
package GP_Hunterimport (
"encoding/json"
"encoding/xml"
"fmt"
"io/ioutil"
"os"
)func ParseFile(file string) {
GPXFile, x := os.Open(file)
CE(x)
defer GPXFile.Close()
byter, _ := ioutil.ReadAll(GPXFile)
var gpx GPX
xml.Unmarshal(byter, &gpx)
var jsonTracks []JSONTrack
for _, trk := range gpx.Trks {
var jsonTrackPoints []JSONTrackPoint
for _, trkseg := range trk.Trksegs {
for _, trkpt := range trkseg.Trkpts {
jsonTrackPoint := JSONTrackPoint{
Latitude: trkpt.Lat,
Longitude: trkpt.Lon,
Elevation: trkpt.Ele,
Timestamp: trkpt.Time,
Speed: trkpt.Speed,
Course: trkpt.Course,
}
jsonTrackPoints = append(jsonTrackPoints, jsonTrackPoint)
}
}
jsonTrack := JSONTrack{
Name: trk.Name,
Desc: trk.Desc,
Points: jsonTrackPoints,
}
jsonTracks = append(jsonTracks, jsonTrack)
} jsonData, x := json.MarshalIndent(jsonTracks, "", " ")
CE(x)
Modify(jsonData)
}Pretty easy right? First, we need to just open a file and read the entire file into bytes. From there we need to initialize some structures we are going to be working with to store the GPX/XML data in. Then we tell the XML module within Go to unmarshal the data into the GPX type structure. We then actually start to iterate over every single track segment, track, and track point and map it out to the JSON data which is then appended to the jsonTrackPoints array which can then be added to append a new track to the jsonTracks list. Finally we then tell the json library to properly marshal the data and call a function that will write or modify the contents of the file ( replacing the contents in the file with the newer contents ).
The function to write to the file is defined in the file GPHunter_FileUpdater.go and is shown below.
package GP_Hunterimport "io/ioutil"// Do not modify this progam
func Modify(data []byte) {
_ = ioutil.WriteFile("Server/cords.json", data, 0600)
}Simple, no?
I forgot to mention that these files also automate errors using a function called CE (Check Error) which looks like the one below.
package GP_Hunterimport "log"func CE(x error) {
if x != nil {
log.Fatal(x)
}
}Exercising A Nerdy Brain | Finishing Touches
Before we can do anything to our program or even test run it, we need to do three main things which are define script data, define flags, and then define the main function!
Exported.go → This file as shown below will define some basic constants and variables used for the script’s command line usage.
package GP_Hunter// Exported variables and general structuresconst ServerDirectory = "Server/"type ScriptSettings struct {
FileList string // Get all files
}var Banner = ` _____ _____ _____ _
| __| _ | | |_ _ ___| |_ ___ ___
| | | __| | | | | _| -_| _|
|_____|__| |__|__|___|_|_|_| |___|_| .------._
'-O---O--'
`Flags.go → This file will just define the command line flags within the program. We will be doing this under a function that runs before the main function which is known as an init() function. This function, as you are about to see is extremely helpful!
package GP_Hunterimport (
"fmt"
"os"
)var Settings ScriptSettingsfunc init() {
fmt.Print("\x1b[H\x1b[2J\x1b[3J") # Linux Clear Hex Code
fmt.Println(Banner) # banner from the variables file
args := os.Args
if len(args) > 1 && args[1] == "--file" {
if len(args) > 2 {
filePath := args[2] // The file path provided after --file
ParseFile(filePath) // Parse the singular GPX file
} else {
fmt.Println("Error: You specified (--file) but did not provide a file path")
os.Exit(1)
}
}
}main.go → Our main.go file is literally going to do nothing but just sit there and wait for the channels to be triggered on the server or even just watch out for variables from the third-party library!
package mainimport Modules "main/Modules"func main() {
Modules.StartServer()
select {}
}Exercising A Nerdy Brain | Testing The Program
As we mentioned before we have two files we need to test out on this program and investigate! Below are the two files once again to make sure everyone does have the right content!
File1: Drone File
<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="Airdata.com"
xsi:schemaLocation="https://app.airdata.com/gpx_files/GPX/1/1 https://app.airdata.com/gpx_files/GPX/1/1/gpx.xsd https://app.airdata.com/gpx_files/xmlschemas/GpxExtensions/v3 https://app.airdata.com/gpx_files/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd https://app.airdata.com/gpx_files/xmlschemas/TrackPointExtension/v1 https://app.airdata.com/gpx_files/xmlschemas/TrackPointExtension/v1/TrackPointExtensionv1.xsd"
xmlns="http://www.topografix.com/GPX/1/1"
xmlns:gpxtpx="http://app.airdata.com/gpx_files/xmlschemas/TrackPointExtension/v1"
xmlns:gpxx="http://app.airdata.com/gpx_files/xmlschemas/GpxExtensions/v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trk>
<name>Oct-9th-2021-05-31PM-Flight-Airdata</name>
<trkseg>
<trkpt lon="-118.371087230394" lat="33.8823536761505">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.100Z</time>
</trkpt>
<trkpt lon="-118.371087226488" lat="33.8823536802802">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.200Z</time>
</trkpt>
<trkpt lon="-118.371087222268" lat="33.882353683485">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.300Z</time>
</trkpt>
<trkpt lon="-118.371087218589" lat="33.8823536854912">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.400Z</time>
</trkpt>
<trkpt lon="-118.371087169113" lat="33.8823536081401">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.500Z</time>
</trkpt>
<trkpt lon="-118.371087166765" lat="33.8823535567269">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.600Z</time>
</trkpt>
<trkpt lon="-118.37108717486" lat="33.8823535232591">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.700Z</time>
</trkpt>
<trkpt lon="-118.371087225817" lat="33.8823535580753">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.800Z</time>
</trkpt>
<trkpt lon="-118.371087269045" lat="33.8823535786783">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:35.900Z</time>
</trkpt>
<trkpt lon="-118.371087343484" lat="33.8823535710702">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.000Z</time>
</trkpt>
<trkpt lon="-118.371087353003" lat="33.8823535414391">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.100Z</time>
</trkpt>
<trkpt lon="-118.371087350222" lat="33.8823535299683">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.200Z</time>
</trkpt>
<trkpt lon="-118.371087347111" lat="33.8823535216632">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.300Z</time>
</trkpt>
<trkpt lon="-118.371087288487" lat="33.8823535407356">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.400Z</time>
</trkpt>
<trkpt lon="-118.371087293182" lat="33.8823535308998">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.500Z</time>
</trkpt>
</trkseg>
</trk>
</gpx>File2: Automobile Session GPX File
<?xml version="1.0" encoding="UTF-8"?>
<gpx xmlns="http://www.topografix.com/GPX/1/1">
<trk>
<name>Driver Track Record | Dual DJI Flight Session - #29</name>
<desc>TrackRecord</desc>
<trkseg>
<trkpt lat="33.882768" lon="-118.372773">
<time>2021-10-10T00:31:35.100Z</time>
<speed>15.5</speed>
</trkpt>
<trkpt lat=" 33.882650" lon="-118.372738">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.200Z</time>
<speed>15.6</speed>
</trkpt>
<trkpt lat="33.882596" lon="-118.372700">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.300Z</time>
<speed>15.9</speed>
</trkpt> <trkpt lat="33.882478" lon="-118.372652">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.600Z</time>
<speed>16.5</speed>
</trkpt>
<trkpt lat="33.882360" lon="-118.372587">
<ele>5.2</ele>
<time>2021-10-10T00:31:35.800Z</time>
<speed>19.0</speed>
</trkpt> <trkpt lat="33.882284" lon="-118.372550">
<ele>5.2</ele>
<time>2021-10-10T00:31:36.200Z</time>
<speed>20.5</speed>
</trkpt> <trkpt lat="33.882180" lon="-118.372569">
<ele>5.2</ele>
<time>2021-10-10T00:31:36.500Z</time>
<speed>0.0</speed>
</trkpt>
</trkseg>
</trk>
</gpx>Let’s go ahead and test-run our program during the parse and execution! First let’s go ahead and run both of the files through it and see what it gives us.
Running the automobile file
Running the drone file
Exercising A Nerdy Brain | Investigative Conclusion
This was an interesting roadmap, but when we were able to look at and map out the coordinates logged within the GPX file did you actually ever pay attention to a pattern within the data? There are two particular patterns to look out for, coordinate mapping and timestamps. Let’s look at the first and most obvious one.
Coordinate Mapping / Drawings
When we took to the skies and took God's eye into our control, we were able to map out the proper coordinates within the driver's and drone's recorded sessions. Let's look at the driver's side again...
Notice how in the image above, the vehicle slowly starts to merge into the grass area which was the same area right across from them that the drone was recording data from. Can we infer that the driver was truly at fault yet? Well of course there are still a few doubts, which is why the next part of the analysis comes in handy.
Data Analysis and Research
Let’s take two small sections from the files of the driver and the drone both of which are right before the log had stopped.
2 sections before the drone log stopped
<trkpt lon="-118.371087288487" lat="33.8823535407356">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.400Z</time>
</trkpt>
<trkpt lon="-118.371087293182" lat="33.8823535308998">
<ele>24.8511868</ele>
<speed>0.00</speed>
<time>2021-10-10T00:31:36.500Z</time>
</trkpt>2 sections before the vehicle log stopped
<trkpt lat="33.882284" lon="-118.372550">
<ele>5.2</ele>
<time>2021-10-10T00:31:36.200Z</time>
<speed>20.5</speed>
</trkpt> <trkpt lat="33.882180" lon="-118.372569">
<ele>5.2</ele>
<time>2021-10-10T00:31:36.500Z</time>
<speed>0.0</speed>
</trkpt>Right here, I want you to pay attention to the time and the speed of both elements. Obviously, the speed of the drone does not matter in this case, but the speed of the vehicle does and so does the timing. Note that the timing of the two sections is almost perfect! Also, notice how when our driver hits the coordinate
lat="33.882180" lon="-118.372569"The vehicle’s speed instantly drops. What happens if we plug this into Google Maps and see where this takes us? The screenshot below pretty much sums it up.
Based on the information provided as well as found within the documents and with the help of our nifty little program, we can determine that this in fact was most likely a driver’s fault for 3 primary reasons.
1: Drone & Automobile Timing → This is a bit controversial but I feel like the drone and the automobile might obviously be able to tell us directly when something happened when the speed drastically dropped especially when the drone is being moved at the same exact time the vehicle is being moved which may indicate that the driver was also operating the drone which is still a bold statement but is possible.
2: Story & Devices → The fact that the automobile had two individual files for logging and recording the drone and vehicle’s session might indicate that as the driver was well-driving the vehicle, they might have had a session or system within the car that could help operate the drone.
3: Gradual Location → This was another big one for me as I felt with the direction the drone was being pulled and flown as well as the speed and the direction of the vehicle slowly merging many indicate the driver was looking out the window instead of in front of the road.
Granted, these are just general points but still give us a great starting point for catching our perp!
Exercising A Nerdy Brain | More To Add
Alright, so being real with you, this program was not the best example of tooling and certainly was not the best example of how to work with specific files, however, it was an example and that was the purpose of it! If you would like to see more, here are some plausible ideas for the modification.
Table Important Information → It may be important to table out some basic analytics like the average speed per round, average vehicle distance, total points made, average time-based ping, etc.
More Advanced Forensics → Maybe you can also verify that the file is a GPX file and is not some random file that you are parsing and you can even go as far as calculating specific speeds and determining criminal behaviors or even based on longitude and latitude zone in on high crime areas!
FIle Fight — Conclusion And Summary
Firmware Analysis → Firmware analysis is something that has its own unique fields but is one field you might want to consider. This is because even outside of vehicles, standard IoT devices such as drones and even smartTV’s have some unique sense of firmware that when analyzed might give you another perspective of where to look for possibly exploitable or researchable endpoints within the system. For example, when analyzing a drone's systems you may occasionally come across the local APIs it uses to fetch and respond with data. This kind of analysis is extremely important and will bring you quite a long way especially in the realm of automotive security in some specific aspects!
Protocol Analysis → This is another thing that will seriously come in handy! With the newest automotive protocols coming into play such as automotive ethernet, you will occasionally and possibly in the future come across some proprietary protocol that needs to be analyzed in some shape or form. This can be for various reasons such as analyzing points of interest for exploitation, manipulation or even abuse even doing something as much as being able to actually reverse engineer the protocol.
Reverse Engineering → This ties into the other fields and is not really digital forensics but is a field to look into if you are going to have some form of firmware or protocol analysis because you may want to go a step further and reverse engineer the systems, files, protocols, networks and individual formats that may be proprietary and unreleased yet!
All in all, automotive cyber security is a fun field, and file forensics and digital forensics really as a whole ties it all together and adds a new aspect I would be surprised most people have not seen yet! Similar to drones or other various IoT devices, files are used everywhere and will forever be used in those systems especially more complex and data-hoarding systems that may want to track data. Not only are these file formats helpful to people who actually want to do something for the betterment of society by helping track down some criminals but even maybe to help out some people!
Side Note: When it comes to cyber security, it's important that you do not look at a system with just one point of interest and instead look at it from multiple angles because that one angle and you might be able to find something unique and something special that you were the first to find! And I assure you, there are a ton of undiscovered vulnerabilities out there!
Ending Note — Extra’s, Resources, Support, Thanks
Typically I never do like promoting stuff but I figured it was worth a shot. This section will provide you with basic information about me, some socials you can follow me on, how you can support me, and some resources that were used to build this article/module. Apparently, my articles are so long people are calling them “modules” so I will go with that for now hahaha! Below are some bullet points that showcase extra sections.
Ending Note | About Me → This section will talk about me, who I am, why I am doing this, current projects, etc.
Ending Note | Where I Came From → A section that gives you a comedic little backstory that I wrote a while back.
Ending Note | Thank You → A section thanking you for reading this article and explaining why I value community.
Ending Note | Ways To Support → A section talking about ways you can support me with currency!
Ending Note | Where To Find Me → A section that talks about where you can find me and how you can follow me.
Ending Note | Resources To Advance Your Knowledge → A section that explains some basic resources used to help you.
Below, sections are listed and talked into!
Ending Note | About Me
Hello there nerd! My name is Ryan and I am commonly known as Totally_Not_A_Haxxer! I am a 16-year-old security researcher and developer with quite the experience primarily in development (50+ languages including working on my own) and take a huge interest in automotive security! I write the articles I write especially in length as well as books because I believe that knowledge is for everyone and should not really be charged so much. For example, I saw someone write a Golang tutorial that was like 10 hours of content and charged over 1K for it- I thought it was a complete waste of time so I started my blog page to not only do what they were doing but do it better and for free! I also have multiple projects going on around education such as $1 Courses which are courses on various topics in tech or even general that get sold off for a single buck! That is a small about me, you can find more which we will get into in quite a second hahaha!
Ending Note | Where I Came From
Hey, there- not sure how I can start this other than going by the title and kind of scraping a bit on the surface. For starters, hello there- my name is Totally_Not_A_Haxxer ( ironic name ), and I am a 16-year-old automotive security researcher working with organizations such as mk.iii to produce quite an amount of cyber-security-related content! This is my short story on how I went from an outcast in school to someone who hacks cars ( legally ) for a living!
Ah, let’s rewind the clock to the good ol’ days before I became the grandmaster of car hacking — yep, you heard me right, car hacking. But before all that wizardry, I was basically the outcast of outcasts. Back in the day, yours truly was knee-deep in writing game cheats, rubbing shoulders with folks whose greatest ambition was mastering the art of game cheats and munching on a hearty selection of mood-altering substances. Ah, the exploits community, where toxicity thrives like a fungus in a damp cave — charming!
Meanwhile, I was juggling my rebellious teenage escapades, the kind that would give your average parent nightmares. Picture me, trying to squeeze every ounce of “oomph” out of life, navigating the treacherous waters of adolescence, and cultivating a personal vendetta against anything remotely associated with the school. As if that wasn’t enough, I was racking up more fights than a Rocky Balboa marathon, probably because I had the brilliant idea of being the ultimate school outcast. My so-called friends managed to forget my existence faster than a Snapchat message.
Things got so wild that my guardian, bless their heart, yanked me out of that hellhole of education and into the glorious world of online schooling — yeah before it was the cool thing to do. So here I was, a lone wolf at home, holed up with my trusty computer, delving into the mystical realm of game cheats (even though I was about as clueless as a goldfish in a maze). But hold up, don’t think my journey ended there. Oh no, dear reader, that’s when the real action began!
I swapped out my teenage angst for a newfound passion — cars, baby! Those four-wheeled marvels and their fancy tech tickled my fancy. I went all in, buying books and resources that were probably worth more than my weight in gold. From tinkering with gadgets to reverse engineering automotive networks, I went from being an irritable mini-human to a bona fide tech maestro.
In a plot twist worthy of Hollywood, my anger-fueled antics transformed into a superpower. Instead of causing chaos in the schoolyard, I was wreaking havoc on systems and networks, making even the most mischievous computer viruses jealous. So there you have it, my friend — from writing sneaky game cheats to playing tag with automotive technology, I became the quirky protagonist of my very own tech-driven saga. And yes, the cars better watch out, because I’ve turned my youthful rebellion into a symphony of circuitry and code. Who would’ve thought, huh?
I would have liked to share more but some things I just could not and plus the story would become WAYYYY too long for this segment haha! So there you have it! As of now at 16 years old I have written multiple books ( one of which is published on Amazon) and others that have been released for free! I have written my own programming language, developed my own security research community, worked with companies like Hakin9 and Pentest Mag to push out IoT security research, and even went as far as working with the best companies to research and present automotive security content! Heck, I even just built my own car-hacking simulator haha! Do also note that everything I do is completely ethical AND LEGAL WITHIN THE U.S. as it is now my job and is also highly certified!
Ending Note | Thank You
I want to also thank you for reading the article and coming this far, I know these articles are extremely large and take a ton of time but I hope they were worth it. I do try my best to actually go and put the time and effort into the articles by ensuring that I can actually help educate people and go deep into the topics I talk about for free! So, if you have made it this far, I appreciate giving the effort back as far as reading the article and hoped it helped :D!
Ending Note | Ways To Support (Financially)
Currently, I am not in the best of situations with money and I do not have the proper funding to afford good equipment for security research even something as much as a laptop where I could do remote work. That being said, I have always been used to saying “I do what I do with passion, and I will stop at nothing to do so”. Even though I do not have direct resources, I always do try my best to deal with what I have and do what I want to do with said resources I do have. With this, I ask that if you can bother to donate or do have the extra to spare, this will make my development, skill, and more go much MUCH faster and also make me much more motivated to continue doing what I am doing! Below I have listed my Cash App and Venmo as well as crypto wallets!
Venmo:
Venmo | Totally Not A Haxxer hacker Venmo is a digital wallet that lets you make and share payments with friends. You can easily split the bill, cab fare…account.venmo.com
CashApp:
BitCoin Address: bc1q45ctj3cwl8zr2qdw4xceukr58cdnayxuutymt8
Ethereum Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
USDC Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
Tether Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
XRP Address: r4s8FeyYCBHJQGJRGuDuPeM2YLMwRCZP4R
Ending Note | Where To Find Me
This sounds weird to say, but you can find me in a few places; social media is one of them. Below I have listed some links of where to find me but I will say this. Often in discord servers, communities, and even other platforms: some people always ask me for links and I can get tired of constantly pasting social media links on days when I have a bunch of stuff to do and given social media is not on my phone ( at this time, working on a study/ghost month ). SOOOO, that being said, Google is a good place to go literally search “Totally_Not_A_Haxxer” or even “totally_not_a_haxxer” and some of my socials should pop up + look at it this way, you get more OSINT experience.
Instagram
Medium:
Totally_Not_A_Haxxer — Medium Read writing from Totally_Not_A_Haxxer on Medium. Cyber Security Educator, Developer, Social media manager, Author…medium.com
Blogger:
Hakin9 Articles / Research point
GitHub
TotallyNotAHaxxer — Overview Single Developer of the red rabbit project, leader of the scare security team, and Single developer of the Grizzly…www.github.com
Google: https://www.google.com/search?q=totally_not_a_haxxer&sxsrf=AB5stBjHLrW6iWuxLvuh7jKHebe6L-BTGQ%3A1690923815850&source=hp&ei=J3PJZJqkL-nakPIP7dqCgAo&iflsig=AD69kcEAAAAAZMmBN09YHcUlW2STp8BofYjoKR1t0GgH&oq=tota&gs_lp=Egdnd3Mtd2l6IgR0b3RhKgIIADIHECMYigUYJzIEECMYJzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIOEC4YgAQYsQMYxwEY0QMyCBAAGIAEGMkDSMYGUABY1QJwAHgAkAEAmAGtAaABhQWqAQMwLjS4AQPIAQD4AQHCAg0QABiKBRixAxiDARhDwgIIEAAYigUYkQLCAhMQLhiKBRixAxiDARjHARjRAxhDwgILEC4YigUYsQMYkQLCAg0QLhiDARixAxiKBRhDwgIKEC4YigUYsQMYQw&sclient=gws-wiz
Comments