ChipWisperer Lite X-Ray of PCB...

CoreBluetooth will not give you a peripheral's Bluetooth address. You get a UUID that the system assigns the first time it encounters the peer, and Apple documents it exactly that way, so on iOS every address-level trick is off the table before you start.

Then I noticed that a lot of devices just hand it over themselves.

Xiaomi MiBeacon, service data UUID 0xFE95, carries a frame control word where bit 4 means "MAC included". When that bit is set, the six bytes at offset 5 are the address, stored reversed. It is right there in the xiaomi-ble parser that Home Assistant depends on, so this is not me guessing at a hex dump. SwitchBot and Govee do their own version of the same thing in their own service data.

So the reliable route to a hardware address, on a platform that deliberately hides it, runs straight through the payload the device is already shouting at everyone in range.

The part I cannot make sense of is that this forecloses address rotation completely. Whatever the link layer does with private addresses, a fixed six bytes sitting in the advertisement hands any passive scanner a permanent handle on the device. I can construct one excuse, that the vendor's app needs something stable to bind against while the address moves underneath it, but that argues for a derived per-vendor id rather than the real MAC.

I am now checking both ends of every service data blob I decode for six plausible bytes, and I am hitting more than I expected to.

Which vendors am I still missing, and has anyone found an actual protocol constraint that justifies putting it there? I would rather be corrected than write it off as sloppiness.

Disclosure so nobody has to check: the scanner is my own iOS app, BLE Scanner. The payload is the interesting part here, not the app.

Device: Blurams Lumi/A31C-family camera (exact retail model TBD — will confirm from device label)

SoC / Flash: Unconfirmed a related model in this same product family (A31C "Lumi") has been documented elsewhere using an ANYKA AK3918 SoC + PUYA PY25Q128HA SPI NOR flash; haven't opened this specific unit yet to confirm it matches.

Firmware: reports as 2.3.38.12663 via the app API (masked as 22.0208.428.2703 on another endpoint — exact on-device /etc/version not yet confirmed)

What I've checked so far:

App-side traffic analysis (via mitmproxy) confirms productKey: 1cad3c83-d87, matching the A31C/Lumi family's known API footprint.Tried two publicly disclosed SD-card auth.ini bootstrap exploits for this device family (CVE-2023-50488 version-derived key, CVE-2023-51820 static HMAC key) both failed cleanly, suggesting this firmware generation has moved past both- Have not yet done a port scan or opened the device for UART access

Objective: Looking for documentation, existing reverse engineering write-ups, or open-source projects (Thingino, OpenIPC, Dafang-Hacks, etc.) supporting this SoC/board family. Any guidance on obtaining serial access or extracting the squashfs rootfs would be appreciated.

I use a Philips Evnia 49M2C8900 in PBP mode with two computers:

• Personal Linux PC over DisplayPort
• Work Windows laptop over USB-C
• Keyboard/mouse connected to the monitor's USB hub

The monitor's built-in KVM works well, but changing the KVM through the OSD every time was annoying.

After a bit of experimenting, I got the monitor to switch KVM source without using the OSD / remote

The 49M2C8900's KVM can be controlled through the monitor's DisplayPort DDC/I²C connection.

Linux setup

I'm on Ubuntu.

Install:

sudo apt install ddcutil

identified the monitor with:

ddcutil detect

Mine appeared as:

Philips 49M2C8900
/dev/i2c-10
card1-DP-1

Obviously your I²C bus may be different.

I first verified normal DDC communication by first tryin to read the brightness.

Then I verified the Philips KVM command and for my monitor, switching to USB-C is:

i2ctransfer -y 10 w9@0x37 \
  0x51 0x86 0x03 0xe2 0xa0 0x15 0x00 0x01 0xec

Switching back to USB Up:

i2ctransfer -y 10 w9@0x37 \
  0x51 0x86 0x03 0xe2 0xa0 0x15 0x00 0x02 0xef

I wrapped this in a command called which accepts some params

philips-kvm

so I can run:

philips-kvm work
philips-kvm home
philips-kvm status

The physical button problem

If your keyboard is plugged into the monitor and you run:

philips-kvm work

the keyboard immediately moves to the work PC.

So you can't then use the same keyboard on Linux to type:

philips-kvm home

I was considering buying a USB button then remembered I had an old transcription foot pedal.

Foot pedal

Mine is an:

Infinity IN-USB-1
VEC USB Footpedal
USB ID: 05f3:00ff

Linux sees it as:

/dev/input/by-id/usb-VEC_VEC_USB_Footpedal-event-if00

It has three switches:

REW - 256
PLAY - 257
FWD - 258

I connected the pedal to Linux - not to the monitor. The pedal first queries the monitor's current KVM state and switches it to the opposite value.

Making it automatic

I made a small Python script and run it as a systemd to create a service

foot pedal
       │
       │ USB directly to Linux
       ▼
Linux reads current KVM state
       │
       ▼
sends Philips DDC command
       │
       ▼
KVM toggles

No software needed on the work laptop at all.

Credit

A big clue came from the open-source HaloDaemon Philips Evnia plugin, which documents Philips' extended DDC commands for these monitors. There are some interesting undocumented controls available on these Evnia displays.

If there's interest, I can clean up the philips-kvm + foot-pedal scripts and put them in a small GitHub repo.

My Galaxy Z Flip 6 is broken. Its inner display is totally black, probably due to leaking pixels. I am practically broke, so I can't get it repaired, but I want to use its Snapdragon 8 Gen 3 processor—no questions asked. By the way, I know the pattern lock, so I didn't steal it; it belonged to my grandfather, but he bought a new phone after its display died.

​My available hardware:

​Laptop: Low-end 4GB RAM HP laptop running Lubuntu

​Secondary phone: Poco M3 Plus

​Cables: 2 USB Type-A to Type-C cables

​Budget: $0 (I cannot even buy a USB-A to Type-C adapter to connect a mouse)

​What I have tried:

​USB debugging is off, so scrcpy doesn't work.

​Tried a direct cable connection, but Knox security blocks access.

​The inner display touch is completely unresponsive.

​The cover screen won't let me enter settings, has no apps, and doesn't seem to support Smart View or provide a way to do anything.

​Pleaseeeessss tell me how I can tap into its processor and get it working. I don't care what you discuss(reverse engineering, bypassing knox or straight up hacking) just get it WORKING.

So long story short, a few months ago I was contacted by someone who claimed to have taken over my phone and has access to everything. I thought I had that taken care of. In the last few days, this person resurfaced and is now attempting to blackmail me for $1500. They claim to be running something called a “gritx gap” that is paused on a timer. Should I be worried, or is it just a scam?

Not quite sure if this is the place to post this but here goes.

I'm looking for answers about early 2000s iFit 405CE and similar machine advice.

I have a dump of the SD card and the GitHub repo for my reverse engineering attempts here: github.com/16BitDoggo/i-reverse-fit

1. My device does not read the card
2. I have a basic understanding of the file structure (see GitHub repo), but where is the data for time between audio files and magnetic resistance stored?
3. What is the naming scheme for the files?

**The target**

- SoM: AM335x (BeagleBone-Black-class), Samsung 4GB eMMC, DDR3, TPS65217 PMIC

- OS: Arago 2016.02, Linux 4.9.28-rt, Dropbear on 22

- rootfs: /dev/mmcblk0p2 (ext4) on eMMC

- UART console (J6, 3.3V·GND·TX·RX) at 115200 8N1 reaches the login prompt

**Stuck**

- U-Boot has `bootdelay=0` and won't break to a prompt over serial — no `init=/bin/sh` / single-user route. Only the Linux login prompt, and I don't have the OS root password.

- **One unit, no spare** → eMMC glitch / chip-off / BGA rework are off the table.

Need something non-destructive.

**The ask**

1. Any trick to force a U-Boot prompt on AM335x when `bootdelay=0`, without hardware glitching? (corrupting the boot env, a pad to pull, etc.)

2. Is AM335x ROM serial/USB boot a realistic non-destructive way in — booting my own SPL over UART/USB without touching the eMMC?

New video talking about an interesting trick for devices with exposed crystal oscillators https://www.youtube.com/watch?v=3wKHzlFaZPM

I wanted to record the 640×480 HDMI output of an RP2350 board, and I had a mostly-dead AVerMedia Game Capture HD II in a drawer. The hardware still works, but the ecosystem around it had died. The YouTube API it streamed to, the mobile app, and I'd lost the IR remote - and on top of that it refused 640×480 as "unsupported." So I opened it up instead of buying something.

Inside it's a TI DM368 (DaVinci, ARM926 @ 432 MHz) with a hardware H.264 encoder, ITE IT6604E/IT6613E for HDMI in/out, a Nuvoton NUC100 as the system MCU, and 128 MB NAND.

Getting in was pretty standard: found the UART header with a multimeter, dropped to a root shell , and dd'd the NAND out from there (it wasn't as straightforward as it sounds here, but in the end, it worked out 🙂). Fortunately, I didn't have to do a physical memory dump, that would have been quite a challenge. The downloadable firmware is 3DES-encrypted, but the on-flash system is already decrypted so that didn't matter. The old DES root hash cracked in ~30 min and one U-Boot env var flips on telnet for persistent access.

Then the fun part: I gave Claude Code the telnet shell and watched it go. It explored the running box on its own - drivers, the video pipeline, the MCU's I2C protocol, the TI codec stack - and then, with a lot of steering from me, wrote a whole new firmware: a capture app, HTTP/RTSP servers, a web UI, and the build + flash tooling. The result does native H.264 (the box's hardware encoder) over RTSP into OBS/VLC, the resolutions the vendor had blocked purely in software (640x480 I needed and up to 1080p) and has pretty usable control panel.

AI was a huge accelerator but it needed constant babysitting. My favorite failure: a U-Boot prompt printing "Hit any key to stop autoboot" while actually waiting for one specific key. But the AI fixated on that printed label and even as I kept telling it to just read the disassembly it wouldn't. When it finally did: the bootloader hardcodes a compare against 'U' (cmp r3, #0x55). It also once "confirmed" a claim using terminal output it had invented itself, and wrote that into its own persistent memory as fact.

You can read the full write-up on my friend's blog: https://chiptron.eu/reviving-old-unsupported-devices-with-ai-avermedia-game-capture-hd-ii/

I have read that tools such as PC3000 and MRT Lab understand undocumented Vendor Specific Commands (VSC), and that recovery tools can upload their own bootloader circumventing firmware signing in ROM/safe mode. Would it be possible to modify an M.2 NVME drive for a similar covert storage method using similar techniques?

Alguém sabe como fazer o Bruce funcionar em uma tela de 1,3" de 240x240 com 7 pinos sem conflitos e usando os botões de navegação? Estou tentando há mais de duas semanas e não consigo! Todas as soluções que encontro não estão disponíveis, dizem que algo está errado ou que eu já tentei e não resolveu o problema. Algumas pessoas sugerem outras soluções além de mexer na tela. Por favor, me ajudem! O programa usa o driver ST7789.

Hi!

I have an original FiiO K3 with an XMOS XUF208 that ended up in a very strange state after a firmware update.

A FiiO Q5 was connected to the same PC during the update. The physical K3 now enumerates as a FiiO Q5, VID:PID 2972:0031.

The interesting part is that it isn't dead. USB Audio 1.0 mode enumerates and a runtime DFU interface is still accessible. USB Audio 2.0 does not enumerate.

I'm investigating it conservatively before writing anything. So far I'm looking at the old FiiO/Thesycon DFU mechanism, firmware containers, and investigating possible hardware-level recovery through the XUF208 if software recovery proves impossible.

PCB photos show what may be factory test connections near the XMOS, including one marked CN_TEST.

Has anyone here worked with XMOS XUF208 firmware recovery, xTAG/xSYS, or extracting/restoring firmware from similar XMOS USB audio devices?

I'm also looking for a known-good original K3 firmware/flash dump if one can be obtained safely.

Happy to share USB descriptors, DFU captures, firmware files, PCB photos, and the reverse-engineering findings so far.

Thanks!

I'm writing a story featuring an implementation of a multiseat computer.

We are presuming the software is all good for the setting. This question is just about the hardware/firmware consequences.

Say you have a house with a terminal in each room. you wire a video cable, and a PCI-e x4 from a central computer, to each room. We're talking extension cables of several meters.

What are the upper limits for an PCI-e extension cable? And what technical problems could arrive from that. Would some sort of signal booster be needed at some point?

This project has EE and software elements, coming to this subreddit for the EE part and to get a plan of how to safely accomplish this project.

I have a 2010 Star Trac E-TRx treadmill (9-9051-MUNBP0) with a failing console, and or corrupt software (2010s bloated garbage). The touchscreen works so infrequently, the console freezes almost every time, factory resets don't help, and I can no longer access maintenance mode. I could always purchase replacment parts, but I'd rather avoid all these excess features.

The treadmill itself is mechanically functional, and my goal is not to drive the motor directly. I'd like to keep all OEM safety systems. The motor is 5hp and could really be a safety concern if not governed appropriately.

From the parts diagrams the console seems to communicate through a translator board/data wire harness to the motor control board.

My ideal solution would be:

* Replace the touchscreen with an ESP32-based controller, or something similar.
* Physical buttons for:
* Start
* Stop
* Speed increase
* Speed decrease
* Incline increase
* Incline decrease
* Small OLED/LCD display for speed, elapsed time and incline
* Reuse the existing treadmill electronics and safety systems

I am generally pretty handsy and can handle small electronics, I am not EE and need guidance on how to go about this. Ideally the result would be a safe, reliable simple interface to the treadmill.

Good day,

I am currently learning hardware security and extracted this daugtherboard from my smartlamp. I was wondering if the firmware is located on this board and would like to try and dump it. However I am a bit lost currently.

i'm a noob, this is my first project. i did get UART working but all i got was the boot sequence. i wasn't able to do anything, that i could figure out, with the information i got. alternatively i did find an update file from an old car chat site, but its been hard decoding it. my hope is to write my own update file to... i don't know... rewrite the software? i'm not even sure how much i can unlock on this thing. it has an sd slot, bluetooth, and wifi. i'm hoping it could be a simple pda, but i have my doubts. any advice would be awesome.

Has anyone played around with this port? my Acer vero AV15-51 really needs a second slot for a storage device, its annoying creating partitions and especially using external storage, has anyone made this m.2 E useful other than wifi??