This post is a work in progress.
Preamble and history
I’ve long had an interest in 3D and VR in general. My early experiments with this technology started circa 2012, with the GoPro Hero 3+ dual camera system and before that I was stitching panoramas with Autodesk/Realviz Stitcher. I’ve since also played with photogrammetry, both on land and underwater.
3D technology saw a large resurgence in 2012, with the likes of the Sony TD10 3D camera (which used a video format that’s extremely hard to work with today) and the very similar JVC GS-TD1. These cameras hit the market along with Plasma TVs that supported 3D, usually through the use of active LCD shutter glasses.
The technology wasn’t great, for various reasons, and after a while, consumers started to forget about 3D. By 2017 the technology had largely disappeared. Then, in late 2023, Apple introduced the Apple Vision Pro AR/MR headset, which integrally supports playback of “spatial” videos (Apple’s term for 3D). Simultaneously Apple introduced the ability to shoot these videos on late generation iPhones (starting with the 15 Pro). A related format, “VR180” is of more interest to me. It is 3D video, but shot with 180 degree lenses on each camera. I find this format particularly “immersive” in a VR headset. I don’t think it will ever be popular but it’s cool. I see a lot of potential in the VR180 format for relaxation and ASMR-like experiences… think a relaxing scene in a forest.
After the AVP was introduced Meta rapidly followed up with support for spatial videos on their Meta Quest 3 headset, so one doesn’t need a £3500 headset to view “spatial” videos. VR180 has been available for some time on the MQ3 via the Youtube VR app, although when last I checked content was limited.
Before I had properly experienced VR180, I thought the ultimate approach would be to shoot 360 3D… that’d be so cool. There are very few cameras on the market that can do this. The main competitors being the Insta360 Pro, Pro 2 and Titan. The Titan is far outside my budget and the original Pro has poor specs. The Pro 2, having retailed for $ 5000 in 2019 can now be had on eBay for under $1500 if you’re patient, which is what I did.
The Insta360 Pro 2 is an absolutely terrible camera. It’s heavy, it takes ages to boot up, it makes a noise (fan), it’s difficult to handle, the app is slow to respond, it has largely been forgotten by the manufacturer (which is what Insta360 does), and it’s super buggy. It’s very sensitive to storage device speed and will often arbitrarily force you to test disk write speed before it’ll let you record. It’s a crap piece of equipment. It has loads of quirks and undocumented oddities. Its only redeeming quality is that the video output is high resolution and bitrate.
The story
The camera stores footage on 7x micro/SD cards and the easiest way of accessing the data is via the camera’s ethernet port. In the limited time I have available to play around with tech these days I’ve been doing some test recordings. Recently, while waiting for files to copy over from the camera’s 7x SD cards, for the fun of it I pointed nmap at it…
mmm, that’s… a lot of open ports. Of course, SSH is the first thing I noticed. The other ports are largely to be expected given how the camera operates. So, now I’m thinking, how could I get the username and password for that SSH port? It’d be impossible to brute-force, assuming of course that they had randomised the password and maybe it’s a weird username too. It’s impossible to say. Then I think, well, I wonder if the OS for the device is on a storage device I can access (like an SD card). If it is, I could take the camera apart and set the username and password directly by mounting the OS disk.
So I go looking for some teardown photos, and I find that the FCC took some for me. Awesome.
I keep digging, it’s a 28 page document. I’m looking for the mainboard that carries the (clearly Linux) OS that drives this thing.
mmm, Nvidia, this looks promising. Nvidia makes ARM dev boards, among other things (Jetson, Xavier, etc).
Great, this must be what’s running the main OS. Now I’m hoping the next photo will reveal an easy to access debug port… or even better an SD card hah!
erf, this doesn’t look promising.
So at this point, I’m sitting at my PC, with a terminal open. And I’m thinking to myself: “Is this it? Dead end?” And then I type a command:
Naw, that’s not going to work. This is a waste of time.
Wait. What if this machine is running a standard dev-image and they didn’t bother to change the username and password? lol. Could it be that simple? This wouldn’t be the first time a company has shipped a dev image on a retail device.
wow 🤷♂️
So, this device is running Ubuntu Desktop 16.04 (Xenial). The rootfs is mounted rw, async (async means that if the device loses power, data corruption is much more likely). Below are some commands, with annotations:
nvidia@tegra-ubuntu:~$ cat /etc/issue
Ubuntu 16.04 LTS \n \l
nvidia@tegra-ubuntu:~$ mount
/dev/mmcblk0p1 on / type ext4 (rw,relatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=7974104k,nr_inodes=1993526,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /run/user/1001 type tmpfs (rw,nosuid,nodev,relatime,size=804092k,mode=700,uid=1001,gid=1001)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1001/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)
tmpfs on /dev/tmp type tmpfs (rw,nosuid,relatime,mode=755)
/dev/sda1 on /mnt/sdcard type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)Another fun fact: this device doesn’t normally get a DHCP IP on the ethernet interface. If you run dhclient in the terminal, it will get a DHCP IP. Now, you’re thinking you can update those package lists and install some convenient tools…
nvidia@tegra-ubuntu:~$ sudo apt install byobu
[sudo] password for nvidia:
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
nvidia@tegra-ubuntu:~$ apt-config dump APT::Periodic::Update-Package-Lists
APT::Periodic::Update-Package-Lists "1";
nvidia@tegra-ubuntu:~$ apt-config dump APT::Periodic::Unattended-Upgrade
APT::Periodic::Unattended-Upgrade "1";And if you do so, you’ll find that auto-package updates are enabled, gah.
Xenial is fortunately a long term release, but even so, it is a 2016 release, that’s 8 years old at this point. I have no easy way of restoring this device should it fail to boot (maybe there’s a process for forcing a re-image). Regardless, the best approach now is to take a disk image.
# On the camera
sudo dd if=/dev/mmcblk0 bs=4M status=progress | nc 192.168.0.64 9999
# On the receiving machine
nc -l 9999 | dd of=insta360.img bs=4M status=progressThe Nvidia module in question is a Jetson TX2. A quick eBay search reveals that they’re pretty affordable now on eBay:
I suspect, if I’m patient, I can get it for next to nothing. I’ll then have a way of testing changes to the firmware before applying them to my “production” unit… and worst case I can restore easily and/or swap modules.
While I wait I’ll disable some services to make this thing boot faster:
sudo systemctl disable lightdm
sudo systemctl disable cups(A month later)
It’s been about a month. I won one auction (£ 42), but the reserve wasn’t met. Four offers to different sellers weren’t accepted. Finally the fifth was, not for the best price (£100), but not terrible. So I now have a spare TX2 and development carrier board.
Ideally I’d like to flash the disk image I took earlier to the dev board and start doing some tuning but these boards don’t work like that. Nvidia doesn’t make a generic board-flash utility available, instead you have to use their “SDK Manager”, which downloads and builds and entire bloated Ubuntu image locally and then using a precarious chain of utilities, flashes that image to the board.
It’s ultra crap, especially when you compare it to the ease of flashing a Raspberry Pi.
It gets worse though; the TX2 is now a deprecated product. Nvidia hasn’t updated the toolchain for the SDK Manager in quite some time, so it only runs on Ubuntu 18.04. To make things worse, it won’t run in a VM, you have to run it on a full machine running Ubuntu 18.04… mmm… maybe this is an opportunity to buy another fun gadget 😂
More to follow…