zasto said:Try this link:
https://www.diolan.com/pic/bootloader.html
nandhu015 said:I think it is not possible to use usb for this purpose like serial port or parallel port.
zasto said:PIC18F3K50 ?? Which uC is this?
Anyway, pleas inform us if you succeed in connecting uC for programming this way.
In the meantime, just some thoughts:
* if you are afraid that your intellectual property can be stolen in the factory that is producing your product (China rings me some bells), just program the controllers with a bootloader and program the firmware at your premises when the manufacturer delivers the finished product,
or:
* hire a person that you trust in, give him/her a good salary and bind him/her with a well written nondisclosure agreement (financially heavy in case of your intellectual property 'leaks').
IMHO it is much cheaper to put a 5-pin ICSP connector on your board than USB connector (pricewise).
zasto said:But be aware, there are companies that DO the reverse engineering of the microcontrollers.
I guess that you are not making lunar landing moduleThe reason I don't want to use even a bootloader, is the theoretical risk that a malicious producer may replace the bootloader with a malicious bootloader, seemingly acting the same way but manipulating the firmware, possibly filtering it or adding backdoors.
You can not combat against reverse engineering of your product, please check your private messages.I know, but the reverse engineering of a single unit is not a problem in my case. But out of curiosity, are you talking about cracking the code protection? Is there anything to be done to combat this?
zasto said:The reason I don't want to use even a bootloader, is the theoretical risk that a malicious producer may replace the bootloader with a malicious bootloader, seemingly acting the same way but manipulating the firmware, possibly filtering it or adding backdoors.
I guess that you are not making lunar landing modulethat should be totally tamper proof . Mainly, backdoors are always WRITTEN in your software (anyway that is a way that I do, just for tamper proof)
zasto said:You can not combat against reverse engineering of your product, please check your private messages.
You have already seen the link that I've sent you, so you figure out how the controllers are secure, even with protection switched onInventorPatentor said:Well, I suppose using the code protection is one way of combating it. But is it not water proof... The important thing is not whether a 100% secure device is possible, but that more secure is better than less secure, and to choose the more secure.
zasto said:What I meant when I wrote that I am leaving the back doors in my software, is that when I design communication devices, there is always byte sequence that triggers the microcontroller to erase it's own program memory
If you analyze the bootloader code, you will see that it does nothing more than receiving bytes from COM/USB port and writes them in the program memory of the uC. By default I DO trust the bootloaders, it is very hard to put malicious code there.
I think that you are much paranoic on the bootloader topic.
Scenario:
Board with untrusted (possibly modified bootloader) arrived to you.
You write your software for your device but with some EXTRAs: Short piece of code that will on first run, after being uploaded to the micro, overwrite the untrusted bootloader with the one that should be there in first place, write a flag (sowhere in the flash program memory that the correct bootloader is in place) and you're done. No "bad" bootloader, your paranoia is satisfied.
zasto said:With that kind of reasoning, your product will never see the daylight.
Bootloader only receives the data from serial port or USB port and writes that data to the program memory of the controller. After the download is done, it transfers the control to your program, from that point YOUR program is in control.
I guess that your program for uC is not like the Great M$ Virus.
zasto said:Will comment no more, it will take us nowhere.
radix DEC
LIST P=16F887, F=INHX8M ; change also: Configure->SelectDevice from Mplab
; auto-start at 4MHz internal osc
xtal EQU 4000000 ; you may also want to change: _HS_OSC _XT_OSC
baud EQU 19200 ; standard TinyBld baud rates: 115200 or 19200
;xtal EQU 4000000 ; you may also want to change: _HS_OSC _XT_OSC
;baud EQU 19200 ; standard TinyBld baud rates: 115200 or 19200
; The above 3 lines can be changed and buid a bootloader for the desired frequency (and PIC type)
;********************************************************************
; Tiny Bootloader 16FxxxA series Size=100words
; [email]claudiu.chiculita@ugal.ro[/email]
; [url]http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm[/url]
;********************************************************************
#include "../icdpictypes.inc" ;takes care of: #include "p16fxxxA.inc", max_flash, IdTypePIC
#include "../spbrgselect.inc"
#include "../bankswitch.inc"
#define first_address max_flash-100 ; 100 word in size
__CONFIG _CONFIG1, _LVP_OFF & _FCMEN_OFF & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & _MCLRE_ON & _PWRTE_ON & _WDT_OFF & _INTRC_OSC_NOCLKOUT
__CONFIG _CONFIG2, _WRT_OFF & _BOR21V
errorlevel 1, -305 ; suppress warning msg that takes f as default
cblock 0x20
buffer:80
endc
cblock 0x78
crc
contor
i
cnt1
cnt2
cnt3
flag
endc
SendL macro car
movlw car
movwf TXREG
endm
;0000000000000000000000000 RESET 00000000000000000000000000
ORG 0x0000
PAGESEL IntrareBootloader
GOTO IntrareBootloader
;view with TabSize=4
;&&&&&&&&&&&&&&&&&&&&&&& START &&&&&&&&&&&&&&&&&
;---------------------- Bootloader ----------------------
;
;PC_flash: C1h AddrH AddrL nr ...(DataLo DataHi)... crc
;PIC_response: id K K
ORG first_address
nop
nop
nop
nop
org first_address+4
IntrareBootloader
;init serial port
clrf STATUS
bsf STATUS,RP0 ;BANK1_
movlw b'00100100'
movwf TXSTA
movlw spbrg_value
movwf SPBRG
BANK0_
movlw b'10010000'
movwf RCSTA
;wait for computer
call Receive
sublw 0xC1 ;Expect C1
skpz
goto way_to_exit
SendL IdTypePIC ;PIC type
;SendL IdSoftVer ;firmware ver x
MainLoop
clrf STATUS ;bank0
SendL 'K'
mainl
clrf crc
call Receive ;H
bsf STATUS,RP1 ;bank2
movwf EEADRH
movwf flag ;used to detect if is eeprom
call Receive ;L
bsf STATUS,RP1 ;bank2
movwf EEADR
call Receive ;count
movwf contor
movwf i
incf i
movlw buffer-1
movwf FSR
rcvoct
call Receive
incf FSR
movwf INDF
decfsz i
goto rcvoct
movf crc,f ;check checksum
skpz
goto ziieroare
;write
bsf STATUS,RP1 ;bank switch 0->2
movlw buffer
movwf FSR
writeloop ; write 2 bytes = 1 instruction
clrwdt
movf INDF,w
movwf EEDATA
incf FSR
movf INDF,w
movwf EEDATH
incf FSR
BANK3_ ;bank 2->3
bcf EECON1,EEPGD
btfss flag,6 ;is eeprom (or flash)
bsf EECON1,EEPGD
bsf EECON1,WREN
movlw 0x55
movwf EECON2
movlw 0xaa
movwf EECON2
bsf EECON1,WR
nop
nop
waitwre
; btfsc EECON1,WR ;for eeprom writes (wait to finish write)
; goto waitwre
bcf EECON1,WREN
BANK2_ ;bank2
incf EEADR ;does not cross zones
btfss flag,6 ; if writing to EEPROM, skip first counter dec.
decf contor
decfsz contor
goto writeloop
goto MainLoop
ziieroare
SendL 'N'
goto mainl
Receive
clrf STATUS
movlw xtal/2000000+1 ; for 20MHz => 11 => 1second
movwf cnt1
rpt2
clrf cnt2
rpt3
clrf cnt3
rptc
btfss PIR1,RCIF ;test RX
goto $+4
movf RCREG,w ;return in W
addwf crc,f ;compute checksum
return
clrwdt
decfsz cnt3
goto rptc
decfsz cnt2
goto rpt3
decfsz cnt1
goto rpt2
;timeout:
way_to_exit ;exit in all other cases; must be BANK0/1
;BANK0_
bcf RCSTA, SPEN ; deactivate UART
goto first_address
;*************************************************************
; After reset
; Do not expect the memory to be zero,
; Do not expect registers to be initialised like in catalog.
END
zasto said:OK, if John Doe or Average Joe has skills to modify your bootloader, that is one thing, but, there is a big BUT, howthhell will JD or AJ know where to 'inject' the malicious 'back door'?
If your product is connected to Internet, I have not heard, yet, for any malware, virus, trojan, etc. for microcontroller.
BTW, for the time being, I'm protected against lot of malware variants, I'm running Linux on the internet enabled computer.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?