Hacking an Iris 3000 Videophone

Project Logs

Collapse

Back From a Two Year Hiatus
The Sycorax • 05/09/2023 at 00:12 • 2 comments

After a two-year hiatus, I've recently decided to return to this area of interest and resume work on my ACN Iris 3000 project. The ACN Iris 3000 is an outdated videophone device from the early 2010s, which presents an opportunity for myslef and others to apply existing knowledge and further develop skills in repurposing older technology.

As I continue with the project, my goal is to leverage my previous work and utilize proven methods to repurpose and enhance this older technology. The ACN Iris 3000, despite being outdated, offers many learning opportunities and makes for an interesting focus for device tinkering and repurposeing.

In order to effectively document my experiences and knowledge, I will allocate time to update and expand on some of my previous project logs. This process will include clarifying aspects of the device modification process to provide a more comprehensive understanding for myself and others who may be interested in following along. I also plan on documenting how to get DOOM running on the device in future project logs, showcasing the device's versatility.

My objective is to create a thorough record of my progress with this project and serve as a helpful resource for others that are interested. Through the documentation of my ACN Iris 3000 project, I aim to share useful information and insights with both experienced individuals and those new to device tinkering and repurposing.

Ultimately, I hope to contribute to the collective knowledge device repurposing. By carefully documenting my ACN Iris 3000 project, I aspire to provide a practical and informative resource that can assist others in the field as they embark on their own projects and explore new ways to creatively repurpose technology, even with outdated devices.
Displaying Images on the Phone
The Sycorax • 01/23/2021 at 22:40 • 0 comments
[Continued from previous log entry]

Once APT was configured, I was now able to download and install software to the phone. At this point the phone was basically a low end but fully functional Linux computer and I could pretty much do whatever I wanted, with the exception of a few limitations. I wanted to start off small though and then work my way up to installing more advanced software.

The first thing that I wanted to install was something that could display a picture on the phones LCD display. I decided to use a program called "fbi" (framebuffer imageviewer) to do that. This program has nothing to do with the actual FBI so don't let the name fool you. It just simply display's images on the framebuffer device (/dev/fb0).

Displaying Images Using fbi

To download and install fbi I issue the following command:
```
apt-get install fbi
```
This will also install additional dependencies that are needed for the program to work. The installation will only use about 31.1 MB's of disk space so it's pretty small.

Once fbi is installed I needed to obtain an image to display on the screen. So changed my directory to /home/user/ (the location that I use for things that I download), and then used wget to download an image of the of the Debian logo to the phone (Pictured below).
```
wget --no-check-certificate https://wiki.videolan.org/images/Debian-logo.jpg
```
*The argument --no-check-certificate is be used because Debian Squeeze has an older version of Open SSL and therefore dose not support https. I will get into updating Open SSL for Debian Squeeze in a future log entry.

Once the image is downloaded, fbi could then be used to display it to the phones LCD. To try and do that I issued the following command:
```
fbi -d /dev/fb0 ./Debian-logo.jpg
```
Using what I assumed were the correct command arguments, I got an error message (Pictured below).

Doing a little bit of research, I found that fbi needs access to a TTY to display an image. So I re-issued the command with an additional argument (-T 1) to give it access to /dev/tty1.
```
fbi -d /dev/fb0 -T 1 ./Debian-logo.jpg
```
This time I got a different error message (Pictured below).

Noticing this, I realized that I did not add tty1 to /dev/. So just as I did in one of my previous log entries about accessing the phones hardware, I used the following mknod command to do that.
```
mknod /dev/tty1 c 4 1
```
After doing that, I issued the fbi command again and was able to successfully display the image to the phones LCD (Pictured below).

Now that I had the ability to display images on the phone, I wanted to see what else I could do. So I decided to begin experimenting with more advanced software that can be run on the device including DOOM, which I will cover in a future log entry.

[To be continued in next log entry...]
Configuring the Package Manager
The Sycorax • 01/19/2021 at 15:47 • 0 comments
[Continued from previous log entry]

To download and install software on the phone I used the default package manager, APT, which already comes with Debian. However it must be configured first. APT relies on the file /etc/apt/sources.list to locate, retrieve, and obtain information about the desired repositories of software packages that are available on the internet. The repositories for Debian Squeeze that were originally included in it's sources.list file are no longer hosted on the internet, so therefore I had to find one that still is and then add it to it's sources.list file, in order to make use of APT for the retrieval and installation of software packages.

A few Google searches later and I was able to find a repository for Debian Squeeze that is still hosted (Included below).
```
deb http://archive.debian.org/debian squeeze main
```
This repository is the official archive for all of the software packages that are available for and compatible with Debian Squeeze.

To add the repository to sources.list I used "nano" to edit the file by issuing the following command:
```
nano /etc/apt/sources.list
```
I commented out the already existing repositories and added the new one, as pictured below.

After that I saved the file and then issued the command "apt-get update" in order to download the package lists from the repository, and update them to get information on the newest available software for Debian Squeeze. After doing that, I was then able to get software downloaded and installed on the phone using "apt-get install".

If "apt-get update" fails and you get an error that says "Temporary failure resolving 'archive.debian.org'" then run the command:
```
echo "nameserver 8.8.8.8" | tee /etc/resolv.conf > /dev/null 
```
*This changes the DNS server that Debian uses to one that can resolve the IP address associated with the repository that we've added to the "sources.list" file. In this case, the DNS server we use is Google's. But you can use another one of your choosing.

After doing that , run the command "apt-get update" again and it should work.

[To be continued in next log entry...]
Granting Access to the Phone's Hardware
The Sycorax • 01/10/2021 at 20:31 • 0 comments
[Continued from previous log entry]

Having Debian running on the ACN Iris 3000 Videophone opens up a world of possibilities for the device. But to effectively utilize its capabilities, we need to establish a clear line of communication between Debian and the device's hardware. This initial setup process involves a few critical steps.

The fundamental requirement is to provide Debian with access to the hardware components of the Videophone. This is achieved through the use of a command known as "mknod". Essentially, mknod serves as a key tool to construct pathways or 'bridges' to the different components of the device that exist within the /dev/ directory. Various online guides are available to help understand and use mknod. For this project, the main components of the ACN Iris 3000 that Debian needs access to are the LCD display and the keypad.

A key resource that we will need in this process is the Linux Device List (https://mjmwired.net/kernel/Documentation/devices.txt). It serves as the official registry of all allocated device numbers and /dev/ directory nodes for Linux. The device list becomes indispensable when using the mknod command, because it will be used as a reference to populate /dev/ with character or block devices.

Granting Access to the Display:

Our initial task involves setting up a connection between Debian and the LCD display of the ACN Iris 3000. We begin this process by creating a bridge to the Linux Framebuffer device (/dev/fb0), which is responsible for controlling the device's screen display. This is achieved by executing the following command:
```
mknod /dev/fb0 c 29 0
```
After running this command, we perform a check using the "ls /dev" command to verify that our bridge (fb0) has been successfully added to the /dev/ directory (Pictured below).

The next step involves testing the newly formed bridge. We need to verify that Debian can effectively use this connection to control and present graphical elements on the screen. This is accomplished by executing the following command:
```
cat /dev/urandom > /dev/fb0
```
This command essentially writes random pixels to the phone's display (Picture below).

To clear the display, use the command:
```
cat /dev/zero > /dev/fb0
```
Facilitating User Input:

With Debian now capable of interacting with the display and rendering graphical content, our next goal is to enable access to the keypad for user input. This involves the creation of another bridge, this time to the Videophone's keypad (/dev/input/event0).

First, we need to create an 'input' subdirectory within /dev/ using the command "mkdir /dev/input". Next, we create a bridge to "event0" inside the /dev/input/ sub-directory by executing the following command:
```
mknod /dev/input/event0 c 13 64
```
As we did with /dev/fb0, we need to verify that the bridge to event0 has been successfully added to the /dev/input/ directory by executing the "ls /dev/input" command (Pictured below).

Subsequently, we need to test the functionality of the keypad to ensure that it responds to user inputs as expected. We achieve this by executing the following command:
```
cat /dev/input/event0 | hexdump
```
This command essentially outputs a hexdump of the data received from the phone's keypad as the keys are pressed (Pictured Below).

*To return to the shell, use Ctrl+C.

The Road Ahead:

With Debian now successfully interfacing with the hardware components of the ACN Iris 3000, our next step is to configure the package manager to download and install relevant software on the device.

[To be continued...]
Running Debian on the Phone
The Sycorax • 01/10/2021 at 15:45 • 0 comments
[Continued from previous log entry]

Following the successful transfer of Debian Squeeze's root filesystem to an SD card, the SD card was inserted into an ACN Iris 3000. The device was subsequently powered on and SSH was utilized to gain access to its system. Having logged into the device, a series of commands were executed to transition from the internal root filesystem to the newly loaded root filesystem on the SD card.

As documented in a prior log entry, a user named AUTUIN provided valuable insight through a blog post from 2013, specifically related to his "Phonetendo" project. Particularly useful was a sequence of commands mentioned in the blog's comment section that facilitate the transition to the SD Card filesystem. The specific commands provided by AUTUIN are:
```
killall mx27
killall acn
killall dropbear
mount /proc /mnt/sd/proc -t proc
mount /sys /mnt/sd/sys -t sysfs
/sbin/pivot_root /mnt/sd /mnt/sd/mnt/mtd
cd /etc/init.d
./ssh start
exec /bin/bash
```
The relevance of the first two commands depends on the specific processes running on your device. I used the "ps aux" command to see which processes were running on the videophone and in my case, there were no active processes named "mx27" or "acn". This was probably due to AUTIIN's Iris 3000 running an earlier version operating system. However, I did notice that there was a running process called "veditions_mx27_fs_r3". This is essentially the main UI process for the device. I presume this is a variant of the "mx27" process (listed above) as implied by it's name. Therefore, I proceeded to terminate it using the command "killall veditions_mx27_fs_r3".

This action led to an unexpected reboot of my Iris 3000. After an hour or so of investigating the cause, it turns out that this was triggered by a safeguard mechanism within a bash script called "healthmon". This script essentially reboots the phone if a disruption in the UI process is observed. This fail-safe makes sense for consumer-oriented devices but for the purposes of this project it was no longer needed. To circumvent this fail-safe, I accessed the "healthmon" script via the "vi" text editor and removed any instance of the reboot command. I would recommend doing this if your device should exhibit similar behavior.

After making those changes, terminating the UI process no longer led to an unexpected reboot of the device. Moving on, issuing the third command serves to terminate the SSH service. I did not execute this command as it would result in an interruption to my SSH connection with the device.

Prior to running the series of commands, it was necessary to generate a new directory using the command "mkdir /mnt/sd/mnt/mtd". This action is vital because of the specific needs of the pivot_root command.

The pivot_root command essentially exchanges the root filesystem of a running system. It allows one filesystem to become the new root filesystem while simultaneously shifting the old root filesystem to another directory, in this case, /mnt/sd/mnt/mtd. This particular configuration is necessary for the pivot_root command because it's a two-step process involving both 'unmounting' and 'mounting' actions.

When the pivot_root command is executed, the existing root filesystem is moved to the directory that we created (i.e., /mnt/sd/mnt/mtd), making way for the new root filesystem (from our Debian-loaded SD card) to take its place. Thus, the directory must exist prior to the execution of the pivot_root command. Once the directory was created, I proceeded to execute the necessary commands sequentially, omitting the ones that were irrelevant to my specific circumstances (as previously mentioned).
These are the commands I used:
```
killall veditions_mx27_fs_r3 (The name of the UI process may be different for your device)
mount /proc /mnt/sd/proc -t proc
mount /sys /mnt/sd/sys -t sysfs
mkdir /mnt/sd/mnt/mtd
/sbin/pivot_root /mnt/sd /mnt/sd/mnt/mtd
cd /etc/init.d
./ssh start
exec /bin/bash
```
... Read more »
Transferring Debian to an SD Card
The Sycorax • 12/31/2020 at 03:39 • 0 comments
[Continued from previous log entry]

To facilitate the transfer of the data within the QCOW2 image to the SD card, I revisited lovelaced's blog post. The blog post suggested converting a QCOW image to a raw image format, then utilizing 'kpartx' to make the data within this raw image accessible on the computer. Following this, 'rsync' would be used to move the accessible data to a USB stick. While this procedure was possible, I found it to be rather time-consuming and not particularly efficient. Consequently, I sought alternative methods.

Upon additional research, I discovered a 2011 Stack Exchange discussion related to transferring a QCOW2 image to a physical disk. The solution proposed in this thread provided sufficient information for me to carry out my task successfully. The suggested command was as follows:
```
qemu-img convert -f qcow2 -O raw my-qcow2.img /dev/sdb
```
*This command should not be executed.

This command, like the one proposed in lovelaced's blog post, used the 'qemu-img' utility, but with different set of arguments that alowed for transfer of the conversion and transfer of the QCOW2 image directly to a physical device. I adapted this command to include the Debian Squeeze QCOW2 image and the intended device for the data transfer, in this case the 32 GB SD card. I also appended the '-p' argument to the command which provides a indicator to monitor the transfer progress. The final version of the command was as follows:
```
sudo qemu-img convert -p -f qcow2 -O raw debian_squeeze_armel_standard.qcow2 /dev/sdb 
```
*Very Important: Please ensure that the storage device targeted for the transfer is indeed the SD card and not any other drive! This command will completely erase the designated device, so it is absolutely crucial to make sure that the device specified in the last argument of the command corresponds to the /dev/ node of your SD card. You can verify this using the 'fdisk -l' command. I bear no responsibility for any potential damages inflicted on your device(s) as a consequence of following the procedures outlined in this project.

After executing the command, the QCOW2 image transfer began, taking roughly thirty minutes to complete. Upon completion, the SD card was correctly mounted, and housed the entire root filesystem of Debian Squeeze. This marked a successful milestone, as I now had Debian Squeeze loaded onto an SD card. With the SD card prepared, I could now insert it into the ACN Iris 3000 and execute a specific set of commands to switch from the phones internal root filesystem to the one loaded on the SD card.
It's worth noting that utilizing an SD Card, is not a mandatory requirement for the processes I've detailed. Given that the ACN Iris 3000 videophone is equipped with a USB port, a USB flash drive can also serve as a viable alternative for hosting the root filesystem of Debian Squeeze, thereby facilitating its use with the videophone.

[To be continued...]
A New Hope: Obtaining Debian Squeeze
The Sycorax • 12/23/2020 at 23:49 • 0 comments
[Continued from previous log entry]

During the course of my research, I discovered a helpful guide on AUTUIN's Blogspot article, which showed the steps for installing Debian on an emulated ARM machine. The guide provided a link to an archive containing QCOW2 images of pre-installed Debian Squeeze versions, suitable for running on QEMU. This was exactly what I needed, as it seemed to be the most feasible solution to obtain a Debian version with a kernel closely matching the ACN Iris 3000.

In the archive, there were two types of Debian Squeeze: a standard version and a desktop version. The standard version operated through a command-line interface, while the desktop version came with a comprehensive graphical user interface. Considering performance and compatibility, I decided to go with the standard version. The downloaded files included the kernel image (vmlinuz-2.6.32-5-versatile), the initrd image (initrd.img-2.6.32-5-versatile), and the QCOW2 image pre-loaded with Debian Squeeze (debian_squeeze_armel_standard.qcow2).

Before moving forward, I needed to ensure that Debian Squeeze would work flawlessly on QEMU. Thankfully, the instructions for this were provided on the archive page. Here is the Linux command used to run the above-mentioned files in QEMU:
```
qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1
```
Once this command was executed, a QEMU window appeared, and Debian Squeeze began to load. Upon completion, I was able to log in using "root" for both the username and password.

With Debian Squeeze confirmed to be running properly in QEMU, the next phase was was to transfer the virtual disk from the QCOW2 image (already loaded with Debian Squeeze) onto an SD Card. At this point, I was no longer dealing with a QCOW image but rather a QCOW2 image, an upgraded version of the QCOW format. Both versions, however, follow the same transfer process to physical media.

Before proceeding with the transfer, I had to determine the size of the virtual disk within the QCOW2 image. This was crucial for ensuring that there was adequate space on the SD card to accommodate the data transfer. While running Debian Squeeze in QEMU, I ran 'fdisk -l' to find out the size of the virtual disk. To my surprise, it revealed a size of around 26.8 GB, much larger than the original QCOW2 image size of 305.9 MB. The difference was quite significant.

The reason for this discrepancy lies in the fact that QCOW images use a copy-on-write strategy, which helps save space and grow as data is added. To better explain this, think of a QCOW image like an expandable suitcase. When it's empty or only partially full, it takes up minimal space, which is akin to the actual size of the QCOW image file. However, like a suitcase that can expand to accommodate more items, the QCOW2 image has a 'maximum defined capacity' or a 'full potential size'.

So, when this QCOW2 image is loaded into QEMU or transferred to an SD card, it's not about how much it currently holds (actual used space) but rather, its total capacity to hold more (maximum defined capacity). That's why I opted for an SD card that had enough room to fit this maximum capacity, and I chose a 32 GB SD card for this purpose.

Although technically I could have shrunk the virtual disk to reflect only the actual used space, allowing for the use of a smaller SD card, I chose not to go down that route. This decision was motivated by concerns of potential data corruption and the complications that could arise from such an operation. Furthermore, it's usually beneficial to have additional free space for system operations and performance, including software installations.

Taking all these considerations into account, I committed to transferring the entire 26.8 GB virtual disk onto a 32 GB SD card, as stated before. This choice signified the conclusion of QEMU's role in this particular project....
Read more »
Doing More Research
The Sycorax • 12/17/2020 at 21:36 • 0 comments

[Continued from previous log entry]
After obtaining root shell access to the device, the objective was to repurpose it into a standard Linux machine. As documented in my previous log entry, this process involved a sequence of operations that were to be executed in a specific order: Firstly, an ARM version of Debian Linux was to be installed onto an SD card, given that the ACN Iris 3000 utilizes an ARM processor; following this, the SD card was to be inserted into the ACN Iris 3000; subsequently, SSH was used to gain access to the phone; and finally, the "pivot_root" command was executed to transition from the device's internal root filesystem to the one housed on the SD card. This would essentially get Debian Linux running on the ACN Iris 3000.

I embarked on further research and discovered AUTUIN's personal blog, dedicated to his array of electronics projects. Despite the blog's inactivity since 2018, it provided some crucial information. In a post from 2013 specifically about his "Phonetendo" project, while a full explanation of how to install Debian Linux on an SD card was not present, he had indeed provided commands in the comment section necessary to switch from the phone's root filesystem to the one located on an SD card. This revelation was particularly valuable as it significantly reduced the need for further extensive research.

However, the challenge remained to install an ARM version of Debian Linux onto an SD card. Revisiting AUTUIN's Blogspot article, a section titled "A Better Operating System" provided a link to instructions on how to install Debian Etch onto a QCOW image using QEMU, a virtualization technology that allows one to run an operating system within another one. This was crucial, as QEMU can be used for emulating ARM machines on non-ARM hardware.

This piece of information was a significant leap forward. Befor proceeding, I would like to explain what QCOW images are. QCOW images are a type of disk file format used by QEMU. These images represent a method of storing disk data in a format consumed by QEMU. A unique feature of QCOW images ion-demand allocation of disk space, which means the image file grows only as data is added. This efficient use of storage is beneficial when dealing with large virtual disk files. QCOW images also support the creation of snapshots, which can be incredibly useful in a variety of use-cases. Furthermore, QCOW images can be converted to various other formats, allowing transfer to a physical storage device such as an SD card. This functionality was exactly what I was searching for.

However, a significant roadblock appeared when I discovered that the links to the Debian Etch installer were no longer hosted and hence, could not be downloaded. This required an alternative approach to install Debian onto a QCOW image using QEMU.

Further research and after a series of Google searches, I came across a blog post from September 2015, authored by a GitHub user named "lovelaced." Remarkably, this individual had successfully navigated the process of getting Debian Linux running on the ACN Iris 3000. The blog post contained a thorough guide on installing the ARM version of Debian Squeeze onto a QCOW image using QEMU, converting this image to a raw format, and subsequently transferring it to an SD card. Crucially, this guide provided active links for downloading the ARM versions of the Debian Squeeze installer and kernel.

Following this guide, I was successful in launching the Debian Squeeze Installer within QEMU. However, this installer required an active internet connection to download the necessary files for Debian Squeeze's installation onto the QCOW image, which I ensured beforehand. These installation files would typically be sourced from a server/mirror chosen by the user from a list provided within the installer. However, due to Debian Squeeze's outdated status and subsequent lack of support, the necessary files for its installation are no longer hosted on any of the listed servers/mirrors....
Read more »
Gaining a Root Shell on the Device
The Sycorax • 12/11/2020 at 20:51 • 0 comments
[Continued from previous log entry]

While exploring the PXBinaFlash forum thread that AUTUIN shared in their Blogspot post, I found plenty of useful information for getting full access to the ACN Iris 3000. The thread is long and I won't cover all of its details here. But it's clear that at one point, a small group of people were actively tinkering with the ACN Iris 3000. However, it seems the activity dropped off around 2017, with only a few posts since then.

One of the main contributors to the thread was a user named Joshoa. He shared lots of information, resources, and methods for getting a root shell on the device. One of his methods involved updating the phone's flash storage using an SD card loaded with files he provided. This method seemed to be the easiest one, and it would let you access the phone's root shell through SSH, so I decided to use it.

As the thread continued, Joshoa kept sharing updated versions of his SD card method. You can find some versions of it at this archive: https://www.techidiots.net/notes/iris-3000/downloads. The archive also has a detailed PDF document titled "Tinkering with Iris-3000 aka CU776," which provides even more useful information.

The steps in the PDF were mostly straightforward. I downloaded Joshoa's sd-upgrade-v-02.zip and extracted the files out of it. Then, I formatted an SD card to FAT32 and copied the files onto it. I put the SD card into the phone, turned the phone on, and watched the update happen.

*Very Important: Please note that there are two versions of the Iris 3000: the SDA and the MTD versions. The distinction of these two versions are outlined in the PDF document. The aforementioned SD card upgrade method is specifically designed for the MTD model. If applied to an SDA model, this method may cause the device to malfunction or become inoperable (Soft brick). However, this condition is not permanent and recovery is possible. Importantly, a separate SD card upgrade process exists specifically for SDA models, which should be used to avoid any potential issues.

After the update finished, I turned the phone off, took out the SD card, and turned the phone back on. This way, the phone wouldn't try to update again. The PDF explained that once the phone is updated and restarted, I should be able to log into it through SSH and get to the phone's root shell.

Using Windows PowerShell, I used the following command to log into the phone through SSH:
```
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc -t root@192.168.2.110 -p 7022
```
If Windows PowerShell dose not work then using a third party ssh client is recommended.

If you are using a linux machine you might have to include a message authentication code option to the ssh command:
```
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc -o MACs=hmac-sha1 root@192.168.2.110 -p 7022
```
*Remember to replace the IP Address with the one for your ACN Iris 3000.*

Once I logged into the device using the password "1234," I found myself in a basic Linux shell. It didn't have many of the features you'd usually find in a standard Linux OS, but it did give me a lot of control over the device's internals.

With full access to the phone, I was ready for the next step: getting Debian Linux running on it.

[To be continued...]
Where do we begin?
The Sycorax • 12/11/2020 at 18:51 • 0 comments

As initially detailed in the overview of this project, I purchased an ACN Iris 3000 device for just $10 from a thrift store back in January 2020. At that time, my interests were largely in reverse engineering consumer electronics. With the assumption that this device was running a Linux based operating system and could be accessed using normal methods, I decided to embark on an project with the ACN Iris 3000. My hypothesis proved to be correct: the device does operate on a Linux system and allows for straightforward access.

My research led me to a Hackaday article from November 2012. This piece showcased a project called "Phonetendo," executed by a user named "AUTUIN." In the Hackaday article, it detailed how AUTUIN gained full access to the ACN Iris 3000's root shell, revealing its internal Linux operating system. Additionally, AUTUIN managed to load the root filesystem of Debian Linux onto an SD card, then insert it into the ACN Iris 3000. By using the "pivot_root" command, AUTUIN switched from the device's internal root filesystem to the one installed on the SD card. This clever move effectively turned the device into a regular Linux computer, adding a range of features it did not originally possess. Additionally, AUTUIN created a small office game that could be played on the device.

The Hackaday article also directed me to a comprehensive Blogspot post written by AUTUIN. This post provided detailed information about the project, including insights into the ACN Iris 3000's hardware and software capabilities, which AUTUIN used to reverse-engineer the device. While this post was crucial for my project, it was clear that further research was necessary. The post did not offer a detailed, step-by-step guide for loading Debian Linux's root filesystem onto an SD card, nor did it provide the specific commands needed to switch the device's internal root filesystem to a new one.

In order to begin this process, I first needed to gain root shell access to the device. Luckily, AUTUIN included a link in his Blogspot post to a PXBinaFlash forum thread filled with valuable information for achieving this.
[To be continued...]