code you HAVE RUN on your dslr - page 12 - DSLR Hack development - CHDK Forum

code you HAVE RUN on your dslr

  • 141 Replies
  • 62551 Views
Re: code you HAVE RUN on your dslr
« Reply #110 on: 05 / June / 2008, 11:16:17 »
Advertisements
Ok. My method was very simple. But for start:

The photodiod is very fragile to light from a standard bulb - It makes the sygnal very bad. The best way I thing is first to observe the signal in a recording program (like Audacity). You can there see if the covering is good, and if the led blinks in the right place. Next thing is to try to narow the blink lenght so that you can easyly see the blinks in the program.

The photodiode works like a differential, with a delay - so a blink don't look like:
___/-------\___
but like
----/-- ------\----
in zoom it goes like:
___|\____ and a similar downward.
So when the blink starts there is a shift upword, then it goes slowly to 0 then when the blink ends there is a move downward and slowly back to 0.

Moral is: When the blinks are near themselfs you can't read it directly - you have to [d/dt] it. Then you'll have a nice  0 0 0 0 -1 0 0 0 0 1 0 0 0 0 -1 0 ...

Ok, now why I said it? becose now you can write yourself a program. You install ESD (linux? cygwin?) and then run: esdrec -m | ./yourprogram. It make life easy: esdrec -m sends a raw stream of integer values 44100/s. You revice it, and analyse it. First program is d/dt and watch what is the hight value, and what is the low value. Next is to count the integers between them. Next is to make the delays in to bits and write them to stdout.

I used the simple method to code strings (I copied the code in some thread) You can use a better one. Thing is - If you'll start the program without running os or something - it blinks perfectly. If you want you can make a checksum :-) I used base64 so that the binary data will be readable so I can see on the screen if there transfering properly. When you stick the photodiode it sometimes slips away - and the signal is lost - you can see it on the screen then :-)

I attache a very badly writen program to analyse the data from esdrec -m (-m is for mono :-) ). It do what I wrote - You can set the delays in the header - and ... you'll see what is for what :-)

Re: code you HAVE RUN on your dslr
« Reply #111 on: 05 / June / 2008, 14:05:20 »
Ok, back to the main subject of this thread. Becose of the recovery-thing I didn't write what I found out playing with boot:

When booting from CF, jumping to the entrypoint works - the system wakes fully.
It means that the full-startup-blocking thing have to be in the bootflags.

The thing I'm working now is to write working Startup Task. The rewriten path romStart->...->Startup works. Problem is in the startup procedure - orginal from the firmware works, but my rewriten don't.
It's not so wierd thought - it calls like 170 functions. And only couple of them are known (args? returns? etc). work. work. work

NEW: If anybody know that (and where) the firmware overwrite the 800000 section - please write it! I didn't find any such thing - but if the code would be overwriten - the test are useless.
« Last Edit: 05 / June / 2008, 14:08:56 by owerlord »

Re: code you HAVE RUN on your dslr
« Reply #112 on: 06 / June / 2008, 04:50:41 »
Can I suggest a completely different approach.
On the old 300D (DOS) code there was a simple peace of code that started and stopped the debug mode. (and swapped a bit)
When the debug mode was started all the debug strings where printed to a log file on the CF card automatically.

Modifying/adding the FIR code was done by truncating many string so memory was freed up for new code. In the original code a jump was made to the code that started this debug mode. This way it was very easy to debug what you where doing.

If we could find out how to start this debug made we would get a lot of information without much effort.

ROM:00970410 Dmstart
ROM:0097043C Dmstop

Could it be that it means Debug Mode Start and Debug Mode Stop ?

[DM] strings in the code are
ROM:00963B44  "[DM ERROR] dmEventDispatch : Current = %d, dwEventID = %ld, dwParam = $#|x"
ROM:00963B90  "[DM] dmSetPrintLevel : dwFlag = %#lx, dwLevel = %ld"
ROM:00963BC8  "[DM] dmSetStoreLevel : dwFlag = %#lx, dwLevel = %ld"
ROM:00970AF4  "[DM] dmGetLogName : opendir A:\"
ROM:00970B18  "[DM ERROR] dmGetLogName : opendir B:\"
ROM:00970B50  "[DM] ERROR : dmGetLogName over 999"
ROM:00963894  "[DM] ASSERT! TryPostEvent() fail.",
ROM:00963880  "../DbgMgr/DbgMgr.c",0

« Last Edit: 06 / June / 2008, 07:32:45 by emklap »

*

ASalina

Re: code you HAVE RUN on your dslr
« Reply #113 on: 06 / June / 2008, 06:20:43 »
I've found a function that tries to open a log file in the 40D 1.0.8 flasher. It's at sub_965A70. Near its end it branches to sub_989A44 and on return it checks R0 for -1, and if EQ it outputs an error message (to where??).


Re: code you HAVE RUN on your dslr
« Reply #114 on: 06 / June / 2008, 06:39:53 »
This way it was very easy to debug what you where doing.

I'm doing it by the led. I have the debug messages in real time on the computer screen - It's easy - If anybody want to do it, I can help with it. Only problem with blinking the messages is that it's a bit slow - writing to CF would be better. Problem with CF is a bit diffrent - the CF drive is initialized by OS after the log messages what are most interest to me :-) so i didn't bother to try to write a log. The Debug Menager have a "print level" and "log level" - it probably can write to a file - But, as I said - I didn't check it.

Re: code you HAVE RUN on your dslr
« Reply #115 on: 06 / June / 2008, 07:24:48 »
I like the LED method to get the complete dump of the MEM to find the keys to decrypt the FW and to find IRQ tables etc.
Debug prints are more useful when adapting code and see how the camera behaves when you change settings or scroll through menu's.

An other way to decrypt the payload would be to find (dump) the loaded firmware and to locate string in there. This way it must be possible build a decryption key ourselves or locate the key in memory.

It takes time, but in the end we will get the right brainwave.

*

ASalina

Re: code you HAVE RUN on your dslr
« Reply #116 on: 06 / June / 2008, 16:50:44 »

Moral is: When the blinks are near themselfs you can't read it directly - you have to [d/dt] it. Then you'll have a nice  0 0 0 0 -1 0 0 0 0 1 0 0 0 0 -1 0 ...

.....

First program is d/dt and watch what is the hight value, and what is the low value.

....

I understand all of what you say except for "d/dt". What is d/dt?

Re: code you HAVE RUN on your dslr
« Reply #117 on: 06 / June / 2008, 16:56:18 »
Derivative. like f(n) is the signal - f(n)-f(n-1) is a "descrete derivative". It's better to use it then the ogrinal signal. 


*

ASalina

Re: code you HAVE RUN on your dslr
« Reply #118 on: 06 / June / 2008, 18:55:19 »
Derivative. like f(n) is the signal - f(n)-f(n-1) is a "descrete derivative". It's better to use it then the ogrinal signal. 

Holy cow! What a difference! I don't know much about higher math, but I looked up "discrete derivative" and did some reading. The function is very simple, just as you show, and I wrote a program to run it on the input data. What a difference viewing the output in Audacity! This should be readable by adc now!

Thank you!

*

Offline mx3

  • ****
  • 372
Re: code you HAVE RUN on your dslr
« Reply #119 on: 08 / June / 2008, 04:49:28 »
but I'd love to hear your method if you think it would be better.
patch flasher so it would save ROM to card

there are some functions in flasher.

UPD_SaveTuneToFile(){
   save_bup( 0xF8620000, 0x140000, "TuneData");// next F8760000 - fixdata
}

UPD_SaveFixToFile(){
   save_bup( 0xF8760000, 0x30000, "FixData"); // next F8790000 - ringdata
}

UPD_SaveRingToFile(){
   save_bup( 0xF8790000, 0x20000, "RingData"); // next F87B0000 - rasendata
}

UPD_SaveRasenToFile(){
   save_bup( 0xF87B0000, 0x30000, "RasenData");// next F87E0000 - ?????
}

it seems first argument of save_bup function - address

so we have :
 - function to save dump
 - some unknown ROM region...


I suggest to substitute tUpdMgr task with code wich saves dump
see attached files. I'm absolutelly sure it will work.

after patching flasher  encrypt it and pack into fir file

« Last Edit: 08 / June / 2008, 04:54:17 by mx3 »
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

 

Related Topics