search

biemster / FindMy

Query Apple's Find My network
329 stars 51 forks source link

Flashing unidentified chip PCB label: RB-WS8000B-FD02_V1.0 #35

Open JayFoxRox opened 11 months ago

JayFoxRox commented 11 months ago

I've just received 3 tags.

Store: https://de.aliexpress.com/item/1005002599386785.html (Bought on 2. Nov 2023) Seller: FuXin Trading Co., Ltd. Product (US name): "Anti-Lost Mini GPS Tracker Locator Finder For Kid Key Pet Dog Cat Bicycle Car Low-Power And Environment-Friendly Practical" ("White" and "Black")

I had hoped these to be Lenze ST17H66. However, unfortunately, they are more similar to #13.

I speculate these are WS8000, judging by the board label (which happened to be WS8030 in the other one). In fact, the WS8030 is also available in SOP8. The pinout roughly seems to match, but I didn't probe it yet.

Factsheet: https://www.taoic.com/company/7287/WS8000==45b88e7c-2bd3-11ec-9475-00163e1552d4-28_detail.html This also lists JLINK TMS / TCK, so it might not be JTAG, but some specific variant of JTAG (that I'm not familiar with). The datasheet also mentions Keil and JLINK in particular.

Testpoints:

Unfortunately there's no TXD / RXD, so I'm not sure if I'll just throw these away.

Appears to be a 16.000 MHz Clock and some SOP8 controller (as mentioned above, likely WS8000).

The included booklet tells you to use the "Kindelf" app: https://play.google.com/store/apps/details?id=com.lenzetech.kindelf Note how this is in fact by Lenze.

Photos:

packaging

internals internals-back

booklet booklet-back

Any ideas for custom firmwares or flashing / flash readback?

What kind of CPU is this? Note that I found an unrelated wisesun datasheet which mentions some common CPU archs:

Also ping-ing @drott

biemster commented 11 months ago

Counting the already used pins (GND, VDD, LED, buzzer, button, xtal x2, antenna) that leaves you with exactly zero pins left for an uart or similar, so if there is any flashing possible here it will have to be pin-shared with either the buzzer, button and/or LED. Does the tag still boot when you hold the button while applying power?

JayFoxRox commented 11 months ago

I've done some more thinking (and reading), trying to figure out how to flash these and what CPU they could be. 2 things stand out.

  1. Keil being mentioned as development environment, but Keil is mostly known for their 8051 and ARM Cortex-M tooling, so it's likely one of those, but the 8051 can be ruled out due to not being 32-bit.

  2. J-Link (JLINK) has this documentation: https://www.segger.com/products/debug-probes/j-link/technology/interface-description/#swd-and-swo-also-called-swv-compatibility The J-Link interface overlaps JTAG TMS / TCK for ARM SWD SWDIO / SWDCLK.

This, to me, strongly indicates an ARM CPU (and also how it could be programmed). I plan to look into this, but I don't have much freetime, so I probably won't get to it anytime soon.

Additionally, I briefly looked at the existing "Kindelf" APK with jadx, but it's a pretty dumb BT protocol. On first inspection I found out how to set the alarm (although I didn't try it) but there doesn't seem to be any OTA capability (the APK also hasn't seen updates since 2022, which is a bad sign).

It seems very amateurish and also contains a lot of debug printing.

This is in "sources/com/lenze/kindelf/application/MyApplication.java" (yes, that's probably their sourcefile name):

            MyBleItem myBleItem = new MyBleItem();
            String trim = Pattern.compile(" [\n`~!@#$%^&*()+=|{}':;',\\[\\].<>/?~！@#￥%……&*（）——+|{}【】‘；：”“’。， 、？] 0").matcher(bluetoothDevice.getName()).replaceAll(" ").trim();
            if (trim.contains("Tag-It")) {
                trim = "iTAG";
            }
            myBleItem.setBleNickName(trim);
            Log.d(TAG, "OnMyDeviceFound123: " + trim);
            myBleItem.setAddresss(bluetoothDevice.getAddress());
            myBleItem.setBtnShowText(getString(R.string.un_conn_ble));
            myBleItem.setImageByte(null);
            if (bool.booleanValue()) {
                myBleItem.setHasBattery(bool);
            }
            this.bleItemHashMap.put(bluetoothDevice.getAddress(), myBleItem);
            DeviceFragment.getInstance().UpDateOnUIThread();
    public void AlarmByAddress(String str) {
        Log.e("开始报警1", "开始报警" + str);
        if (this.bleGattMap.containsKey(str) && this.bleGattMap.containsKey(str)) {
            Log.e("开始报警2", "开始报警" + str);
            Log.e("开始报警4", "开始报警" + str);
            this.bleWrireCharaterMap.get(str).setValue(new byte[]{1});
            Log.e("开始报警5", "开始报警" + str);
            this.bleGattMap.get(str).writeCharacteristic(this.bleWrireCharaterMap.get(str));
            return;
        }
        Log.e("开始报警3", "开始报警" + str);
    }

    public void CancleAlarmByAddress(String str) {
        Log.e("开始报警1", "开始报警" + str);
        if (this.bleGattMap.containsKey(str)) {
            Log.e("开始报警2", "开始报警" + str);
            Log.e("开始报警4", "开始报警" + str);
            this.bleWrireCharaterMap.get(str).setValue(new byte[]{0});
            Log.e("开始报警5", "开始报警" + str);
            this.bleGattMap.get(str).writeCharacteristic(this.bleWrireCharaterMap.get(str));
            return;
        }
        Log.e("开始报警3", "开始报警" + str);
    }

    public void SetDeviceISAlarm(String str, boolean z) {
        Log.e("设置断开是否报警", "设置断开是否报警" + str);
        if (!this.bleAlarmWrireCharaterMap.containsKey(str)) {
            Log.e("设置断开是否报警", "设置断开是否报警" + str);
            return;
        }
        Log.e("设置断开是否报警", "设置断开是否报警" + str);
        if (z) {
            Log.e("设置断开是否报警:断开报警", "设置断开是否报警" + str);
            this.bleAlarmWrireCharaterMap.get(str).setValue(new byte[]{1});
        } else {
            Log.e("设置断开是否报警:不报警", "设置断开是否报警" + str);
            this.bleAlarmWrireCharaterMap.get(str).setValue(new byte[]{0});
        }
        Log.e("设置断开是否报警", "设置断开是否报警OK" + str);
        if (this.bleGattMap.containsKey(str)) {
            this.bleGattMap.get(str).writeCharacteristic(this.bleAlarmWrireCharaterMap.get(str));
        }
    }

(I suggest to read the full code for context, if anyone plans to reimplement this in some other language / tool)

I didn't check if they also have a network / online service where the app reports the location to. I'm mostly interested in using the Apple network (and Google or Samsung later maybe?), so I didn't look much further into it. I also don't expect a dense network of finder nodes where I live (Germany / Europe).

biemster commented 11 months ago

This tag in its current state will not have a network to report to for sure. The TMS/TCK pins are indeed prime suspects, I would start my investigation there if I had one of those.

JayFoxRox commented 11 months ago

Does the tag still boot when you hold the button while applying power?

It doesn't seem to show up in the list of bluetooth devices then, it also beeps differently during bootup. I also suspect this might be what the chip is using to determine wether it should use pins as GPIO or debug mode.

Unfortunately I'm still not sure how to get the chip into debug mode though. While it doesn't appear in the list of bluetooth devices, which I've scanned using bleak in a python3 repl:

import asyncio
import bleak
from bleak import BleakScanner

async def main():
  devices = await BleakScanner.discover()
  for d in devices:
    print(d)

(Then rescan using asyncio.run(main()))

I have it wired up for testing (using some clamps and clips) but I'm unable to get SWD to work from an ESP8266 (nodemcu v3). I'm currently trying https://github.com/denisn73/esp8266-arm-swd to speak SWD. I'm supplying 3.3V from nodemcu to the tag battery holder.

I speculate the following pin usages:

(left north to south, starting near notch)

(right south to north)

Taken orientation from PCB label:

I'll probably have to sacrifice one of my boards to desolder the chip. The board I'm probing is also already rather broken as the soldermask scratches away very easily. I'm not sure how the rest of the components are interacting with the chip and I'd also rather have a clean breakout.

One last thing I'll try before is to listen on the GPIOs during bootup. But I'll have to set up my logic analyzer first and I'm not sure when I'll find time for this.

biemster commented 11 months ago

Great find on the different boot beeps, it seems to at least boot different code when you hold the button! I'd also listen to the gpios during this alternate boot, although keep in mind that for example the lenze 17h66 needs some magic input on an rx pin before it goes into debug mode, so silent gpios does not mean it's not there. It would be really helpful if we could find some developer documentation on these, but no luck yet.

JayFoxRox commented 11 months ago

Great find on the different boot beeps, it seems to at least boot different code when you hold the button!

I think that might have been a fluke 😢

Here are some observations with TCK / TMS disconnected:

But:

So there doesn't seem to be a difference here. it simply didn't appear in BT because I probably held the button for too long, so it also went to sleep on BT. The sound was simply the button press sound.

I'm noticing that it also powers up without VDD:

I've also tried grounding some pins but it just reset the ESP (probably cause I'm causing shorts)

The question remains: once normal operation starts, these are all GPIO.. so how does this chip (if possible) ever return to debugging mode?

I've done a bunch of sigrok / pulseview sniffing on all 3 GPIOs and confirmed my SWD looks correct - but at least in the current state, the board does not reply. I also plan to check cJTAG, but I don't have high hopes, given that these pins are in GPIO mode.

I also noticed the https://datasheet.lcsc.com/lcsc/2206281830_wisesun-WS8300F5ES16_C2980817.pdf manual even explicitly mentions "SWD (JTAG)" for a similar pinout.

It would be really helpful if we could find some developer documentation on these, but no luck yet.

I'd even try to send them an e-mail, but wisesun.com and wisesun.com.cn have been offline for the past week already (last google cache and archive.org are from mid November).

I'm also not too motivated to desolder the chip right now because I totally forgot that I'd also have to wire up another XTAL / support components.

I'm also not sure what the unnamed test pad is for. I'm starting to think it might be used to pull some pin in another direction (potentially other side of beeper or LED?). I'll probably try to figure out where it connects when I have unplugged the rest of the clips again.

biemster commented 11 months ago

The datasheet of the WS8000 here: https://www.taoic.com/company/7287/WS8000==45b88e7c-2bd3-11ec-9475-00163e1552d4-28_detail.html mentions OTP, which is not a good sign..

JayFoxRox commented 11 months ago

The datasheet of the WS8000 here: https://www.taoic.com/company/7287/WS8000==45b88e7c-2bd3-11ec-9475-00163e1552d4-28_detail.html

Yes, I had linked it in my initial post already - it's also my main source about the WS8000 (aside from extrapolating from datasheets for other chips). However, I wouldn't go as far and call it a "Datasheet" - it's an excerpt and more similar to a "Factsheet" / marketing material. I'd prefer to have the original PDF.

Wisesun, for other chips, also has more detailed datasheets with some instruction listings, block diagrams etc.

After realising that wisesun.com isn't down, but simply blocked for me (or the western audience in general?) I've accessed it through a china-proxy. They don't have any material for WS8030 (#13) and limited info on WS8000 (not even a factsheet), but I'm also attempting to send mails to ask for datasheets now (hoping that some of my mailhosters will be accepted by their route and host).

mentions OTP, which is not a good sign..

Note that only a portion of the memory is OTP. I'm not too concerned with that (yet).

JayFoxRox commented 10 months ago

Not sure how I missed this so far, but http://wisesun.com/products_table.php?protypeid=21&parenttypeid=19 has an image with their 2.4GHz chips. These pages are category entry points which have tables (as image) which list some of their products. Sub-entries for each item reveal more information.

This overview includes the WS8000 (which always starts with WS8000P) and confirms it as Cortex-M0 (although they keep saying "Context M0"):

I guess the OTP is a problem now, because these tables suggest it's only RAM and OTP, critically, no flash and only a small EEPROM (if we are lucky). Interestingly this conflicts with the factsheet we have found which also lists a 96k ROM. It also conflicts with the actual WS8000 product page which lists an additional 96k ROM. So I'll probably still attempt to get some data out of it sometime in the distant future.

Another table (蓝牙模组 / Bluetooth module) names WS8000-M6 which is Cortex-M3 [error?]:

The dimensions make it sound like it's a daughterboard. I assume that WS8000-M6 is a daughterboard, similar to the WS8100_01=WS8100-01 (http://wisesun.com/product_detail.php?parenttypeid=19&protypeid=22&proid=48).

Also note how the naming scheme appears to be:

I'll probably also try to check the chip under different light, in case I missed a chip marking.