Code injection - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2]   Go Down

Code injection

  • 14 Replies
  • 5316 Views
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: Code injection
« Reply #10 on: 27 / September / 2008, 15:14:52 »
Advertisements
The reason that you see 'your' value for a short time is probably because you didn't define your pointer as volatile, so if you write a value into it and then read it, the compiler will probably not generate an instruction to reread the value from memory, because it won't change if it's not volatile.

If you really want to bypass that function, there are, I think, only two possible non-destructive ways:
1) If the function is an event procedure (usually has only one data xref immediately followed by a call to RegisterEventProcedure) the function entry point should be stored somewhere in memory, in some sort of table. You might want to search for that address and change it with the address of a 'return' function.
2) Do it the way CHDK does things: bypass all asm code leading to that function. Copy all functions in the path to that function into a code file like boot.c and bypass all subroutine references to point to the bypassed functions. Replace that last function by a return-function.

Keep in mind that if you overwrite a subroutine in ROM it might lead to all sorts of (mechanical/software) errors, possibly putting your camera in some sort of semi-irreperable state. I can imagine the thing refusing to start after it fails to retract the lens, because it assumes the mechanism is broken.
Logged
*

Offline igor

  • *
  • 21
Re: Code injection
« Reply #11 on: 27 / September / 2008, 16:45:28 »
>> 1) If the function is an event procedure (usually has only one data xref immediately followed by a call to RegisterEventProcedure) the function entry point should be stored somewhere in memory, in some sort of table. You might want to search for that address and change it with the address of a 'return' function.

It doesn't look like PrepareLens/StoreLens are event procedures. They might be too, but at least I see direct tree from startup root to those functions in IDE...

>>2) Do it the way CHDK does things: bypass all asm code leading to that function. Copy all functions in the path to that function into a code file like boot.c and bypass all subroutine references to point to the bypassed functions. Replace that last function by a return-function.

Not feasible, as too mach to replace => huge asm call tree from top to bottom has to be rewritten...

So, from what I understant, the functions I want to modify, are a little bit different from what normally CHDK uses. CHDK just takes small named task/thread normally created by call to CreateTaskStrictly and overloads that whole task/thread with it's own implementation, mostly calling original functions and replacing some of them with it's own implementation. THat's how I understand that.
So, in common case, function may not be inside that small and named task/thread. And this is the case with PrepareLens/StoreLens... They are getting called on top thread, and it's just too much work to replicate the whole asm tree to them.
So, there must be some different approach for such cases, if at all it exists.
I understand that concern and know that it's dangerous to modify ROMs code. But what else could be done?

Thanx everybody.
« Last Edit: 27 / September / 2008, 16:47:45 by igor »
Logged
*

Offline igor

  • *
  • 21
Re: Code injection
« Reply #12 on: 27 / September / 2008, 18:50:50 »
OK, looks like I'll be soon ready for "self-sacrifice".

I'm finding out that yes, there is ROMchecksum function, likely being called on 2 event procedures under "RomCheckSum" and "CheckSumAll" names. In fact, RomCheckSum (at ROM:FF818190 on TX1) is getting called from CheckSumAll (ROM:FF81822C SomeChecks)...
Event creation is here:

ROM:FF817F50                 LDR     R0, =aGetfirmwarever
ROM:FF817F54                 LDR     R1, =sub_FF817FE8
ROM:FF817F58                 BL      ExportToEventProcedure
ROM:FF817F5C                 LDR     R0, =aRomchecksum
ROM:FF817F60                 LDR     R1, =RomCheckSum
ROM:FF817F64                 BL      ExportToEventProcedure
ROM:FF817F68                 LDR     R0, =aChecksumall
ROM:FF817F6C                 LDR     R1, =SomeChecks
ROM:FF817F70                 LDR     LR, [SP],#arg_4
ROM:FF817F74                 B       ExportToEventProcedure
...
As I need to disable those 2 functions before "injection" and changing ROM, now I have a choice of either overloading aChecksumall and aRomchecksum event pointers (as DataGhost suggested above), or as I'm planning to "inject" anyway, I migh just first "inject" proper code into RomCheckSum, and shortcircuit it so it will always return that checksum is OK or just remove calls to those Event creation completely by writing just 1 byte to ROM at ROM:FF817F58+3 replacing value of that byte from 0xEB to 0xEA, thus forcing not to execute Checksums event procedure registration. Effectively asm will look like:

ROM:FF817F50                 LDR     R0, =aGetfirmwarever
ROM:FF817F54                 LDR     R1, =sub_FF817FE8
ROM:FF817F58                 B      ExportToEventProcedure
ROM:FF817F5C                 LDR     R0, =aRomchecksum  <= not executable portion now....
ROM:FF817F60                 LDR     R1, =RomCheckSum
ROM:FF817F64                 BL      ExportToEventProcedure
ROM:FF817F68                 LDR     R0, =aChecksumall
ROM:FF817F6C                 LDR     R1, =SomeChecks
ROM:FF817F70                 LDR     LR, [SP],#arg_4
ROM:FF817F74                 B       ExportToEventProcedure
...


I might be brave, but looks like I need a spare FLASH though.LOL


« Last Edit: 27 / September / 2008, 19:45:10 by igor »
Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Code injection
« Reply #13 on: 28 / September / 2008, 04:06:25 »
Quote from: igor on 27 / September / 2008, 18:50:50
I might be brave, but looks like I need a spare FLASH though.LOL

It certainly wouldn't hurt to have one. As a side benefit, you would learn how to handle BGA chips...

I'd suggest that prior to experimenting you informed yourself about the specifics of flash memory, in particular of its NOR variety, which is most probably used in our case because of its "execute in place" capability. As an extremely brief summary, such flash can be read/written to byte-by-byte, where "writing" changes the bits 1->0, but not the other way around. To change a single bit 0->1 one has to erase the whole block of memory, to which the bit belongs, the blocks usually being a few dozen kBytes in size. (It is actually this "erase in a flash" feature that earned the memory its name.) As you see, to change a single byte one actually has to re-program the whole block. It is possible that this is done internally in the ROM write functions that you intend to use, so you may want to examine them in more detail before actually trying. It would also be useful to find out the type of flash chip, and find its datasheet...

edit: here's a couple of functions to look at,  EraseSectorOfRom, EraseSignature, AmdCommand.c (the latter actually suggests it might be an AMD flash)

« Last Edit: 28 / September / 2008, 04:52:13 by whoever »
Logged
*

Offline igor

  • *
  • 21
Re: Code injection
« Reply #14 on: 28 / September / 2008, 14:15:06 »
Too much to swallow...

I was just thinking on brute force attempt, mostly gambling and if this fails I was planning to buy another camera.
Now you want me to do "research". I'm so lazy...LOL. Plus, I doubt this would change the result.

Hopefully, WriteToRom will do the job, as it does it on witing parms data + there is full upgrade firmware code that uses it.

On the other hand, if idea is only of intetest to me, maybe I should just shut up and keep this private.


For now that's what I see:

ROM:FF811B70 MainTask                                ; DATA XREF: ROM:off_FF811B6Co
ROM:FF811B70                 STR     LR, [SP,#-4]!
ROM:FF811B74                 BL      LooksLikeStartClock
ROM:FF811B78                 BL      LooksLikeMemsetSomeMemory
ROM:FF811B7C                 BL      LooksLikeExtractOfSomeParameters
ROM:FF811B80                 BL      LooksLikeThisIsJustArgumentShuffle
ROM:FF811B84                 BL      LooksLikeInitTimer
ROM:FF811B88                 BL      CheckAndIfOKStartBootDisk
ROM:FF811B8C                 BL      LooksLikeErrorNumberListCreation
ROM:FF811B90                 BL      EventualyCalls_ChecksumCheck
ROM:FF811B94                 BL      sub_FFB3C9B4
ROM:FF811B98                 BL      LooksLikeEventCreationAndAutoShutdownSet
ROM:FF811B9C                 BL      PhySwTaskCreation
ROM:FF811BA0                 BL      StrictWrapperWhoKnowsWhatIsIt
ROM:FF811BA4                 BL      AnotherStrictWrapperWhoKnowsWhatIsIt
ROM:FF811BA8                 BL      nullsub_11
ROM:FF811BAC                 BL      LPFParameterWhatIsThis
ROM:FF811BB0                 BL      CreateOfByeTask
ROM:FF811BB4                 BL      OneMoreStrictWrapperWhoKnowsWhatIsIt
ROM:FF811BB8                 BL      TempCheckTaskCreation
ROM:FF811BBC                 BL      EventualyCalls_SSAPI_StoreLensForShutDown
ROM:FF811BC0                 BL      LooksLikeSomethingRelatedToBattery
ROM:FF811BC4                 LDR     LR, [SP],#4
ROM:FF811BC8                 B       loc_FF811FA4

MainTask is getting eventually called by CreateTask at startup, and looks like CheckAndIfOKStartBootDisk is called in front of
EventualyCalls_ChecksumCheck (those are just aliases that I came up with and not real names).

So, it looks like that even if ROM is completely corrupted somewhere, but not in the tree of StartUp code up to and including CheckAndIfOKStartBootDisk, locked SD card with DISKBOOT.BIN will be always loaded before EventualyCalls_ChecksumCheck.
Explanation might be: as probably CANON's developers might also screw up with there ROM, this would be fast way to restore it to proper state. If they "screw up" they can just insert prepared before locked SD card that has DISKBOOT.BIN as well as current ROM image. There DISKBOOT.BIN will just read ROM image and use WriteToRom to write not equal bytes, thus restoring proper ROM.

So, the question is and please, someone who knows or tried answer:
When power supply accidently dies, do the camera's electronics has capacitors or other means that continue emergency shutdown procedure on software level?

Because if it has, then there is a simple way of "injecting" on startup and then "restoring" on shutdown... So, camera ROM will always be OK when run stand alone.

Another question:  What is the price of new TX1 in Russia?
« Last Edit: 29 / September / 2008, 00:02:13 by igor »
Logged
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics