Trammell Hudson

Trammel Hudson, the guy behind Heads, does a lot of interesting maker type projects too. His personal project site is worth checking out: https://trmm.net

Off topic, but highly recommended: Trammell Hudson's other projects[0]. The most famous of which is Magic Lantern, an alternative firmware for Canon DSLRs which makes them infinitely more useful for movie making (and a little more useful for stills); but other projects are also worth looking at. [0] https://trmm.net/

A few years ago I built an adapter to allow classic Mac CRT's to be used with BeagleBone or Raspberry Pi systems ( https://trmm.net/Mac-SE_video). X11 has supported 1-bit mono displays since forever, so it mostly worked out of the box with well written programs. Watching youtube videos in 1-bit is an amazing aesthetic. Unfortunately all of my videos of it were on vine, so this Muybridge-esque cat video seems to be the only one that I cross-posted to twitter: https://twitter.com/qrs/status/1045272076750401536

Disclaimer: I didn't fully read the article yet. I wanted to mention the excellent HEADS project (as in the other side of TAILS): https://github.com/osresearch/heads This talk is great: https://trmm.net/Heads_33c3 I remember when UEFI became a thing and people were complaining in linux forums that the keys are controlled by the manufacturers and 'the whole thing is a ploy by microsoft to kill linux' (UEFI is just a convoluted standard way to write BIOS in a certain way). Now we can control the keys, all we need to do is kick UEFI to the curb and use linux from BIOS all the way to the DE/WM (coreboot..). Turns out we can turn the boot process into a chain of kexec's and simplify everything greatly.

They have a lot of power, and plugging something like a thunderbolt device in can load an option ROM that runs there [1]. It is one of the reasons linuxboot is such an important project [2]. There is a great talk on why linuxboot is required [3]. [1] https://trmm.net/Thunderstrike [2] https://www.linuxboot.org [3] https://trmm.net/LinuxBoot_34c3

Very interesting thank you. You may already be aware, but when I first saw the replies here mentioning Option ROMs I immediately thought of the thunderstrike EFI vulnerabilities for Macbooks. I've yet to actually mess with them, but apparently that was how they worked at least in the first generation, I haven't followed the research much further yet [https://trmm.net/Thunderstrike]. So since option ROMs, for obvious reasons, survived the "transition" to EFI, does this mean the same mechanism could be used in BIOS machines? At least this might also have implications for backporting peripheral drivers too (for whatever reason)...

This is a great point. The advantage I see to using pubkey is integration with, for example, a cryptocard (https://trmm.net/Yubikey). Still, I wonder if the default should be to use gpg --symmetric instead.

> As far as I know, you’ll need to take the machine apart to reflash it, plus special hardware This doesn't take very long. Maybe 5 minutes to disassemble the machine. As for hardware, you can flash SPI chips using a Teensy and a clip chip. [1] The total cost of parts is under $30. Incidentally, I highly recommend investing in one of these if you're doing firmware development for routers. It's so much easier to flash a backup than muck around with TFTP. > because when a firmware password is set, a Mac requires the password to choose a different boot disk. This is hardly unique to Apple. Most PC laptop manufacturers also disable changing the boot device or choosing a temporary boot device when a setup password is enabled. > with this feature, Apple HQ can give a service center the ability to clear a particular firmware password without giving them a universal backdoor (hardware or software). Um, this is how it works for PC firmware passwords as well. Unless there is a keygen available, most modern implementations use a hashed value from the serial number or hard drive as the master unlock password. It's unique to the laptop being unlocked. [1] https://trmm.net/SPI_flash

> That said I don't like contributing to the business model of paying for privacy - seems broken. I fully agree. But to be fair, in a other comment someone linked to a website [0] explaining that the app could be used without connection to internet. So in this case perhaps Bosch didn't have as much of a malicious intent as originally thought. Quote from the link: However, [..], the BSH "HomeConnect" appliances have a no-cloud mode built into their app without any hacks required to disconnect them from the internet. They do require a one-time connection to perform key exchange of a long-live authorization key, but from then on the appliances can be operated entirely disconnected from the network. [0] https://trmm.net/homeconnect/#no-cloud-mode

Seems like this Home Connect stuff does support local only/no cloud mode[0]. I recently discovered my parent's kitchen hardware is all Bosch with Home Connect and was afraid I had to run it through their cloud. But there seems to be some decent effort done in getting it to work with Home Assistant[1]. [0] https://trmm.net/homeconnect/ [1] https://github.com/hcpy2-0/hcpy

The connection machine had several modes for the front lights. The one most familiar is "random and pleasing" and the code can be found here: https://trmm.net/CM-2/ Reference: https://thedailywtf.com/articles/Thinking-Machines#comment-194568

> My dream is to intercept the write-enable lines on the flash chips holding these firmwares so I can lock out updates. And schedule a daily reboot for any memory-resident-only crap. There was an open hardware project for SD card emulation, where the emulator could reject writes, https://github.com/racklet/meeting-notes/blob/main/community/2021.md OSS emulation for SPI flash, https://trmm.net/Spispy/ Some USB drives (Kanguru) and SSD enclosures (ElecGear M.2 2230 NVME) have firmware and physical switch to block writes, useful to boot custom "live ISOs" that run from RAM.

If I had a plotter, I'd try a few things with plotter.vision. It converts a 3D STL file to SVG with "hidden wireframe removal". There is also an "anaglyph" mode to output red/blue lines to be seen in 3D with red/blue glasses. The online converter: https://plotter.vision/ More info from Trammell Hudson, the author: https://trmm.net/Plotter-Vision/

Yeah if I’m understanding the article correctly it’s not that the glue is pre-printed with a specific code but rather the glue has a bunch of particles suspended in it and take on an arbitrary pattern when used. Conceptually similar to https://trmm.net/Glitter/ but at a much smaller scale.

I enjoyed this reverse engineering, using a direct connection within your home network after the keys have been extracted after an initial authorization to the Bosch/Siemens cloud: https://trmm.net/homeconnect/

Heads project page: https://trmm.net/Heads/ > Heads is an open source custom firmware and OS configuration for laptops and servers that aims to provide slightly better physical security and protection for data on the system ... it combines physical hardening of specific hardware platforms and flash security features with custom Coreboot firmware and a Linux boot loader in ROM. > This moves the root of trust into the write-protected ROM and prevents further modifications to the bootup code. Controlling the first instruction the CPU executes allows Heads to measure every step of the boot process into the TPM, which makes it possible to attest to the user or a remote system that the firmware has not been tampered with.

With Intel Boot Guard (now almost pre-enabled on all laptops on the market), the CPU verifies the digital signature of BIOS code. The public key is burned into the chip [0] by the OEM before it leaves the factory. If signature verification fails, the CPU refuses to execute any code. Naturally, any code modification in the BIOS causes the check to fail and effectively bricking the BIOS. [0] Actually the PCH, aka southbridge, not the CPU. But it's not much of a difference for end users. See: * Intel Boot Guard, Coreboot and user freedom https://mjg59.dreamwidth.org/33981.html * Why You Don't See Coreboot Supported By Many Modern Intel Systems https://www.phoronix.com/news/Intel-Boot-Guard-Kills-Coreboot * Bootguard (for a technical description) https://trmm.net/Bootguard/

Can MAME[1] emulate Vectrex games on a normal screen now? I searched for a few minutes, but the results seem to be about using MAME to control an original Vectrex vector display, (such as: https://trmm.net/Vectrex/), not emulation of Vectrex on an LCD display, [1] https://wiki.mamedev.org

You might start with https://trmm.net/Symbolics/ which seems to be pretty much ready-to-go with an Arduino. If you're in the Bay Area, I would build the adapter for you just to have the opportunity to check out a Symbolics keyboard first-hand :)

Check out trmml's thunderstrike for an example of a working hardware worm. Its not exactly what you are outlining, but close enough for me to think 'yeah, does not need a nation-state level actor to do'. It would be a different exploit chain for HDMI, and I am no expert in either HDMI or thunderbolt to make a claim that its possible, but I've been surprised with the amount of complexity HDMI offers. https://trmm.net/Thunderstrike/

>> It was completely implausible - the chip that was identified could not possibly carry enough processing ability to do anything useful as far as espionage goes, had no connectivity to networking, and there was never any evidence of communication from these devices to anything suspicious or unknown. > Could the device not simply get the host to do these things for it, by e.g. rootkit-ing the server’s BMC? A “hardware virus”, per se. IIRC, that's exactly what was alleged in the article. It was an implant that sat on the BMC ROM bus, fiddling with bits as the ROM was read during bootup. No need for any networking or processing ability beyond what was needed to that. This guy actually did a POC of that: https://trmm.net/Modchips/. So totally plausable.

Nope. That's dangerous, TPM keys can be sniffed on the bus: https://trmm.net/tpm-sniffing/

Check out this project! https://trmm.net/Ikea/ Apparently, the firmware on some IKEA smart home devices can be easily flashed.

Why are you insisting on going back to the 1970s? What you are describing is more or less what my first computer terminal was in 1978: a second-hand ASR33 (https://trmm.net/Model_ASR33_Teletype/). If that's too big and bulky for you, there was a Brother electronic typewriter in the mid-1980s that could save small amounts of text in its memory for printing later. (https://www.shopgoodwill.com/Item/85456117) You could also interface it to some form of computer. These things were superseded by word-processors: Dedicated computers that had screens, keyboards and printers. That enable you to prepare text, fix up your typos, shift text around, and when you were satisfied with it, to print out your final copy. Finally we had general-purpose personal computers that could not only do word-processing, but were just as happy doing financial work and also browsing the internet.

https://trmm.net/Modchips/ This presentation at 35C3 made me a believe that the original Bloomberg report is grounded in truth

https://trmm.net/AVR_RFID/ Looks like a pretty unregulated power supply to me, lol. I realize you're talking about normal use, and not abuse like this avrTiny example, but... those Microchip / Atmel chips are pretty legendary with regards to the electrical abuse they withstand.

Ah - brings back memories of the old teletype I first used that had an actual mechanical bell that rang if it got that. Similar to https://trmm.net/Model_ASR33_Teletype

Several months after the story was published someone actually presented a proof of concept demonstrating the practical feasibility of the claimed hack[1]. See presentation at https://media.ccc.de/v/35c3-9597-modchips_of_the_state (https://www.youtube.com/watch?v=C7H3V7tkxeA), and project website at https://trmm.net/Modchips There's irony in how people repeat and share the technical rebuttals long after those rebuttals have been conclusively rebutted themselves. That in no way absolves Bloomberg, but the indignation of their critics is tiresome. [1] Of course the specific details of the claimed hack were never reported, but the proof-of-concept fits the claims, and in any event is more than sufficient to rebut the rebuttals.

Hilariously enough it was proven as plausible and a proof of concept was built. https://trmm.net/Modchips

Trammell Hudson in 2009 reverse engineered the firmware of the Canon EOS 5D Mark II because he was frustrated with some of the limitations in the camera's firmware when making short films. That little hack turned into Magic Lantern. On his website [1] you'll find a screenshot [2] of his first success: adding three extra vanity letters to the firmware version number. He states: "Re-writing strings is a good easy technique for figuring out if you have 'won' and your code is running on the system." [1] https://trmm.net/Taking_things_apart#Extending [2] https://www.flickr.com/photos/osr/16412008471/lightbox/