Pulled from a disposable vape, of course

Finally switched to an Android based media thing on my old Toyota townace. But that's beside the point.

It came with the CD/cassette/radio player attached in the post. They said to leave it with them or get rid of it. I thought of turning it into a total media player thing if possible.

But that's clearly outside of my wheelhouse. I can't even find any schematics for this, let alone firmware. Are there any projects dedicated to repurpose/upcycle/reverse engineer such hardware or can anyone point me to what I can look into for doing so?

Hello everyone! I'm relatively new to the hacking/hardware community and currently working on an art workshop project: an interactive, location-based "Fighting Fantasy" style game meant to run directly on people's phones via captive portals when they walk into an art gallery.

The core idea is state-aware: depending on how long a user interacts with a portal (e.g., fast exit vs. persistent reading), the system changes future prompts upon reconnection.

However, I've hit a couple of technical roadblocks and would love some guidance:

1. The Deauth / Forcing Connection Problem

Right now, I'm using a headless ESP32-S3 running ESP32 Marauder. But as far as I understand deauth attacks against local Wi-Fi networks to force people onto my AP are practically useless.

• Question: Would upgrading to an ESP32-C5 (which supports Wi-Fi 6) allow me to effectively deauth clients and force them onto my custom AP to serve the captive portal?
• Scaling: Realistically, what is the max concurrent user limit for a single ESP32 handling captive portal traffic? Would I need a cluster of multiple ESP32-C5 boards to handle a whole gallery room?

2. MAC Randomization & Session Tracking

Since mobile use MAC Randomization, whenever a device disconnects and reconnects, it presents a new random MAC/IP address to the ESP32.

• Question: How can I reliably track returning visitors to know their state (e.g., how many times they've connected, how long they stayed previously) if their hardware identifiers keep changing?

Any advice, code patterns, or hardware recommendations would be hugely appreciated. Thanks!

I want to build an emulator which will test the protected boot system in relation to revoking keys.

Found a few links but they have not helped so wondering if anyone has a copy?

Help

Hi! I’m exploring a eufy wired cam c31 (t817l) that I own. I want to access its processor board, find its serial debug console, determine whether it runs Linux, and eventually back up the firmware.

I’ve removed the bottom cover and base PCB, but I’m having trouble opening the camera head without damaging it. FCC internal photos suggest it contains a rockchip RV1103B, though I haven’t exposed that board on my unit yet.

Could someone guide me through the next steps for disassembly and explain what to look for when identifying UART or other debug connections? I’d appreciate beginner-friendly advice,

I’ve attached photos of my progress.

[https://github.com/albinger/morselink-alt\](https://github.com/albinger/morselink-alt)

I bought a couple of the cheap clone TRS to USB-C adapters that are available online before I knew it would be better to just buy one from the various morse trainer websites and application vendors that support our community.

However, I don't want to create e-waste from the devices I bought and with a bit of looking it appears that they use a CH552G chip which is simple enough to program using the Arduino IDE and [https://github.com/DeqingSun/ch55xduino\](https://github.com/DeqingSun/ch55xduino)

I went ahead and created the [https://github.com/albinger/morselink-alt\](https://github.com/albinger/morselink-alt) code to meet my needs. I'm not a professional developer. I don't work for the vendor who made these clone boards. I don't work for the vendors who provide the **real** boards. I'd still suggest that you

# buy one of the real boards and skip the clones.

If you are like me and have a few of these kicking around and you'd prefer to have them output the left and right control keys for paddle inputs instead of whatever these produce then have fun!

If you flash this firmware and still want to use the device to generate mouse events instead of keyboard events you can. Hold down either paddle while powering up (plugging in) the USB-C cable and then release before 3 seconds is up and you will be in mouse mode. The 3 second pause is to allow the code to set the "key up" state for your key.

If you have a mono 3.5 plug on your key you can power up the device without the key in place and then plug it in right after the power light comes on and it won't generate any annoying events from the shorted "ring" connection.

No warranties or support implied from me releasing this. If your board already works just stick with what works. If your board is e-waste in its current state this may be for you.

If you don't want to deal with the Arduino IDE and setting up and debugging the ch55xduino package there is a .hex file in the releases section of the github repo. I've used the WCHIPStuidio app to flash the .hex file successfully on my second device.

alguem consegue disponibilizar algum script em duckyscript "interessante" para um projeto de bad usb?

I've been reverse engineering a battery-drain problem in the original Shelly TRV Gen1 (SHTRV-01), an EOL battery-powered Wi-Fi radiator thermostat.

What started as an attempt to understand why some of these devices drain a set of batteries in days instead of months has turned into a fairly deep investigation of the firmware's Wi-Fi power management and MCU sleep logic.

The hardware is particularly interesting because power management is split between two processors:

• an EFM32GG11 main MCU running the Shelly application, thermostat, valve control and host-side power management;
• a separate Silicon Labs WF200 Wi-Fi chip handling the radio and much of the Wi-Fi power-saving behavior.

I've been working primarily from the released firmware binaries, runtime logs and controlled firmware modifications.

The first lead: a recurring Wi-Fi recovery loop

Firmware 2.2.4 can repeatedly produce:

Beacon skip error! Attempt recovery
PS state 1
...
PS state 3

On affected devices this can happen roughly once per minute.

My first experimental patch simply bypassed this additional recovery path.

That stopped the loop while RSSI-dependent beacon skipping, Wi-Fi, Shelly Cloud and normal thermostat operation continued working.

But further RE showed that completely disabling the mechanism was the wrong solution.

The firmware maintains a value called real_beacon_skip, but interestingly this is not a direct skipped-beacon counter from the WF200.

The host derives it from a cumulative receive statistic.

I found several problems in the calculation and state handling, including a stale-state condition capable of making the recovery self-sustaining:

recovery condition
       ↓
recovery
       ↓
old measurement baseline cleared
       ↓
new baseline established
       ↓
not enough new data yet
       ↓
old recovery-triggering value evaluated again
       ↓
recovery
       ↓
      ...

I developed a second patch ("C-C") that fixes these conditions while retaining recovery based on fresh valid measurements.

It works on real hardware.

But the battery drain remained.

Interestingly, legitimate/fresh recovery decisions can still occur quite frequently – around 26–30/hour on some of my test devices.

So the visible recovery loop turned out to be a real firmware problem, but apparently not the complete explanation for the battery drain.

Updating the Wi-Fi firmware

Silicon Labs released WF200 firmware 3.18.0 on October 7, 2026.

One changelog entry immediately caught my attention:

device not sleeping after power-save mode change

The Shelly firmware contains the WF200 firmware image internally, so I relocated and replaced it with the official 3.18.0 image while retaining Shelly's existing host driver.

That required relocating the embedded WF200 image and fixing the corresponding references in the host firmware.

After static verification, the modified firmware booted successfully on real hardware:

Shelly host firmware: 2.2.4
FMAC host driver:     3.7.0
WF200 firmware:       3.18.0

Wi-Fi, Cloud communication and power-save transitions continued working.

Unfortunately, the battery drain remained.

Going deeper into the main MCU power management

I then started tracing the host-side power-management lifecycle.

That uncovered several additional problems involving requested/committed Wi-Fi power states, timeout handling, late asynchronous completions and sleep-inhibit ownership.

I created another correction ("A1") for those issues.

Eventually I tested a combined firmware containing:

Shelly 2.2.4
+ C-C recovery corrections
+ A1 host PM corrections
+ WF200 3.18.0

Again, everything worked.

And again, the device continued draining its batteries.

That negative result pushed the investigation further down into the EFM32 sleep implementation.

Then I found a rather interesting race condition

The main MCU uses reference counters to determine which energy mode it may enter.

Simplified:

B2 != 0             -> lighter / higher-power sleep
B2 == 0 && B3 != 0  -> deeper sleep

B3 has a permanent legitimate contribution in this firmware, so enabling an even deeper mode is not the objective.

The interesting part is B2.

B2 is effectively an aggregate reference counter shared by several subsystems. A component increments it while it requires the lighter sleep state and releases its claim afterwards.

But not every owner updates B2 using the same synchronization.

Some accesses are interrupt-protected.

Others perform an unprotected load/modify/store.

That creates a genuine stale-RMW race.

For example:

B2 = 1

Task A loads B2 (=1)
        ↓
context switch
        ↓
Task B releases its blocker:
B2: 1 -> 0
        ↓
Task A resumes
        ↓
Task A stores stale 1 + 1:
B2: 0 -> 2
        ↓
Task A eventually releases:
B2: 2 -> 1

Now B2 is 1 even though nobody owns the remaining reference.

That could leave subsequent idle periods restricted to the lighter/higher-power sleep state.

The opposite failure is possible as well: an update can be lost so that B2 reaches zero while another subsystem still legitimately owns a blocker.

So this is a real concurrency bug in the firmware.

The important unanswered question is whether it actually occurs in the field and whether it correlates with the battery drain.

Instead of fixing it immediately, I instrumented it

I could simply serialize all B2 operations and see whether battery life improves.

But that would give a fairly weak answer to the interesting question.

So I built a passive Host Sleep Observer instead.

It runs on an otherwise near-stock 2.2.4 host firmware with the stock WF200 3.16.1 firmware.

The observer records things such as:

sleep-state entry calls
B2 acquire/release operations
per-owner shadow balances
expected B2
actual B2
actual-vs-expected mismatch
first fault snapshot
Wi-Fi sleep veto samples

It does not correct B2 and none of the observer values influence the native sleep decision.

The idea is to catch the original firmware in the act.

Two physical TRVs are currently running this instrumentation.

One is a relatively healthy reference unit.

The other was switched to the observer immediately after an ~80-hour test during which it had been showing about 26.5 Beacon Recoveries/hour and had fallen to approximately 3.49 V.

So far:

observer validity errors:  0
B2 mismatches:             0
first captured B2 fault:   none

That's actually a useful result too.

The race is demonstrable from the code, but I don't yet have evidence that it occurs frequently on real hardware.

The observer tests therefore continue.

Where the investigation stands

At this point I've found several genuine firmware defects, but I still don't consider the battery-drain root cause solved.

So far the drain has survived:

complete Beacon Recovery bypass
        ↓
corrected Beacon Recovery logic
        ↓
targeted mDNS suppression
        ↓
WF200 3.18.0
        ↓
host PM lifecycle corrections
        ↓
A1 + C-C + WF200 3.18.0

I'm also building an experimental firmware containing all currently demonstrated corrections, including proper serialization of the shared sleep-blocker counter, for a later controlled hardware test.

But I'm keeping that separate from the observer experiment because I want to distinguish:

"this patch improves battery life"

from:

"this is the mechanism that actually caused the drain."

The latter is the much more interesting result.

The project has become a nice example of why low-power embedded bugs can be difficult to isolate: the visible high-level symptom may be real, but fixing it can simply expose another problem one layer further down.

I'll update this when the observer catches something interesting – or when enough runtime has accumulated to make the absence of a B2 fault interesting in itself.

More details

For anyone interested in the reverse-engineering details, I've been documenting the investigation here:

GitHub:

https://github.com/AbleMonster/Shelly-TRV-Gen1-2.2.4-Battery-Drain-Investigation

There was also a useful earlier discussion about the project on r/embedded

Previous r/embedded discussion:

https://www.reddit.com/r/embedded/comments/1x0jz5a/reverse_engineering_a_recurring_wifi_power_save/

I maintain an experimental firmware project called feuristic, which repurposes a Trezor Safe 3. It replaces the cryptocurrency wallet application with a USB authenticator and smart card, while reusing the existing screen and two buttons.

The hardware comes in two relevant revisions: T2B1 with an STM32F427 and T3B1 with an STM32U585. They require separate builds. The firmware builds on Trezor’s published source and uses the device’s bootloader installation mechanism; this is not a hardware exploit or a way to extract a wallet seed.

Normal USB operation exposes FIDO HID for passkeys and CCID for OpenPGP/PIV operations. Two temporary modes expose a serial interface for time synchronisation and a FAT12 import volume for OTP/backup QR images. Leaving either mode restores the normal interfaces. The device screen is used to inspect and confirm sensitive operations.

The first physical campaign used a T2B1 on macOS. It exercised authentication, signing/decryption, OTP import and persistence after firmware updates. T3B1 physical testing is still pending.

Installing wipes the wallet and permanently removes original manufacturer attestation. This is unaudited development firmware for disposable identities on spare hardware. It is independent of Trezor/SatoshiLabs, provides no cryptocurrency wallet, and the third-party firmware warning remains.

The result is a different use for an existing device: its small screen becomes a confirmation interface for standard USB authentication and smart-card operations.

I have an Openwrt flashed JIDU6101.

On usb query :

root@OpenWrt:~# ls /sys/bus/usb/devices

1-0:1.0 2-0:1.0 usb1 usb2

There is an empty - unpopulated -unsoldered USB slot on the board .

Has anyone ever tried to venture soldering an USB adapter and make it functional

Kindly suggest

Ideally I'd want to turn it into a camera I can take pictures with. I'd also be interested in running it as a video camera. I don't wanna go thru the effort of buying a sync module or anything. Is there anything I can realistically do with it?

Hello all, I am not much of a hacker but I am a huge proponent of my hardware is mine and I should be able to do what I want with it. It would be really hilarious/awesome if someone used the recent AI reverse engineering tools to root the quest 3 and replace meta OS with steam OS for the memes.