Firmware for PIC16F877A woes and worries..

[R-M-I]

If I didn't mess up when checking continuity from the legs on the PIC and the updateport-pins..

this is the pins that are in use by the programmer:

PIN 7 - VDD
PIN 13 - NC
PIN 16 - PGC
PIN 18 - MCLR\VPP
PIN 32 - OSC1/CLKI



But...from my previous documentation I think this looks more right (that these are the pins in use).
vss ground
mclr Vpp
pgc
pgd
vdd target


EDIT: I'll check again when the kids go to sleep tonight..

I have access to more identical devices aswell as some similar running different chips.
The code-protection-bits ARE set on the device I'm trying to get working now. If it wasn't I guess it'd be a extremely easy task to get usable hex just by reading it out in MPLab and exporting it to file. Then program it to another device. Unfortunately this is not an option for me.
I am lucky enough to have:

- The original firmware or bootloader-files or whatever the hell it is that I have (the BIN-files with the various firmwares).

- The original firmware update utility for the boards I want to update.

I also know the type of programmer that was originally used, but I don't have it myself.


I'll include info on that aswell later today..
And again, thank you so much for trying everyone..

[Skimask]

But...from my previous documentation I think this looks more right (that these are the pins in use).
vss ground
mclr Vpp
pgc
pgd
vdd target

That would likely mean that an actual programmer is in use vs a bootloader.

- The original firmware or bootloader-files or whatever the hell it is that I have (the BIN-files with the various firmwares).
- The original firmware update utility for the boards I want to update.
I also know the type of programmer that was originally used, but I don't have it myself.

If those cases hold true, then you shouldn't have any problem...unless...the programmer being used had a specific modification, along with the target board having a specific modification, which would disallow any standard programmers to work.

K, bootloader vs firmware vs whatever-the-hell...a quicky...

If you've got a full copy of the firmware, you've got the whole thing.
It's kinda like having a "dumbass" in the next room, and you have to give him a task to do.  Problem is, he's a "complete dumbass", so you gotta tell him step-by-step-by-freeking-step every little bitty thing to do.

If you've got a firmware that requires a bootloader, you've only got a part of the whole thing.
Using the same analogy, it's kinda like having a smart kid from next door.  He knows how to do stuff, just needs to know the title of what needs to be done.

Similarly (and this is one scenario of many), if you've got a bootloader and firmware (the program that normally runs) already programmed into the PIC, upon power-up, this bootloader will wait X number of seconds for a specific sequence to come across some set of pins...whether it's something down the serial port, or a certain pin combination, or whatever, it'll wait for it.  If it sees this sequence, it'll jump to a different mode which will overwrite the main program with whatever program comes down the lines.  When it's finished writing that code, it starts it up.

If you've got firmware without a bootloader, it starts up and runs.  That's it.  It doesn't necessarily wait for anything to come along and change it...It just runs.

If you've got a PIC that HAD a bootloader and firmware, but you overwrote the bootloader and/or firmware with something else, the "programmer" may or may not know about this (sounds like it doesn't) and just go duhhhhhhhhhhhhhh.......and it's game over.

A bootloader is just a small subset of the complete firmware that makes other stuff happen independently of the main program.

You said you were using a PICKIT3?
Some people swear by it, some swear at it.  I used to swear at it loudly.  Since the newer firmware for the PICKIT3 has come out, I still swear at it, but not as much.
If you can, I'd try to get your hands on a PICKIT2.  It was around "back in the day" when the 16F877A was more popular and might be a bit more adept at programming it.  Sounds almost stupid I know, but that's the way it is.

It would still help if we knew WHAT this magical piece of hardware you are dealing with is...for that matter, anything else.
This cloak and dagger stuff ain't the way this game is played.  It ain't my job to figure out what you're trying to do.  It's your job to feed us any information you can about what you're trying to do so we can best help you.

[R-M-I]

Here's some info on the original programmer:


Just to give you a picture of how it looks, here are two





I cracked the box open to check what was inside (ofcourse):
the chips in there were these:

------------
FTDI
FT232BM
0233
------------
ATMEL
ATMEGA8
16AI 0444I
--------------
93LC46B
I/SN

As you can see from the picture, there's one side with a RJ11 connector on it.. going from that to the plug  that fits into the circuitboard I'm working with getting up and running again the other side is obviously the USB-cable that goes into the computer.

In addition to this, I needed to install the FTDI D2XX drivers to get it working.
I also seem to remember there were some virtual COM-ports in the mix here, but guessing they come with the drivers?

[Skimask]

www.ftdichip.com for the FTDI drivers.
The FT232BM is an older chip, but it's still used.
You've got a USB-serial converter, an ATMega MCU, and an eeprom in that programmer.
No telling what it actually does to the data going into and out of it, at least not without doing a bunch of probing, datalogging, and so on....

[ptricks]

What is the target chip , the pic, used for ? Is it just a demo board , what task is the pic supposed to be performing ?
The last time I saw a programmer like that was one of the ones that used a micro in the programmer to read the bin file and also in that file were the parameters of the target device so it would know how to write the actual data into the chip. Usually if you look at the .bin file in a hex editor you can find the part where the configuration data for the programmer starts and stops and where the programming data begins, lot of 00 00 00 stuff or other repeating characters.

[amyk]

It looks like a somewhat intelligent programmer, the FT232/Atmega8 combination is used in AVR programmers too. If you can get a logic analyser on the pins and log at least the start of the programming process you can figure out whether or not it's the standard PIC programming protocol. Otherwise the hope is that the software running on the PC is what does the decryption/decompression of the .bin file and you can try disassembling that and analysing it (rather steep learning curve if you're not familiar with RE already...)

Usually if you look at the .bin file in a hex editor you can find the part where the configuration data for the programmer starts and stops and where the programming data begins, lot of 00 00 00 stuff or other repeating characters.

There is a bit of a header in the file posted above, but the bulk of it doesn't have the characteristic texture of machine instructions.

[R-M-I]

I've ran the bin-file in with magic\hexwalk..

And it identifies it as  "G3 data, byte-padded"

I'm also trying to look through the FUU(Firmware Upload Utility) in IDA Pro. I need to be pulling in some people more knowledgeable about reverse engineering\ASM and what to look for than myself on this one though.. Hopefully I'll get it working in the end

[JTR]

The Bin file is encrypted.  You aint going to have any luck with any asm experts until you figure out the rather simple encryption method used.  Really, just look at it. It is begging to be broken...

[AlfBaz]

I swear I had nothing to do with this 

[R-M-I]

THE PLOT THICKENS!! *insert dramatic chipmunk here*

[JoannaK]

For a old hack, that binary file looks real odd. Obviously this is not any 14-bit wide Pic code, and most of it seems way too repeating to be any code at all.. And for even to be graphical/audio data.. Not likely, cause this is just a small pic.

Code: [Select]

000015B0  410C 4FCA 3D68 0BE6 B944 4782 B5A0 039E  A.OÊ=h.æ¹DG‚µ .ž
000015C0  317C 3F3A 2DD8 FB56 A9B4 37F2 A510 F30E  1|?:-ØûV©´7ò¥.ó.
000015D0  21EC 2FAA 1D48 EBC6 9924 2762 9580 E37E  !ì/ª.HëÆ™$'b•€ã~
000015E0  115C 1F1A 0DB8 DB36 8994 17D2 85F0 D3EE  .\...¸Û6‰”.Ò…ðÓî
000015F0  01CC 0F8A FD28 CBA6 7904 0742 7560 C35E  .Ì.Šý(˦y..Bu`Ã^
00001600  F13C FFFA ED98 BB16 6974 F7B2 65D0 B3CE  ñ<ÿú혻.it÷²eгÎ
00001610  E1AC EF6A DD08 AB86 59E4 E722 5540 A33E  á¬ïjÝ.«†Yäç"U@£>
00001620  D11C DFDA CD78 9BF6 4954 D792 45B0 93AE  Ñ.ßÚÍx›öIT×’E°“®
00001630  C18C CF4A BDE8 8B66 39C4 C702 3520 831E  ÁŒÏJ½è‹f9ÄÇ.5 ƒ.
00001640  B1FC BFBA AD58 7BD6 2934 B772 2590 738E  ±ü¿º.X{Ö)4·r%.sŽ
00001650  A16C AF2A 9DC8 6B46 19A4 A7E2 1500 63FE  ¡l¯*.ÈkF.¤§â..cþ
00001660  91DC 9F9A 8D38 5BB6 0914 9752 0570 536E  ‘ÜŸš.8[¶..—R.pSn
00001670  814C 8F0A 7DA8 4B26 F984 87C2 F5E0 43DE  .L..}¨K&ù„‡ÂõàCÞ
00001680  2D43 31B5 16E7 E761 9519 8BDA 97AF 43B0  -C1µ.çça•.‹Ú—¯C°
00001690  1DC5 9302 2E64 D8ED A589 9B4A 2637 5C41  .Å“..dØí¥‰›J&7\A
000016A0  2D71 A3B6 110D 6083 E51B ACEF 39D2 EFFA  -q£¶..`ƒå.¬ï9Òïú
000016B0  34F2 B835 3D68 0BE6 B944 4782 B5A0 039E  4ò¸5=h.æ¹DG‚µ .ž
000016C0  317C 3F3A 2DD8 FB56 A9B4 37F2 A510 F30E  1|?:-ØûV©´7ò¥.ó.
000016D0  21EC 2FAA 1D48 EBC6 9924 2762 9580 E37E  !ì/ª.HëÆ™$'b•€ã~
000016E0  115C 1F1A 0DB8 DB36 8994 17D2 85F0 D3EE  .\...¸Û6‰”.Ò…ðÓî
000016F0  01CC 0F8A FD28 CBA6 7904 0742 7560 C35E  .Ì.Šý(˦y..Bu`Ã^
00001700  F13C FFFA ED98 BB16 6974 F7B2 65D0 B3CE  ñ<ÿú혻.it÷²eгÎ

In the middle of this hex list there are couple lines that obviously look different. Most likely those are real code/data and the rest is just Blank rom with XOR:ed with some pseudorandom pattern.

[R-M-I]

I know for a fact that the file works perfectly when loaded to the PIC vis the usb->serial device through the firmware uploaded utility that went with it..

The file has be obfuscuated somehow though.. Compression? Encryption?

I again thank you all for your input.. Know that I am thankful for it.

[AlfBaz]

Do you have any company/manufacturers names for the original programer and software or for who built the boards?

Even if they don't have any technical details on their programming methods, the marketing spiel may give up some clues as to what format the bin file is

[R-M-I]

I believe the programmer was made by NEO Electronics LTD in the Uk.
That's what came up in my device-manager when I checked it on my computer atleast..

I'm building a new programmer now.. USB/Serial using FTDI's RS232TL chip.
Hoping I'll be able to communicate with the original firmware-utility with this one updating when/if there are news..

If someone has any more pointers I'm gladly accepting them..