Any developers interested in working on CHDK firmware for DSLRs ? - page 11 - DSLR Hack development - CHDK Forum supplierdeeply

Any developers interested in working on CHDK firmware for DSLRs ?

  • 202 Replies
  • 99302 Views
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #100 on: 22 / April / 2008, 18:20:17 »
Advertisements
We'll work faster if we'll post what we know. So todays work with 400D firmware:

File structure is [loader]+[firmware pack].
4B: model ID (36 02 00 80 for 400D)
12B: 0?
16B: firmware number (string)
4B: checksum - see below
4B: file offset of the loader
4B: file offset where is the firmware pack (for 400d: 127C90)
4B: 0?
all rest until the firmware pack is the loader code (starting point for the code. propably 0x800000)


Now for the firmware pack.
16B+8B: don't know yet - but one 4B is for table lenght.
next is a table of segments of the pack, with records in form:
4B: don't know yet - mostly #4 propably a flag
4B: offset of the segment (in reference to the begining of the pack)
4B: lenght of the segment
28B: name of the segment (string).

I the 400D pack there are segment like firmware version (5B), model id (4B - is not the USB device ID for 400D).
There are also big segments - firmware, bind_resource (pictures of errors while updating), lens table and so.

my conclusion for today is:
 fir is a program with attached resources witch is not loaded permanently to rom, designed to load some of it's data segments to rom (lens table, firmware, and so).

todo for tomorow:
find the checksum's

Mayby even porting the chdk to dslr will be just minor changes and other packing.

I would want to make only a small program, to run on the camera (like the "blinker"). If somebody who wrote something for other camera would help - it would be great.

>news edited:

the checksum for the entire file is:
sum of all bytes without 0x20-0x24 summed with word in 0x20-0x24 will give -1 (0xff ff ff ff).
works for both 400d firmwares.
« Last Edit: 22 / April / 2008, 19:07:07 by owerlord »

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #101 on: 23 / April / 2008, 07:41:46 »
Is there a way to help, I've got a 5D and would really like to see CHDK on it.

*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #102 on: 23 / April / 2008, 12:52:45 »
We'll work faster if we'll post what we know. So todays work with 400D firmware:
Bytes 0x24 to 0x28:
Quote
4B: file offset of the loader
This value is 0xB0000000 in 40D's 1.0.5 FW (can that be right?)
Quote
4B: file offset where is the firmware pack (for 400d: 127C90)
3 bytes or 4? You show 3 bytes as your value.
40D-1.0.5: Bytes 0x29 to 0x2D = 0x20010000
Quote
4B: 0?
These 4 bytes are 0xFF

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #103 on: 23 / April / 2008, 13:04:21 »
remember that ARM have a little indian - so:

12 34 56 78 in hex editor is realy:
0x78563412

mayby that's the case

ps: post the diffrences ! we'll gather some information and work it down :-)


*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #104 on: 24 / April / 2008, 02:17:27 »
remember that ARM have a little indian - so:

12 34 56 78 in hex editor is realy:
0x78563412

Ahh! I still need to find a good book on ARM asm/architecture
that I can bring to work and read when I'm not busy.

Quote
ps: post the diffrences ! we'll gather some information and work it down :-)

Ok, here is what I know about 40D-1.0.5 FW:

Unencrypted portion of the .fir file is 288 bytes long starting at the first byte in the file.

In the hex editor:
Bytes 0 to 03h: 90 01 00 80h
Bytes 04h to 0Fh: 0h
Bytes 10h to 14h: FW version string ("1.0.5")
Bytes 15h to 1Fh: 0h
Bytes 20h to 23h: 5E 2D C7 C1h (checksum?)
Bytes 24h to 27h: B0 00 00 00h
Bytes 28h to 2Bh: 20 01 00 00h
Bytes 2Ch to 2Fh: FFh
Bytes 30h to 33h: 80 DC 19 00h
Bytes 34h to 37h: FFh
Bytes 38h to 3Ah: 9C EC 7Ch
Bytes 3B to 3Fh: 0h
There is some more data interspersed with strings of 0's until we get to byte C0h. Then it is nothing but 0's until the start of the encrypted portion. I don't know what this other data is but the decrypting utility discards it. I think I'll change the decrypting utility to just output it to the decrypted file and examine it closer.

How many bytes of unencrypted header are in the 400D FW?

*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #105 on: 24 / April / 2008, 13:45:56 »

>news edited:

the checksum for the entire file is:
sum of all bytes without 0x20-0x24 summed with word in 0x20-0x24 will give -1 (0xff ff ff ff).
works for both 400d firmwares.

I wrote a short C program (see below) to check this against the 40D-1.0.5 FW
and it does not work. I tried swab(3) to correct for endianness of the file's checksum, and also without correcting it, and neither gave -1 as a final result.

Does this program do what you meant?

Code: [Select]
#include <stdio.h>
#include <unistd.h>

#define FCSUMPOS 0x20

main(int argc, char *argv[])
{
        FILE *in;
        char c;
        long sum = 0L, fsum1, fsum;
        long fpos;

        if (argc != 2)
                exit(-1);

        if ((in = fopen(argv[1], "rb")) == NULL) {
                printf("Cant't open file name %s\n", argv[1]);
                exit(-1);
        }

        printf("Filename: %s\n", argv[1]);

        while((fpos = ftell(in)) < FCSUMPOS){ /* Sum bytes until we get to c-sum */
                fread(&c, sizeof(char), 1, in);        /* stored in file. */
                sum += c;
        }

        fread(&fsum1, sizeof(long), 1, in); /* Grab Checksum stored in file */
        swab(&fsum1, &fsum, sizeof(long)); /* Swap bytes to restore endianness */

        printf("File's csum: %ld\n", fsum);

        while(!feof(in)){
                fread(&c, sizeof(char), 1, in);
                sum += c;
        }

        fclose(in);

        printf("Calculated csum: %ld\n", sum);
        printf("Result = %ld\n", sum + fsum);

        exit(0);
}

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #106 on: 24 / April / 2008, 18:57:01 »
no. you dont need a swab. and don't use signed types. you make char c = 0xff. that means -1. then you sum += c. that means sum -= 1. not sum += 0xff.

when I changed the code I end up with 9.
I don't know why. I thought I should be -1. mayby It's my error - or it's in the code. but it works for both my firmwares (end with 9)

magic. more magic.

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #107 on: 25 / April / 2008, 06:20:51 »
In the header of the data pack:

16B+8B: don't know yet - but one 4B is for table lenght.

ok. More knowledge:
4B are the checksum (same method) of the data pack.
4B number of parts in the pack ("files" in the pack)
4B offset of the "file" table. (=24)
4B header size (offset of the first "file")
4B size of the "file" table (number of "files" * 40)
4B summary size of the "files" (size of the pack minus offset of the first)
« Last Edit: 25 / April / 2008, 06:26:54 by owerlord »


Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #108 on: 25 / April / 2008, 11:08:13 »
 fread(&c, sizeof(char), 1, in);        /* stored in file. */
                sum += c;

it should be:

n= fread(&c, sizeof(char), 1, in);        /* stored in file. */
if (n) sum += c;

otherwise the last byte is doubled.
now it end's with -1 :-)

ps: i'm writing a small packing code. I'll be ready soon.

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #109 on: 25 / April / 2008, 11:31:29 »
Ok. My packing code works. my 400d didn't vomit. The format is working.
From experiments I think that loader code is runned when there is a data pack attached - without it it didn't work. But it works with an empty data pack attached (no files - only headers). So if you want to experiment with new code, you can attache an empty pack:

CF FF FF FF  00 00 00 00  18 00 00 00  18 00 00 00
00 00 00 00  00 00 00 00

it is: checksum, 0 files, table offset=0x18, first file offset=0x18, table size=0, size of files =0

 

Related Topics