350d boot from cf card

crazyklaus

77

Re: 350d boot from cf card

« Reply #330 on: 18 / November / 2010, 14:50:07 »

Advertisements

the function Zero looks like it is meant to write 0 into the memory "size" times beginning at the address stored in "buf"
but if this is the case, it contains an error.

Code: [Select]

void Zero(int* buf, int size) {
   int i = 0;
   for (; i < size; i++)
      buf[i] = 0;
}

the above code (or equivalent) would do what I described, but the actual code

Code: [Select]

void Zero(int* buf, int size) {
   int i = 0;
   for (; i < size; i++)
      buf = 0;
}

would only set the address the pointer "buf" is pointing to to 0 "size" times, actually doing nothing of any effect at all (the pointer "buf" only exists in the context of the function "Zero", so changing it won't affect the rest of the code).

so your finding that nothin in the memory gets zeroed is correct.

can you find out if the function Zero is executed at all when the program runs?

I will look at the rest and the

Code: [Select]

if (buf1[0] != boot_flag[0] || buf1[1] != boot_flag[1] || buf1[2] != boot_flag[2]) later

Logged

peabody

167

Re: 350d boot from cf card

« Reply #331 on: 18 / November / 2010, 19:16:22 »

Ok, I think I have the program figured out. This is bootflag.fir, which is the version that TOGGLES the boot flag to its opposite state, so that you can undo the mod if you want to. Here's what it does (leaving out the delays and most of the LED stuff):

1. It copies 52,224 bytes of code from firmware (ffff25f4 - fffff1f4) into ram (100000 - 10cc00). Not sure why, except maybe it needs to be executed from ram for some reason.

2. It creates two 128-byte buffers in ram - buf1 and buf2.

3. It fills buf1 and buf2 with zeros. (should)

4. It calls a subroutine at 1059b0 (ffff7fa4), feeding that routine the addresses of buf1 and buf2. This is the read_boot_flag routine.

5. It compares the value of the first three quads in buf1 with equivalent values at f8000000, and quits if there's any difference. I assume that's the actual address of the boot flags. So, it looks like the subroutine must copy those values to the pointer it is given (buf1). This then is a test to see if the right subroutine is at ffff7fa4. If it isn't, then presumably buf1 would still be zeros, or something else, but probably not the value of the boot flags at f8000000.

6, It then toggles the second quad of buf1 from 0 to -1, or from -1 to 0. This turns on, or off, the boot flag for CF.

7. It calls a subroutine at 10586c (ffff7e60), feeding it the addresses of buf1 and buf2, which I assume writes the buf1 values into the actual boot flags. We don't know how much more of buf1 and buf2 are involved in either the read or the write beyond the first three values of buf1.

8. Then it tests buf1 against the boot flags again, and if they match it turns on the blue LED and quits. If they don't, it turns on the red LED and quits - but at that point presumably some damage has been done since there's no telling what was at those subroutine addresses.

So it would seem that zeroing out buf1 and buf2 doesn't make any difference if you're dealing with firmware v1.0.3 and everything is where it should be. But it's important as part of the test - to make sure the uninitialized values in buf1 don't just happen to equal the values at f8000000 even if the firmware version or something else is wrong.

I think we need to do the firmware version test, and maybe even the first quad of those subroutines, before calling even the READ routine. Because if it's some other firmware version, you don't know what you're calling - it may or may not be destructive.

I should add that it appears that the scanled.fir program that most are using (and that the wiki specifies) does the first READ test but then ignores the result, except for which LED to turn on, and then proceeds to write the new boot flag even if the test failed. That's very dangerous, and is no doubt what caused the bricked cameras.

So, I found the "1.0.3" string in the 1.0.3 firmware update from Canon. How do we calculate where that's found after flashing the new version to the camera? We would need to know where the flasher code ends and the flashed code begins in the update file, and where the flashed code is flashed to. Do we know that?

Logged

kuku

14

Re: 350d boot from cf card

« Reply #332 on: 19 / November / 2010, 04:10:55 »

I tried crazyklaus files from 20101011 and got a problem - when I run the au_courant version my camera runs fine but when I run the normal version (with 23 or 24 config items) then my camera sometimes normally boots and works but sometimes dont: only the alphanumerical lcd works after launch but I cant take pictures and I cant browse the pictures too (the color lcd or the buttons left from it dont work)and the only option to fix it is to change the autoexec.bin to the au_courant version and remove the battery.

Logged

crazyklaus

77

Re: 350d boot from cf card

« Reply #333 on: 19 / November / 2010, 08:17:59 »

@kuku
I agree that this file isn't very useful with all that options. My code is actually meant to be used like this:
you choose the functions you want to have, edit the user_settings.txt file accordingly and build your own autoexec.bin without the unnecessary stuff.

@peabody
so if the "Zero" function would work correctly the code could test whether those new values are correct.
but it's highly unlikely for buf1 to have contained the values at 0xf8000000 that are being compared to it before the attempted zeroing (at least if those values are anything special, probably less so if it's only some 0s and 1s), so the test should still work in most cases, shouldn't it?

I have got no idea how to let the code check the firmware of the camera it runs on.

I will look at the difference between bootflag and scanled.

I, too, used scanled for my camera going from the wiki. Is it confirmed bootflag works?

« Last Edit: 19 / November / 2010, 08:23:17 by crazyklaus »

Logged

crazyklaus

77

Re: 350d boot from cf card

« Reply #334 on: 19 / November / 2010, 08:46:32 »

ok, I looked through scanled.c
you are right, the file tests something similar to bootflag, except the values are number literals and not bootflag[0..2], so I can't tell if it's really exactly the same (don't know what is in the memory at *bootflag).
Then it ignores the test result and goes on.

that's obviously a mistake.
but for me there's no indication that the test would save a camera with the wrong firmware.
it is possible that bootflag.fir (not ignoring the test result as opposed to scanled.fir) would also kill a camera with the wrong firmware.
one would need to change the code in a way that is does nothing except blinking lights for debug and then test with different firmwares.
can one down-grade the firmware on a non-hacked camera?
do you think it would be safe to deactivate the bootability of a hacked camera with bootflag.fir and trying to down-grade?

do you think scanled.fir is responsible for the reports of dead cameras with the right firmware version?

« Last Edit: 19 / November / 2010, 08:48:59 by crazyklaus »

Logged

peabody

167

Re: 350d boot from cf card

« Reply #335 on: 19 / November / 2010, 10:03:06 »

Quote from: crazyklaus on 19 / November / 2010, 08:17:59

@peabody
so if the "Zero" function would work correctly the code could test whether those new values are correct.
but it's highly unlikely for buf1 to have contained the values at 0xf8000000 that are being compared to it before the attempted zeroing (at least if those values are anything special, probably less so if it's only some 0s and 1s), so the test should still work in most cases, shouldn't it?

I have got no idea how to let the code check the firmware of the camera it runs on.

I will look at the difference between bootflag and scanled.

I, too, used scanled for my camera going from the wiki. Is it confirmed bootflag works?

Yes, I think the test is still likely to work, but it does depend on the power-on state of ram in the camera. But, you know, if that were the only problem, I don't think I'd worry about it too much.

The code can check the firmware by seeing if the string "1.0.32005.06.29" exists at a specific location, or really at any location, in the firmware. Do you know where in the camera's memory the firmware begins and ends?

The difference between the two programs is that scanled just turns the boot flag ON, whereas bootflag TOGGLES its state each time you run it.

A couple people report using bootflag.fir successfully. But others can't get either program to work, even with 1.0.3.

Logged

peabody

167

Re: 350d boot from cf card

« Reply #336 on: 19 / November / 2010, 10:29:52 »

Using bootflag WOULD NOT prevent bricking if you run it on the wrong firmware. The reason is that before doing the comparison tests it calls the read_bootflag subroutine in the camera's firmware to move the data into buf1. But if you don't have 1.0.3, you don't know what's at that subroutine address. It's highly UNlikely to be the same subroutine, and could even be in the middle of some other routine. It's a total crapshoot. To be safe, you can't even call a firmware subroutine unless you're already sure it's what/where you think it is. Otherwise, you don't have any idea of what you're calling.

And unfortunately, bricking seems to have the result of preventing the camera from accessing any CF card. So even if we could figure out what actually happened to cause the bricking, there's no way to get back in to reverse it.

I don't know about downgrading.

What bothers me about this is, as you say, the bricked cameras that supposedly had 1.0.3 installed. And then we have the case of maxes and annuges, both with 1.0.3, who report (replies 98-110 or so) that they are unable to set the bootflag with either program, but the camera is not bricked. In fact, in the case of maxes, who used bootflag, it's clear the program is quitting because the test fails. No damage is done in his case, but still - if he really has 1.0.3, the test shouldn't fail, even without the zeros.

Annuges finally got his camera to work by recompiling the source code, with no changes. Well, that doesn't sound likely, but if he still has the "new" version produced by that recompile, we could compare it to the original and see if it's just coincidence.

We don't know why the two firmware subroutines are used in these programs, or whether they are reliable. But we can at least do as much checking and testing as possible to make sure we are in the right environment before we go calling subroutines, and at a minimum that includes knowing we have 1.0.3 installed.

If we know where in memory the camera's firmware is located, it should be possible to at least dump a copy of it to a file. Then we can see where the "1.0.3" flag is, and also examine those two subroutines to see what they're doing.

Logged

peabody

167

Re: 350d boot from cf card

« Reply #337 on: 20 / November / 2010, 23:27:52 »

In another thread, mx3 says that the portion of the decrypted e3kr2103.fir file beginning at 0xb749c in that file is flashed beginning at location 0xff810000. If that's true, then the string "1.0.32005.06.29" should be located at 0xffa6ab14 if firmware v1.0.3 is installed in the camera.

Logged

peabody

167

Re: 350d boot from cf card

« Reply #338 on: 22 / November / 2010, 12:31:51 »

Well, I didn't find that string there, so I'll look for another one that might work as a 1.0.3 confirmation.

I would like to do a firmware dump of the 350D. Apparently the code in the Canon .fir file gets split up and flashed to various locations. It also looks like the code at FFFF0000 may not get updated at all, and it's that code that I'd like to go over.

I can't find a working link to the udumper, or instructions on how to use it (if that's possible) on a DSLR using CF cards. Can anyone help?

Or, if someone has already done such a dump, and is willing to share it, that would work too.

Logged

annuges

7

Re: 350d boot from cf card

« Reply #339 on: 23 / November / 2010, 07:42:54 »

I reinstalled my os recently and probably lost the whole firmware stuff. Once i get home in a few hours i'll check if i have a backup somewhere. chances are i also have it on a cf card but that might be the dowloaded version. I didnt change the code anyway so that probably was just a coincidence. if i remember correctly i was fiddling around with various cards and whatnot so that might be another reason it suddely worked. I was just really happy i got it to run and didnt think about it much further.

Logged