PIC Bootloader/ICSP hacking...

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Danish to

Threaded View
Hej gruppe.

Jeg sidder med et problem på jobbet, og ville lige høre her om nogen har
en idé til hvordan at jeg løser det.

Jeg sidder i RMA afdeling, og står for reparation af nogle avancerede
batteriopladere. Laderne er software baserede, og software løsningen i
dem består af 2 dele - en bootloader og et stykke firmware.

Firmwaren i laderen er noget kunden selv kan opgradere via Serial eller
USB (same shit, bare en indbygget USB kreds i nogle modeller)

Der sidder også en standard Microchip ISCP header på motherboardet, der
passer direkte i en Pickit2 f.eks.

Processoren i produktet er en PIC24FJ64

Når kunden lægger en ny firmware ind i laderen, og den er markant nyere
end den gamle, skal bootloaderen også opdateres, og her sker det af og
til at noget går galt, og man ender op med en ret død lader der ikke kan
boote.

Firmware re-flash er af gode grunde ikke muligt, da bootloaderen der
lytter via Serial, ikke virker.

På værkstedet har vi nogle "brikker" der flasher firmwaren om. Disse
består af et lille print med en ATMEGA128 processor, lidt passive
komponenter, et par lysdioder osv.

Den sættes i laderen og den flasher en bootloader ned. Kildefilen til
kredsen udleveres ikke. Egentlig nok et forsøg på at forhindre
piratkopiering af produktet.

Vi har kun én brik for hver model af produktet, og går den i stykker er
vi mildest talt på skideren - så en kopi af den, eller bare muligheden
for at smide en Pickit2 i og flashe fra computeren ville være en super
løsning.

Jeg kan ikke udlæse koden i laderen via Pickit2 da code protect er slået
til, så alt læses som "00"

Kan jeg stole på de configuration bits som Pickit2 kan udlæse fra
kredsen, selvom at code protect er slået til? I så fald ser jeg en mulig
løsning. Inden i firmware flasher programmet, i selve exe filen ligger
der også en opdateret bootloader - hvis jeg åbner exe filen i en hex
editor står der højt og tydeligt BOOTLOADER og så en stor blok af data
bagefter.

Hvis ellers at config bits er korrekt, burde jeg kunne flashe denne blok
data ned med Pickit2, og så starte laderen op, og flashe selve firmwaren
via Seriel porten....

Jeg har spekuleret over en anden mulighed. Reverse ICSP - er der nogen
der har en idé om det kan lade sig gøre at "snuse" til ICSP
programmeringen med en logic analyser/datalogger og så gendanne hex data
den sender til kredsen ?

Nå, det var en lang smøre, jeg håber at det ikke var for stor en
mundfuld at tygge sig igennem ;-)

Iøvrigt, vi har konfronteret producenten af laderen med vores projekt,
og de har ikke noget problem med at vi roder med det, det er trods alt
ladere uden for garanti vi eksperimenterer med p.t. - så ingen grund til
at himle op om at der nok er en grund til at de ikke udleverer hexkoden
osv - de har simpelthen ingen interesse i det, det er langt nemmere for
dem at sende os en "brik" der programmerer produktet. Det er nemt og
(næsten) idiotsikkert.

Det mest frustrende er næsten, at aller nyeste model i programmet, den
har vi ikke engang en brik til, så når kunden får fejlflashet den, så er
den død - ihvertfald indtil at vi får en brik der passer til den.....

Hvis du har nogen ideer eller indspark, så råb op!

// Per.

Re: PIC Bootloader/ICSP hacking...
Quoted text here. Click to load it

Kig på kommunikationen mellem brik og lader.


Klaus
--
 Modelbane Europas hjemmeside: http://www.modelbaneeuropa.dk
        Min egen hjemmeside: http://www.moppe.dk
We've slightly trimmed the long signature. Click to see the full one.
Re: PIC Bootloader/ICSP hacking...
Quoted text here. Click to load it
Det var også planen.

Jeg må læse lidt op på hvordan at ICSP er implementeret, og så sætte en
logic analyser på brikken og sniffe alt hvad der foregår.

Jeg har ellers forsøgt at sniffe den serielle kommunikation når der
flashes en bootloader ind via seriel.

Problemet er, at det jeg får frem i terminalprogrammet ikke ligner
strukturerede data (en hexfil f.eks.) så dér kommer jeg ikke videre.

Kunne man evt. tænke sig at bruge f.eks. hyperterminal til at modtage en
fil på serielporten, og således logge alle dataene ned i en fil, så
giver det måske mening det der sendes... ?

Jeg sniffer serielporten vha. 2 USB/seriel adaptorer koblet som et Y
(kun én dataretning selvf.)


// Per.

Re: PIC Bootloader/ICSP hacking...
Hej

Hvis du har brug for at "splitte" seriel porte for at sniffe / logge så er
virtuelle porte ganske praktiske :-)
http://www.eterlogic.com/Products.VSPE.html

Wiljan



Re: PIC Bootloader/ICSP hacking...
Henvend dig til producenten !


/Kjeld



Quoted text here. Click to load it



Re: PIC Bootloader/ICSP hacking...
Quoted text here. Click to load it

De er tunge at danse med, derfor at vi selv må finde en løsning...


// Per.


Re: PIC Bootloader/ICSP hacking...
Tak for tips og ideer.

Jeg har faktisk løst problemet på en lidt opfindsom måde.

Den programmer "brik" vi har, den er f.eks. 30 sekunder om at flashe
target PIC'en - og så læste jeg mig til at ICSP programmeringen foregår
således at PIC'en først slettes, så programmeres data, og til sidst
protection bits.

Jeg fandt ud af ved at slukke for strømmen efter 25 sekunder, at det
virkede, og den ikke havde flashet security bits. Så formodentlig
flasher den data, laver en verify og så låser den PIC'en.

Den nyeste lader vi har i programmet, den har jeg ingen "brik" til. Jeg
havde en jeg alligevel havde kasseret da powertrinet var sprunget
luften, så jeg tog chancen og flashede den med brikken til modellen
mindre - det virker, og laderen bipper - det indikerer at bootloaderen
leder efter et program den kan eksekvere.

PC applikationen flasher herefter softwaren beregnet til laderen uden et
problem, men efter en genstart bipper laderen stadig.

Tilsyneladende, så er start-adresen på programmet ikke ens i laderene,
så jeg skal bare have hitte ud af den, rette den i Hex filen og så
skulle det virke.

// Per.

Site Timeline