Chief Delphi - .BIN format

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - .BIN format (http://www.chiefdelphi.com/forums/showthread.php?t=40333)

I heard a rumor that the .BIN files containing the master proc code are encrypted. Does anybody have any information about these at all?

Is the decryption performed by the bootloader or IFILoader?

It isn't a rumor - the master firmware (.bin) files are just encrypted .hex files. The bin files are decrypted by IFI loader and then downloaded to the controller.

Quote:

Originally Posted by fowlerm

It isn't a rumor - the master firmware (.bin) files are just encrypted .hex files. The bin files are decrypted by IFI loader and then downloaded to the controller.

I'm not at all surprised if they are - if they weren't encrypted, it would be a simple matter of disassembling and reverse-engineering them, and then you could change the code to ignore the "disable" signal or something else equally dangerous and un-GP...

...Not that I wouldn't be extremely curious to know exactly what goes on in the master processor, of course. :)

Quote:

Originally Posted by Pat Fairbank

...Not that I wouldn't be extremely curious to know exactly what goes on in the master processor, of course. :)

Hence why i am reverse engineering it. Partially out of curiousty, partially as a challenge and partially to learn about disassembling and revernse engineering software. After thorough review i have decided that the PIC code protection scheem is pretty solid, so there is no hope of schnarfing the code directly off the pic through any method, So i am left with decrypting the bin files. Now, if the decryption is performed by IFILoader then all i need to do is sniff the serial port while uploading master code and then write a simple program to generate a hex file from the intercepted traffic. Now if the decryption is done by the bootloader on the master proc itself, then things are ALOT more difficult. I am assuming whatever encryption they are using its probably pretty secure.

Is it known for sure the IFI Loader does the decrypting? I'd figure they'd do it in the bootloader if only to prevent the sniffing. If so, you'll need to work on cracking the encryption.

Quote:

Originally Posted by Matt Krass

I'd figure they'd do it in the bootloader if only to prevent the sniffing.

I doubt it. Mainly because of how much energy it takes to decrypt something. A PC can do it easily. A microcontroller that isn't really designed for that kind of thing will have some trouble. The other issue is that for stronger encryption, you'd need to work with the entire file. Single byte encryption (or even a few bytes for that matter) wouldn't be that great. So, the entire file would have to be sent to the controller before it starts decrypting it. However, after decrypting the bin file, it'd be simple to impliment some kind of encoding to send it to the bootloader.

Some microchip reference encryption libraries:

AN953 - Data Encryption Routines for PIC18 Microcontrollers

These look pretty secure to me and i'm guessing they are using something similar. I guess i will find out once i do some sniffing.

This may seem off subject, but I have looked into emulators and ROMs and the file extensions for ROMs are .BIN and I tried looking at them to edit them for my own use, but they are encrypted. Now I don't have any software related to robots yet, but they probably are by my assumption.

Does anyone know where I can get help/mentor to help me get started on the programming portion of a robot? thanks

They're encrypted? I just figured they were memory dumps instead of Intel Hex.

Code:

000800 00 EC 1C F0 D9 EC 04 F0 EB EC 04 F0 F4 EC 04 F0

000810 3B EC 1C F0 04 00 10 EC 04 F0 0A EF 04 F0 FF 00

000820 F2 B2 19 EC 04 F0 9E B6 24 EC 04 F0 F2 B0 F2 90

000830 12 00 F2 92 82 82 20 0E 45 6E 20 0E D9 6E 00 0E

I spent some time attempting to disassemble it and figure it out. I've attached a PHP file I used to translate from this "dump" format to hex. (Note that it includes a bug in calculating checksums which I never solved.) It acts as a "filter"; it translates from STDIN to STDOUT.

After that, I used a modified version of picdis18 (removed checksum checks) to convert it to assembly. I didn't get much farther than this, because I don't know ASM18.

If you were to spy as IFI Loader downloaded the "firmware", I think what would actually be downloaded is to the user proc that loads the firmware proper onto the master proc.

If anyone gets farther on this, I'd love to know.

If you have looked at the Microchip AN851 app note, the .mcp files that are generated when you open a .hex file are the in the same format as the .bin files used by IFI Loader.

Re: .BIN format (in relation to ROMS and programming

Quote:

Originally Posted by skrew-ball

1. .bin, to the best of my knowledge, are used by other apps for information storage. They aren't opened independently. When you dl an emu or ROM, more often than not they come with .cue files that dictate burning locations should you decide to store it on an external drive (Fable:TLC torrents... ;))

2. Get started in your local team. If you've taken a language class before, you're well ahead in the game. Just remember that some languages react diferrently than others. If your team's been around, they may have some spare stamps for you to fool around with and learn the basics of syntax and . Ex: Our team has some old PBASIC stamps that we use for fundraiser robots. I used BOE-Bots before, so I'm the official PBASIC programmer for the team, however useless my job is. Modding a VEXbot from FVC for use with MPLAB is a good way to start, if your team has the cash, as the FRCbots use the very same language, C. You can always salvage parts from old bots for use in a minibot that gives practice in auto mode.
And we all know that eC isn't 1337 ;)