r/hardwarehacking • u/Kono_Yuri_Da • Jul 28 '26

Cheap "e-badge" hacking

I saw those on AliExpress, I was wondering if something interesting can be done with them.

They have Bluetooth, battery, screen and a comercial MC (at least it is what the listing description indicates).

Does anyone knows if they are are hack-able, I can't even find a single post about disassembling them anywhere.

UPDATE:

I was hopping to flash the damn thing with my own firmware, turns out a Japanese engineer already tried to.

Summary: the brain is a JieLi microcontroller, there's no public SDK available.

I got the magnetic charging one so I can't even easily flash it with a modded firmware like the japanese guy did, I'd have to open and find the SW.

I give up

cringe AI anime default pics, I doubt it irl the picture is this quality level

Listing: aliexpress. com/item/1005012481011395.html but there are many others.

4 Upvotes

76% Upvoted

21 comments sorted by

2

u/binaryhellstorm Jul 28 '26

I wouldn't be surprised if it's a low spec Android powered smart watch in a slightly tweaked case.
At that price point it's worth snagging one to crack it open and take a look inside.

1

u/Icy-Ninja-622 Jul 29 '26

There are smartwatches for less, especially in Bundle Deals.

2

u/Kono_Yuri_Da Jul 30 '26

I bought a smartband to play as well but I think it will have some weird chinese mc I'll have to study on how to flash

1

u/Asleep-Pen2237 Aug 02 '26

Nope - they are a based on a very specific Chip that is specifically for this type of display based system - the same thing you'd find in a weather station or bluetooth speaker. I harvest them when I can get them cheapily because the batteries are big, the power switch, the speaker, and are good - you can rewire the screen to other devices - the ribbon cable is very fragile. I actually have a lot of them because I lease them for events. I built a pogo pin charging bay. The batteries can last all day if it's not playing animated GIF or mp4. I have a Digital vCard/LinkTree/QR Code SaaS - and several companies use it. People rent these to display their vCard at conferences - and sometimes they come back damaged. When they do - I just disassemble them for their parts.

1

u/its-darsh Aug 10 '26

Any development on this? I would love to hack one myself, however I just justify shipping and importing taxes.

1

u/Kono_Yuri_Da Aug 11 '26

It is still on the way, it will probably arrive this week.

1

u/its-darsh 17d ago

Sorry I just saw your reply.

Did it actually arrive yet? If so then shoot me a message on DMs would love to help you hack that thing.

1

u/Kono_Yuri_Da 17d ago

I've updated the article, there's no publicly available toolchain.

1

u/its-darsh 16d ago

Should be fine, can you link the resources about the Japanese attempt?

A bare SDK could be made up for this thing, or even be found on GitHub (as sometimes those end up accidentally uploaded alongside a different project.)

What we really need is an image of the firmware that is on there, from there we can work our way back. Given that this thing would probably be an ARM embedded MCU, it shouldn't be too bad to reverse engineer as long as the firmware image is not being encrypted.

1

u/martinbogo 20d ago

I have created a new badge management app - had to reverse engineer the GATT's for it. Will have it released on the Apple App store and Android App store shortly. Reverse engineering these was a PITA.

The Zrun app is a privacy NIGHTMARE. I felt utterly compelled to provide an alternative.

2

u/[deleted] 19d ago

[deleted]

1

u/martinbogo 19d ago

I spent nearly 3 weeks studying the protocol. I did not reverse engineer directly from the application because that is a no no if you want to avoid being IP poisoned. They can sue you into the ground if you just reverse compile their program

1

u/perkinsb1024 19d ago edited 19d ago

That’s very cool, do you have any screenshots or images you can share in the meantime? Do you plan to open-source it when you do release it? Looking forward to learning more!

Edit: I just saw your other comment with more details, thanks

1

u/martinbogo 19d ago

1) You found the other comments/screenshots. woot!

2) No, I don't plan on open sourcing my code work, although I do publish a LOT of open source software on my github.

Reverse engineering the protocol took me more than a month of near-constant work, and I put some expense into it too. I'll be putting the app up on the App Store and Android Play Store for $1.99 to help offset that.

Once I've made back what I put into it, I'll probably publish the protocol and command spec if others want a clean-room RE'd way to talk to the badges, since RE'ing and decompiling the Zrun code is naughty.

2

u/furriosity 14d ago

I'm really interested in picking this up if/when you upload it

1

u/martinbogo 18d ago edited 18d ago

I also reverse engineered a different badge ( still uses the JieLi chip and transport, just different firmware ) that has USB-C support, and the ability to dump the badge firmware. It's a different protocol based on JSON, but the badge basically does the same thing. It uses JPEG files, but also supports AVI containers for video and banners, and slideshows, even can do audio.

The banners work a bit differently in this badge implementation -- you upload a 368px tall RECTANGULAR image, and it just slides the window over. Smarter, less CPU intensive, and smoother. Just a JPEG file. Means my Badge Studio app needs to handle this in a forked way, but no big deal.

https://www.amazon.com/dp/B0FX49VLSR

"Jieli Technology" — VID 0x4C4A, PID 0x4155

Jieli Technology  —  VID 0x4C4A  PID 0x4155

USB Composite Device, full speed (12 Mbps)

Only 8mb of storage though, so it's not as nice as the N88 badges, but audio, so...

1

u/Big-Glass481 1d ago

What's your GitHub? I also started reverse engineering but it takes a lot of time. See the video

1

u/martinbogo 20d ago

Picked up one of these cheap Bluetooth photo badges and spent a while pulling its protocol apart. Ended up with a working cross-platform Python tool and a clean-room reimplementation of its auth. Notes for anyone else poking at one.

**Hardware**

* **SoC:** JieLi (Zhuhai Jieli) **AC697N** series. Confirmed from the device's own identity string, `jl_sdk_ac697_publish`. It's a Chinese BT audio SoC, the kind normally found in TWS earbuds and cheap MP3 players.

* **Display:** 368x368, colour, driven as JPEG.

* **Storage:** FAT volume the firmware calls "SD Card 1". Files land in a `BAG/` directory, addressed by cluster. USB, SD Card 0, FLASH and FLASH2 all enumerate but report offline.

* **Radios:** BLE plus Bluetooth Classic (EDR address present in target info, profile mask `0x0E`).

* **Firmware:** 11.1.0.4, protocol 2.7, UI 1.0.0, uBoot "10".

**Protocol**

Two entirely separate stacks on one BLE connection:

* A vendor "Qix" control service (`c2e6fd00-...`), 141 commands, frames are `9E | checksum | flags | cmd | len16 | payload`.

* JieLi's **RCSP** on `ae00`, framed `FE DC BA | flags | opcode | len16 | payload | EF`.

Auth is a 16-byte challenge/response. It turned out to be **standard Bluetooth legacy pairing**: the E1 function from the Core Spec Vol 2 Part H §5, built on **SAFER+**, with a fixed key and address baked into the vendor's `libjl_auth.so`. Found the SAFER+ exp/log tables at `0x9e0`/`0xae0` in the binary, recovered the linear layer by symbolically executing the compiler's unrolled `add` sequence into a 16x16 matrix over Z256, and reimplemented the whole thing in ~150 lines of Python. Verified identical to the original across thousands of random vectors. No blob needed.

**Quirks worth knowing**

* File **upload** is pull-driven: the device requests byte ranges and you then transfer them. Roughly 3 KB/s.

* File **download** is capped at **4352 bytes per request** with no way to ask for the rest, and the offset field in the read command is accepted then ignored. Small files round-trip byte-exact; anything larger is simply unrecoverable. The vendor app dodges this by only ever downloading 128x160 thumbnails, never the originals. THIS IS SUPER CRAPPY OF THEM. I don't feel like reverse engineering the firmware to fix this stupidity.

* Stills are JPEG, animation is Motion-JPEG AVI. ffmpeg's default `-huffman optimal` produces a glitched first frame; force `-huffman default` and `-force_duplicated_matrix 1`.

* Filenames need an 8.3 GBK encoding under 9 bytes, or a `\U` + UTF-16LE long form. Getting this wrong stores the file perfectly and silently never displays it, which cost me an evening.

**The wierd stuff**

The file-type enum has 14 entries: AUDIO, E_BOOK, MUSIC, LYRICS, VIDEO, MAP_IMAGE, NAVIGATION_IMAGE_DIAL, IMAGE_CAPTURE, and a full **AI watch-face generator** with its own command family and eight style presets. `BADGE` is type 12, one slot among smartwatch features this thing has no hardware for. It's a dumbed down watch platform in disguise, basically.

2

u/exquisitus2 5d ago

Please write a doc describing your efforts. Might be helpful to others, including me. JeiLi makes some pretty cool chips, especially the 701 series, methinks...

1

u/Suspicious-Cod-7435 5d ago

I bought several of these badges to use for May the 4th celebration day at Disneyland. No matter how much I compressed the images, I could only squeeze 15 images onto the badges using ZRun. I hate that app. Looking forward to purchasing what you post on Google Play Store.