Aha, so when you encrypt it back, you have to add original 32Bytes or can be ommited? Napalm meand bytes 32-34 from decrypted file? then it's effectively 64-66 in original FIR.
I always keep the first 32 bytes and I mean 32-34 not 64-66:
ROM:00800020 DCB 0x59 ; Y
ROM:00800021 DCB 0xC0 ; +
ROM:00800022 DCB 0x55 ; U
That's the checksum ^
I think these bytes better to transfer to output without decryption
Yep, if you do that the file fits exactly at 0x800000 for the loader.
BTW I found that leading code and copyright message is not protected by checksum on 350D so I wonder how napalm did repaired it by bytes 32-34 (which belongs to copyright on 350D). Checksum must me fixed by some further bytes. I will try to find the range of protected bytes.
I guess I'm calculating the checksum on more bytes than I should, because it only works for v1.1.1, for other versions I'd have to adjust adding or substracting the difference from the correct checksum but I don't care for the time being- but I think the copyright is included, as the code near it should in theory be included as well. If you can find out the exact range great
Are there some knowledges about VxWorks? Do we have some working complette image? I thought it's a kind of linux-like os, I searched for some classic locations like /bin /etc/ /dev but there are very few strings with paths. It seems like this firmware don't use ROM filesystem with multiple files like powershots. Also the FW update maybe only a small part of huge firmware inside i don't know how big is the flash size. Can I get some complette dump from digicII powershot somewhere?
It's not linux-like at all. And you're not going to find any useful files/scripts either because it's not using any. It's a real-time OS for embedded systems, not a sort of dirty hack of consumer pc os like the os in 300D. The best thing we can do to find out how the camera is using the OS is looking for calls to os functions, isr, message queues,