How to use the USB plug for ICSP programming of a PIC

InventorPatentor · Jan 26, 2010

I am (with help) developing a USB product based around PIC18F3K50 (which supports ss-ICSP). For programming it, instead of adding a special ICSP adapter to my PCB, I’d like to use the existing USB plug somehow. Of course, the PIC can’t simply be programmed over the pins used for USB communication, but there might still be a way to make use of the USB plug for programming!

For ICSP, the following PIC pins are involved:
VPP (not needed for ss-ICSP)
VDD (already wired to VBUS of USB plug)
GND (already wired to GND of USB plug)
PGD (already wired to D+ of USB plug)
PGC (already wired to D- of USB plug)
PGM (should be enabled for ss-ICSP)

My idea was to wire PGM (or VPP, in case high-voltage ICSP programming is better) to the USB shield! Of course, the product would not conform to the USB standard during firmware programming, and I would have to use a non-standard connection on my USB ICSP programming adapter - but that is no big issue, because my product is only going to be firmware-programmed on the factory, not on the field. However, the product must of course work normally after the firmware programming is completed.

Ideas, feedback, suggestions?

nandhu015 · Jan 26, 2010

I think it is not possible to use usb for this purpose like serial port or parallel port.

Nandhu

ZASto · Jan 26, 2010

Try this link:
https://www.diolan.com/pic/bootloader.html

InventorPatentor · Jan 27, 2010

zasto said:
Try this link:
https://www.diolan.com/pic/bootloader.html

Thanks, I've seen that already. A bootloader is good but not in my case, because the PIC still needs to be programmed with the bootloader program somehow. Security requirements for this product demand that the PIC must not be programmed until just before delivery.

nandhu015 said:
I think it is not possible to use usb for this purpose like serial port or parallel port.

Would you like to develop how you arrived at that conclusion?

ZASto · Jan 27, 2010

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).

But be aware, there are companies that DO the reverse engineering of the microcontrollers.

InventorPatentor · Jan 27, 2010

zasto said:
PIC18F3K50 ?? Which uC is this?

Anyway, pleas inform us if you succeed in connecting uC for programming this way.

Should be 18F13K50; this keyboard is acting up.

OK, I will!

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,

Thanks for the input. 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.

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').

Could be a problem to prove who leaked, though... Better to make such leaks more difficult. Besides, the potential risk is so high that this employee must be very rich.

IMHO it is much cheaper to put a 5-pin ICSP connector on your board than USB connector (pricewise).

Yes, but the USB will be there anyway, so the additional cost is zero. The work cost for disassembling the housing to reveal the 5-pin connector is more expensive. And putting it on the outside is not possible in my case.

zasto said:
But be aware, there are companies that DO the reverse engineering of the microcontrollers.

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 · Jan 27, 2010

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 module

that 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)

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?

You can not combat against reverse engineering of your product, please check your private messages.

InventorPatentor · Jan 27, 2010

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.

Click to expand...

I guess that you are not making lunar landing module that 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)

Who would be tampering with it? The man in the moon?

Are you saying you always write backdoors in your software, to make it tamper proof?
I was saying that a bootloader, if it is malicious, can change the code entered through it, and thus add maliciousness to it, such as backdoor functions or properties.

zasto said:
You can not combat against reverse engineering of your product, please check your private messages.

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 · Jan 28, 2010

InventorPatentor 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.

You have already seen the link that I've sent you, so you figure out how the controllers are secure, even with protection switched on

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.

InventorPatentor · Jan 28, 2010

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

Sounds smart, but it is not clear what you mean. Do you mean the program is supposed to selfdestruct if the execution pointer is manipulated, or what?

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.

While it is true that you can trust a bootloader after having checked the source and compiled it and programmed it into the PIC yourself, it is still possible that a PIC received from an untrusted pcba, claimed to be programmed with said code, is in fact progammed with a bootloader seemingly working okay, but which has backdoors added.

ZASto · Jan 28, 2010

I think that you are much paranoic on the bootloader topic. Anyhow, if you do nit trust the PCB manufacturer/assembler, there is still a solution

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.

InventorPatentor · Jan 28, 2010

I think that you are much paranoic on the bootloader topic.

Security thinking is about doing everything you can to enhance security, and accept that you can't do everything.

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.

Well, if the suspected bootloader can modify code, it can also modify the trusted second bootloader code.

ZASto · Jan 28, 2010

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.

Will comment no more, it will take us nowhere.

InventorPatentor · Jan 29, 2010

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.

Correction - my program, OR (if the bootloader is malicious) - a maliciously modified version of my program.

I guess that your program for uC is not like the Great M$ Virus.

FYI, The very purpose of my product is actually to solve the enourmous problem that almost 59% of all PC's are infected with malware (source: **broken link removed**). For this reason, my product would not sell if I opened it up to backdoors.

zasto said:
Will comment no more, it will take us nowhere.

Correct. It will take us nowhere as long as you refuse to motivate your point; i.e. why the default should be to trust things. Trust is something that has to be motivated. Microchip, for example, can be trusted sufficiently, because of their company size; they have a well-known name to maintain. On the other hand, I see no good reason to trust John Doe's local pcb assembly factory in China. Sure, by a probability of >99%, they will NOT add backdoors to the bootloader, simply because they don't know how to. But the remaining approx 1% is still way too much.
And this is how every professional in the western world, that works with any aspect of security issues, thinks. Most software developers must think secure, too.

ZASto · Jan 29, 2010

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'? in your mC is only bootloader and nothing else.

Rest 1% have no idea how your firmware operates and have no idea how to modify it, unless they put their eyes/hands on your source code

(trojans, backdoors on your computer included).

Code:

	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

Here you have a bootloader source (it prodices 100+4 bytes of code) and analyze it yourself and try to figure out where the backdoor can be implemented (this is the actual bootloader that I've found on the Internet and I am using it for some product that I make - my uC is in QFN package and there is no way to take it from the PCB when new revision of software has to be programmed).

As this product has the GSM modem, one of my 'backdoor' routines just interprets the command received by SMS and wipes out the program FLASH memory.

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.

InventorPatentor · Jan 29, 2010

Substitute Malicous Bootloader

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'?

You're getting off topic now, but there are ways to do that. I think many people in this forum could find ways. Some ways of places in a target firmware program, that a SMB (substitute malicious bootloader) could detect, and insert itself into, is;

* sleep
* the setting of a certain I/O pin to a certain value
* the reading of a certain I/O pin

Which to use would depend on the specific target.

If your product is connected to Internet, I have not heard, yet, for any malware, virus, trojan, etc. for microcontroller.

But didn't I explain how? The malicious pcb assembly factory writes a bootloader and programs it into the product delivered to you. You think it is your bootloader, because it acts the same way, but because of Code Protection you can't take random samples to be sure. But the actual bootloader filters your program and modifies things in your program. The attacker can relatively easy guess how to adjust his bootloader, without having seen the source code or even the compiled code.

If you still don't understand the problem, please start a new thread about this instead of hijacking this one.

BTW, for the time being, I'm protected against lot of malware variants, I'm running Linux on the internet enabled computer.

You are talking about viruses. Not all malicious software is spreading. BTW, thanks for the info on what O/S you are using. I will make a note of it.

Welcome to EDAboard.com

How to use the USB plug for ICSP programming of a PIC

Newbie level 5

Advanced Member level 5

Advanced Member level 3

Newbie level 5

Advanced Member level 3

Newbie level 5

Advanced Member level 3

Newbie level 5

Advanced Member level 3

Newbie level 5

Advanced Member level 3

Newbie level 5

Advanced Member level 3

Newbie level 5

Advanced Member level 3

Newbie level 5

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor