Ya so pretty much what the title says. I think it’s bullshit how she swiped my phone and her sister blatantly admitted she has hacked it. Also my girlfriend Samsung cloud is hooked up to a different number then the one I call her at and when I try to log into her Samsung account she can’t verify with text message because it doesn’t got her number but she says it is her brothers cell number. I also found out she is using a secondary digital SIM card that’s connected to her phone .

Hi everyone,I am trying to build a custom HTML site using the Web Bluetooth API to connect to my 2026 KuKirin G4 e-scooter, which runs a BK-BLE-1.0 Bluetooth module (Firmware version 6.1.2).No official or third-party apps connect to this scooter model, but I successfully cracked the code to unlock the Bluetooth data stream. By continuously sending the passcode A5 00 00 00 00 00 00 A5 every 600ms to the write channel (0000fff1), the scooter stays connected and streams data back to me on the notification channel (0000fff2).While the scooter is sitting completely still at 0 km/h with a 100% full battery, it continuously alternates back and forth between two different 16-byte data packets.Here are the exact numbers that show up on my screen:Packet Type 1 (Starts with 25 26)25 26 82 17 DF 19 18 00 04 00 00 00 00 00 DB 0BPacket Type 2 (Starts with F2 B0)F2 B0 11 28 8C 14 00 8C 1A 55 11 04 1F 00 00 13What changes when testing:When sitting idle (0 km/h): The bytes change back and forth by themselves between these two packets, which causes values like battery and speed placeholders to jump around constantly.When accelerating: Byte 11 immediately switches from 00 to A9. Meanwhile, Byte 13 starts changing frantically, spiking all the way up to 90 or higher from a standstill, but then drops all the way back down to 00 even if I hold the throttle steady at speed.I do not know what these byte numbers mean, how they are formatted, or how the scooter calculates its actual speed and battery percentage from them.If anyone knows how to decode this specific Beken controller data format, please let me know!

Hi everyone, I'm building a DIY smart watch and I want to use an epaper display, but the only one I've found so far is the 1.6in spectra 6 which looked perfect but does not support partial refresh which is a deal-breaker for the software I want to run. Any recommendations? I feel like the 1.1inch ones are too small for the vision I have in mind. If anything I'd be prepared to go slightly larger on the diameter. If anyone can help me find something I'd greatly appreciate it, I'm coming up empty at the moment. Thanks!

Hey everyone,

I’m trying to revive a legacy standalone setup with a Cisco Codec Plus and a Precision 60 camera. Right now, the camera won't update because the codec is pointing to a dead legacy server domain (management.join.vc) and throwing a Failed to connect / No route to host error.

I need to flash it locally over the web GUI to fix this, but I'm completely stuck trying to source the firmware package.

I’ve already exhausted the usual routes:

official cisco route - completely blocked - I don't have an active SmartNet contract, and Cisco's registration portal keeps throwing a "server error" and rejecting my personal email domain anyway

"index of" search - spent hours looking for halleyce9_15 or s53200ce9 PKG/COP files on open indices, but the mirrors I found are either dead or taken down

cloud/DevNet sandboxes are retired, so I can't spin up a quick Webex Control Hub trial org to let it auto-provision over the internet.

Does anyone happen to have a stable CE9 bundle (ideally halleyce9_15_3_26.pkg or the cmterm-synergy-ce9 COP file) sitting in their deployment archives that they could drop into a temporary Google Drive or Dropbox link?

Any pointers appreciated!

--- UPDATE ---

I forgot to mention that the whole reason I bought the codec is to get these cameras (got 3, couldn't help myself) to fully work standalone - full PTZ, exposure and other parameters control. Plan is to capture and reverse-engineer the codec-camera IP communication

--- UPDATE - Solved ---

When I initially set up the camera (wizard) provisioning was switched to some custom mode (codec tried to download the firmware from admin.vc or similar address). I did a lot of stuff at once, so I am not sure if provisioning config was enough:

>!Generally I've experimented with different provisioning configurations, and I think switching to webex integration (not webex edge/iot) has helped. I also created a free normal (not control hub) webex account and while clicking through found "devices" section in settings. It has an option to activate a device which generates the standard activation code. I did not have high hopes, but strangely the codec accepted the code happily! At some point codec upgrade started installing. Some time later the camera got silently upgraded to the same version (I didn't even notice at first because I expected CE camera firmware, but it has HC prefix with the following version number the same as codec software).!<

If you play around with running iSH on iPhone/iPad as a mobile red/blue team rig:

Crimson Cloak gives you a full HTTP + WebSocket dashboard inside iSH:
- Embedded dark-themed control panel
- Tool discovery & shortcut launching
- Clipboard sync, file events, network monitoring
- SSH reverse tunnel auto-connect to Kali/Pi backend

All sandboxed. No jailbreak required.

Repo: https://github.com/synchancybersecurity/Crimson-Cloak-ISH-wrapper-iOS-

Curious if anyone else is using iSH for mobile ops.

I was curious about the content of an STM32F103RFT6 firmware binary. It uses CAN communication and it is being updated via CAN bootloader, thats how the firmware is being updated.

So I opened it in a hex editor and had a look. But that was not what I expected.

reverse engineering binary

Right in the beginning, there seems to be a 0x200 long header. The first four bytes are the size of the whole file, that was easy. Then four bytes containing the version, I guess, because I have another firmware which is a bit newer and they just differ by increasing 0x2c to 0x30.

Everying after that I don't understand right away, and the header after 0x050 is just zeros until it ends at 0x1FF.

At offset 0x200, the real firmware seems to start:

reverse engineering binary

At first glance, it looks as expected: First four bytes show the stack pointer address, and it's located in SRAM (starting 0x2000_0000).

But the following entries are supposed to be a vector table, and the addresses in there point to strings:

reverse engineering binary

I know that's thumb addressing, and all the LSB are set, but in the vicinity of these addresses there's just strings.

I don't understand that. And I don't know how to go on from here, if I don't know where the actual entry point is located.

For comparison, I opened an STM32 .elf for a project I wrote. In this .elf, the real code starts at offset 0x1000:

STM32.elf

Four bytes stack pointer, and then flash locations for the vector table. Going there and taking the file offset 0x1000 into account:

STM32.elf

I figured, fe e7 fe e7 must be pretty rare in the original firmware binary, so I searched for it:

reverse engineering binary

That does look pretty similar. But why is that, and where does this offset come from? And how should I continue?

I'm curious about how manufacturers identify individual Bluetooth headsets and other consumer electronics during service or warranty inspections.

If two units of the same model look identical and don't have a visible serial number, how do service technicians distinguish one from another? Do they use an internal serial number, Bluetooth MAC address, firmware ID, or other unique hardware identifier? Can these identifiers be read using diagnostic software through the USB port?

I'd appreciate insights from electronics repair technicians or anyone with experience servicing these devices.

!!CAGE LAB🧪🥼!!! hardware security testing framework, I guess I just wanted to share the architecture with people who understand both the offensive and defensive sides.

D.Z.D.E or Daedalus SubZD Engine lil break down:

8 independent cells, each running a Raspberry Pi 5 controller with auto detected I2C/SPI/UART/USB extensions.
Designed for Rowhammer, EMFI, laser fault injection, thermal manipulation, and voltage glitching all commodity hardware under $15K total.

The bs problem it solves imo:

Hardware security R&D usually dies at the whole "can we even talk to this chip?"
This auto detects extensions, provides per target calibration interfaces, and runs everything through a physical kill switch with CAGE/LIVE/WAR safety modes.

Cost per cell hardware is \~$600:

Pi 5 8GB + Pi Edge HAT
RTL-SDR / HackRF for RF verification
RFID (MFRC522), LoRa (SX1276), GPS (NEO-6M), CAN (MCP2515)
EMFI coils, 808nm laser diodes, TEC1 12706 Peltier
ADS1115 ADC + MCP4725 DAC for precision glitching
8 channel relays, PCA9685 PWM drivers.

Repo: github.com/synchancybersecurity/Daedalus-SubZD-Engine-1.0

Cage lab authorized only.
Physical kill switch is the sole fail-safe.

Agent F.

This summer I started a personal project: turning my old 2009-ish ebook reader (Rockchip RK2818X) into a Tamagotchi-like virtual pet.
Not because it’s useful, but because I want to learn how to reshape closed systems.

So far I’ve:

• Identified the SoC (RK2818X).
• Dumped the original firmware.
• Unpacked everything with the few tools that still work for this platform.
• Loaded the main binary into Ghidra.

And now I’m stuck.

The firmware isn’t Linux-based, it’s a single monolithic blob full of trampolines, DSP-style pipelines, mixed code/data regions, weird control flow, and functions that look autogenerated.

I can analyze pieces, but I don’t know the right strategy to move forward.

If anyone has experience with Rockchip devices, monolithic DSP firmware, or general blob reverse engineering…

I’d really appreciate any pointers, workflows, or documentation.
Just need direction, not someone to do the work for me.

Thanks!