Paul Sajna's Blog

I accidentally a car

2025-10-02T00:00:00+00:00

Question: How long does it take to turn lolcatz into production automobiles? Answer: 5 years and 2 days.

Obviously that's a ridiculous question with an overly-specific answer. As the description of this blog post ("A surreal story of Open Source maintainership"), indicates, the whole story you're about to read feels equally ridiculous to me. But that's part of what makes it so fun. Those who know me personally probably know I get a bit lost trying to explain things on the spot, and prefer to contemplate my words longer than realtime speech allows, so it's time to get this story down somewhere people can see it (also a few years late).

Alright, so lolcatz and cars, what? Stay with me here. During Winter break of 2018 (while I was in college), I posted a PR</a> on GitHub to a project called atsamd-rs. A little while earlier, I had received (free of charge, thanks Scott Shawcroft!) some Adafruit</a> dev boards, in particular, a Metro M4</a>, Circuit Playground Express</a>, and a Feather M0 Express</a>. A lot of people use their early 20s and college years as a time to experiment. For me, in 2018, that meant trying out hot new programming languages, Go and Rust. I fell in love with Rust</a>, made some contributions to Redox OS</a>, and continued exploring, particularly in the realm of Embedded Rust</a>. My programming journey has been characterized by a need to unravel abstractions and see what's beneath them. I had been programming for roughly 10 years in my spare time by 2018, so I was pretty deep below the surface-level abstractions, close to the metal, at the level of microcontrollers. Anyway, I had some adafruit dev boards, and I wanted to try embedded rust. For the Circuit Playground Express and the Feather M0, the underlying microcontroller a Microchip/Atmel SAM D21, was supported by the atsamd-rs project already, so I contributed some board-specific support files and examples for the CPX, and reviewed/tested Ben Bergman's changes to add the Feather M0. That was a good way to get my feet wet, but the Metro M4 posed a more interesting challenge. It had a newer, more powerful variant of the Microchip/Atmel SAM D family, the SAM D51. The SAM D51 had no HAL (hardware abstraction layer) support in atsamd-rs, meaning none of the microcontroller functionality had a usable interface for doing much of anything in Rust. That takes us back to the PR at the start of this long-winded paragraph. By late December 2018, I had gotten the SAM D51 and Metro M4 roughly working enough to blink an LED, and posted the PR. There was more to do to get other basics working, but by February 25 2019, I had enough working to draw the following image to an SSD1306 embedded oled display, and jokingly added a comment to the PR containing the image.

Ok so that's a lolcat, maybe, or is it called happycat? Eh, close enough. But what does any of this rant have to do with cars? I have an answer, I promise, it's coming, but hopefully the way I'm telling this story expresses how disconnected I personally feel the two things are. Initially, atsamd-rs was maintained by a gentleman named Wez Furlong, but shortly after I started contributing, he moved on to his WezTerm</a> project, and I was left to maintain atsamd-rs, along with some other contributors and maintainers. I continued adding more features, and reviewed a lot of PRs from other contributors, some of which went way over my head. On March 29th 2021, roughly 2 years after I started contributing, atsamd-rs received it's first commits and PR</a> from Glaeqen and vcchtjader We didn't realize at this time, but the vcc in vcchtjader stands for Volvo Cars Corporation. Check the merge commit message</a> if you don't believe me. By this time I was getting distracted by other cool rust projects, and starting my career, so I mostly left reviews to others, and eventually passed maintainership to Bradley Harden, like Wez had passed it to me. So I can't take much of the credit and I don't mean to. The blog title "I accidentally a car", isn't an attempt to take credit, it's more of a joke in the style of "I accidentally a word", like, "where did that come from?". By September of 2022, Volvo posted a blog to Medium</a> announcing it's usage of Rust in cars, and how it was using "an ATMEL/Microchip ATSAME chip, and there is an Open Source project for it." Props to mvniekerk for adding the ATSAME53 by the way, without which I might not have this story to tell. The SAM E53 is similar to the SAM D51 in a lot of aspects, and I like to think my addition of SAM D51 set the stage, but the SAM E53 was the real star of the automotive world. It turns out, very similar chips to those used in Adafruit dev boards played with by college students, are used in the safety critical automotive industry. Who'da thunk?

So by September 2022, we were well aware of Volvo's involvement, and atsamd-rs was increasingly being used for professional development, not just in cars either. A little later we learned Volvo was working with Polestar on the Polestar 3, which finally takes us back to the initial question's answer. The Polestar 3 was announced production ready</a> on February 27th 2024. 5 years and 2 days after I had posted the lolcatz on February 25 2019. Thanks to the atsamd-rs contributors and maintainers, and especially Volvo employees for putting this wild scenario in my lap. Thanks for reading.

Redox in your pocket

2025-09-21T00:00:00+00:00

I had the pleasure of going to RustConf 2025 in Seattle this year. During the conference, I met lots of new people, but in particular, I had the pleasure of spending a large portion of the conference hanging out with Jeremy Soller of Redox and System76. Eventually, we got chatting about EFI and bootloaders, and my contributions to PostmarketOS</a>, and my experience booting EFI-based operating systems (Linux) on smartphones using U-Boot</a>. Redox OS</a> is also booted via EFI, and so the nerdsnipe began. Could I run Redox OS on my smartphone the same way I could run PostmarketOS Linux?
Spoilers, yes.

This blog post will document the process I took to get it to boot, so that others can hopefully follow in my footsteps and improve some of the challenges I bumped up against, and maybe even contribute drivers and further the support. It will be a little handwavey and assume a high level of knowledge in some areas, because it is written for developers, and I don't want to explain every little detail.
Step 1: Das U-Boot</h2>
As alluded to in the introduction, U-Boot is a critical part of getting this to work. PostmarketOS developers (and others), have created compatible Qualcomm U-Boot Android bootimg for a handful of devices. This work is very much ongoing and scattered, but a few places to look include: the PostmarketOS wiki</a>, the U-Boot Qualcomm blogpost by Linaro</a> Tauchgang</a> U-Boot Qualcomm matrix channel</a>.
Now, we'll assume those resources are sufficient, and that you have a U-Boot Android Bootimg for the device in question. The first thing to do is get into fastboot (refer to postmarketos wiki), and flash the U-Boot image to your boot partition. We'll also assume you have backed up any internal storage you want to keep from your device.
THE FOLLOWING WILL OVERWRITE INTERNAL STORAGE AND YOU COULD BREAK THE PHONE, PLEASE TAKE APPROPRIATE PRECAUTIONS
fastboot erase dtbo fastboot flash boot /tmp/u-boot.img fastboot reboot </code></pre> Now the device will boot into U-Boot, and for most Qualcomm phones you have to hold volume up while U-Boot is booting to get a menu. Select USB Mass Storage in this menu (use volume and power to navigate), plug in a USB cable, and your phone's internal storage should show up as a series of partitions on your computer. Step 2: Flash and Hack Redox image</h2> Download the latest AARCH64 Redox Desktop live iso from https://static.redox-os.org/img/aarch64/</code> (currently at time of writing https://static.redox-os.org/img/aarch64/redox_desktop_aarch64_2025-09-21_91_redox-live.iso.zst)</li> Uncompress the zstd image zstd -d redox_desktop_aarch64_2025-09-21_91_redox-live.iso.zst</code></li> Loopback mount the image losetup -f -P redox_desktop_aarch64_2025-09-21_91_redox-live.iso</code></li> </ul> Now we have the individual partitions of the redox image ready to flash and change on the phone. We'll be overwriting the phone's storage once again, so ensure you have a copy of whatever you want to keep. Alright then, choose a couple small partitions that are big enough on the phone's internal storage, in my case that's cache and system but in your case it might be different. dd if=/dev/loop0p2 of=/dev/disk/by-partlabel/cache bs=8M oflag=direct status=progress dd if=/dev/loop0p3 of=/dev/disk/by-partlabel/system bs=8M oflag=direct status=progress </code></pre> Now we need to mount the partitions we just flashed onto the phone and make some changes. Perhaps eventually Redox will support split images, and the problems I uncovered with the bootloader and pcid will be fixed, and this will all be redundant. The RedoxFS filesystem isn't natively supported under Linux, but can be mounted as a Filesystem-in-userspace by running the redoxfs command from the following repo https://gitlab.redox-os.org/redox-os/redoxfs mkdir -p /mnt/redox-boot mkdir -p /mnt/redox-root mount /dev/disk/by-partlabel/cache /mnt/redox-boot redoxfs /dev/disk/by-partlabel/system /mnt/redox-root </code></pre> Copy the DTB for your phone (from postmarketos or u-boot) to the boot partition cp u-boot/.output/dts/dt.dtb /mnt/redox-boot/dt.dtb</code> The Redox bootloader does some weird stuff when parsing DTBs, and I hacked around it to get things working. My patch doesn't make a lot of sense so I haven't upstreamed it yet, but basically it turns all reads into 32-bit. Apply the following patch to the bootloader, recompile it, and copy it over the existing one. git clone https://gitlab.redox-os.org/redox-os/bootloader cd bootloader vim bootloader.patch </code></pre> diff --git a/src/os/uefi/dtb.rs b/src/os/uefi/dtb.rs index 3c7662e..59bf25e 100644 --- a/src/os/uefi/dtb.rs +++ b/src/os/uefi/dtb.rs @@ -46,24 +46,25 @@ unsafe fn get_dev_mem_region(fdt: &Fdt) { } }; let parent_bus_addr = { - if cell_sizes.address_cells == 1 { - BE::read_u32(&chunk[4..8]) as u64 - } else if cell_sizes.address_cells == 2 { - BE::read_u32(&chunk[8..16]) as u64 - } else { - DEV_MEM_AREA.clear(); - return; - } + BE::read_u32(&chunk[0..4]) as u64 }; let addr_size = { - if cell_sizes.size_cells == 1 { - BE::read_u32(&chunk[8..12]) as u64 - } else if cell_sizes.size_cells == 2 { - BE::read_u32(&chunk[16..20]) as u64 - } else { - DEV_MEM_AREA.clear(); - return; - } + BE::read_u32(&chunk[0..4]) as u64 }; println!( "dev mem 0x{:08x} 0x{:08x} 0x{:08x}", </code></pre> git apply bootloader.patch make TARGET=aarch64-unknown-uefi BUILD=build cp build/bootloader.efi /mnt/redox-boot/EFI/BOOT/BOOTAA64.EFI </code></pre> pcid fails to launch because Redox doesn't have a pci controller for Qualcomm. It doesn't need it to boot, but by default it will try and halt the boot if it fails. Remove the following line from /mnt/redox-root/usr/lib/init.d/00_drivers</code> pcid-spawner /etc/pcid.d/ </code></pre> Alright, changes made, unmount and let's get booting! umount /mnt/redox-root umount /mnt/redox-boot losetup -d /dev/loop0 </code></pre> Step 3 boot</h2> Press volume buttons to exit the usb mass storage function of u-boot, and select the usb serial gadget function Then we'll get to configuring the bootloader. picocom -b 115200 /dev/ttyACM0 eficonfig </code></pre> This will bring up the menu to configure EFI, unfortunately the partitions are listed by number rather than name, so either try a bunch of them until you find the partition redox boot partition, or go back to ums and run blkid</code> to find it. Configure roughly as follows: Then run bootefi bootmgr</code> and the Redox bootloader should start Press l</code> for live mode when prompted, then press enter After all that work, it will most likely still be temperamental and require a few retries to boot. There's some weird issue with parsing and mapping the available memory After a few tries though, it should show the login prompt. This is the end of the road for now, because there are no touch drivers etc. Until next time. 
FPGA MCS6530 RRIOT Replacement Released! 2025-02-04T00:00:00+00:00 Today I'm excited to announce a project I've been working on for over a year is working and ready for early adopters to play with. Since October 2023, I've been writing FPGA gateware to replicate one of the rarest chips in the retrocomputing space, the MCS6530 released by MOS. This chip is featured in the KIM-1 Computer, released in 1975, as well as several other arcade boards from the 70s and 80s. My project is called yo6530 and it is available on github here</a>. The board it uses is called the reDIP RIOT</a> and it was designed by Dag Lem, creator of the reSID engine used by the VICE C64 emulator. The board features a Lattice ICE40UP5k FPGA, and the gateware compiles with the opensource toolchains. I currently have the 6530-002 and 6530-003 variants of this chip functioning well enough to boot my replica KIM-1 with the motherboard</a> designed by Eduardo Casino. There is more work to do to support different variants of the 6530 in my project, as well as ironing out any bugs found. Contributions are welcome on github. I have more exciting things coming in the world of KIM-1, so stay tuned! This is just the beginning of what I have coming, but people seem to be taking notice</a>, so I suppose I should make it official. Modern Desktop Linux on a Sony PS3 in 2024 2024-08-18T00:00:00+00:00 Alternate title: 2024 - The year of the linux desktop on a PS3 This guide will show you how to install the latest Debian (trixie/sid) distro with a very modern Linux kernel (6.4 currently). The instructions should be pretty much the same going forward beyond these versions in the future. Why would you want to do that, you may be asking? I don't have a great answer but maybe you want to bring new life to your old console or maybe you just think it's cool/funny/interesting like I do. If you found your way here you probably don't need my weak attempts at justification anyways. I consider many of my projects to be what I've taken to calling Dada programming (as in Dadaism</a>), but that's a blog post for another time. So let's get on with it then. Installing CFW</h2> The first thing you'll need to do is install up to date CFW (custom firmware) on your PS3. I used Evilnat CFW but anything with OtherOS/PetitBoot support should work. There's a video that shows you how to do that here</a> One thing I ran into while trying to follow that video was that my PS3 didn't have recent enough SSL certificates to browse to the https://www.ps3toolset.com URL. (error code 0x80710a06) If that's the case you may have to update to OFW (official firmware) 4.91 before installing custom firmware, or you can use a reverse proxy. I used a modified version of the script from this stackoverflow page</a>, but I no longer have the exact script I used and the more think about it I'm not really sure how it works well enough to make a firm recommendation. Proxying http to http to a page that redirects to https??? Sorry, I did something that worked on 4.75 but I really don't know how it worked or what it was anymore. Installing Petitboot Bootloader</h2> Once you have the custom firmware running, the next step is to set up the bootloader for OtherOS, which is called Petitboot. You can download it here</a>. Whether you download the NAND or NOR file depends on the model of PS3 you have. You can look up the model number here</a>. Put the dtbimage file for your model on a USB flash drive and plug it into your PS3, then select these options in the XMB in this order. Downloading tools</h2> I'm assuming you have a traditional Linux Desktop PC to set this up on. You'll also need an external USB HDD/SSD/or I guess a 32GB+ flash drive might work too. So on your linux workstation, you're going to need the following tools to follow along with the rest of this guide. How you'll obtain and configure them is distro-specific, but should be easy enough to search if you have a moderate level of linux experience. git</li> powerpc64-linux-gnu-gcc ( not powerpc64le-linux-gnu-gcc! )</li> qemu binfmt (also sometimes called binfmt-misc)</li> gparted</li> debootstrap</li> </ul> Formatting the disk</h2> Whether the disk is MBR or GPT partition table doesn't seem to matter. I've heard GPT is recommended but I used MBR without noticing it and it works fine. Set up the disk with a large ext4 root partition and a 2GB (or more if you want) swap partition. The PS3 has 256MB of main system RAM and another 256MB of VRAM that can be used with some manual setup, and you'll probably be swapping lots as a result. Once I formatted the disk as ext4 and tried to boot off it, I got some weird errors from petitboot (or maybe it was the kernel, I don't remember for sure). I had to disable journalling and checksumming in the filesystem to get it to boot sudo tune2fs -O ^metadata_csum /dev/sdb1 # MAKE SURE YOU REPLACE THIS WITH THE CORRECT BLOCK DEVICE sudo tune2fs -O ^has_journal /dev/sdb1 # MAKE SURE YOU REPLACE THIS WITH THE CORRECT BLOCK DEVICE </code></pre> Cross-Compiling the Kernel</h2> You might need to download a bunch of other nonsense like yacc and bison for this step, search up the packages you need to compile a kernel before continuing. The kernel sources for ps3 linux are available here</a>. I used the master branch which is currently version 6.4.0 but you're welcome to explore some of the other branches/tags if you're feeling adventurous. Clone this repo using git. My kernel config is here</a>. It's similar to this one</a> which itself is derived from the upstream ps3_defconfig</a>. My config adds some drivers specific to the usb keyboard I was using because I had issues with that initially. I think the actual problem I encountered may have been kernel modules not being properly installed, so one of the other configs would probably work just as well. Place the config in the ps3-linux folder you cloned from git and call it .config (this will make it a hidden file!). As new kernel options are added you may also need to run make ARCH=powerpc CROSS_COMPILE="powerpc64-linux-gnu-" olddefconfig </code></pre> to update the config and you can also use menuconfig</code> in place of olddefconfig</code> to bring up the kernel configuration menu if you have any additional customizations to make. Once the kernel is configured, run make ARCH=powerpc CROSS_COMPILE="powerpc64-linux-gnu-" -j$(nproc) </code></pre> to compile the kernel Next you'll want to mount the ext4 partition you created on your external disk with gparted so we can install the kernel to it. sudo mkdir /mnt/ps3linux sudo mount -t ext4 /dev/sdb1 /mnt/ps3linux # replace sdb1 with your actual block device sudo mkdir /mnt/ps3linux/boot </code></pre> Then to actually install the kernel, run sudo make ARCH=powerpc CROSS_COMPILE="powerpc64-linux-gnu-" INSTALL_PATH="/mnt/ps3linux/boot" install sudo make ARCH=powerpc CROSS_COMPILE="powerpc64-linux-gnu-" INSTALL_MOD_PATH="/mnt/ps3linux/" modules_install </code></pre> Creating the rootfs</h2> Ok we have the kernel, next up is the userspace! You could probably use any distro that supports PPC64 (big endian) here but to keep things focused and straightforward I'll show you how to set up Debian. Debian has a tool called debootstrap that it uses to create the rootfs. You might also be able to use mmdebstrap to install the rootfs and the standard desktop packages together, but I didn't try that, so I'll show you what I tried. sudo apt install debian-ports-archive-keyring sudo debootstrap --arch=ppc64 --variant=buildd --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg sid /mnt/ps3linux https://deb.debian.org/debian-ports sudo mount -t proc proc /mnt/ps3linux/proc sudo chroot /mnt/ps3linux sudo apt install debian-ports-archive-keyring </code></pre> This creates a very simple small debian install on our external drive, and changes-root (chroots) into it using qemu-binfmt so we can continue adding things we need. Configuring the rootfs</h2> At this point, you've got a debian install you can add whatever you need to. I'll make some recommendations but this part is very individualized and personal to what you like on your linux systems. I typically install a text editor (vim), some build tools (build-essential), curl, wget, git, ssh, etc. You're also going to want to configure your users and passwords in this step so you can login when the system boots up on the ps3. I installed and ran the tasksel</code> command which is part of the debian installer and gives you a guided menu to install the default desktop environment and many other default packages. Lastly, when I was troubleshooting the boot process later on, I noticed I needed to install the login</code> package, because systemd-logind</code> was somehow broken and I was unable to login to my user accounts. We'll also need to set up the initial ram filesystem (initramfs) which the kernel uses during the boot process mkinitramfs -k -o /boot/initrd.img 6.4.0+ # replace '6.4.0+' with the kernel version you compiled </code></pre> Once you're done, run exit</code> to leave the chroot. Configuring the bootloader</h2> Place this bootloader config in /mnt/ps3linux/etc/yaboot.conf</code> Note this assumes a 1080p screen video mode. init-message = "Debian on PS3" timeout=5 default=Debian image=/boot/vmlinux label=Debian initrd=/boot/initrd.img root=UUID=f9937a76-f7e6-4c7a-a4bd-04820c13d420 append="video=ps3fb:mode:133 nomodeset rw" image=/boot/vmlinux label=Debian failsafe initrd=/boot/initrd.img root=UUID=f9937a76-f7e6-4c7a-a4bd-04820c13d420 append="video=ps3fb:mode:133 nomodeset rw memtest noapic noapm nodma nomce net.ifnames=0 nolapic vga=normal" image=/boot/vmlinux.old label=Debian old initrd=/boot/initrd.img.old root=UUID=f9937a76-f7e6-4c7a-a4bd-04820c13d420 append="video=ps3fb:mode:133 nomodeset rw nosplash" image=/boot/vmlinux.old label=Debian old failsafe initrd=/boot/initrd.img.old root=UUID=f9937a76-f7e6-4c7a-a4bd-04820c13d420 append="video=ps3fb:mode:133 nomodeset rw nosplash memtest noapic noapm nodma nomce nolapic vga=normal" </code></pre> Other video modes may be used by replacing 133 with one of these AUTO Detect Mode: 0: auto (480i/576i if not HDMI) 60 Hz Broadcast Modes: 1: 480i (576 x 384) 2: 480p (576 x 384) 3: 720p (1124 x 644) 4: 1080i (1688 x 964) 5: 1080p (1688 x 964) 50 Hz Broadcast Modes: 6: 576i (576 x 460) 7: 576p (576 x 460) 8: 720p (1124 x 644) 9: 1080i (1688 x 964) 10: 1080p (1688 x 964) VESA Modes: 11: wxga (1280 x 768) 12: sxga (1280 x 1024) 13: wuxga (1920 x 1200) 60 Hz Full Screen Broadcast Modes: 129: 480if (720 x 480) 130: 480pf (720 x 480) 131: 720pf (1280 x 720) 132: 1080if (1920 x 1080) 133: 1080pf (1920 x 1080) 50 Hz Full Screen Broadcast Modes: 134: 576if (720 x 576) 135: 576pf (720 x 576) 136: 720pf (1280 x 720) 137: 1080if (1920 x 1080) 138: 1080pf (1920 x 1080) </code></pre> Boot 🐧🐧 🎉</h2> With all that set up, you should be ready to unplug the external drive from your linux workstation, plug it and a usb keyboard into your PS3, and select the "Set OtherOS boot flag" option in the menu we previously used to install petitboot. Petitboot will present the bootloader options we've just configured, you can select one of them to boot. Hopefully you see the happy Tux penguins during boot and land at a login prompt. Happy Linuxing! Miscellaneous Notes</h2> You can use PS3 vram as swap by following this guide</a> You may also need to set up /etc/fstab to take advantage of the swap partition you configured earlier. References/Kudos</h2> https://sourceforge.net/p/redribbon/wiki/Home/</a> https://github.com/olin000/PS3-Debian</a> EvilNat CFW</a> https://wiki.debian.org/PPC64</a> PSP Reverse Engineering - Choose your words wisely 2021-03-23T00:00:00+00:00 “Words have a magical power. They can either bring the greatest happiness or the deepest despair.” -Sigmund Freud </blockquote> The problem</h2> What went wrong when I initially tested my Rust nidcracker program? As I mentioned in the original post, high entropy and a small hash == garbage output. The high entropy problem comes from using every permutation of 4 words from 1000 words (give or take). The solution</h2> How can we solve it? Simple, use a shorter, more carefully crafted wordlist. User Meeeow in The PSP Homebrew Discord Server</a>, One of the main contributors behind UOFW</a>, used my same exact nidcracker program from the previous post, combined with some knowledge of what the functions with unknown NIDs did, chose specific words related to what the functions were doing, and successfully cracked a few unknown NIDs. found match: 0x7939C851 = sceChkregGetPspModel found match: 0x6894A027 = sceChkregGetPsFlags </code></pre> Lessons</h2> The first lesson is, with the right wordlist, these NIDs can be cracked, and there's absolutely nothing wrong with my program, but with the approach I took to creating the wordlist for it. In the first blog post, I basically alleged that NIDs couldn't be cracked without the results being meaningless. I now know this is not the case. In fact, watch what happens if I cheat a bit and use known nids, with a wordlist built from words in those known NIDs. found match: ED1410E0 = sceKernelDeleteFpl found match: 86255ADA = sceKernelDeleteMbx found match: 6B2371C2 = sceKernelDeleteModule found match: F8170FBE = sceKernelDeleteMutex found match: 28B6489C = sceKernelDeleteSema found match: 9FA03CD3 = sceKernelDeleteThread found match: 32BF938E = sceKernelDeleteTlspl found match: 89B3D48C = sceKernelDeleteVpl found match: 3FC9AE6A = sceKernelDevkitVersion found match: D636B827 = sceKernelDipswAll found match: 5282DD5E = sceKernelDipswSet found match: D774BA45 = sceKernelDisableIntr found match: 1C46158A = sceKernelDmaExit found match: 4D6E7305 = sceKernelEnableIntr found match: 05572A5F = sceKernelExitGame ... </code></pre> Within seconds, we have hundreds of valid nids. (list shortened for blogpost) That brings me to the second lesson: test the happy path before giving up. A coworker of mine says the happy path hides bugs, because it's usually the things you don't think about that cause problems in code. But, if we never test the happy path at all, how can we ever be happy? In the previous blog post, I tested NIDs that had been uncracked for years, with 1000 words from NIDs we knew, and concluded that a solution was impossible. I failed to ever test the happy path, and I was unhappy with the outcome. It seems obvious now. In conclusion: Don't worry, be happy. -Bob Marley </blockquote> PS: I wrote a hashcat module for NIDs</a> after I was inspired by the successful outcomes of Meeeow. PSP Reverse Engineering - NID Cracking 2020-10-07T00:00:00+00:00 What is a NID?</h2> A NID, which I believe stands for Name Identifier, is an identifier used in Sony's PRX executable format for function imports and exports. They are located in the .rodata.SceNid section of every PRX, to identify which operating system or other external functions are used in the program. A NID consists of the first 4 little-endian bytes of the SHA-1 hash of the function name, and in later versions of the PSP OS, a salt. Legend has it, they can be bruteforced to discover the names Sony used for their functions, to aid in reverse engineering. Experienced cryptographers would have probably realized the problem before writing a program to check the results. The problem</h2> So it turns out, there are quite a few hash collisions for the first 4 hexadecimal bytes of a SHA-1 hash. Here are a few of my favourites, which you can check by running echo -n <name> | sha1sum</code> on any linux pc (assuming checksum packages are installed). Note that you have to swap endianness (read the bytes backwards). 7CF05E81 = sceSysregAllocateNotifyRapidHead 4C0BED71 = sceSysregAbortFatfmtSteepIn 7CF05E81 = sceSysregActivateDataMbogoPIO </code></pre> I purposely chose two here that came up with the same NID for the function name, to demonstrate the problem of hash collisions. If you're following along at home, run the following at a linux prompt: echo -n sceSysregAllocateNotifyRapidHead | sha1sum echo -n sceSysregActivateDataMbogoPIO | sha1sum </code></pre> The results are 815ef07c4b2f44c74cab9af3772c49e49dc41544 - 815ef07cbd77ac3b13f1813c063aff7794960741 - </code></pre> It is plain to see that they start with the same 4 bytes (8 characters), and if you read the bytes (digit pairs) backwards, you will see the NID. So that's no good, we have multiple possible answers to the same problem, and both of them are nonsensical. I'm unsure how functionnames were ever recovered from NIDs, after working through this. I know some of the function names were leaked in games with debug symbols</a>, but that doesn't account for all the kernel functions that were never used in games that have been recovered. Maybe the salts narrow the problem down a bit, I'm not sure. I tested without salts, because I was told earlier versions of the kernel didn't use them, with NIDs, and it was easier for me not to. Methods</h2> So, if you want to try your hand at NID cracking, I'll explain what I did in this section. I wrote a parallelized Rust</a> program that runs on a modern desktop CPU. I was planning to later use GPUs for more parallelism/speed, but the ridiculous results I got have me convinced it's not worth persuing further. If you're unfamiliar with Rust, you can download it at https://rustup.rs</a>, and learn how to use it at https://doc.rust-lang.org/book/</a> The (slightly messy) source of my program is below: use openssl::sha::sha1; use rayon::prelude::*; use rayon::iter::ParallelBridge; use std::fs::read_to_string; use itertools::Itertools; fn main() { //let module_names_string = read_to_string("module-names.txt").unwrap(); //let module_names_split = module_names_string.split('\n'); //let module_names: Vec<&str> = module_names_split.collect(); let module_name = "sceSysreg"; let wordlist_string = read_to_string("wordlist.txt").unwrap(); let wordlist_split = wordlist_string.split('\n'); let wordlist: Vec<&str> = wordlist_split.collect(); let unknown_nids_string = read_to_string("unknown_nids.txt").unwrap(); let unk_nids_split = unknown_nids_string.split('\n'); let unk_nids: Vec<&str> = unk_nids_split.collect(); wordlist.par_iter().for_each(|word| { let test_string = module_name.to_string() + word; let hash = sha1(test_string.as_str().as_bytes()); let test_nid = format!( "{:02X}{:02X}{:02X}{:02X}", hash[3], hash[2], hash[1], hash[0], ); if unk_nids.contains(&test_nid.as_str()) { println!("found match: {} = {}", test_nid, test_string); } }); let wordlist_2perms = wordlist .iter() .permutations(2) .into_iter() .par_bridge() .into_par_iter(); wordlist_2perms.for_each(|perm| { let test_string = module_name.to_string() + perm[0] + perm[1]; let hash = sha1(test_string.as_str().as_bytes()); let test_nid = format!( "{:02X}{:02X}{:02X}{:02X}", hash[3], hash[2], hash[1], hash[0], ); if unk_nids.contains(&test_nid.as_str()) { println!("found match: {} = {}", test_nid, test_string); } }); let wordlist_3perms = wordlist .iter() .permutations(3) .into_iter() .par_bridge() .into_par_iter(); wordlist_3perms.for_each(|perm| { let test_string = module_name.to_string() + perm[0] + perm[1] + perm[2]; let hash = sha1(test_string.as_str().as_bytes()); let test_nid = format!( "{:02X}{:02X}{:02X}{:02X}", hash[3], hash[2], hash[1], hash[0], ); if unk_nids.contains(&test_nid.as_str()) { println!("found match: {} = {}", test_nid, test_string); } }); let wordlist_4perms = wordlist .iter() .permutations(4) .into_iter() .par_bridge() .into_par_iter(); wordlist_4perms.for_each(|perm| { let test_string = module_name.to_string() + perm[0] + perm[1] + perm[2] + perm[3]; let hash = sha1(test_string.as_str().as_bytes()); let test_nid = format!( "{:02X}{:02X}{:02X}{:02X}", hash[3], hash[2], hash[1], hash[0], ); if unk_nids.contains(&test_nid.as_str()) { println!("found match: {} = {}", test_nid, test_string); } }); } </code></pre> I hard-coded the module name to look for functions of the sceSysreg module for this first test, and was planning to cover other modules as well. The program then uses rayon's parallel iterator and itertools to calculate permutations of a wordlist, and calculates hashes of the permuations with openssl. I used a python program to build a wordlist from known nids (basically splitting camelcase into words), and got some unknown nids from the emulator JPCSP</a>. My wordlist is at wordlist.txt</a> and the nids I chose to crack are at unknown_nids.txt</a> Rust projects also have a Cargo.toml file with basic metadata, which I will supply below [package] name = "nidcracker" version = "0.1.0" authors = ["Paul Sajna <sajattack@gmail.com>"] edition = "2018" [dependencies] openssl = "0.10" rayon = "1.4.1" itertools = "0.8.2" </code></pre> The latest version of the code is available at https://github.com/sajattack/nidcracker</a>. Build the project like any other rust project, with cargo build --release</code>, and the binary will be output as target/release/nidcracker. So I ran all this for a few hours, and you can see my results at https://gist.github.com/sajattack/dd4c6df4aec0de8b641216515bdc49ed</a> Conclusion</h2> I'm not really sure where to go from here. The results are nonsensical so I will have to find another way to uncover kernel function names. If you have any suggestions feel free to contact me on Twitter</a>.

Miscellaneous Notes</h2>
You can use PS3 vram as swap by following this guide</a></p>
You may also need to set up /etc/fstab to take advantage of the swap partition you configured earlier.</p>

References/Kudos</h2>
https://sourceforge.net/p/redribbon/wiki/Home/</a></p>
https://github.com/olin000/PS3-Debian</a></p>
EvilNat CFW</a></p>
https://wiki.debian.org/PPC64</a></p>

The problem</h2>
What went wrong when I initially tested my Rust nidcracker program? As I mentioned in the original post, high entropy and a small hash == garbage output. The high entropy problem comes from using every permutation of 4 words from 1000 words (give or take).</p>

`Conclusion</h2> I'm not really sure where to go from here. The results are nonsensical so I will have to find another way to uncover kernel function names. If you have any suggestions feel free to contact me on Twitter</a>.</p>`

Paul Sajna's Blog

I accidentally a car

Redox in your pocket

FPGA MCS6530 RRIOT Replacement Released!

Modern Desktop Linux on a Sony PS3 in 2024

PSP Reverse Engineering - Choose your words wisely

PSP Reverse Engineering - NID Cracking

Paul Sajna's Blog

I accidentally a car

Redox in your pocket

FPGA MCS6530 RRIOT Replacement Released!

Modern Desktop Linux on a Sony PS3 in 2024

Cross-Compiling the Kernel</h2> You might need to download a bunch of other nonsense like yacc and bison for this step, search up the packages you need to compile a kernel before continuing.</p>

Miscellaneous Notes</h2> You can use PS3 vram as swap by following this guide</a></p> You may also need to set up /etc/fstab to take advantage of the swap partition you configured earlier.</p>

References/Kudos</h2> https://sourceforge.net/p/redribbon/wiki/Home/</a></p> https://github.com/olin000/PS3-Debian</a></p> EvilNat CFW</a></p> https://wiki.debian.org/PPC64</a></p>

PSP Reverse Engineering - Choose your words wisely

The problem</h2> What went wrong when I initially tested my Rust nidcracker program? As I mentioned in the original post, high entropy and a small hash == garbage output. The high entropy problem comes from using every permutation of 4 words from 1000 words (give or take).</p>

PSP Reverse Engineering - NID Cracking

Conclusion</h2> I'm not really sure where to go from here. The results are nonsensical so I will have to find another way to uncover kernel function names. If you have any suggestions feel free to contact me on Twitter</a>.</p>

Miscellaneous Notes</h2>
You can use PS3 vram as swap by following this guide</a></p>
You may also need to set up /etc/fstab to take advantage of the swap partition you configured earlier.</p>

References/Kudos</h2>
https://sourceforge.net/p/redribbon/wiki/Home/</a></p>
https://github.com/olin000/PS3-Debian</a></p>
EvilNat CFW</a></p>
https://wiki.debian.org/PPC64</a></p>

The problem</h2>
What went wrong when I initially tested my Rust nidcracker program? As I mentioned in the original post, high entropy and a small hash == garbage output. The high entropy problem comes from using every permutation of 4 words from 1000 words (give or take).</p>

`Conclusion</h2> I'm not really sure where to go from here. The results are nonsensical so I will have to find another way to uncover kernel function names. If you have any suggestions feel free to contact me on Twitter</a>.</p>`