No bootable images found / FsOpen - Error [Help needed for unbricking]

Good evening everybody,

It seems like i bricked my ToniBox will trying to make a backup of all crucial files.
Maybe I’m just doing something wrong, but the box isn’t booting anymore.

When I tried to get a copy of the flash content and the filesystem the following happened:

cc3200tool -p /dev/ttyUSB0 --reset rts read_flash firmware.dmp read_all_files ./filedump
2024-01-20 18:46:53,252 -- Connecting to target...
2024-01-20 18:46:55,630 -- timed out while waiting for ack
2024-01-20 18:46:55,901 -- Connected, reading version...
2024-01-20 18:46:55,908 -- connected to target
2024-01-20 18:46:55,908 -- Version: CC3x00VersionInfo((0, 4, 1, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2024-01-20 18:46:55,909 -- This is a CC3200 device
2024-01-20 18:46:55,909 -- Switching to NWP bootloader...
2024-01-20 18:46:55,925 -- Switching UART to APPS...
2024-01-20 18:46:55,940 -- Resetting communications ...
2024-01-20 18:46:57,220 -- Uploading rbtl3100s.dll...
2024-01-20 18:46:57,221 -- Getting storage list...
2024-01-20 18:46:57,941 -- APPS version: CC3x00VersionInfo((0, 4, 0, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2024-01-20 18:46:57,941 -- Getting storage list...
2024-01-20 18:46:57,957 -- Getting storage info...
2024-01-20 18:46:57,973 -- storage #2 info bytes: 0x10, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0
2024-01-20 18:46:57,973 -- Setting raw read size to maximum: 4194304
2024-01-20 18:46:57,973 -- Reading raw storage #2 start 0x0, size 0x400000...
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
2024-01-20 18:48:04,255 -- Getting storage info...
2024-01-20 18:48:04,261 -- storage #2 info bytes: 0x10, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0
2024-01-20 18:48:04,261 -- Getting storage list...
2024-01-20 18:48:04,277 -- Reading raw storage #2 start 0x0, size 0x2000...
..
2024-01-20 18:48:04,403 -- [0] detected a valid FAT revision: 58
2024-01-20 18:48:04,403 -- broken FAT: (invalid header signature: 0x00000010, 0x00001040)
2024-01-20 18:48:04,403 -- Getting storage list...
2024-01-20 18:48:04,419 -- Reading raw storage #2 start 0x774, size 0x1774...
..
2024-01-20 18:48:04,520 -- selected FAT revision: 58 (active)
Traceback (most recent call last):
  File "/usr/local/bin/cc3200tool", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.10/dist-packages/cc3200tool/cc.py", line 1419, in main
    cc.read_all_files(command.local_dir, command.by_file_id)
  File "/usr/local/lib/python3.10/dist-packages/cc3200tool/cc.py", line 1278, in read_all_files
    fat_info = self.get_fat_info(inactive=False)
  File "/usr/local/lib/python3.10/dist-packages/cc3200tool/cc.py", line 1261, in get_fat_info
    fat_info = CC3x00SffsInfo(fat_hdr, sinfo, meta2, self._device)
  File "/usr/local/lib/python3.10/dist-packages/cc3200tool/cc.py", line 532, in __init__
    mirrored, flags, fname.decode('ascii'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcb in position 98: ordinal not in range(128)

So it seems as if the download of the raw flash content succeed, but the cc3200tool wasn’t able to get the content of the filesystem.

When I try to boot the box normally it also doesn’t boot . Seems like it’s running into some sort of bootloop.

CC3200 bootloader v1472818501 (09c6374) build: Fri Sep  2 14:15:01 CEST 2016 dl:1.2.0 sl:1.0.1.6 hw:tb-smt-16:3:24
loaded battery critical level = 3600
battery_level = 4780
Error [1] - ID=[-77] Sender=[6]
Error [1] - ID=[-78] Sender=[2]
ERROR: FsOpen (/sys/mcubootinfo.bin) -> -49
  /sys/mcuimg1.bin: -49
  /sys/mcuimg2.bin: -49
  /sys/mcuimg3.bin: -49
ASSERT (main.c @ 364): 
No bootable images found
Rebooting to complete WDT recovery...
Rebooting...



Did I manage to brick my box?
Or is there anything I can do?

Any help would be much appreciated.

Greetings…

It’s unlikely to brick it while reading.
I assume you disconnected VCC and SUP2 afterwards?

What does it do when you try to read the flash again?

Did you run any commands except of the first line?

I only tried 2 commands…
The first one was list_filesystem, which gave me the same error
as stated in the first log.
And the one which is stated in the first log. (read_flash / read all files)

Since I haven’t been able to collect the necessary backups I didn’t tried any writing command.

The second log (bootlog) is taken with only RX and TX pin connected. (After a full power reset.)

If I only try to read the flash everything seems to be fine.

cc3200tool -p /dev/ttyUSB0 --reset rts read_flash ./firmware.dmp.2 
2024-01-20 21:07:30,376 -- Connecting to target...
2024-01-20 21:07:32,750 -- timed out while waiting for ack
2024-01-20 21:07:33,021 -- Connected, reading version...
2024-01-20 21:07:33,027 -- connected to target
2024-01-20 21:07:33,028 -- Version: CC3x00VersionInfo((0, 4, 1, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2024-01-20 21:07:33,028 -- This is a CC3200 device
2024-01-20 21:07:33,028 -- Switching to NWP bootloader...
2024-01-20 21:07:33,044 -- Switching UART to APPS...
2024-01-20 21:07:33,059 -- Resetting communications ...
2024-01-20 21:07:34,340 -- Uploading rbtl3100s.dll...
2024-01-20 21:07:34,340 -- Getting storage list...
2024-01-20 21:07:35,060 -- APPS version: CC3x00VersionInfo((0, 4, 0, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2024-01-20 21:07:35,060 -- Getting storage list...
2024-01-20 21:07:35,076 -- Getting storage info...
2024-01-20 21:07:35,092 -- storage #2 info bytes: 0x10, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0
2024-01-20 21:07:35,092 -- Setting raw read size to maximum: 4194304
2024-01-20 21:07:35,092 -- Reading raw storage #2 start 0x0, size 0x400000...
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
2024-01-20 21:08:40,532 -- All commands done, bye.

Does the box boot without any pins connected? Maybe RX and TX interfere with something

No, it doesn’t.

The led ring is flashing green (it only lasts for a less than a second).
Then nothing happens for around 20 seconds.
And then there’s another led flash.

No sound, no reaction to Tonies.

Edit: Just checked it with TX and RX connected again:
The short flashing of the green ring occurs exactly in the moment when the box reboots.

It looks to me, that the filesystem is broken on the flash. It is very unlikely that you bricked it via reading it. If you manage to get at least the certificates from the flash (and better all the firmware related files) we can rebuild it.

Please do a second dump of the complete flash and check if the files are identical.

After that try to dump the important files of the box via read_file. A ready to go command can be found here.

Beside that I would be very interested in the dump to analyze the problem. Feel free to send it to me via PM or Telegram.

The cc3200tool isn’t able to extract the files from the flash. When I switch to single file reading
just the error changes.

 File "/usr/local/lib/python3.10/dist-packages/cc3200tool/cc.py", line 1403, in main
    cc.read_file(command.cc_filename, command.local_file, command.file_id)
  File "/usr/local/lib/python3.10/dist-packages/cc3200tool/cc.py", line 1150, in read_file
    raise CC3200Error(f"{cc_fname} does not exist on target")
cc3200tool.cc.CC3200Error: /cert/client.der does not exist on target

I tried this command for every file in the list of important files. None of them seems to exist.

All 3 dumps of the flash I made are identical. I will send you one after I finished this post.

When I open the dumps in a hex-Editor it seems, as if there might be some files in the dump…
There are also some TextStrings like “Boxine Factory SubCA” (along with a few other Strings which are needed to create a certificate) which I believe to be part of the Client Certificate…

I really, really doesn’t tried to write any files on the device.

Could it be related to the Version of cc3200tool?

Whats Version do you use? Have you tried the other available version? There are 1.1.0 and 1.2.0.

Have you tried to read the Flash from a different Host/PC?

Just to give you some additional ideas.

Small Update:

It seems to me that I was able to export the certificate files from the box image using binwalk.

I’ve never run a teddycloud before, but the log files look plausible after I copied the extracted certificates into the appropriate directory.

In the meantime, 0xbadbee wrote a patch for the cc3200tool which should make it possible to extract files from within a bad filesystem by it’s id.
I will try this next, to also retrieve the other important files from the box.

Thanks to this amazing community.
You people are awesome!

Can anyone of you confirm that this log from the teddycloud locks like an error-free communication and does this mean that my client-Certificates are fine?

INFO |tls_adapter.c:0201:read_certificate| File 'certs/client/ca.der' detected as DER style CERTIFICATE
INFO |tls_adapter.c:0201:read_certificate| File 'certs/client/client.der' detected as DER style CERTIFICATE
INFO |tls_adapter.c:0205:read_certificate| File 'certs/client/private.der' detected as DER style RSA PRIVATE KEY
--------
NFO |cloud_request.c:0158:web_request| Connecting to HTTP server prod.de.tbs.toys:443...
INFO |cloud_request.c:0208:web_request|   trying IP: 3.69.182.181
INFO |cloud_request.c:0036:httpClientTlsInitCallbackBase| Initializing TLS...
INFO |cloud_request.c:0071:httpClientTlsInitCallbackBase| Initializing TLS done
INFO |cloud_request.c:0308:web_request| HTTP code: 200
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Server = openresty
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Date = Sun, 21 Jan 2024 15:02:03 GMT
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Content-Type = text/plain; charset=utf-8
INFO |cloud_request.c:0339:web_request| Content-Type is text/plain; charset=utf-8
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Content-Length = 10
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Connection = keep-alive
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: cache-control = max-age=0, private, must-revalidate
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: x-request-id = F6xk699PhajrNAQVBsGx
INFO |handler.c:0061:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: NULL
INFO |cloud_request.c:0386:web_request| Response: '1705849323'
INFO |handler.c:0225:cbrCloudServerDiscoPassthrough| >> cbrCloudServerDiscoPassthrough
INFO |cloud_request.c:0417:web_request| Connection closed
INFO |handler_cloud.c:0038:handleCloudTime|  >> respond with current time
INFO |mqtt.c:0684:mqtt_init_box| Skipping client 'Toniebox' (cn: 'default')
INFO |cloud_request.c:0158:web_request| Connecting to HTTP server prod.de.tbs.toys:443...
INFO |cloud_request.c:0208:web_request|   trying IP: 3.74.99.150
INFO |cloud_request.c:0036:httpClientTlsInitCallbackBase| Initializing TLS...
INFO |cloud_request.c:0071:httpClientTlsInitCallbackBase| Initializing TLS done
INFO |cloud_request.c:0308:web_request| HTTP code: 200
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Server = openresty
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Date = Sun, 21 Jan 2024 15:02:49 GMT
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Content-Type = text/plain; charset=utf-8
INFO |cloud_request.c:0339:web_request| Content-Type is text/plain; charset=utf-8
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Content-Length = 10
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: Connection = keep-alive
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: cache-control = max-age=0, private, must-revalidate
INFO |handler.c:0056:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: x-request-id = F6xk9rdX7jm0bYcO0Eex
INFO |handler.c:0061:cbrCloudHeaderPassthrough| >> cbrCloudHeaderPassthrough: NULL
INFO |cloud_request.c:0386:web_request| Response: '1705849369'
INFO |handler.c:0225:cbrCloudServerDiscoPassthrough| >> cbrCloudServerDiscoPassthrough
INFO |cloud_request.c:0417:web_request| Connection closed


The box is booting and working again :partying_face:

Most of the credit goes to @0xbadbee without whose tireless help the box would certainly not be running…

Thank you so much for the great support.

For documentation purposes, I would like to write down what
has happened and how we were able to determine it and bring these box back to life:

  1. The file system of my Tonibox was screwed up…
    Unfortunately, it was not possible to reconstruct how this happened

  2. I created a FlashDump from my box and searched it with binwalk…
    binwalk was able to save my certificates from the FlashDump with automatic extraction.
    Of course you can also simply read them from the dump in a HexEditor…
    But using binwalk was way more convenient.

  3. At the same time, @0xbadbee “just” wrote a patch for the cc3200tool and uploaded it to the dev branch, which can extract files based on their file ID with some sort of tolerance against bad file tables…
    Thanks to the patch we were able to recover many more files from my image.

  4. I was able to retrive the initial setup AccessPoint SSID from my cell phone, which I used for the first setup of the cloud connection. I was then able to enter the name in /sys/ap.cfg using a HEX editor, for which @0xbadbee sent me a template-file.

  5. The rest was piecing together several system images that @0xbadbee provided, the saved files from my file system, the service packs downloaded manually from TI (exact version ota_1.0.1.13-2.11.0.1.ucf, only with exactly this one ( neither later nor earlier version) my box was able to establish a WLAN connection again / communicate with the cloud server…

  6. Then , in this order, format the flash memory install the service pack, copy the file system over, reboot

cc3200tool -p /dev/ttyUSB0 --reset rts format_flash -s 4M write_file --signature ./spti/ota_1.0.1.13-2.11.0.1.ucf.signed.bin ./spti/ota_1.0.1.13-2.11.0.1.ucf /sys/servicepack.ucf write_all_files ./new_fs_2/

Thanks to all the other guys trying to help me out.