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

Code injection

  • 14 Replies
  • 5259 Views
*

Offline igor

  • *
  • 21
Code injection
« on: 26 / September / 2008, 05:18:04 »
Advertisements
I have a question to ranked hackers here. Maybe someone could answer.
So, on Windows as code segment is usualy not protected it is common to modify code in memory, thus installing possible injectors and etc. (see Detours for example).
So, here are couple of questions:
1. Is this possible on Canons OS (whatever OS they are using)?;
2. If it is possible, then how?

For example on my TX1, I want my camera not to retract back lens and have it contsantly in out position. So, I have found an entry point that does that retraction (SSAPI::StoreLensForShutDown and on TX1 it is at FFB25850.
So, what I want to do, is just on entry overwite original code with the RET opcode (0x0E, 0xF0, 0xA0, 0xE1)...
However, I'm trying and it looks like values are overwriten just for a small period of time (I'm having print immediately after and before). So, my print after and before shows constantly changing values from there original (40 10 9F E5) to mine (0x0E, 0xF0, 0xA0, 0xE1).
As if there is somekind of a thread running and restoring those values...
I'm not crashing on setting them, which I think those code pages are not write protected.

So, could someone explain/recommend solution. Or maybe that techniques is not appropriate for some other reasons?

Logged
*

Offline reyalp

  • ******
  • 14080
Re: Code injection
« Reply #1 on: 26 / September / 2008, 05:46:38 »
There are no pages. All the cams run in a flat address space without any sort of virtual memory. You can read/write any part of RAM. There is an MPU (memory protection unit) which can be used to set permissions on regions, but it isn't configured to write protect any RAM, and in any case you could just re-program it if it was. See this thread: Getting CPU configuration from CP15 and this page Developer Technical Documents - CHDK Wiki for various related ARM docs.

The address you mention is in ROM. Perhaps your value gets written to cache, and then evicted. Of course it is flash ROM, so you could overwrite it if you really wanted, but down that road lies void warranties and expensive paperweights.

It did occur to me that you could hijack ROM code by
- setting a protection region that prohibits reading
- setting an exception handler to handle that exception
- using that to divert to your own code.

However, there are some very severe limitations: There are only 7 protection regions, and most of them are already set by the firmware. To catch one or two functions, you'd generate a whole bunch of exceptions on other stuff (regions have a minimum size of 4k) and there's all kinds of ways it could go wrong.
Logged
Don't forget what the H stands for.
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Code injection
« Reply #2 on: 26 / September / 2008, 12:43:21 »
Relating to this, how are CHDK video mode overrides and ewavr's new usb code different from this? Are there tasks involved or something similar that makes replacing code easier in those cases? Because I thought they were implemented by cut & pasting stuff from the firmware and modifying it a bit, which essentially is very similar to what igor wants to do.
Logged
*

Offline igor

  • *
  • 21
Re: Code injection
« Reply #3 on: 26 / September / 2008, 15:46:05 »
>> The address you mention is in ROM. Perhaps your value gets written to cache, and then evicted. Of course it is flash ROM, so you could overwrite it if you really wanted, but down that road lies void warranties and expensive paperweights.

That's fine. Being able to overwrite ROM to modify originals meens I can always revert back by restoring it.
So, then the question is: how to modify ROM? In case of above mentioned example this is just 4bytes.
Could you give me more specific sample of this?
Logged
*

Offline igor

  • *
  • 21
Re: Code injection
« Reply #4 on: 26 / September / 2008, 16:35:17 »
So, I loooked again into IDA and see that there is exposed WriteToRom function and on TX1 here is how it's entry looks like:
....
ROM:FFB45500 sub_FFB45500                            ; CODE XREF: ROM:FF8187D8p
ROM:FFB45500                                         ; sub_FFB3D484+6Cp ...
ROM:FFB45500
ROM:FFB45500 var_1C          = -0x1C
ROM:FFB45500
ROM:FFB45500                 STMFD   SP!, {R4-R8,LR}
ROM:FFB45504                 MOV     R3, #0
ROM:FFB45508                 SUB     SP, SP, #4
ROM:FFB4550C                 SUBS    R5, R2, #0
ROM:FFB45510                 MOV     R4, R0
ROM:FFB45514                 STR     R3, [SP,#0x1C+var_1C]
ROM:FFB45518                 MOV     R8, R1
ROM:FFB4551C                 MOVEQ   R0, #3
ROM:FFB45520                 BEQ     loc_FFB455CC
ROM:FFB45524                 MOVL    R3, 0x3FFFFFE
ROM:FFB45528                 ADD     R7, R4, #0x800000
ROM:FFB4552C                 SUB     R3, R3, #0x3800000
ROM:FFB45530                 CMP     R7, R3
ROM:FFB45534                 BHI     loc_FFB455C8
ROM:FFB45538                 ADDS    R6, R4, R5
ROM:FFB4553C                 BCC     loc_FFB4554C
ROM:FFB45540                 RSB     R3, R4, #0
ROM:FFB45544                 CMP     R3, R5
ROM:FFB45548                 BCC     loc_FFB455C8
ROM:FFB4554C
ROM:FFB4554C loc_FFB4554C                            ; CODE XREF: sub_FFB45500+3Cj
ROM:FFB4554C                 BL      sub_FFB459A8
ROM:FFB45550                 SUB     R0, R0, #1
ROM:FFB45554                 SUB     R0, R0, #0x800000
ROM:FFB45558                 CMP     R0, R6
ROM:FFB4555C                 BCS     loc_FFB45574
ROM:FFB45560                 BL      sub_FFB459A8

This is getting called from multiple palces, but below is one of the calls:

ROM:FFB3D4E0                 MOVL    R0, 0xFFFFE03F
ROM:FFB3D4E4                 SUB     R2, R4, #4
ROM:FFB3D4E8                 SUB     R0, R0, #0x3B
ROM:FFB3D4EC                 ADD     R1, R5, #4
ROM:FFB3D4F0                 BL      sub_FFB45500


As I'm not ARMs asm. guru and if it's of interest, could someone look and see how that call prototype might look like. I assume it should look like memcpy(dst, src, size). But who knows...
As wrong calling of this function might be dangerous, I would prefer only doing this, after some expert will figure out proper prototype.
On the other hand, I'm ready to sacrifice my camera for that purpose and thus possibly help the community...LOL

I feel there might be endless features that could be implemented/simplified should "injection" code works, especially with direct ROM modification. For example, we could probably make CHDK system automatically started by modifying startup camera sequence independent of whether SD card is locked or not... Or we can try intercepting normall processing path with calls to our functions... Or as in example I've provided with LensExtend functionality, fix extended lens position, thus avoiding possibility of that E18 error + annoying mechanical movements. And who knows what else....
« Last Edit: 26 / September / 2008, 16:48:25 by igor »
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Code injection
« Reply #5 on: 26 / September / 2008, 16:51:45 »
Quote from: igor on 26 / September / 2008, 15:46:05
>> The address you mention is in ROM. Perhaps your value gets written to cache, and then evicted. Of course it is flash ROM, so you could overwrite it if you really wanted, but down that road lies void warranties and expensive paperweights.

That's fine. Being able to overwrite ROM to modify originals meens I can always revert back by restoring it.
Not at all true. Just changing one sector may cause a checksum check to fail, and the camera to assume it's damaged. Even if that is not true, you could easily screw up and modify a sector of flash containing something related to the boot process. Then your camera becomes a paperweight. There is a reason CHDK never does this. If you aren't willing  to destroy your camera STOP NOW.

Based on what you've posted so far, it seems to me your current level of knowledge of the cams would lead to a very high risk of this (no offense intended, just an observation that you don't yet seem very familiar with how they work) Again, if you wouldn't be willing to throw your camera in the trash can, don't even try it.

Also keep in mind that anything that modifies the firmware is not likely to ever be accepted into CHDK.

AFAIK, you cannot write just 4 bytes of flash ROM (edit: but I might be wrong, I've not looked into it in detail).

If you really, really want to do this, look for WriteToRom. On the a610-100e (vxworks reference firmware #1) it's located at FFC12900.

fudgey
The normal way CHDK does this is by 1) doing stuff in the startup code 2) intercepting task creation. Both require replicating the stock firmware code up to the point you want to change (minus subroutine calls), rather than just changing specific instructions.
Logged
Don't forget what the H stands for.
*

Offline igor

  • *
  • 21
Re: Code injection
« Reply #6 on: 26 / September / 2008, 17:59:10 »
>> Based on what you've posted so far, it seems to me your current level of knowledge of the cams would lead to a very high risk of this (no offense intended, just an observation that you don't yet seem very familiar with how they work) Again, if you wouldn't be willing to throw your camera in the trash can, don't even try it.

Sure, and you remarks are well taken here. I'm Windows guy. And even on windows I know close to nothing.

On the other hand, from what I understood, set_parameters_data uses ROM to store variables. So, if the hardware checks control sum, how it knows what pages to check? Are those pages somehow marked? If this done on software, where is such code?

Anyway, if community feels that my proposed "sacrifice" is useless, then I rest my case.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Code injection
« Reply #7 on: 26 / September / 2008, 18:31:43 »
Quote from: igor on 26 / September / 2008, 17:59:10
On the other hand, from what I understood, set_parameters_data uses ROM to store variables. So, if the hardware checks control sum, how it knows what pages to check? Are those pages somehow marked? If this done on software, where is such code?
There are some strings and such that refer to ROM checksum. I have no idea whether this is only used in response to diagnostic commands, or is checked at bootup. It would be easy for it to only check a range of addresses, not including the param values. Again, this isn't something I've looked into much, just one possible way in which you could permanently brick your camera.

There is also some logging stuff that writes crash logs to ROM, which some people have enabled.

Quote
Anyway, if community feels that my proposed "sacrifice" is useless, then I rest my case.
My personal opinion is that it is very unlikely that CHDK would ever include code that modifies the canon firmware in flash. However, that's just my opinion, and there is certainly a lot of interesting stuff you could do if you went that route (the memory size limitations for example would pretty much go away, and changing things that are deep in a bunch of subroutine calls would be a lot easier.)

The problem is that if you ever distributed such a thing, you would very likely have people destroying their cameras. Not only would many of these people be angry (even if they had been warned at it was their fault, look at the number of people who try to run the wrong CHDK version etc), it would eventually get back to canon, and canon might be encouraged to shut the whole thing down.
Logged
Don't forget what the H stands for.
*

Offline igor

  • *
  • 21
Re: Code injection
« Reply #8 on: 26 / September / 2008, 18:46:10 »
reyalp,

Just for my personal curiosity, could you refference me to something that might allow full ROM replacement. Canon does it on frmware update.
So, what I might hypothetically be looking into is being able to just modify ROM dump and upload it back to the camera. Maybe there is a simple way to do that? So, if this works then maybe I don't need to "inject" anything on the fly, but instead just have customized firmware.
And if just "unimportant" places of firmware are touched, not related to boot or upgrade, and assuming there is no checksum check, then there is always way to revert back to original.
« Last Edit: 26 / September / 2008, 18:49:34 by igor »
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Code injection
« Reply #9 on: 26 / September / 2008, 19:33:30 »
I'd suggest you study the canon firmware updaters if you want to do that. You can find links here FAQ - CHDK Wiki

Relatively speaking, it shouldn't be too hard. From what I understand, the PS.FIR method of booting CHDK uses the start of the update process to get running. However, for the reasons I've explained above, I don't have any interest in investigating this stuff, so I certainly won't be able to help you with the details. There are plenty of interesting, useful things to do in CHDK without changing the canon firmware.

I will warn again (yes, I know, I'm repeating) that assuming that you fully understand the process and assuming that you are only changing unimportant parts is a risky plan. We're all human, and we all make mistakes. Making plans that depend on not making mistakes is generally not an effective way of avoiding them.

There's also some risk involved in updating the firmware (i.e. your batteries or SD card go bad in the middle of the process). These risks should be pretty small, but if you are developing replacement firmware, you'll be flashing a lot.
Logged
Don't forget what the H stands for.
Pages: [1] 2   Go Up
« previous next »
 

Related Topics