Continue discussion on the universal dumper idea of mx32

[kangxn]

Copied from dpreview, per mx32's suggestion,

Just want to continue discussion of the universal dumper idea of mx32. I have to admit at the first time I saw it. I thought it was some day dreams, but now I think it is theoretically doable.
The technical problems to have the dumper running in the live OS are:

1: How to prevent the live OS overwriting the space that dumper sits.
2: How to re-gain control when the live OS is running.
3: How to find the FileSystem related API entries in a new live OS.

For 3, it is possible to find the api entry points using function signature, with enough FW dumps we should be able to solve this problem for most of the models.

The hard part is 1 & 2, If we were able to modify the ROM, it could be easy. but it is impossible. mx32's proposal is to use cpu's memory protection unit, I think this is like gamble. I prefer to use the method which CHDK uses currently.

CHDK has the same requirement to hide it self from the live OS. currently, we copy the initialization assembly code from the firmware into CHDK itself. In the initialization code, Canon FW passes the size of its data segment and BSS segment to the init routine. we enlarge the size, and call those routines as original Canon FW does, at last, jump to "the next point" in Canon FW and return control to the FW. so that CHDK cheats the FW and it can hide in Canon FW's data segment.

After some reading on both VXworks and DryOS init code, I found they are mostly identical, I can see the data segment and size at the beginning of the code. So the same trick can work with both vxworks and dryos. problem 1 can be solved if we can use this trick.

How to re-gain control when the OS is running? this is pretty easy, since we copy the code into CHDK, we always have the control before we decide to return it to the OS. A better way may be to create a task using the CreateTask API provided by the FW(thanks god this one is easy to find in Canon FW), after the task system is initialized. so that we can always have cpu time to run during the whole period the OS is running. This is useful if some IO systems like SD card aren't initialized at early stage. problem 2 is solved, too. (Even CHDK for dryos can use this approach, maybe)

So only the most hard problem is left: How can we copy the code like we do in IDA without dumping out the FW? Well. that's why I say this idea is "theoretically doable". It is possible that we write something like a disassembler, it reads the code from the beginning, tracks the execution path and copy the binary opcodes to RAM, then modify the binary codes to fix all the reference to old data and procedures., at last, apply our fix. This sounds like impossible, but it is the major technique used in decent software protectors like StarForce, Themida, ACProtect... Since X86 is a more complex and variable length instruction set, ARM should be much simpler than it. Anyway it require lots of code work, and is not something that can be done quickly....

(In more detail, the idea of copying code is not always doable because sometimes people use LDR PC, reg to do jump, but it seems to be ok for vxworks/dryos initialization code, we don't need to copy all the code in subfunction , we only need to copy the top level code as we do in CHDK, if there is some jump-by-reg code, we don't know how to copy either)
Thanks

[mx3]

idea to use MPU belongs to Cail

> 2: How to re-gain control when the live OS is running.
i think CHDK can't start thread in startup code. why would CHDK need taskcreatehookadd then instead of simply launching its own thread?
why to substitute some thread using hooks instead of killing some thread latter and launching new one own?

it seems it needs some investigation but I think your way to launch code is far more complicated than using MPU.


> use cpu's memory protection unit, I think this is like gamble
yes . it is.
first we need to guess right memory location which is not critical for running OS
there is a big buffer which is used for shoots. it can be used for first stage startup procedure.
after OS starts we can use memAlloc to relocate our code to safe place

anyway we do not need to know exact address of this buffer. we can make one base binary file and patch it so it would use any address we chose. one of them will work.

I don't  know English enough to express my ideas quickly. it takes alot of my time to to make translation.
i think I will make little posts periodicaly instead of one huge

Best regards,
max

[kangxn]

idea to use MPU belongs to Cail

 

>> 2: How to re-gain control when the live OS is running.
>i think CHDK can't start thread in startup code. why would CHDK need taskcreatehookadd then instead of simply >launching its own thread?
>why to substitute some thread using hooks instead of killing some thread latter and launching new one own?

I'm not sure whether CHDK can start thread in startup mode or not.  However,  using taskCreateHookAdd is the most natrual way in my eyes, because you don't want to start both yours and original. Killing a running task may cause unexpected behaviour of the OS, for example, resource leakage.  Also, some of the tasks like "captive" task, may start by the OS for multiple times.  Hooking is the way to change the behaviour.


>it seems it needs some investigation but I think your way to launch code is far more complicated than using MPU.

I agree, my way is by far complicated, the good point is that it is more reliable.

> use cpu's memory protection unit, I think this is like gamble
>yes . it is.
>first we need to guess right memory location which is not critical for running OS
>there is a big buffer which is used for shoots. it can be used for first stage startup procedure.
>after OS starts we can use memAlloc to relocate our code to safe place

>anyway we do not need to know exact address of this buffer. we can make one base binary file and patch it so it would >use any address we chose. one of them will work.

I still don't quite understand how can you gain control after the OS is running. can you explain a little? I understand you can use MPU to protect the dumper not to be overwritten by the OS. but that doesn't mean OS will give you execution time.

>I don't  know English enough to express my ideas quickly. it takes alot of my time to to make translation.
>i think I will make little posts periodicaly instead of one huge

It doesn't matter, I'm not a English speaking person, either. 

>Best regards,
>max

[jeff666]

I had some thoughts about getting control over the device when the OS runs and had the idea of exploting some buffer overflow in (e.g.) the jpeg-viewer.

We do have the firmware and it should be possible to find a vulnerability that can be exploited.

Console hackers regularly use such methods to get their own code running.


Something different:
Yesterday I tried to jump to the official firmware-start to force a boot-loop but it didn't happen.

What I did was

• Turn off an LED (which is on from the previous run)
• Turn on the LED
• Jump to firmware-entrypoint (0xffc00000)

I expected the LED to blink, but it didn't. It went

• on (first run)
• off (second run)
• and on again (still second run)
• remained on, no further activity

Obviously something isn't reset on execution of the bootdisk-loader.

Cheers.

[mx3]

> use cpu's memory protection unit, I think this is like gamble
>yes . it is.
>first we need to guess right memory location which is not critical for running OS
>there is a big buffer which is used for shoots. it can be used for first stage startup procedure.
>after OS starts we can use memAlloc to relocate our code to safe place

>anyway we do not need to know exact address of this buffer. we can make one base binary file and patch it so it would >use any address we chose. one of them will work.

I still don't quite understand how can you gain control after the OS is running. can you explain a little? I understand you can use MPU to protect the dumper not to be overwritten by the OS. but that doesn't mean OS will give you execution time.

code which uses MPU to protect itself can count of writes into specific memory address range
when its count reached some limit we can asume OS already running.
MPU minimal ddress block size = 4kb
OS uses lower memory for it's use very frequently
so it is up to write_counter_limit constant to decide if OS have been started

[kangxn]

> use cpu's memory protection unit, I think this is like gamble
>yes . it is.
>first we need to guess right memory location which is not critical for running OS
>there is a big buffer which is used for shoots. it can be used for first stage startup procedure.
>after OS starts we can use memAlloc to relocate our code to safe place

>anyway we do not need to know exact address of this buffer. we can make one base binary file and patch it so it would >use any address we chose. one of them will work.

I still don't quite understand how can you gain control after the OS is running. can you explain a little? I understand you can use MPU to protect the dumper not to be overwritten by the OS. but that doesn't mean OS will give you execution time.

code which uses MPU to protect itself can count of writes into specific memory address range
when its count reached some limit we can asume OS already running.
MPU minimal ddress block size = 4kb
OS uses lower memory for it's use very frequently
so it is up to write_counter_limit constant to decide if OS have been started

Can you show me the code?  I'm more confused   In my mind once you give execution control to the OS, the OS will keep running and left your code intacted.  You probably can set up exception handler, when OS writes to the address range the cpu will call your handler, but almost all OSes will take over exception handlers for their own use.

Thanks

[kangxn]

I had some thoughts about getting control over the device when the OS runs and had the idea of exploting some buffer overflow in (e.g.) the jpeg-viewer.

We do have the firmware and it should be possible to find a vulnerability that can be exploited.

Console hackers regularly use such methods to get their own code running.


Something different:
Yesterday I tried to jump to the official firmware-start to force a boot-loop but it didn't happen.

What I did was

• Turn off an LED (which is on from the previous run)
• Turn on the LED
• Jump to firmware-entrypoint (0xffc00000)

I expected the LED to blink, but it didn't. It went

• on (first run)
• off (second run)
• and on again (still second run)
• remained on, no further activity

Obviously something isn't reset on execution of the bootdisk-loader.

Cheers.

Using exploit could be a good approach, the problem is that most exploits are FW version dependent. you have to analyze them case by case.  Anyway it can elimate the hardware requirement, which isn't available to people like me.

[mx3]

Can you show me the code?  I'm more confused   In my mind once you give execution control to the OS, the OS will keep running and left your code intacted.  You probably can set up exception handler, when OS writes to the address range the cpu will call your handler, but almost all OSes will take over exception handlers for their own use.

keeping code intact means our code must disassemble instruction and emulate it if write operation destination was not our code address range.
using this method we can prevent OS from installing its own data abort handler

http://tools.assembla.com/chdk/browser/branches/cail-udumper
I have not seen it (last code from Cail) yet, but it is most recent version of code developed to make universal boot loader

[mx3]

so what is going on?
anybody working on it?

it seems to me it is logical to split project into two independent parts :
1) bootloader : MPU powered code or code relocator(as sugested by kangxn)
2) independent .bin file which is loaded by bootloader and do other any thing (load CHDK/make dump/etc)
_______________
bootloader (diskboot.bin)

 mandatory requirements:
- it must know how to find and to use File API
- it must be able to allocate memory in a such a way OS will not touch it in future (it must be made after OS startup)
- it must be able to load secondary independent .bin file into allocated memory and make a call into function located in it

 optional requirements:
- it must pass to secondary loaded module following addresses:
 -- file API entry points
 -- ? mem/threads
_______________
bootloader emulation to test secondary .bin file:
- any camera with CHDK already ported in can be used to emulate launch of secondary .bin file
 -- find file
 -- alloc memory
 -- load file
 -- call function in it
 -- it is assumed that secondary module is going to live until camera is switched off (so no need to call memfree() )
_______________
 
benefits:
- developers can work on independent parts (no matter DryOS/VxWorks, prime(boot) module or second module (CHDK/DUMP))
- work on secondary bin file can be made without worry about loading process
- it is possible to remove native CHDK bootloader from CHDK to simplify porting process
- once second .bin file is compiled it is up to bootloader to load it into alredy working OS



also I sugest anybody interested in this topic to be subscribed to it
Post reply -> Additional Options... -> Notify me of replies.