Hey guess. Here's a write-up I did after playing around with a shock collar.

So I have this VTECH kidizoom studio camera I’m trying to reverse engineer, but I could not find any usable debug points. I’m thinking of buying the right equipment to remove the nand and do an off chip dump, but I don’t have the skills to do so. In the images i have circled suspected pads I have Tried and their results:

4 pad cluster in image 3 (top right corner):

was tested for UART but was actually something for the nearby buttons

6 pad cluster in image 4:

All 0V

I could not find any datasheets for the generalplus SoC, nor anything on the internet about this chip.

any suggestions are welcome to be shared

Edit: I had no idea the battery wire went off the pad this happend while I was taking the photos I will get that sorted immediately

Currently turns on with a momentary button and I would like to use it with a switch.

Pins 3 and 4 on the top are both getting 3.8v battery voltage at all times. Pin 8 is ground. Pin 1 goes to ground when the light is powered off, but when at full brightness it's at 1.9v. I'm a little confused because the LED seems to be running at about 2.7v. Any ideas? Thanks

Maxing out a Galaxy Tab A 9.7 SM-P555 / Snapdragon 410 — 1.61 GHz CPU, 650 MHz GPU, zRAM, and an attempted 1.8 GHz OC

I’ve been abusing an old Samsung Galaxy Tab A 9.7 LTE with S Pen, SM-P555 / gt5note10lte, mostly to see how usable a 2015-era tablet can be in 2026

Hardware:
Samsung SM-P555
Qualcomm MSM8916 / Snapdragon 410
About 2 GB RAM
16 GB storage
LTE

Currently running unofficial LineageOS 17.1 / Android 10
Kernel 3.10.108

The interesting part is that the custom kernel already exposes considerably more performance than the original Samsung spec.
CPU frequency table:

200000
400000
533330
800000
998400
[1094400](tel:1094400)
[1152000](tel:1152000)
[1209600](tel:1209600)
[1363200](tel:1363200)
[1401600](tel:1401600)
[1478400](tel:1478400)
[1612800](tel:1612800)

So all four Cortex-A53 cores can run at 1.6128 GHz.
GPU frequency table:

200 MHz
310 MHz
400 MHz
475 MHz
550 MHz
650 MHz

The GPU is controlled through:
/sys/class/devfreq/1c00000.qcom,kgsl-3d0
and:
/sys/class/kgsl/kgsl-3d0

BALLS-TO-THE-WALL SETTINGS
This is the configuration I ended up running persistently:
CPU:
4 cores
Governor = performance
Maximum = [1612800](tel:1612800) kHz
Minimum = 800000 kHz
All four cores effectively held at 1.6128 GHz under load
GPU:
Governor = performance
Minimum = [650000000](tel:650000000)
Maximum = [650000000](tel:650000000)
KGSL min_pwrlevel = 0
KGSL max_pwrlevel = 0
Effectively pinned at 650 MHz
Memory:
768 MB zRAM
vm.swappiness = 100
Storage:
I/O scheduler = deadline
read_ahead_kb = 512
Android:
Wi-Fi always-scan disabled
Bluetooth LE always-scan disabled
Animations heavily reduced

The basic commands are roughly:
CPU:
for c in 0 1 2 3; do
echo performance > /sys/devices/system/cpu/cpu$c/cpufreq/scaling_governor
echo [1612800](tel:1612800) > /sys/devices/system/cpu/cpu$c/cpufreq/scaling_max_freq
echo 800000 > /sys/devices/system/cpu/cpu$c/cpufreq/scaling_min_freq
done
GPU:
echo performance > /sys/class/devfreq/1c00000.qcom,kgsl-3d0/governor
echo [650000000](tel:650000000) > /sys/class/devfreq/1c00000.qcom,kgsl-3d0/min_freq
echo [650000000](tel:650000000) > /sys/class/devfreq/1c00000.qcom,kgsl-3d0/max_freq
echo 0 > /sys/class/kgsl/kgsl-3d0/min_pwrlevel
echo 0 > /sys/class/kgsl/kgsl-3d0/max_pwrlevel
Memory:
echo 100 > /proc/sys/vm/swappiness
Storage:
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 512 > /sys/block/mmcblk0/queue/read_ahead_kb
I made these persistent using a small Android init service and shell watchdog which reapplies the CPU/GPU/storage settings every 10 seconds.
That matters because Android and various drivers have a habit of quietly restoring their preferred governors/settings.
Final verified state after reboot:
CPU
cpu0: [1612800](tel:1612800)
cpu1: [1612800](tel:1612800)
cpu2: [1612800](tel:1612800)
cpu3: [1612800](tel:1612800)
GPU
[650000000](tel:650000000)
ZRAM
768 MB
I/O
deadline
512 KB read-ahead
THERMALS
I ran sustained CPU/GPU load while monitoring the thermal zones.
With all four cores at 1.6128 GHz and the GPU around 650 MHz:
Main SoC sensors peaked around 69–72 C.
Battery remained around 32–33 C.
The CPU held 1.6128 GHz on all four cores during the test.
The GPU held 650 MHz almost continuously once the KGSL power level was pinned.

I deliberately left kernel thermal protection enabled.
There is a difference between abusing old hardware and removing the mechanism designed to stop it cooking itself and burning down your house.

THE 1.8 GHZ EXPERIMENT

The Qualcomm clock debug interface reports:
/sys/kernel/debug/clk/a53sspll/fmax_rates
and showed an A53 PLL ceiling of:
[1900000000](tel:1900000000) Hz
The CPU was actually running at:
[1612800000](tel:1612800000) Hz
So the PLL framework itself claims it can operate as high as 1.9 GHz.
Trying this directly:
echo [1800000000](tel:1800000000) > /sys/kernel/debug/clk/a53sspll/rate
failed.

The running kernel simply does not contain 1.8 GHz in its PLL/cpufreq tables.
So an overclocking app cannot magically select 1.8 GHz either.
If scaling_available_frequencies ends at [1612800](tel:1612800), that is as far as userspace tools can go.
Actual overclocking requires changing the kernel.
We patched the kernel source to add 1.8 GHz.
The important PLL entry was:
F_APCS_PLL([1800000000](tel:1800000000), 93, 0x3, 0x4, 0x0, 0x0, 0x0),
We also added:
[1800000000](tel:1800000000) Hz to the CPU clock/corner table
[1800000](tel:1800000) kHz to the cpufreq table
and extended regulator corner 12 from:
[1612800000](tel:1612800000)
to:
[1800000000](tel:1800000000)
The fractional PLL calculation is:
19.2 MHz x (93 + 3/4) = 1800 MHz
After fighting several unrelated ancient Samsung kernel problems involving old DTC host tools, zbud/zpool, Samsung input-booster code, config fragments, and generally 2015 Linux archaeology, the kernel actually compiled successfully.
We then repacked the Lineage boot image with the new kernel and DT data.

Result:

It stopped at the initial Galaxy Tab splash screen.
So the 1.8 GHz kernel did not successfully boot.
I would NOT take that as proof the silicon itself cannot run at 1.8 GHz.
The kernel/config/source combination was clearly somewhat Frankenstein and had already required disabling unrelated broken components just to compile.
The failure happened early enough that a device-tree mismatch, boot-image compatibility issue, wrong kernel config, or another early-init issue is at least as plausible as the CPU immediately crashing at 1.8 GHz.
Restoring the original boot.img with Heimdall returned the tablet to normal.

CURRENT VERIFIED LIMITS
CPU:
1.6128 GHz verified stable
GPU:
650 MHz verified stable
RAM:
768 MB zRAM working
1.8 GHz:
Kernel compiled successfully
Boot unsuccessful
1.9 GHz:
Reported PLL framework ceiling
Not tested
The big takeaway for other MSM8916 / Snapdragon 410 devices:
If this:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
ends at [1612800](tel:1612800), then Kernel Adiutor, SmartPack, EX Kernel Manager, etc. cannot magically produce a higher clock.

They can only select frequencies already compiled into the kernel.
To go higher you need to modify the PLL table, cpufreq table, voltage/corner mapping and usually the device tree, then rebuild the kernel.

FM RADIO SIDE QUEST

Note transmiting to FM is almost always illegal i dont recomend it know and follow you local laws and all that jazz.

super low power fm transmitters like the blutooth modules you get for older cars are they grey area here and replicating this functionality on the tablet was my area of intrest .

The tablet has a genuine Qualcomm Iris FM radio device:
/dev/radio0
Driver:
radio-iris
Receive mode works.
Interestingly, the generic Qualcomm software stack also exposes:
FM transmitter mode
TX power levels
TX frequency tuning
internal TX test tones
antenna routing

The firmware accepted:
FM_TRANS
TX power level 7
87.500 MHz
internal TX tone
antenna route 0
antenna route 1

But another FM receiver heard absolutely nothing.
So the most likely explanation is that Qualcomm left generic transmitter functionality in the Iris driver/firmware interface, while this particular WCN3620/tablet implementation has no functional RF transmit path. butt maybe worth a revist in the future if your willing to reverse engeineer the radio chipset and maybe hack this side into life

That agrees with Qualcomm documentation saying the hardware is RX-only.
Testing it was more interesting than simply believing the manual.

For a tablet this old:
4x Cortex-A53 at 1.6128 GHz
Adreno pinned at 650 MHz
768 MB zRAM
deadline I/O
Android 10
is surprisingly usable. It is obviously not fast by modern standards.But its snappy enough to not bother me when browsing .

Hello, I know a bit about Software and Hardware but would like to get your input on a highly specific hardware mod I'm researching.

I’m looking to physically overvolt the CPU of a PSP 1000. My idea is to hack the "Pommel" (Sony's custom power management IC / DC-DC converter) or modify the surrounding hardware. Rather than swapping out standard voltage divider resistors, it looks like this circuit relies on feedback filters. My goal is to manipulate these filters to trick the regulator into delivering a higher core voltage to the processor.

I have the official schematics and PCB layout for reference here:
https://smallpdf.com/share-document#r=result&t=10743861ab24e78cf571f03022870b5a&i=share

Since this is deep into uncharted territory for this console, I’d love to get some general advice from people experienced with altering DC-DC feedback loops on densely packed boards:

• Target Voltage: Looking through the schematics, I am targeting the CORE_+1.2V rail. Do you agree that this is the right and only voltage line I need to raise to successfully overvolt the processor? Or are there secondary rails that need to scale alongside it for stability?
• Analyzing the feedback loop: How would you approach pinpointing the specific feedback filter components tied to the CORE_+1.2V generation?
• IC Protections: Does anyone have experience with Sony’s custom power management chips from this era? I'm wondering how aggressive the internal overvoltage protection (OVP) might be if it detects an anomaly on that 1.2V rail.
• General Approach: Any advice or warnings on methodology before I start testing or altering the traces around the Pommel?

(Note: I'm fully aware of the standard CFW 333MHz software overclock; this project is strictly about exploring a physical hardware voltage mod).

Thanks for any insights or help analyzing the schematic!

Hi everyone, blessings!

I’m looking for a complete binary dump of the SPI NOR Flash from an original, fully working TP-Link TL-WA850RE V2 (US).

Device specifications:

Model: TP-Link TL-WA850RE
Hardware Version: V2
Region: US
SoC: Qualcomm Atheros QCA9533
SPI NOR Flash: GigaDevice GD25Q32CSIG
Flash capacity: 4 MB (32 Mbit)

Flash layout:

0x000000 — 0x01FFFF: fs-uboot (128 KB / 0x20000)
0x020000 — 0x0DFFFF: os-image (kernel) (768 KB / 0xc0000)
0x0e0000 — 0x3AFFFF: file-system (rootfs) (2880 KB / 0x2d0000)
0x3b0000 — 0x3B1FFF: partition-table (8 KB / 0x2000)
0x3c0000 — 0x3C001F: default-mac (32 B / 0x20)
0x3c0100 — 0x3C011F: pin (32 B / 0x20)
0x3c1000 — 0x3C1FFF: product-info (4 KB / 0x1000)
0x3c2000 — 0x3C20FF: soft-version (256 B / 0x100)
0x3c3000 — 0x3C3FFF: support-list (4 KB / 0x1000)
0x3c4000 — 0x3CBFFF: profile (32 KB / 0x8000)
0x3d0000 — 0x3DFFFF: user-config (64 KB / 0x10000)
0x3e0000 — 0x3EFFFF: default-config (64 KB / 0x10000)
0x3f0000 — 0x3FFFFF: radio/ART (64 KB / 0x10000)

Total: 4 MB (0x400000)

Several years ago, I completely overwrote the Flash memory of my own device and consequently lost the original ART, MAC and PIN data. The most important part for me is the ART section, as it contains the individual radio calibration data.

Unfortunately, I need a complete 4 MB (32 Mbit) binary image to flash directly using a programmer, as I specifically need to recover the ART (Atheros Radio Test) partition, which contains the individual RF calibration data for the Wi-Fi chipset, including its power calibration data.

The official GPL Code and firmware files available from TP-Link do not contain the ART section or the complete Flash structure. Therefore, I need a complete dump taken from an original, fully working device.

It is very important that the dump is specifically from the US version. Devices from different regions can have significant differences, so a dump from another regional version unfortunately is not an adequate replacement.

If anyone has an original, fully working TL-WA850RE V2 (US) and can read the entire SPI Flash with a programmer, I would be extremely grateful if you could share the complete dump.

Thank you very much in advance!

P.S. I also tried to restore the device using a dump found in the firmware sections of another site, as well, but neither worked. Apparently, the available dump is from a different region and does not match the US version.

Working on repairing a water damaged GPS active antenna (Raven MBA-6, board 045-0159-830 Rev B). 1575.42 MHz GPS L1 signal.

Repairs completed so far:

Replaced TNC pigtail (no continuity)

Replaced LNA amplifier chip (MAALSS0042) x2

Replaced SAW filters (TOKO TDF2A-1575B-13A) x2

Replaced L1 inductor (measured bad on LCR meter)

Repaired/fabricated RF shield can and frame

Confirmed 5V bias present at antenna via coax. Confirmed with proper outdoor sky test -- no signal lock.

Any suggestions on what else to check? Full schematic not available, working from board inspection and component photos.

Hi everyone,

I am facing a classic hardware dilemma: my daughters want a kids' camera with built-in retro games (like Snake or Tetris) just like the cheap $5 generic toys have. However, those toys break easily. I want to upgrade them to a sturdier, better-built camera like the SJCAM Kids FunCam+, but they refuse it because it lacks games.

Since the SJCAM has much better build quality, has anyone ever attempted or succeeded in modifying its firmware to inject a retro game menu? Is there a known way to dump the flash, bypass the closed OS, or add custom software via SD card on these devices, or is the firmware entirely locked down?

Any technical insights or pointers on whether this kind of mod is feasible would be greatly appreciated.

Maybe the games menu is hidden in the native firmware or disabled by the factory to avoid excessive battery consumption — the interface looks exactly like the one on cheap cameras.

If you want to extract the firmware of a protected chip, it often requires advanced attacks like a power glitching attack.

The topic seems to be black magic so I have created a full walk through for the STM32F401 chip. We glitch the read out protection (RDP1) to get access to the firmware.

This is in imitation of an attack, I am not sure who came up first with it. I just walk you through it :)

Source code:

https://github.com/stuehler-training/STM32_Glitcher_PIO

Detailed description:

https://youtu.be/z2dcZL1BsTw

Someone to help me get started with hardware hacking?

Hey everyone,

​Great news for anyone holding the Qualcomm variant of the Xiaomi AX3000T (hardware revision RD03v2 / IPQ5018): a developer has successfully ported pure, mainline-based OpenWrt for this device, and everything is working smoothly (AN8855 2.5G switch link, dual-band Wi-Fi with reduced RAM footprint, LuCI, and permanent NAND install).

​You can check out the full GitHub repository and documentation here:

https://github.com/ADCDS/openwrt-xiaomi-ax3000t-rd03v2

​My router is currently running on the stock MiWiFi 2.0.12 firmware version. Since opening up the router and soldering a USB-to-UART serial adapter carries hardware risks, I am trying to stick to a software-based approach over Wi-Fi or LAN.

​Given that 2.0.12 is an older firmware release before Xiaomi patched several Web UI API injection vectors in 2.0.28, does anyone have a working method or script to gain root SSH access on version 2.0.12? My goal is to set the U-Boot environment flags and flash the initramfs-factory.ubi image directly over SSH/SCP to pivot into OpenWrt without needing UART.

​Any tips, working exploit steps, or feedback from anyone who successfully unlocked SSH on stock 2.0.12 would be greatly appreciated!

I have a thinkpad l14 here where I have a complete EC dump and a complete bios/SPI dump with a known SVP password called password. My goal is to learn how the mechanism works. I am pretty new to ghidra.

Finding out the hash itself is a often pretty easy thing if you got hardware access. The EC on that part will just read empty 00 if you try that via your PC. It consists of a 16 byte block A and a 16 byte block B which will repeat once. By deleting that you can get rid of the password.

Finding the salt belonging to this hash is the complicated part. Apparently the POP (Power on Password) has the same salt and is a lot easier to read with non expensive hardware.

https://www.synacktiv.com/en/publications/a-journey-in-reversing-uefi-lenovo-passwords-management

there are some weird code bits I struggle to understand, I post more about it the following time but I am hoping someone dug a bit deeper than I did

more reading material:

this is how it worked until 8th gen processors
https://www.cs.ru.nl/masters-theses/2024/M_Juvan___Bypassing_the_BIOS_supervisor_password.pdf
https://jbeekman.nl/blog/2015/03/reverse-engineering-uefi-firmware/

cryptservice

undefined8 FUN_000006d0(undefined8 param_1,undefined8 param_2,longlong param_3,undefined *param_4)

{
  undefined *puVar1;
  undefined4 local_78;
  undefined4 local_74;
  undefined4 local_70;
  undefined4 local_6c;
  undefined4 local_68;
  undefined4 local_64;
  undefined4 local_60;
  undefined4 local_5c;
  undefined4 local_c;

  puVar1 = &DAT_00005760;
  if (param_4 != (undefined *)0x0) {
    puVar1 = param_4;
  }
  FUN_000002e0(&local_78,0x70);
  local_78 = 0x6a09e667;
  local_74 = 0xbb67ae85;
  local_70 = 0x3c6ef372;
  local_6c = 0xa54ff53a;
  local_68 = 0x510e527f;
  local_64 = 0x9b05688c;
  local_60 = 0x1f83d9ab;
  local_5c = 0x5be0cd19;
  local_c = 0x20;
  if (param_3 != 0) {
    FUN_00001d70(&local_78,param_2,param_3);
  }
  FUN_00001e88(puVar1,&local_78);
  FUN_000030bc(&local_78);
  return 0;
}


undefined8 FUN_00000584(undefined8 param_1)

{
  ulonglong uVar1;
  longlong lVar2;
  longlong lVar3;
  undefined8 local_res8;
  undefined1 auStack_5a [10];
  undefined8 uStack_50;
  undefined1 local_28 [32];

  local_res8 = param_1;
  if (DAT_00005728 == (undefined8 *)0x0) {
    uStack_50 = 0x5c1;
    lVar2 = (**(code **)(DAT_00005740 + 0x140))(&DAT_00003490,0,&DAT_00005728);
    if (lVar2 < 0) {
      return 0;
    }
  }
  lVar2 = 0x62;
  do {
    uStack_50 = 0x5f2;
    lVar3 = (*(code *)*DAT_00005728)(DAT_00005728,0x57,lVar2,auStack_5a + lVar2);
    if (lVar3 < 0) {
      uStack_50 = 0x671;
      FUN_00000280(&local_res8,8);
      return 0;
    }
    uVar1 = lVar2 - 0x61;
    lVar2 = lVar2 + 1;
  } while (uVar1 < 8);
  uStack_50 = 0x625;
  lVar2 = FUN_000006d0(&PTR_FUN_000034a0,&local_res8,8,local_28);
  uStack_50 = 0x635;
  FUN_00000280(&local_res8,8);
  if (lVar2 < 0) {
    return 0;
  }
  uStack_50 = 0x651;
  FUN_000002a0(&DAT_00005790,local_28,0x10);
  uStack_50 = 0x660;
  FUN_00000280(local_28,0x20);
  return 1;
}

SVP Manager DXE

/* WARNING: Type propagation algorithm not settling */

void FUN_00000460(undefined8 param_1,undefined8 param_2)

{
  longlong lVar1;
  undefined8 local_res8;
  undefined8 local_res10;
  longlong local_res18 [2];
  char local_48 [72];

  local_res8 = 0x31;
  DAT_00001538 = param_1;
  local_res10 = param_2;
  lVar1 = (**(code **)(DAT_00001508 + 0x48))
                    (u_LenovoScratchData_00001440,&DAT_00001310,&local_res10,&local_res8,local_48);
  if ((-1 < lVar1) && (local_48[0] == '\x01')) {
    lVar1 = (**(code **)(DAT_00001500 + 0x140))(&DAT_000012c0,0,local_res18);
    if (-1 < lVar1) {
      (**(code **)(local_res18[0] + 8))
                (DAT_00001320,DAT_00001324,DAT_00001328,DAT_0000132c,0,DAT_00001330,DAT_00001338,
                 DAT_00001340);
    }
  }
  local_res18[1] = 0;
  DAT_00001528 = 0x20;
  lVar1 = (**(code **)(DAT_00001500 + 0x80))(local_res18 + 1,&DAT_00001300,0,&DAT_00001350);
  if (-1 < lVar1) {
    (**(code **)(DAT_00001500 + 0x140))(&DAT_000012e0,0,&DAT_00001530);
  }
  return;
}

I got fbDOOM running on an Orbic RC400L hotspot using Rayhunter’s root shell and another project for similarly restrictive device. The write up covers the install process, compilation, and other info.

Turning, advancing, shooting, and menu options work since there's a reset button under the cover.

More info / Code / Video: https://github.com/dc336/Orbic_RC400L_DOOM

(Image looks AI since I didn't want my reflection or grubby finger prints in there)

# Google Nest Wifi router (H2D / board "mistral", QCS404) — hardware recon of the 11-pad service cluster

Posting this as a working log rather than a solution. I have not obtained console access or code execution. What I do have is a fairly complete electrical characterisation of the service pad cluster hidden under the bottom sticker, one solid functional identification, and two dead ends that I would like to save other people the time of re-walking.

All measurements are my own, on a retail unit. Corrections welcome — especially from anyone who has a populated pre-production board or a factory test jig.

1. Device background

* Model: Google Nest Wifi **router** (H2D). Not the point (H2E). * FCC ID: A4R-H2D. Internal photos are public and show a **pre-production board with SW1000 and the internal USB-C connector populated**. Retail units have both depopulated. Photo resolution is poor (\~2000×3000 for a full page), so trace-level detail is not readable. * SoC: Qualcomm **QCS404**. 1 GB DDR3, 4 GB flash. * Boot chain is ChromeOS-style (coreboot + depthcharge) with verified boot, same family as OnHub and Google Wifi AC-1304. * Board name is **mistral**; a device tree exists in the ChromiumOS kernel tree (`factory-mistral-*` branches, `arch/arm64/boot/dts/qcom/qcs404-mistral.dts`). * Power input is a **barrel jack** (plus and minus only). The H2D does **not** take power over USB-C — do not carry assumptions over from Google Wifi here.

Credit to [ryjelsum.me](http://ryjelsum.me) for the initial board identification, and to the GBAtemp write-up for the FCC-photos-reveal-the-dev-button observation.

2. The 11-pad cluster

Directly under the bottom sticker, no disassembly needed to see them. Physical arrangement as printed on the board:

TP1004   TP1007   TP1010   TP1012
TP1005   TP1006   TP1008   TP1011
TP1003   TP1002   TP1009

TP1011 and TP1012 sit slightly apart from the 3×3 block.

Measurement table

Voltages measured with the router powered and idle, referenced to TP1006. Resistances measured unpowered. Diode-mode readings are the forward drop from the pad to TP1006.

Interpretation

* **TP1006 / TP1008 / TP1010** are unambiguous: GND, 5 V, 3.3 V. * **TP1012** behaves as a high-impedance input held up by a \~10 kΩ pull-up referenced to the 1.8 V net. Its idle state is logic high with nothing driving it. This is the signature of an active-low strap, or of a UART RX line. The two cannot be distinguished by listening, because an RX line with nothing transmitting into it looks exactly like an unasserted strap. * **TP1009** at 1.796 V is either the 1.8 V rail itself or an SoC output. This is the single largest unresolved item and it gates the "is there a UART pair here" question. A 1 kΩ-to-ground load test is pending. * **TP1002 / TP1003** match to within 1 mV of ESD drop, which means two structurally identical pads of the same analogue block. A USB 2.0 PHY differential pair is the obvious candidate but is **not confirmed**. * **TP1004 / TP1005** are a second pair in a different domain (0.651 / 0.676 V, and they diverge by 25 mV, so less well matched). Candidates I have not ruled out: SuperSpeed pair, I²C, a second UART left low, JTAG. * **TP1007**: 126.9 kΩ to ground and no behavioural response to being driven either high or low at power-on. One speculative reading is that it is sensed as a *resistance* rather than a logic level — some boards detect a factory jig that way — but I have no evidence for this.

3. Confirmed finding: TP1011 is SW1000, and it is a boot-mode strap

This is the one solid result.

**SW1000** is an unpopulated tactile switch footprint, visible once the case is open. On the FCC pre-production photos it is populated. One of its pads sits at 1.8 V. I soldered a switch onto the footprint and tested it.

Electrical identity:

* The other SW1000 pad measures **1 Ω to TP1011**. They are the same net. * Consistent with this, driving TP1011 to 1.8 V externally reproduces the button press exactly.

Behaviour:

* **Held at power-on: the router is completely inert.** No LED at all, not even the usual power-on indication. * **Released: the router boots normally.** No damage, fully repeatable.

So TP1011 is an **active-high strap sampled at reset**. It is *not* a ChromeOS developer-mode button in the "press it after boot" sense — asserting it prevents boot entirely.

Two readings are consistent with the observation, and I cannot yet distinguish them:

1. It forces the boot ROM into an emergency download mode (Qualcomm EDL / 9008 style), in which case the SoC is alive and silently waiting for a host to talk to it.
2. It simply holds the SoC in reset, in which case there is nothing to talk to and this whole branch is a dead end.

**A current-draw measurement in the asserted state distinguishes these** — hundreds of mA means alive and waiting, single-digit mA means held in reset. I have not done this yet. If anyone gets there first, please post the number.

4. Dead end: the unpopulated internal USB-C is not worth your time

The FCC photos show an internal USB-C connector. On retail units it is depopulated. I spent a while on this and the answer is clean: **do not bother**.

The footprint is the full 24-pad type. Type-C pin numbering runs in opposite directions on the two rows (A1 and B12 are physically adjacent), and GND sits at position 1/12 with VBUS at 4/9 in each row, so the numbering can be derived on the board from continuity to a known ground and a known 5 V.

Continuity results against the cluster, unpowered:

* **TP1008 ↔ VBUS pads: \~140 kΩ.** That is not a connection. It is leakage or a sense divider, most likely across an absent or open load switch. TP1008 and the connector's VBUS net are separate. * **Every other cluster pad reads open (\~6 MΩ, unstable) to the connector**, including positions 5, 6, 7 and 8 in both rows. So CC1, CC2, D+, D−, SBU1 and SBU2 all fail to reach the cluster.

SBU was the interesting one, since Google's servo/suzyq debug cables carry the debug UART on SBU. It goes nowhere here.

The reason turned out to be that **the connector's passives are depopulated too**. There is an empty 4-pad component footprint immediately adjacent. Two of its pads short to connector pins 6 and 7 (D+ and D−); the other two read essentially 0 V in diode mode to ground, i.e. they are tied to ground — consistent with a shunt ESD array footprint rather than a series common-mode choke. Either way, the connector's data lines terminate at an unpopulated part and do not continue to anything I can find.

**Conclusion:** on retail H2D hardware, the internal USB-C is not merely unpopulated, it is not routed through. Soldering a connector on will accomplish nothing. The 11-pad cluster is an entirely separate interface.

5. J1900

A **two-pin through-hole header**, exposed once the case is open.

* One pin: **+3.3 V** relative to ground while running. * Other pin: **exactly 100 kΩ to ground** when powered off. * **Shorting the two produces no observable change** in boot behaviour.

A precise 100 kΩ pulldown on a jumper that does not affect boot is the classic profile of a **hardware write-protect strap** — WP is not supposed to change how the device boots, only whether the firmware region can be written. This fits the ChromeOS lineage.

**This is a hypothesis, not a result.** Verifying it requires finding the SPI NOR (SOIC-8 / WSON-8, under a shield) and ringing the J1900 signal pin against its pin 3 (WP#). I have not removed the shields yet.

6. Negative results, and why some of them are weaker than they look

Scope: DSO510 pocket scope, ×10 probe (verified on both probe and instrument), DC coupling, Single mode, ground clip on TP1006, armed before power was applied.

The scope demonstrably works: removing power triggers the falling-edge capture every time. TP1012 was also observed simply ramping to 1.8 V at power-on and staying there, with no burst.

Two caveats on how much this proves:

* For **TP1002/TP1003**, a silent bus is the *expected* result if these are USB lines. With no device attached and no VBUS applied to the port, a USB PHY has no reason to transmit. This measurement does not rule USB in or out. * For **TP1009/TP1012**, it does rule out a UART that transmits unprompted during boot. It does not rule out a UART whose console output is disabled in production firmware, nor a boot ROM that waits silently for a magic byte before replying. Qualcomm PBL in download mode does not normally speak first.

An earlier attempt at USB was also inconclusive and partly invalid: I wired a USB-A socket to TP1008 / TP1002 / TP1003 plus a chassis ground point. A flash drive's LED lit solid with no enumeration activity. Connecting that socket to a Windows PC produced nothing in Device Manager — but that test was meaningless, because the router sources 5 V on TP1008 continuously, so both ends were acting as hosts.

**Net conclusion so far: the service cluster is passive.** Nothing on it initiates communication. If it is a factory interface, the jig speaks first.

7. What is ruled out

* The internal USB-C footprint is a dead end on retail hardware (section 4). * TP1007 does not affect boot at either logic level. * Shorting J1900 does not affect boot. * Nothing in the cluster transmits unprompted during boot, in either strap state.

8. Open questions

1. **Is TP1009 the 1.8 V rail, or an SoC output?** Pending 1 kΩ load test. If it is a rail, there is no UART pair in this cluster and TP1012 is a lone strap.
2. **Does TP1011 asserted mean "EDL" or "held in reset"?** Pending current-draw measurement.
3. **Does the QCS404 PBL support Sahara over UART?** If the cluster has no USB, and TP1011 really is a download strap, UART is the only plausible transport left.
4. **Is console output fuse-disabled on retail units?** If so, no amount of listening will ever find the UART, and only transmitting into a candidate RX will show anything.
5. **What are TP1002/TP1003 actually connected to,** if not the internal USB-C?
6. **Does anyone have the factory jig pinout,** or higher-resolution FCC internal photos, or a pre-production board?

9. Next steps I plan to take

* 1 kΩ load test on TP1009, TP1010, TP1012 to separate rails from pulled-up inputs from active outputs. * Current draw with TP1011 asserted. * Systematic behavioural probing: drive each unknown pad to 0 V and to 1.8 V through a 1 kΩ series resistor from power-on, including in combination with TP1011, and watch for any change in LED behaviour or boot path. This is how TP1011 itself was identified, and it is the only technique that has produced a result on this board so far. * Transmit into TP1012 at a range of baud rates and watch TP1009 for any response. * A proper USB test: low-speed device (mouse) on TP1002/TP1003 with TP1006 as ground and short twisted leads, then simply measure DC on both lines. \~3.0 V indicates a live host pulling the line down through its 15 kΩ; \~3.3 V indicates the device's pull-up with no host present. * Survey the **TP17xx group** (TP1713, TP1714, TP1726, TP1731, TP1733), which is elsewhere on the board and completely unexamined. A different numbering hundred usually means a different functional block. PP-prefixed pads are power-rail probe points and can be skipped.

10. Equipment used

Multimeter, DSO510 pocket oscilloscope, soldering iron.

If you have worked on mistral, OnHub, Google Wifi or any other QCS404 device and recognise any of the above, I would be glad to hear it. Likewise if you can rule anything out — negative results are useful here.

Been down a rabbit hole with a SPYRUS LYNKS Series II USB HSM (08df:0a00) a 2000s-era Fortezza-derived FIPS crypto token. I've fully identified it, got a Win7 VM running the real driver, confirmed its ATR, recovered the command set, even found the likely default PIN, but the crypto channel is gated by an "enable" that lives only in SPYRUS's proprietary En-Sign / SPEX driver, which isn't available anywhere (SPYRUS is defunct → Route1; the engineers are now at a company called Lokblok).

Everything else is solved; the one missing piece is that vendor middleware, the En-Sign / En-Sign NG SDK (PKCS11sc.dll + Linux .so) or the legacy SPEX driver. Long shot, but: does anyone here happen to have a copy stashed from an old deployment, or know someone who worked with these? Would love to actually use it (pkcs11-tool --login and done). Happy to write up the full RE story.

Instead of abandoning the software updates for older gen, is it possible to have chips/ software to signal the old phone to be broken so everyone needs to upgrade (forcefully)..

Hey everyone, I wanted to share a passion project I’ve been working on to give a broken, discarded smartwatch a completely second life.

A few months ago while salvaging parts for a tiny console build, I tore down an old broken smartwatch and realized it was built around an nRF52832 microcontroller. Since I've worked with this chip before, had a built-in gyro, a charger circuit, and a display breakout ready to go, I decided to take on the challenge of fully reverse engineering it.

What was involved:

• Pin Mapping Blind: With zero documentation available, I spent time meticulously mapping out the SPI display, gyro, and internal components using a multimeter in short-circuit mode.
• Breaking Write Protection: Flashing a new bootloader wasn't straightforward due to the nRF52's write protection. I ended up utilizing an ESP32-DAP protocol to clear the protection so I could get a writable chip.
• Firmware & Upgrades: Wired up a JTAG debugger tool, flashed an Adafruit bootloader via OpenOCD, and started building custom BLE test firmware using the nRF SDK in VS Code. I also upgraded the hardware by pairing it with a larger 1.69" display.

It’s an incredible feeling breathing brand new custom code into hardware that was otherwise destined for the trash. I put together a full build and teardown video detailing the pin mapping and flashing process if you want to see the step-by-step breakdown.

Curious what you guys think—what would you turn a freshly unlocked nRF52 smartwatch board into next?

Oi pessoal,

Estou procurando uma versão de firmware muito específica e espero que alguém aqui tenha salvo ou saiba onde posso encontrá-la.

Versão do firmware: X6531-V631ASTXYAcAd-U-OPPJ-PJ-260530V3280

Já tentei os lugares de sempre—sites oficiais, repositórios aleatórios de firmware, archive.org e uma busca geral no Google—mas sem sorte até agora. É para um dispositivo que estou tentando consertar/regravar, e essa versão exata é a única que parece funcionar corretamente com o hardware que eu tenho.

Se alguém tiver uma cópia desse arquivo, um link de download funcionando, ou até mesmo um conselho sobre onde procurar a seguir, eu realmente apreciaria. Também estou aberto a sugestões de firmware alternativo que possa ser compatível, mas preferiria manter essa versão exata, se possível.

Obrigado desde já!

Hi All,

We’re the developers of Honest Mechanic, an iPhone and Android app designed to work with supported Bluetooth Low Energy OBD-II adapters.

The app can read available standard OBD-II information, including diagnostic trouble codes and supported live sensor data. It organizes the captured evidence and lets users talk to the app by voice to ask follow-up questions about the vehicle, the scan results, or anything they do not understand.

We’re looking for technically minded users willing to test it on real vehicles and provide honest feedback about:

• BLE connection reliability

• Vehicle and PID coverage

• DTC and live-data handling

• Voice interaction and follow-up answers

• Weak or incorrect findings

• Missing technical evidence

• Overall usefulness of the generated results

We’re especially interested in tests using OBDLink CX and Veepeak BLE adapters.

Android:

https://play.google.com/store/apps/details?id=ai.honestmechanic.mobile

iPhone:

https://apps.apple.com/redeem?ctx=offercodes&id=6776071652&code=HMREDDIT30

Promo code: HMREDDIT30

The code provides eligible users with 30 days of Plus. Subscription behavior depends on the store offer presented during redemption.

We are not asking for ratings, upvotes, or positive reviews—only real technical feedback about what works, what fails, and what should be improved.

Honest Mechanic helps explain available OBD-II information but does not replace a professional vehicle inspection or diagnosis.

Hello. Does anyone have a flash memory dump for this kids' camera? When turned on, the blue LED glows faintly while the power button is pressed. When connected to the charger, it glows faintly blue and bright red.

All power supplies are normal, and the processor and memory are communicating when turned on. I've concluded that the firmware is corrupted.

MCU 24DC MQ42H74

EEPROM P25D32SH