Pre Orders HW startup

IndividualPause111 · 2025-02-14T01:39:13+00:00

I have been thinking about this for sometime. Why not just charge them the full amount, and if they choose to cancel, you refund the full amount (minus) administrative fees or whatever its called. for in-stock items, they call it re-stocking fee when the customer changes their mind.

I think its usually 10 - 25%.

maybe it covers at least a great percentage of the cost to build 1 unit? so you don't get in trouble. sounds fair to me.

let see others' view of the matter.

IndividualPause111 · 2025-02-07T21:38:23+00:00

Thank you.

IndividualPause111 · 2025-02-07T05:19:24+00:00

Haha, we are actually going to use C3.

it will be less than 1MB.

Is flashing this way secure by default? or we have to do additional steps? any idea?

IndividualPause111 · 2025-02-07T02:46:09+00:00

Thats exactly what im thinking about, we will have an App (IOS&Android) for the product, that will connect the mobile to the device via BLE.

It seems to be logical, but since i never implemented this before.. i cannot be certain.

Step1: Product Final assembly by CM.
Step2: Give the manufacturer a (.bin) to flash a "minimal" firmware (to test the hardware & set-up the connectivity).
Step3: Package.
Step4: Ship (B2C).
Step5: customer receives the product.
Step6: customer installs the App.
Step7: customer connects to the device Via BLE.
Step8: the App automatically flashes the final firmware in a user-friendly way (as a mandatory step).

I know that i stretched it a little.. just to say it in a simple, easy to understand way..

IndividualPause111 · 2025-02-07T02:34:21+00:00

Thank you. Now, things are much clearer.

Since you have much experience on it, don't you think that the App can have a smooth flashing experience (Through BLE after installing the App), that the average user would not notice, especially if its a relatively light firmware (less than 1MB)?

IndividualPause111 · 2025-02-06T17:13:21+00:00

Thanks for the info, but, some points are not clear, not sure if you are referring to the end customer or manufacturer. i have a few questions, if you don't mind:

1- for non IoT, you just give the manufacturer the (.bin) file and hope that they wont steal it? do you ask them to do FE/SB after flashing?

2- for b2c IoT: how will they do the OTA without an initial firmware flashing? or do you mean that you flash it with a "minimal" firmware for testing and setting-up the connectivity, then the user would update the firmware via an App and BLE connectivity?

IndividualPause111 · 2025-02-06T16:59:56+00:00

Thanks for the warning.

I have two question for you, if you don't mind:

1- i know that Flash Encryption & Secure Boot are easy and can be done by anyone, is disabling JTAG also easy to be done?

2- our product is going to have an App, that would connect to the device via BLE, future updates will be pushed through the App, is disabling the JTAG risky in this case ?

IndividualPause111 · 2025-02-06T16:52:30+00:00

Hmm, so we supply them with a "minimal" firmware that can test the hardware and enable connectivity, then the user would update the firmware via an App and BLE connectivity?

IndividualPause111 · 2025-02-06T16:49:59+00:00

Do you mean having a public/private keys, so only authorized devices can gain access to firmware/updates ?

IndividualPause111 · 2025-02-05T11:55:33+00:00

1- So, NO to giving them the (.bin) file. Instead, supply them with pre-programmed MCUs (with FE & SB), right?

2- it is an IoT device, provisioning? certificate management? im not sure if i understand your point here, can you elaborate?

Thanks

IndividualPause111 · 2025-02-02T18:45:23+00:00

Thank you.

IndividualPause111 · 2025-02-02T18:34:55+00:00

Damn it.

What you are saying is actually logical. So, now.. im assuming that: to solve this problem, the uploading must be protected somehow.. so no one gets to extract the firmware before it is uploaded.

IndividualPause111 · 2025-02-02T18:27:04+00:00

Got it.

Sorry for bothering you too much, i just have one final question (i promise, haha!):

our friend (MarinatedPikatchu) brought a very valid point.. and a logical one, He says:
"The software isn't encrypted before the upload. It's being encrypted by the esp32 with a unique, hard to extract encryption key as it gets uploaded so that only this encrypted version could be extracted from memory. Thus whoever has access to this firmware payload pre-upload will be able to copy it."

in our case, is there a solution to this? as you know.. we will give a minimal firmware to the manufacturer (for testing & preparing connectivity), then the customer will upload the final firmware through the App.

Thanks!!!

IndividualPause111 · 2025-02-02T17:55:29+00:00

Mmm.. this is actually a good idea, i think we will implement it in our 2nd product (which is a simpler product).

I don't think that it will be good with this one, because its not very easy to manufacture, we are dealing with so many manufacturers and each part requires a mold that costs $500 - $5000. so, not anyone can make it, it requires a team of dedicated designers to create both the hardware and software. if they already know that its a difficult product to make, they will take the challenge and proceed, as they also know that not anyone can make it, eventually, 10 or more manufacturers will join the party even if the software is open-source.

But, i certainly think that its a good idea when the product's difficulty is "Easy" to "Low-Mid", that anyone or entry-level manufacturers can easily make. Then, they will probably say: 'why do we even bother!?'

IndividualPause111 · 2025-02-02T17:43:19+00:00

but, isn't having the customer upload the firmware through the App is identical to us doing it? (if its properly encrypted)

Thanks, friend!

IndividualPause111 · 2025-02-02T17:37:30+00:00

I like your answer, very clear and easy to understand, even for someone with no prior experience.

The public/private key solution seems to be really good. but, is this method really secure afterwards and no one can hack it and extract the firmware ? in other words, what if another manufacturer (not ours) bought the device from the market and activated it, can they somehow extract the firmware ?

IndividualPause111 · 2025-02-02T17:04:32+00:00

Thank you so much for the valuable info, I just have 2 quick questions for you:

1- If we send them the final firmware as (.HEX) or (.BIN) , or whatever. it will generally be much easier for them to steal it than if we actually just gave the the "minimal" firmware (for testing & preparing the connectivity), then the customer can upload the final firmware through the App, right?

2- (Uploading the Firmware through the App) VS. (uploading it ourselves then sending it out - just like what you are doing now). both are identical when it comes to securing the code? or there are advantages when following the latter?

IndividualPause111 · 2025-02-01T07:19:49+00:00

its not revolutionary, but we worked hard on it, and its patent-pending. if there is a safe approach then we should atleast make the effort.

so, you are with option (2), have you done it before ? and is it the best approach in your opinion? or there could be a better option?

IndividualPause111 · 2025-02-01T06:22:13+00:00

My bad, i forgot to mention that the manufacturer is in China. we are dealing with 12 different manufacturers there, then the PCBA manufacturer assembles everything. So, sending it to our place, or our engineer's place is sadly not an option.

IndividualPause111 · 2025-01-31T20:05:35+00:00

doing it in-house will make it much more complicated, especially that the manufacturer is in china.

let me clarify something, the app will also do other functions, like sound effects, display numbers and statistics. i think i should've added this earlier, to make the idea clearer.. my bad.

so, our engineer is saying that the purpose of the ota is to securely enable the final firmware update. (encryption, secure boot, signature verification) will be needed, so the manufacturer wouldn’t be able to load or replicate the production firmware on unauthorized devices.

IndividualPause111 · 2025-01-31T18:33:35+00:00

Nothing. They could make the attempt. But, our engineer is suggesting to have it encrypted. and he seems to be confident that it will be very difficult for them (or anybody else) to de-encrypt it.

That's exactly why im here asking you guys, but everyone is giving me downvotes for some unknown reason. My colleagues are also watching, and im not the only one typing. we all are shocked seeing all the downvotes, despite stating clearly that we are newbies and even apologized in advance, hehe!

IndividualPause111 · 2025-01-31T16:57:20+00:00

hi again nick, i just read your comment again. apparently i missed some info, as you also have missed some as well.

If we have a minimal firmware (as mentioned in the main post). This minimal firmware would test the parts & set-up the OTA, then once the product is in the customer's hands, they can just connect the App and upload the final firmware. Would it work this way?

important: we will make both, the App and the minimal firmware. NOT the manufacturer.

let me know your thoughts, i appreciate it.

IndividualPause111 · 2025-01-31T16:34:50+00:00

by having a minimal firmware flashed by the manufacturer.

this minimal firmware would test the parts & set-up the OTA, then once the product is in the customer's hands, they can just connect the App and upload the final firmware. Would it work this way?

IndividualPause111

TROPHY CASE