sorry, with all respect but I am not sure if you know about what you speak ...
- Nexttion HMI Displays are based on STM32 / GD32 Cortex Core MCU's ...
- Firmware is flashed with code-protection fuse set ...
- compiled TFT files are encrypted native code files ...
- Nextion Displays are local used, connected via RS232 interface, where is the need to encrypt the serial local datastream to your remote mcu?
- every flashed TFT can make any display unique, just choose an ID. Your TFT is not saved in any eeprom ...
- a TFT is native STM code, flashed directly into your STM ...
You surely can replace your STM, or even reprogram it, but then you have nolonger a Nextion HMI Display, you just have a dumb black LCD panel ... and we won't give you the bootloader firmware to reactivate your Nextion again ... :-)
About cloning, to clone a STM is the same hard or easy as cloning a PIC, AVR, LPC or any other MCU out ...
That has nothing to do with Nextion displays ...
And what kind of security do you use for a monitor?
As far as I know my desktop monitors are also not encrypted.
- actually they are not, there is no uncertainty about it.
1) Sorry, Encryption can indeed be programmed with out XOR AND OR
a bit more processing indeed, but hardly impossible.
2) Every Nextion has unique serial number
Basic models have no external EEPROM but have Unique Serial Number.
but is this now stored in invisible non-existent external EEPROM?
Nextion is not lacking 100% security with 0% security
- but it seems your understanding of security is indeed less than 100%
Replacement of EEPROM does not change Unique Serial Number
- 1K EEPROM is 100% user data storage.
Before bashing Nextion for your lack of understanding
maybe investigate before you spout.
You will look less like an ass because of your ass-u-mptions
Let me to rephrase the question, after contacting the hardware guys:
We changed the external eeproms/flash (250128 winbond) of several displays (NX4832T035_11) and the serial was following the chips, simple like that. I repeat, we removed the chips, swaped and soldered again and got the same information (than the "connect" command will return), in both cases even when the boards were different. So the serial is stored in that ic.
Question: instead storing the serial info, etc. in the same eeprom than the display TFT code, could you store it in the mcu cortex itself? Separating this info allow to do something about security (not 100% safe since you always can move all the ics from one board to another), but much more than now.
We talk about this could minimize the issue; minimize, not removal. It's important. From a bussiness point of view, it is a major issue.
I hope the main issue now it's clearer (forget about the encryption, that's for another day).
Ps: It's not a competition to see who knows more or has a bigger ego. Gerry Kropf could be confused about how I exposed the question, so I rephrase it. Patrick Martin has no manners simply.
I expect respect because first I deserve respect, and second I haven't been irrespectful with anyone. Some comments are out of tone, only intending to be offensive for free. You decide how the world will see you.
It's not kindergarden
Respect and Manners
- The first thing you ever posted is to blame Nextion
- made some accusations without basis
- calling a flash an eeprom is only minor
- say encryption can not be programmed and 0% security
- well, your design is flawed - security can be had.
Blaming Nextion for a lack of understanding or skill is
perhaps in the wrong manner, and I responded indeed.
Not like I want other readers thinking wrong statements is fact,
So since it's not kindergarden, I figure turnaround is fair play.
Unique Serial Number is Itead application, not user application.
During mass TFT upload on commercial end
the S/N may indeed be useful for tracking and progress.
But therein lays the end of Nextion's Unique Serial Number
First design flaw is to think this Serial Number has user use
Second to base ones user design on this Serial Number
Third flaw might be to void your warranty but only close to
Fourth expecting to store sensitive data in a display.
Nextion is an HMI device Human Machine Interfacing
Press/Release Event of what component sent to MCU
MCU to display status/progress to user on HMI device
As an HMI device, there is no need for "encryption"
- else the HMI is unusable to the end user
Do we now find a way to encrypt the BRB Button?
or look for ways to encrypt a dial? an LED?
Now even though I can put AES128 straight in Nextion Logic
- warping the use of a device only because you can
does not make it in the right manner at all.
- this is just wrong, in the wrong manner
The TFT file is the User's HMI design, meant to run at runtime
- again there is zero need to place sensitive data in the HMI
- when it is designed as a template for data/text
the MCU will send data and text as required
- and again, the user of the HMI needs to be able to read
the provided choices and status/alerts - or such is useless
So what do we have left ... an RTC and an EEPROM
- I'll spare making fun of the encrypted RTC
- so that leaves the EEPROM
- the data stored in EEPROM does not have to be sensitive
- this is user design, certainly not a security conscious design
- and EEPROM data can indeed be encrypted when at REST.
So are we now worried about Serial-MCU communications
- As stated, encryption can indeed be programmed if desired
- but really not needed in a touch panel, wrong manner.
MCU side encryption is user domain
- it is the user that chooses the MCU, the compiler, language
- and indeed encryption can be had
Assumptions that security is unachievable and blame Nextion
- certainly in the wrong manner to come out of the gate swinging.
- distort an HMI device to become an MCU, again a design flaw
A proper secured design will not put sensitive data on a display
A proper secured design will handle security MCU side
- you choose that MCU,
- you choose how to design for your security requirements
But instead blame Nextion when understanding or skill is missing.
As a Feature Request
- we won't deplete firmware space and infringe on user HMI space
for the needs of a few and useless for the needs of the masses.
- and also not when such shouldn't be on the HMI in the first place.
Nextion is an HMI device, not a user secondary MCU
- even if I can make it do some amazing things. Wrong manner.
and at which point will an encrypted serial data-transfer protect the design (including your logo)?
to copy a design, you only need to see it ...
again, encrypting your serial data-stream wont protect your design in any case ...
to copy a design, you even don't need to know the internal names of anything used ...
so, where is the need of encryption in terms of make your HMI more save ...
in worst case, you copy the winbond, for use the copy again in a Nextion display?
Winbond flash without Nextion STM part makes no sense ...
It's not so far-fetched
I'm listening ...
Imagine for a moment that you design a product for your company, with your logo on the screen and with the appearance of your company ...
Been done, keep going ...
Now goes a bad person and spies transparent communications from the MCU to the nextion and gets the names of the controls and others ..
Now you're not listening
As stated can indeed be secured, your design is flawed
Do you think you can really crack AES128 anytime soon?
With this information you can program a different visual interface with your company logo and a totally different appearance without the author's permission.
No intelligent information garnered, just encrypted garble as told
But your logo is indeed now on new product - visual is necessary
The nextion are still young .. think that they are unbeatable and refuse to attend the improvements that the end users who are the ones who are going to decide for a product or another is not a good company policy.
Encryptation communications solve and protect your company..
Encryption can indeed help, but flawed security designs with always undermine
Nextion displays is oriented for professionals?? or is only use for arduino generation?
So you are now back to bashing, hmmmm?
Yes, protect entire interface of spy data and do not make cloning viable.
Cloning is already viable. So protect visual is not doable.
Hence your suggestion is somewhat flawed.
But as I already stated above
- security with Nextion can indeed be had - not in the manner you speak of
Encryption is good per se. But it should stay where it really makes sense ...
- on the interface side, I don't see this
- on the communication side, just use a serial to WIFI Lantronix Matchport or similar, and you have all security you like ...
If somebody has hardware access, your best encryption won't help aginst copy ...
Where I live, it cost me around 20US$ to physically open a PIC, AVR, STM, ... and read out the die directly bit for bit with an microscope ... and get the final working hex file ready to flash ...
Perhaps Security is one of the more advanced concepts to be mentioned.
- discussion of security could even have been an interesting topic to debate.
Bashing Nextion is not
- yet when people run out of supporting arguments,
they unfortunately they resolve to bashing Nextion.
- worse indeed is to lead with the bashing.
- The majority of Nextion volume is indeed commercial, not hobby
- Nextion is an HMI device, not an MCU, and not a primary display.
- Human Machine Interfacing (HMI) is not a hobby practise/concept
but indeed industrial/commercial in nature.
- Nextion is two wire TTL Serial, ASCII text based instructions
As such Nextion can be used with 10,000+ MCU types
- any with at least one or more hardware UART module
or capable of bit banging two digital pins (not 36 pins)
- using any of 130+ programming languages, users choice.
Arduino is certainly not the primary MCU used
- there is nothing wrong in also selling to the hobbyists
- there is nothing wrong in providing a public forum
- absolutely such a small public forum will have hobby projects
posted and coding questions presented
... as if anyone expects full commercial product designs and code
to be posted to a public forum from commercial endeavour ??
I think when the conversation is about someone not making a design
the same or similar, I highly doubt full code and HMI will be posted.
- any other contributions made to the community? examples, tools?
- go with what one sees, there's no other posts to support such theory.
Copy costs less than teenagers weekly allowance.
But for security, there must be purposeful programming
- XOR, AND, NOT, OR a must to achieve?
No, these can indeed be built if missing and used.
If security needed and one needs a missing NOT function
- build it, use it and done.
- such a commercial project does not miss out on security only
because a function is not pre-built
To identify a Winbond Flash IC, but not identify the onboard MCU IC
- so an STM32F030C8T6 with 8K SRAM and 64K Flash
- but a promised 3584 SRAM bytes dedicated to the User HMI Design
- so hey, when everyone is suppose to be such great MCU programmers
where does the requested fit without breaking existing user HMI designs
And without that conversation, is there much point to discuss
perhaps, more understanding is required and less Nextion bashing
Itead has implemented many user requests made by the users
- making such loose statements like
" still young .. think that they are unbeatable and refuse to attend the improvements ..."
- Sorry, this is indeed in the wrong manner.
- where is the sense to finally squeeze native AES128 or RSA-2048 public key
into an 8K STM and then have no resources to load and run the user HMI design ??
Big talk about securing the Nextion device from all evils (can not be done)
and then state (even with a basic level, xor, etc)
XOR will not provide for security, such is not an encryption
- so a half-baked implementation is worse than none
- reread to where if really needed, one builds and uses it and doesn't wait
so XOR is not "needed", especially to clog the user HMI's that have no need.
- those that needed it, already have it done.
But I will argue that security requires a solid design implementation, not flawed.
going half-baked gives a false sense of security - of the worst kind.
Again, those that needed it, already did it
is their code available for this? No. Is yours? Right.
- their code, just as yours is, it's commercial in nature - certainly not for free.
But even having their code with less than "needed" understandings ...
leads to improper implementations ...
- only a feeling of secure - but NOT secure
(Nextion has such and such security, but I never programmed against X threat)
So when one understands the threats they are trying to prevent
- they don't put sensitive data in harms way
- they implement their designs to address the threats
- they already coded it, not needing another native command to do so.
So here is a partial list of Features Requested by users that are now implemented.
Editor enhancements requested by users Show the x,y position when designing Import GIF picture resources (non-animating) Reorder Picture ID Click to get larger view of image Working panes resizable Select Multiple components Keyboard Shortcuts for Cut/Copy/Paste HMI name in Nextion Editor Title Bar Component Layering with Bring Top and Bring Bottom Change Drawing order of Objects “Do you want to save Changes” Undo and Redo Check for new Versions from Menu View per version change list before update Align Options from Tool Bar Run more than on instance of Nextion Editor Horizontal/Vertical upgraded to 0°, 90°, 180° and 270° Import a page from another project Escape support for newline (supported with \r) Click compile error to jump to error in code Font enhancements requested by users Cyrillic Text Support (supported with iso-8859-05) Korean Text Support (supported with KS_C_5601-1987) GB3212 Text Support (supported with GB2312) Hardware enhancements requested by users Bezel files for Nextion Models Capacitive Touch with Enclosure Nextion IO Adapter Command and Coding enhancements requested by users Improvements to the if statement (else, else if, nesting) Create Graphs and Charts from GUI commands pic, picq, xpic for pictures over serial cirs for filled circle rest command to reset Nextion device addt to add multiple waveform values cov command to convert .txt to .val Component show/hide (vis command) Global support to change value on another page Component touch enable/disable (tsw command) Inc/Dec counter solely within Nextion HMI Send x,y touch coordinate over serial (sendxy variable) Component enhancements requested by users password masking on-screen keyboards enable/disable component touch (tsw command) trigger component event (click command) Checkbox and Radio Buttons implemented Barcharts (fill command and Progress Bar) backgrounds of solid colors/crop image/image Scrolling Text marquee component Number component to support negative and positive Text with solid background color Added .txt attribute to Dual State Letter spacing (.spax and .spay) Multiline support Arduino support (big difference in 0.70 and 0.90) more access to attributes change component colors over serial Ongoing increases of Iteadlib’s capabilities, the effort continues Raspberry PI supported via Itead’s Segnix and Iteadlib
But perhaps when one wants to bash Nextion without understanding
there is a level of "right back at you" that is indeed deserved.
For those that bothered to use the Search Bar to look for related topics
they would have seen I already let the cat out of the bag (Jun 7, 2017)
(should not have) that some of these functions are up and coming ...
When one starts bashing Nextion because one doesn't bother to read ??
I'm sorry, but I just can't help but indeed respond.
When one doesn't get their way
- make a statement we don't listen to users ... just the wrong way
Some customizations can even be discussed when commitment is given
- and by commitment given ... is when order completes
not on future hopes and dreams, but on actual quantity purchase
- (quantity purchase in China is not defined as 1 dozen for the record)
So, much of the "Itead doesn't listen" is customer didn't want to pay for.