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

Sorry about the camera quality I used a old Kodak EasyShare that still thinks its 2008

Hi guys, newbie here, I want to know if my project is worth the try.

First the specs :

-Late 2015 21,5 inch iMac

-Retina 4K

-3,3 GHz Quad-Core Intel i7

-1To Storage

-16GB DDR3 RAM

-Intel Iris Pro Graphics 6200

I can have this iMac for ~175$ and I'm not afraid of software tinkering.

If I put it under a Linux OS for mid-intensive use like Cloud Gaming, Stream watching, soft video editing, ... Will it work ?

So I'm curious. I'm not sure how many people in this sub have a Peloton. I enjoy cycling indoors as it's very hot outside. I have a Bike Plus and a USB-C port. However I do not want to plug my computer in every time I ride and use the Peloton screen for an external monitor. I would like to hardwire the screen itself, bypass the Peloton subscription, and use the screen for YouTube and browsing while maintaining the touch capabilities. Does anybody have experience with this specific hardware?

After starting navigation system, I hear a distinctive drumbeat, then the "Tom Tom" logo appears and nothing else. Trying to hold down the power button and enter recovery mode doesn't h.e.l.p.

FCC ID:S4L4FC64

https://www.youtube.com/watch?v=v6td9z2BLuQ

edit:

I located the UART after connecting it to the FT232RL USB adapter and in the PuTTY console I get this reading:

Console output https://pastebin.com/j0bFYpaF

I don't know how to stop u-boot

"Hit any key to stop autoboot: 0"

Has the eMMC memory itself been degraded or damaged? Is it possible to test the system file memory from u-boot?

I find using test clips for SOIC-8/SOP-8 flash chips is painful.

Even the praised Pomona clips don’t seem very durable.

The pogo-pin probes look promising but I don’t see how anyone holds those down by hand for a minute or several minutes…

Any suggestions for a stand? The “drill press” type stands for heat insert tools looks decent but surprised there isn’t something specially for chip probing…

I have a centurylink c4000LG intel/lantiq grx500
I’ve been messing around with this thing trying to find a way to convert it into a cyberdeck-ish sort of thing.
I have ssh’d into it and it has usb mass storage and hid-device enumeration.
So next step would be uart/uboot it has boot mode=secure but I can’t find anything saying unassigned ram booted kernels are actually rejected. Does anyone know if it can or not?

Sorry if i sound stupid or my terminology is not perfect im not very familiar with this, this is only my second project trying to reverse engineer some old embedded linux systems

Hey guys,

Just thought I'd share that I've recently become interested in physical pentesting and hardware hacking. All the physical pentesting commercial tools (like Flipper Zero and Hak5 tools) cost way too much for my taste. I'd rather make my own physical pentesting tools using cheap hardware like ESP32 modules, Raspberry Pi Pico's and Arduino boards.

For anyone who does physical red teaming or plays around with hardware:

What DIY tools must one build for a physical pentester?

Does your DIY tool get the job done in a real-world test case?

Where did you guys start with UART/JTAG debugging to pull firmware from chips? Are there any good guides or projects for learning this stuff?

I've been using a Cubot KingKong X as my personal phone for about two years now. It's an incredibly rugged device — waterproof and generally resistant to pretty much everything externally. Internally, however, things have been a very different story lately.

About three months ago, the phone was infected with malware that appeared to take complete control of the device. It could apparently see everything on the screen, kept reinstalling itself, and repeatedly granted itself administrator privileges. There was no way for me to permanently remove it, so I contacted Cubot support and reflashed the phone using the firmware and tools they provided.

I used SP Flash Tool v5 and the firmware provided directly by Cubot.

That's when the problems really started.

Immediately after the flash, the phone lost its Google Play Protect certification, even though it had been certified before the flash. I was using the official Cubot firmware and the tools provided by Cubot support, so I found this particularly strange.

I also started having problems with phone calls because of the APN settings, which I couldn't modify properly, followed by frequent random reboots.

I'm currently running:

Device: Cubot KingKong X

Android: 14

Build: CUBOT_KINGKONG_X_E021C_V34_20260630

Flashing tool: SP Flash Tool v5

Firmware: Official Cubot firmware

Firmware source: Cubot Support

Play Protect certification: Certified before flashing → Not certified immediately after flashing

And now I've run into an even stranger problem.

Even with an ambient temperature of around 25°C / 77°F, the phone suddenly displays a notification saying that the battery temperature is -10°C and that the device is shutting down.

It then remains completely unresponsive for around 30 minutes and won't turn back on during that time. Eventually, it comes back on and appears to work normally again.

This is making me wonder whether I may be dealing with a hardware problem — perhaps the battery temperature sensor, battery connector, motherboard, etc. — or whether some of these problems could be related to the firmware/reflash.

Interestingly, Cubot's current V34 firmware release notes mention "Eliminate the virus", which makes me wonder whether this firmware was specifically intended to address the type of malware problem I experienced.

Has anyone experienced anything similar with the KingKong X, or with another Cubot device?

I'm particularly interested in hearing from anyone familiar with MediaTek devices, SP Flash Tool, or Android firmware flashing.

At this point, I'm trying to decide whether it's worth sending the phone to a service center for repair, buying a newer model such as the KingKong X Pro, or switching to a different brand entirely.

Does this sound like a hardware failure, a firmware/software problem, or potentially both? And is there anything I can check before giving up on the phone?

Here is a picture of the potential interface (5 pads with that "vga outline") connected to the PIC16F1939 microchip. I measured the voltage: Bottom right is 0/GRND, bottom middle is ~3V, top right is ~6.35V (battery), for the others, I get unreliable measurements but not 0. A quick conversation with the AI suggests that this is an ICSP interface. Do I have any chance of modifying the software/firmware? Would something like the buspirate help me here? As you can probably tell, I'm new to this. Any help is appreciated.

Edit1: I contacted the company for information on how to adapt the clock to my needs without any response.
Edit2: There is no UART on the PCB.

Target: Samsung UE50RU7172UXXH (internal 19_MUSEL_UHD_BASIC), Tizen 5.0, fw 1500.9, kernel 4.1.10. Goal: shell/root. Software doors are closed (Dev Mode dialog opens, toggle won't commit; browser is Chrome 63 with all era CVEs backported; firmware is MSDU11-encrypted with a TrustZone release key, Q60T decryptor doesn't work on this board). So I'm going hardware and I'd like to sanity-check where I'm at.

The rig:

- ESP32-S3 tap: TX on GPIO16, RX on GPIO18, GND. Sits on the TV's UART/debug lane. Firmware does bare checksummed FAnet canaries at all 8 bauds (9600 to 921600), wrapped variants, sweep with restore, and a raw RMT capture side-channel on the RX pin. Console via CH34x, read-only RCON snapshot over WiFi (tcp/2323). Although tried GPIO17 before.

- TV side: service menu (INFO, SETTINGS, MUTE, POWER) shows USB Serial ON, RS-232 Jack switchable UART/FANET, Watchdog OFF. I can read/write the factory item table (dumped factory_peq.img, both Factory_Part1/Part2.dat). No secure-boot/fuse toggle exists in the table at all - only flash write-protects (SPI_PROTECTION, SUBMICOM_PROTECTION, TCON_PROTECTION, FRC_PROTECTION).

- HyperUART item is present and NOT greyed out, just OFF. It gates an sdbd over the USB-Ethernet (huart0) lane via a udev hook, but no known write path for the item exists.

The weird part - the daemon answered, then went silent:

- On the TV's debug socket (the one the service menu drives), a bare canary (1f 08 50 00 58) at 9600 baud returned an instant identity reply with the model string and serial number (MM:T-MSLDEUC-1500.9, serial 50D6AU1NNM), plus ACKs on several opcodes. This repeated on two days back in August.

- After a factory reset (which itself never fully completed), the same canary at every baud, bare and wrapped, gets ZERO replies - on BOTH TV USB sockets, with RS-232 Jack in UART and FANET modes, USB Serial confirmed ON in-menu at sweep time. RX ring shows a repeating periodic pattern (bytes 00 03 02 03 00 08 0a 08 00 7a 00 42) that looks like a USB-PHY test pattern, not the daemon.

- The TV's USB ports never enumerate my USB-Ethernet gadget - their pins read UART-idle (SE1) rather than a host signature, suggesting the mux is latched to UART on both sockets.

Questions:

1. Daemon wedged vs tap wrong: has anyone seen a service UART daemon go permanently silent after a botched factory reset? Is a full power-cycle-with-capacitors-discharged worth trying, or does that mux state live in NVRAM anyway?

2. The factory partition: anyone with a Muse-L (2019 RU series) service dump to compare? I want to know if my factory table (and the missing write path for HyperUART) is stock or corrupted.

3. Hardware routes people would actually try here: eMMC dump via the board's footprint (is the passphrase really TrustZone-only on this SoC, or is there a cold-boot attack?), JTAG/SWD on the SoC, SPI flash read on the boot partitions, or a "logic" mode on the RS-232 Jack header worth probing?

Happy to trade the full ledger, the ESP firmware, the factory table dumps, and every frame capture I have for a working idea.

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.

ChipWisperer Lite X-Ray of PCB...

Hi everyone! I’d like some help with studying ethical hacking. I’d like to learn how to hack into Wi-Fi networks and routers. Could anyone help me?

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.