Any interest for an ARM disassambler? - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply

Any interest for an ARM disassambler?

  • 28 Replies
  • 11744 Views
*

Offline mx3

  • ****
  • 372
Re: Any interest for an ARM disassambler?
« Reply #10 on: 03 / April / 2009, 03:48:39 »
Advertisements
Ok, maybe I don't understand the complexity of the problem, but.. rather than use the MPU and fancy stuff, why not just put a hook in the malloc() function used by the OS and make sure it does not allocate memory in that range? And this hook can be also used to check if the OS is running..

our code planted into RAM when OS is not started yet. there are no mallocs at this stage.
and it is unknown which OS actually we starting - we just return control to ROM boot address - 0xFFFF0000.
main idea of proposed approach to make resident code wich could survive OS start and latter could use hi-level OS functions found by signatures.

lets see some applications of such approach:
1) universal dumper. current version uses low-level sector reading/writing functions to save ROM dump. it works but it would work better if it used fopen, fread, fwrite, fclose functions.

2) universal chdk binary + supplied text file with information specific to some model (sensor size, functions/data addresses).
supose porting process:
 - man loads universal diskboot.bin into NEW not-ported camera.( we assume that universal binary can find atleast fopen, fwrite, fclose functions)
 - binary writes file ROM dump and automatically found function addresses to SD/CF/etc card.
 - at this stage chdk already particulary working.
 - then man gets dump and disassembler to find lacking functions. then he updates text file.
 - annnnd - CHDK is fully ported - no need to compile anything....

skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline RaduP

  • *****
  • 908
Re: Any interest for an ARM disassambler?
« Reply #11 on: 03 / April / 2009, 04:13:39 »
Oh, wait a second, does the camera firmware run directly from the ROM, or is it first transferred in the RAM and then executed from there? Can the ROM functions in the OS be modified to add some hook to them? If not, I guess we have a small problem. If the firmware code inside the camera CAN be modified, then I think I have a relatively simple solution to the problem:
1. Scan the firmware for the malloc() function.
2. Add a hook to it at the beginning, so that whenever it is called it runs out code.
3. Our code would make sure that malloc() never allocates memory where our code is.

If the firmware code can not be modified (by normal means), then maybe we can use the flashing function to write the modified code directly to the ROM, although this can be quite dangerous if not done properly.

*

Offline mx3

  • ****
  • 372
Re: Any interest for an ARM disassambler?
« Reply #12 on: 03 / April / 2009, 04:32:29 »
Oh, wait a second, does the camera firmware run directly from the ROM, or is it first transferred in the RAM and then executed from there? Can the ROM functions in the OS be modified to add some hook to them? If not, I guess we have a small problem. If the firmware code inside the camera CAN be modified, then I think I have a relatively simple solution to the problem:
1. Scan the firmware for the malloc() function.
2. Add a hook to it at the beginning, so that whenever it is called it runs out code.
3. Our code would make sure that malloc() never allocates memory where our code is.

If the firmware code can not be modified (by normal means), then maybe we can use the flashing function to write the modified code directly to the ROM, although this can be quite dangerous if not done properly.

canon firmware runs directly from ROM ( digic processor do not have MMU so we can not map part of RAM over ROM to make patches).

we don't want to change flash :
 1) main idea is to launch code inside unknown environment (we do not know ROM contents beforehand)
 2) few people would like to use hack wich brakes guarantee
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline RaduP

  • *****
  • 908
Re: Any interest for an ARM disassambler?
« Reply #13 on: 03 / April / 2009, 04:52:14 »
Ok, I reread the thread you pointed to earlier, to get a better understanding of what you want.
So basically you want an ARM emulator, not disassembler, to copy the needed code into RAM and patch it so that we can use it for our own purposes?

Now, wouldn't it be more simple to actually 'steal' the functions we are interested in (for example, the file i/o for an universal dumper), then modify them on the PC (where there are no memory or time constraints), and then just pack them in the universal dumper?

I guess the i/o routines should be pretty standard and work the same on all cameras, with little modifications (maybe some memory addresses for i/o are different, but the rest should be the same, right?)


*

Offline mx3

  • ****
  • 372
Re: Any interest for an ARM disassambler?
« Reply #14 on: 03 / April / 2009, 05:16:02 »
So basically you want an ARM emulator, not disassembler, to copy the needed code into RAM and patch it so that we can use it for our own purposes?
embedded arm emulator - yes - to protect code from overwriting.
actually I want nothing. I'm not interested in this project.
it was just idea which CAN be implemented - for any OS (vxWorks, DryOS, linux , you name it).
I did not say it MUST be implemented.

When i saw your thread I decided to bring up old topic.
that is all.

if you like we can talk on this topic outside of forum (IRC, Skype, ICQ, Email) and publish here results .
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline RaduP

  • *****
  • 908
Re: Any interest for an ARM disassambler?
« Reply #15 on: 06 / April / 2009, 01:49:30 »
Ok, I have the first screenshot now, with syntax highlighting.
A lot of the instructions are not supported, but 99.9% of the ones used in the bios dump I have are supported.

I still need to add some code navigation bar and some other features, but so far it works pretty well.
I will post a binary once I add more features.

P.S. I took the liberty to add the conditions before the isntructions, rather than in the instructions themselves. I think it makes the code much more readable.

Re: Any interest for an ARM disassambler?
« Reply #16 on: 06 / April / 2009, 01:57:50 »
looking good, looking forward to use it :) unfortunately i dont know too much about disassm so i cannot beof any help.

*

Offline mx3

  • ****
  • 372
Re: Any interest for an ARM disassambler?
« Reply #17 on: 06 / April / 2009, 03:11:48 »
I will post a binary once I add more features.
why not sources?

P.S. I took the liberty to add the conditions before the isntructions, rather than in the instructions themselves. I think it makes the code much more readable.
copy+paste & compile would be great also.

PS: I think there are free ARM disassemblers

Code: [Select]
$ tar -xvjf binutils-2.17.tar.bz2
$ cd binutils-2.17
$ mkdir build
$ cd build
$ ../configure --target=arm-elf --prefix=$TOOLPATH --enable-interwork --enable-multilib--with-gnu-as --with-gnu-ld --disable-nls
$ make all
$ sudo make install
$ export PATH=${TOOLPATH}/bin:$PATH

Now you have your ARM "binutils" (assembler, linker, disassembler ...) in your PATH.
I think it is possible to build it for windows also...
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler


*

Offline RaduP

  • *****
  • 908
Re: Any interest for an ARM disassambler?
« Reply #18 on: 06 / April / 2009, 04:20:49 »
The sources are too dirty yet, I will need to do some code cleanup.
And yes, I know there are some disassemblers already, but I want something more powerful, with some of the features IDA has.

Quote
copy+paste & compile would be great also.
Is that really needed?

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Any interest for an ARM disassambler?
« Reply #19 on: 06 / April / 2009, 05:48:53 »
The kind of output that can be pasted to CHDK platform code as inline asm would be precious (similar to IDA + asmify.sh). It would simplify things like porting >64 second exposures to new cameras, at least for those of us who don't have IDA. It mainly involves labeling all subroutines that get branched to in the code and doing for 32-bit constants what I think you already did.

This is not the best output for readability, of course, so it can't be the only output format.

 

Related Topics