madx
Hi, All! It is possible to disable the preflash in mode M?
Sergei
Can anybody post a short video with info screen in action.
Thanks.
Txelu
I'm happy I discovered this hack some days ago so I can keep using my old 350D for little more time. So after reading all theses posts I decide to install the version 350D-20101011.zip by crazyklaus. I had no problem at all to make it work but the intervalometer option. I can set the number of shots and the delay time with Menu/Info/Jump buttons, but the SET button does nothing when I pressed. I don't know how to start the series of shots. Am I missing something??
By the way I think it would be a good idea to use a wiki to keep the relevant info of versions and instructions available for reference. I wouldn't mind to contribute in that wiki.
Thanks for your work!
crazyklaus
yes, you're missing something 😉 but it's actually quite simple to get it work, you have to set custom function 1 to a value 1, 2 or 3. with values 0 (standard value) and 4 the code won't recognize the set button.
there is also the option to change the functionality of the SET and JUMP buttons eg if you want to have the custom function set to 4 but of course you will lose the function that was on the jump button.
Txelu
Thanks a lot! I could make it work with your help 😀
peabody
I'd like to work on making the boot flag modifier .fir program somewhat more bulletproof, but the first step of that is to see if I can compile the original scanled.c or bootflag.c and come up with the identical .bin and .fir files. Back in the day I did MASM, but know nothing about C compilers.
I found gcc346.zip, which appears to be the compiler, but also has a "myproject" folder with 350D related stuff in it. But just for scanled.c, could someone tell me how to compile it? I have all the original files including the Makefile, build.bat, clean.bat and entry.s, but I need to know how to run the compile, assuming gcc346 will do that. I'm on Windows XP.
In looking through the decrypted firmware updates for 1.0.2 and 1.0.3, I find these strings at the locations indicated:
v1.0.2 - 30cea8 "1.0.2.2005.04.11"
v1.0.3 - 311fb0 "1.0.3.2005.06.29"
Further, the string "1.0.3" doesn't appear anywhere in the 1.0.2 firmware, and "1.0.3" doesn't appear anywhere in the 1.0.2 firmware. Of course at this point I don't know where these strings are located in the camera, or if they are there at all, but maybe someone knows how to find that out. Seems like the .fir could check for that "1.0.3" before changing the boot flag, and maybe prevent bricking.
[Edit: I figured out the compiling part, and by adding the appropriate Path statement was able to compile and get the identical output. So then does anybody know how to find where the "1.0.3" string is located in the camera's firmware, or where it should be?]
crazyklaus
can you give a link to the source code?
peabody
The bootflag.fir and scanled.fir files are located here:
http://www.mediafire.com/?sharekey=78ee45b97520ae1308f8df73f2072ed62590fcdbf5f0ba1af7e866bfb1230ce0
This file has bootflag: bootflag-20090921.zip
and this file has scanled: 350d_bootflag_update_20090914.zip
But I've made a bit of progress in figuring out exactly what these files do, and so far the result is a bit disturbing. So I gave up on trying to figure out the C, and did an object file dump to look at the actual assembler code, which is what my programming background is. And I found some helpful pdf's on the arm instruction set and register structure.
So here's one thing I found so far. This is the bootflag C code for a subroutine called Zero:
// zero memory
void Zero(int* buf, int size) {
int i = 0;
for (; i < size; i++)
buf = 0;
}
And here is how that was compiled:
00000060 <Zero>:
60: e3a03000 mov r3, #0 ; 0x0
64: e1530001 cmp r3, r1
68: a1a0f00e movge pc, lr
6c: e2833001 add r3, r3, #1 ; 0x1
70: e1530001 cmp r3, r1
74: bafffffc blt 6c <Zero+0xc>
78: e1a0f00e mov pc, lr
So, in assembler, you enter the routine with the pointer to the block in r0 and the count in r1. You then go into a loop incrementing r3 from zero to the value in r1, then you return from the routine (mov pc,lr). But, at no point does anything in memory get zeroed. So the C entry "buf = 0" appears to do nothing. It's the same in scanled.fir. The OP who gave us these boot flag programs isn't around anymore to ask about this, so it's hard to know whether anything needs to be zeroed at all. It seems to work for most people without that, but then we have these cases of bricked cameras. So I don't know whether to fix it or not.
What I'm trying to figure out now, in bootflag.c, is exactly what is being compared in this line:
if (buf1[0] != boot_flag[0] || buf1[1] != boot_flag[1] || buf1[2] != boot_flag[2]) {
LEDRED = LEDON;
} else {
but it's hard going trying to make sure I understand the assembler.
I'd still like to add the v1.0.3 test if that's possible.
crazyklaus
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.
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
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
if (buf1[0] != boot_flag[0] || buf1[1] != boot_flag[1] || buf1[2] != boot_flag[2])
later
peabody
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?
kuku
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.
crazyklaus
@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?
crazyklaus
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?
peabody
crazyklaus
@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.
peabody
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.
peabody
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.
peabody
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.
annuges
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.
peabody
I re-wrote the bootflag.fir file to fix the problems and to check for v1.0.3, and my version seems to work fine. An autoexec.bin file loads and executes.
But the wiki says that when I insert a bootable CF card but with no autoexec.bin file present, I will get an error message saying there's no autoexec.bin file. Well, I don't get any such message. In fact, the camera is completely dead, with no display and no lights. And I have to cycle the battery to get the camera back to normal. It's as though the camera is in an infinite loop as a result of there being no autoexec.bin file present.
What am I missing here? Is the wiki wrong about that error message, or is it just me?
peabody
About the shutter release count - mine shows 21780, which is a good bit lower than I expected. I just got the camera, but I'm the third owner that I know of, and just would have expected a higher number. Anybody else get a suspiciously low number?
One reason it looks suspicious is that I'm on folder 643, which if they started at 100 would indicate over 50k shutters. But I guess that can happen if someone moved a CF from another camera which had a higher count. Well if my release count is right, is there any way to change the folder number back to what would be right for the release count?
I'll try to post my revised boot flag .fir stuff later today, assuming you can still attach files here.
