Flashing (maybe) gone wrong - did I brick my box?

Stff0r · January 14, 2024, 9:25pm

Hi there!
I tried to change the certificates on a V3 box and I’m not sure if I bricked it now. The extracted files from flash look strange to me. The box now gives an Eule error.

What I did in detail:

Connected SOP8 clamp with pico-serprog (GND, CS, SI, SO, CLK)
flashrom -p serprog:dev=/dev/ttyACM0:115200,spispeed=1M -r cc32xx-flash.bin
→ were these the correct settings? speed?
→ flashrom gave a message that the chip isn’t recognized but can be read out
→ $ flashrom --version: flashrom 1.4.0-devel (git:v1.2-1388-gbb8e6f90)
→ cc32xx-flash.bin is 4194304 bytes
cc3200tool -if cc32xx-flash.bin -d cc32xx read_all_files extract/
→ checked certs, looked ok. Copied to teddycloud.
cc3200tool -if cc32xx-flash.bin -of cc32xx-flash.customca.bin -d cc32xx write_file <teddycloud/certs/server/ca.der> /cert/ca.der
→ the command in the wiki did not include the “write_file” command, but without this the tool did not work at all
flashrom -p serprog:dev=/dev/ttyACM0:115200,spispeed=1M -w cc32xx-flash.customca.bin
→ were these the correct settings? speed?
→ flashrom gave a message that the chip isn’t recognized but can be written
→ verify after write was ok
setting DNS record for prod.de.tbs.toys to teddycloud IP, in pihole
teddycloud log does not show a connection attempt from Box and the Box has the Eule error whenever a new Tonie is placed.

What I did further:

Reconfigured Wifi settings (holding both ears and enter wifi password again) → no change
Checked the extracted files from flash: While the certs looked OK, some other files seem to have only garbage in it, e.g. settings.cfg does not contain readable content, is this ok?

Did something fail during read / write of the flash?
I haven’t tried flashing back the unmodified .bin, to not “destroy” more…

Any tips or hints what I can check are very welcome

Thanks!

0xbadbee · January 15, 2024, 7:32am

Thank you for the hint, I have fixed that in the wiki.

These settings really depend on the device you use. Generally, the speed doesn’t matter, as long it works for you. If you have problems dumping/flashing you can always reduce the speed.

You should also set the rtnl.bxcl.de domain
Beware that teddyCloud itself should have a different DNS Server, so it can access the domains of the boxine cloud.

This is okay. It is binary anyway and may be encrypted on the cc3235.

Everything looks fine for me. If the flashing had failed, the box wouldn’t boot any more.
It will be an issue with the box not reaching teddyCloud. So check your network.

Stff0r · January 15, 2024, 9:27pm

Thanks! I am a bit relaxed now that flashing obviously worked

Yes, did that.
In teddycloud I have set the IP for now, as I haven’t found a way to assign different DNS Servers.
Reaching boxine cloud seems to work, log file:

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 3.74.99.150: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
cyclone/cyclone_crypto/cipher/aes.c:496:35: runtime error: left shift of 233 by 24 places cannot be represented in type 'int'
cyclone/cyclone_crypto/cipher/aes.c:501:35: runtime error: left shift of 231 by 24 places cannot be represented in type 'int'
cyclone/cyclone_crypto/cipher/aes.c:506:35: runtime error: left shift of 160 by 24 places cannot be represented in type 'int'
cyclone/cyclone_crypto/cipher/aes.c:511:35: runtime error: left shift of 160 by 24 places cannot be represented in type 'int'
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 = Mon, 15 Jan 2024 20:54:07 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 = F6qgpt7NIWBhwd0B4y-h
INFO |handler.c:0061:cbrCloudHeaderPassthrough()| >> cbrCloudHeaderPassthrough: NULL
INFO |server.c:0570:server_init()| 1 open HTTPS connections
INFO |server.c:0570:server_init()| 0 open HTTPS connections
INFO |server.c:0570:server_init()| 1 open HTTPS connections
INFO |server.c:0570:server_init()| 0 open HTTPS connections
INFO |server.c:0570:server_init()| 1 open HTTPS connections
INFO |server.c:0570:server_init()| 0 open HTTPS connections

What are those cyclone errors and the 0/1 open HTTPS connections?

Somehow it seems that the box doesn’t use the pihole DNS. But pinging prod.de.tbs.toys from the computer correctly leads to teddycloud IP

0xbadbee · January 15, 2024, 9:35pm

The errors are no problem.
The http connection log just show the active connection count including your web interface connections.

Now you’ll need to check your network for the source of the problem.

Stff0r · January 22, 2024, 9:31am

Hi,
I have checked with wireshark, network seems to be fine but the box gives an error with the certificate.
Changed IP to names to make it easier to understand:

204	15.443124	<TONIEBOX>	<PIHOLE>	DNS	96	Standard query A prod.de.tbs.toys
217	15.540680	<PIHOLE>	<TONIEBOX>	DNS	112	Standard query response A <TEDDYCLOUD>


252	15.757748	<TONIEBOX>	<TEDDYCLOUD>	TLSv1.2	210	Client Hello
254	15.758279	<TEDDYCLOUD>	<TONIEBOX>	TCP	80	https > 57900 [ACK] Seq=1 Ack=137 Win=30016 Len=0
255	15.758460	<TEDDYCLOUD>	<TONIEBOX>	TLSv1.2	153	Server Hello
259	15.761781	<TEDDYCLOUD>	<TONIEBOX>	TLSv1.2	209	Certificate
260	15.795900	<TONIEBOX>	<TEDDYCLOUD>	TLSv1.2	81	Alert (Level: Fatal, Description: Bad Certificate)

The ca.der that was generated by teddycloud on first run, is dated 2004-01-03 while the wiki says certificates shall have starting date 2015-11-03. Is that an issue or is there something else I should check?

0xbadbee · January 22, 2024, 11:02am

You may check the time in your container. Maybe there is something off.

The wrong date is very weird, as it is a fixed value in the code.
You may try to regenerate it and check if the date is the right one then.

Stff0r · January 22, 2024, 1:06pm

Date in the container is fine
root@ghcr:/# date
Mon Jan 22 12:58:17 UTC 2024

I tried to have it generated again, but it is always “today - 20 years” (first teddycloud run was on 3rd January 2024 → cert 2004-01-03).

When I use ./gencerts.sh (after installing faketime) this will create certs with 2015-11-03.
Left one created by teddycloud container startup, right one created with ./gencerts.sh

0xbadbee · January 22, 2024, 1:20pm

You can use the certificates created by ./gencert.sh for teddyCloud and for your box. Does this work?

I am going to fix the date for the code within teddyCloud

Stff0r · January 22, 2024, 3:15pm

YES! it does!

Am I the only one with this bug or do the non-V3 boxes with custom firmware don’t care about the cert date?

0xbadbee · January 22, 2024, 3:56pm

The none v3 boxes worked fine. So this is cc3235 specific. It is already fixed in the develop build. Thank you for digging in.

0xbadbee · July 15, 2024, 6:40pm

3 posts were split to a new topic: CC3235 TLS Alert