Jollyrogerxp
It looks like they chose to split functions between the two processors.
The FR series are the CPU cores (MCU) inside numerous of their video processing engines; it seems to run all the video part including the LDC, and it runs the "main" DryOS that operates user menus etc., but it doesn't seem to be connected to any I/O for some reason.
The MIPS core, which supports the MIPS16 extensions, and also runs DryOS, seems to operate all the I/O like the SD card and the USB port.
The different parts of the firmware are clearly for two different cores, I really don't know why they chose to use two processors instead of relying only on the MB8 engine, maybe they use a scaled down and cheaper version of the video engine, or maybe in order to get the performance they required from all functions they couldn't use the MB8 engine to handle I/O functions too...
Jolly
Wiesel
Jollyrogerxp
At address 2E7D8C of the FR71 there seems to be a 0/1 flag that determines the PAL/NTSC menu messages, it would be nice to find out where it gets set at startup, I haven't had any time to look into that...
I took a look at it but couldn't find a single write operation to that address... maybe this address points to a nonvolatile memory where the configuration is stored so there's no need to write it.
Jollyrogerxp
I found that there is some code around 0xFAB00 that is not present anywhere in the FW update, nor in any other place I looked at so far...
Parts of code are copied to that part of RAM from around 0x2D0000 after they are copied there from around 0x043D0000 at bootstrap, but some pieces of it are nowhere to be seen, I am looking around the address space to see if I can find them...
It could be that ~0x2E70000 is NVRAM, but as you know around the same locations the FW writes code copying it from ROM at startup, so I don't know if it is really NVRAM there...
Ah I also found in the MIPS FW some big chunks of MIPS16 code that IDA doesn't disassemble properly (or at least v5.2 doesn't), I compiled (what a pain) a cross disassembler to disassemble those parts of code, when I do it I will send you the listings and the corresponding addresses.
Jolly
Wiesel
Jolly, I read that you're going to update the wiki with what you have found at some point. Therefore I have reworked the wiki for both the HV30 and HF10/100 so it now contains hopefully everything that is spread across this thread, except your recent discoveries.
Jollyrogerxp
Excellent! Thanks!
terig
Hi,
I've been following the progress and analyzing the fr part of the firmware just for kicks... If you still stuck with dumping fr memory areas I have an idea that might work.
Why not just use the firewire connection? The code is right there in the firmware and it can be modified. Probably too hard to use it directly though, I was thinking about setting up a side channel.
For example, as a part of the firewire protocol, the camera reports the vendor and the model name. I've identified the parts of the firmware that setup these strings and the memory areas where they're stored, also I think I've found the sub that handles the corresponding firewire request. What we can do is inject that sub with code that replaces the model name with a few bytes of memory we're interested in (and increment a global counter so subsequent requests will copy new bytes). Also, we'll need to write a client that issues the request and captures the results.
Will this work? Messing with this part of the firmware will likely break some functionality of the camera (video transfer).
Here are some technical details:
0x040C29A6 Main ieee1394 video sub
0x040C3264 Vendor data initialization sub
0x01725ED4 Storage for vendor/model data
-Vendor name (Canon) is stored starting from offset 0x5C
-Model name (e.g. VIXIA HV30) is stored starting from offset 0x70
0x040C3584 Sub that calculates CRC and possibly adds more data
0x040C758E Sub that handles the request for vendor/model information
Jollyrogerxp
Hello terig, thanks for your comments, I had thought to use the 1394 port, as I also found the code that manages it but I didn't investigate it as much as you did.
The problem I have is mainly on the PC client side, I looked around for easy ways to get the raw data stream from ieee 1394 and I couldn't find much, if you know a way to do that I would be glad to know!
As an aside, how did you find the contents of the area that contains 0x01725ED4? I haven't had the time to look around all the code to see where this area is mapped to/copied from, so I would appreciate any insight you have.
For now I have been using a different (much slower) technique that I already managed to run on small pieces of RAM: I hooked into one of the display routines and I intermittently display two different symbols to describe individual 1s and 0s, and I capture the LCD with a webcam and detect the symbols.
I haven't tried connecting the TV out to a PC TV capture yet, that way the signal would be much, much clearer too.
Jolly
terig
Hi,
Yeah the client side is not trivial but it shouldn't be too hard. Don't really need raw access, just a way to query for the name of the device (ok, the crc check will fail so we may need raw access to bypass it). I'll see if I can put something together for the client side.
I didn't find the (initial) contents of the are around 0x01725ED4, I just discovered that this is where the vendor and model name are eventually stored, this happens in sub 0x040C3264.
t.
Jollyrogerxp
If we can work something out that's good, the only problem with the device name is that apparently the windows PnP system looks for uses the device name sent by the init process to compose the device ID that is stored in the registry and associated with the driver.
If we constantly change the device name the PnP system might try to rediscover the device all the time, we need to be careful with that; if the PnP system uses only the first initialization to compose the device ID and then never asks for it again, then we could have the routine on the camera answer correctly the first time it is issued, and then from the second time it can start sending data instead.
I have seen those routines myself, I believe it would be pretty easy to hook in a piece of code to inject data in the string buffer, it looks like we can safely inject 13 bytes in there as it seems to be the size of the buffer.
Maybe we will also need to UUENCODE the data too, as raw binary in the 13 bytes that are used for the device name could break some routines on the PC side that expect to find a string, we'll see...
As for the memory area, I thought you managed to have a clearer idea of what else is around there, never mind it was my misunderstanding...
terig
I managed to get a simple client running that retrieves the whole 1394 config rom including the vendor and model name. Seems to be working good and very fast, there should be no issues with plug and play and device name changes as I hook at a low level.
I can provide the source if interested, this is for 32-bit winxp ... although the linux version would have been much easier.
Jollyrogerxp
Hi terig,
it would be excellent if you could send me the sources, let me know when/where you can send them to me.
I have also written a 1394 client for linux to experiment, and it is of course much easier to retrieve the rom configuration.
After some fighting I managed to install Ubuntu, and the raw1394 lib makes it very easy to communicate with the camera and retrieve the device information structure, inclusing the vendor/model string.
Cheers,
Jolly
terig
Ok, will send the sources,
To answer your question about the memory layout, it seems like 17XXXXX addresses contain global data used by various tasks, most of it gets initialized sometimes during the setup of the system.
For example 0x1c4 bytes are copied from 0x4075318 0x1725E00 and are used by the 1394 video subsystem. Control ROM is a part of this and it starts at 0x01725ED4. It matches the values I retrieved using the 1394 connection except for the model name and the hash values that get calculated later.
Immediately after that block, starting 0x1725FC4 is a block of memory used by the shell.
Jollyrogerxp
thanks for your comments, they match with what we have found ourselves, so it is good to see we weren't wrong...
Let me know how/when you can provide the win32 sources, in the mean time I will proceed experimenting with the linux-based client.
Jolly
terig
Hi Jolly,
I investigated the FCP subsystem a bit, here's the results. You might know this already but better to dump it here then forget it in any case.
-Fcp handler method is at 0x040C95A2
-Few instructions into this method another method is called to copy the fcp request data
-Request data is stored at 0x017212C0, this buffer can host 4 blocks of 1<<9 (512) bytes
-Counter denoting the current block is at 0x01725FB5
-Method is simple from here, first a type of request is determined, then the type of device, then the message is pushed into the fcp command queue to be handled by the main loop in the fcp task (in a separate thread).
-Hence if you want to intercept fcp request hook into this method, your data will be at 0x017212C0+(1<<9)*@0x01725FB5
-You probably don't want to inject too much code here, this is a callback and not sure what will happen if it hangs/takes long time to finish.
t.
Jollyrogerxp
This is excellent, I did find the main FCP thread, but I didn't really have any time to check the main FCP handler, this is really good information.
I am looking at some OSD stuff, I found a lot of the LCD drawing code, lines, rectangle filling, font drawing, strings, symbols, a bit of everything...
Jollyrogerxp
Unfortunately I don't have time to look at the FCP right now, I am working on the OSD dialogs, and on the PAL/NTSC switches, I will get back to the FCP as soon as I can...
terig
OK Jolly,
I'd be interested to hear the progress on the PAL/NTSC switches too, I traced most of them back to ROM, to me this indicates (together with dissasembling the flashing code) that the firmware is universal but the update is applied differently depending on the type.
Also, did you figure out how are camcorder key presses mapped to OSD actions? Been trying to enable service mode, but no luck so far.
Jollyrogerxp
One of these days it would be good to have a chat about the PAL/NTSC switches if you can, please get online.
The firmware is definitely universal, but I believe the region setting is part of the initialization process somewhere.
I am not 100% sure and you may absolutely be correct, but I dumped the address space 0x04000000 where the main ROM is and the dump is EXACTLY identical to the firmware image contained in the update file, besides some parts in the low part of the ROM where it looks like the update process copies the part of the firmware that actually performs the flashing.
As for the service mode, because some actions are mapped to some easy to obtain keypresses, I might modify the firmware to enter service mode when one of these keypresses are performed, like turning on the camera in CAMERA mode.
I haven't started looking for the keypress management code yet, right now I am looking at something else...
Jolly
terig
OK will try to catch you,
Here's some of my notes regarding flags:
As far as I can tell this is the most widely used PAL/NTSC flag is the byte at 0x00150027, the logic is if (x>>6)&1 the NTSC else PAL. This is referenced all over the place, the only write I could find happens very early in the OS initialization when the 0x34 bytes get copied from 0x406dcf4 to 0x150000, hence the original value of the flag is in rom at 0x0406DD1B.
This value is zero in the firmware update i'm looking at, hence the flashed camera should be PAL, in particular it should report "HV 30" instead of "VIXIA HV 30" as the model, but it's doesn't as you said before.
You should figure out what the values of 0x0406DD1B and 0x00150027 are in a running camera (preferably for both pal and ntsc models) ... then we'll know better where to look.
Jollyrogerxp
Ok good, 0x00150027 is the one I have been looking at since the beginning, so it's good to have a second opinion.
It is in my opinion the flag that all the others propagate from, and so it is the one we need to watch.
The running NTSC camera has 0xCC in 0x00150027, whereas the PAL camera (dumped yesterday thanks to a fellow owner in the UK) has 0x8C.
I know that the 0x34 bytes at 0x00150000 come from ROM, and they contain 0x00 at that position even in the ROM dump, that is why I have tried to follow up the procedures in the camera initialization to see where the flag is tested for the first time after the 0x34 bytes have been copied.
That considerably narrows down the parts of code where the flag could be set, unless of course it gets set by another device that shares that piece of address space, as from my dumps it looks like 0x00150000 might be a set of MMIO registers which is only 0x40 bytes long, and that repeats itself all the way up to 0x0015FFFF.
Reading those locations (0x00150040-0x0015FFFF) very similar values come out for all the positions in the 0x40 bytes, except for a few that vary, which could well be some registers that change in between every read that I perform for the dump.
We need to investigate it further...
Jolly
