Messages

Hi,
as winter comes and the "stay home and safe thing" continues I might be interested in testing that hardware thingy.

So a task proposed by @a1ex was to make qemu export function calls directly in r2 format.
Here is what I came up with. To be honest I just poked the code and it magically worked right away. (I'm still trying to shut my mouth on the techniques used in qemu_log.c to produce the input parameter including command line doc )
Here's what I did. In log.h add a line (around line 85):

Code Select Expand


#define EOS_LOG_R2         (1LL << 59)      /* export unique calls to radare2 */

in qemu_log.c below EOS_LOG_IDC:

Code Select Expand

   
{ EOS_LOG_R2  | EOS_LOG_CALLSTACK | CPU_LOG_TB_NOCHAIN, "r2",
        "EOS: export called functions to radare2 (implies callstack,nochain,singlestep)" },

and finally in logging.c

Code Select Expand


static FILE * r2 = NULL;

/* QEMU is usually closed with CTRL-C, so call this when finished */
static void close_r2(void)
{
    fprintf(r2, "\n");
    fclose(r2);
    fprintf(stderr, "%s saved.\n", idc_path);
}

static void eos_r2_log_call(EOSState *s, CPUState *cpu, CPUARMState *env,
    TranslationBlock *tb, uint32_t prev_pc, uint32_t prev_lr, uint32_t prev_size)
{
    static int stderr_dup = 0;

    if (!r2)
    {
        snprintf(idc_path, sizeof(idc_path), "%s.r2", MACHINE_GET_CLASS(current_machine)->name);
        fprintf(stderr, "Exporting called functions to %s.\n", idc_path);
        r2 = fopen(idc_path, "w");
        assert(r2);

        atexit(close_r2);

        fprintf(r2, "# List of functions called during execution. */");
        fprintf(r2, "# Generated from QEMU. \n\n");

        stderr_dup = dup(fileno(stderr));
    }

    /* bit array for every possible PC & ~3 */
    static uint32_t saved_pcs[(1 << 30) / 32] = {0};

    uint32_t pc = env->regs[15];
    uint32_t lr = env->regs[14];
    uint32_t sp = env->regs[13];

    /* log each called function to IDC, only once */
    int pca = pc >> 2;
    if (!(saved_pcs[pca/32] & (1 << (pca%32))))
    {
        saved_pcs[pca/32] |= (1 << pca%32);

        /* log_target_disas writes to stderr; redirect it to our output file */
        /* todo: any other threads that might output to stderr? */
        assert(stderr_dup);
        fflush(stderr); fflush(r2);
        dup2(fileno(r2), fileno(stderr));
        fprintf(stderr, "  /* from "); log_target_disas(cpu, prev_pc, prev_size, 0);
        fprintf(stderr, "   *   -> "); log_target_disas(cpu, tb->pc, tb->size, 0);
        char * task_name = eos_get_current_task_name(s);
        fprintf(stderr, "   * %s%sPC:%x->%x LR:%x->%x SP:%x */\n",
            task_name ? task_name : "", task_name ? " " : "",
            prev_pc, pc, prev_lr, lr, sp
        );
        fprintf(stderr, "  s 0x%X \n", pc);
        env->thumb == 1? fprintf(stderr, "  afB 16\n af @ 0x%X\n", pc):fprintf(stderr, "  af @ 0x%X\n", pc);
        //TODO find solution for name   printf("afn 0x%08X %s\n",ea,name);
        fprintf(stderr, "\n");
        dup2(stderr_dup, fileno(stderr));
    }
}


Maybe I find some time and integrate the function  with the original idc function and don't duplicate code.
And then use the script from a1ex to create the "afn" commands.

Included this in the install script. Please test, in particular on Mac, WSL, 32-bit Ubuntu and 64-bit Ubuntu.

I tested it on Mac without the PATH to gdb set the first time it complained about the gdb being there and told me how to export the PATH. I did that.
Second run it complained about gdb being V7 it did install V8 then and told me to export PATH again.
Third time round it did the normal routine of compiling qemu.
So thumbs up from me.

Hi everyone,
I did this post the originally over at the QEMU thread as most of the stuff in here will be using the QEMU gdbserver as the host system. a1ex suggested I open a new sticky thread here (@a1ex I think for the sticky part one needs to be a bit higher in hierarchy  )
I got some PNs here regarding the use of radare2 for debugging. I thought I might share some of the things I use and some ideas I have for it on the qemu side and maybe someone joins in on it. 
So first of all why radare2 its not the standard used by the other guys here. Well frankly IDA pro with ARM debugging cost more than a Camera which has features of MagicLantern available and on gdb was never my thing. I like that r2 is free and there are lots of articles on reversing with it. It can do ARM and ARM Thumb and has scripting (python, java ruby ...) interface. It has even an build in emulation which is quite capable of running emulating stuff without qemu.
So lets start.
First you can connect radare2 to QEMU like you would with gdb (-s -S or in the nc qemu.monitor and gdbserver)
The start r2 with the following:

Code Select Expand

r2 -i load_db.r2 -d gdb://localhost:1234
so what is load_db.r2? It is a file giving lots of commands for a good setup here are some of the things I put in it:

Code Select Expand


## Pretty stuff
# Solarized theme
eco solarized
# Use UTF-8 to show cool arrows
e scr.utf8 = true
e scr.utf8.curvy=true
# Show comments at right of disassembly if they fit in screen
e asm.cmtright=true
## Processor stuff
# set arch and cpu type
e io.va = true
e asm.arch = arm
e asm.bits = 16
e asm.cpu=cortex
# anal.armthumb (aae computes arm/thumb changes (lot of false positives ahead))
e anal.armthumb=true
# Shows pseudocode in disassembly. Eg mov eax, str.ok = > eax = str.ok
e asm.pseudo = true
# (Show ESIL instead of mnemonic)
# e asm.esil = true
# Selected: asm.describe (Show opcode description)
e asm.describe = false
#asm.emu (Run ESIL emulation analysis on disasm)
e asm.emu = true
e asm.section.sub = true
e io.va=true

that was quite generic and the comments should tell ya whats happening. The following is camera specific it sets up memory regions and gives names to these regions.

Code Select Expand


S 0x00000000 0x00000000 0x00003fff tcmcode mrwx #00000000 - 00003FFF: eos.tcm_code
S 0x00004000 0x00004000 0x1FFFC000 eosram mrw- #00004000 - 1FFFFFFF: eos.ram
S 0x40000000 0x40000000 0x00004000 eosramuncached0 mrw- #40000000 - 40003FFF: eos.ram_uncached0
S 0x40004000 0x40004000 0x1FFFC000 eosramuncached mrw- #40004000 - 5FFFFFFF: eos.ram_uncached
S 0x80000000 0x80000000 0x00010000 tcmram mrw- #80000000 - 8000FFFF: eos.tcm_data
S 0xBFE00000 0xBFE00000 0x00200000 eosramextra mrw- #BFE00000 - BFFFFFFF: eos.ram_extra
S 0xc0000000 0xc0000000 0x20000000 eosiomem mrw- #C0000000 - DFFFFFFF: eos.iomem
S 0xfc000000 0xfc000000 0x20000000 eosrom1 mr-x #FC000000 - FDFFFFFF: eos.rom1
S 0xfe000000 0xfe000000 0x20000000 eosrom1m mr-x#FE000000 - FFFFFFFF: eos.rom1_mirror

the next lines will setup analysis and define some flags in memory taken from debugmsgs.gdb. r2 uses flags for everything and if I understand documentation right functions follow a fcn.<name> scheme. I have so far not been able to use the afn command to create functions but more later. It would be possible to define these flags as breakpoints and put a modified version of a1ex script for indentifiying functions here. Speaking of which.
I used the script of a1ex to create as described above in this thread an .idc file.
Here I modified the header as follows:

Code Select Expand


#include "stubshelper.h"

int  main(void)
{
  MakeAutoNamedFunc(0xFE0FD5C9, "LoadScript");


and another file stubhelper.h 

Code Select Expand


#include <stdio.h>


void MakeAutoNamedFunc(unsigned int ea ,char name[])
{
  printf("af @ 0x%08X\n",ea);
  printf("afn 0x%08X %s\n",ea,name);
}

void NSTUB(unsigned int ea ,char name[])
{
  printf("af @  0x%08X\n",ea);
  printf("afn 0x%08X %s\n",ea,name);
}

compile and pipe the output to your load_db.r2
Loading can Take a while now

Code Select Expand


s <name>
VV
to inspect a function.


Ideas:
- Use the strings file generate from disassemble.pl to define Strings in the same way as the functions.
- Radare provides a scripting interface. Use python script to search through memory for e.g. Frambuffer
- define Names for IO areas to have them marked in the assembly
- is it possible to use the signaturez function of radare to help speedup new firmware ports or new ports.
- as a1ex suggest generating the memory map from qemu
- write my own hook into register function to create the functions.
- use projects to store the reverse engineered data
- ...

Questions:
- anyone got a better idea on how to define functions
- functions from the qemu idc file sometimes seem to be "one off"

Further reading:
- i found this Video of a talk very helpful where the inventor of radare describes how to use it to reverse an ARM based radio: http://radare.org/r/talks.html the talk in 2017. I have not yet looked into the possibility of emulation of io devices via the scripted breakpoints ...

Hi guys,
didn't have much time lately. But nonetheless I got some PNs here regarding the use of radare2 for debugging. I thought I might share some of the things I use and some ideas I have for it on the qemu side and maybe someone joins in on it.
So first of all why radare2 its not the standard used by the other guys here. Well frankly IDA pro with ARM debugging cost more than a Camera which has features of MagicLantern available and on gdb I was never able to get a decent gui running and its missing some features I like its free and there are lots of articles on reversing with it. It can do ARM and ARM Thumb and has scripting (python, java ruby ...) interface. It has even an build in emulation which is quite capable of running emulating stuff without qemu.
So lets start.
First you can connect radare2 to QEMU like you would with gdb (-s -S or in the nc qemu.monitor and gdbserver)
The start r2 with the following:

Code Select Expand

r2 -i load_db.r2 -d gdb://localhost:1234
so what is load_db.r2? It is a file giving lots of commands for a good setup here are some of the things I put in it:

Code Select Expand


## Pretty stuff
# Solarized theme
eco solarized
# Use UTF-8 to show cool arrows
e scr.utf8 = true
e scr.utf8.curvy=true
# Show comments at right of disassembly if they fit in screen
e asm.cmtright=true
## Processor stuff
# set arch and cpu type
e io.va = true
e asm.arch = arm
e asm.bits = 16
e asm.cpu=cortex
# anal.armthumb (aae computes arm/thumb changes (lot of false positives ahead))
e anal.armthumb=true
# Shows pseudocode in disassembly. Eg mov eax, str.ok = > eax = str.ok
e asm.pseudo = true
# (Show ESIL instead of mnemonic)
# e asm.esil = true
# Selected: asm.describe (Show opcode description)
e asm.describe = false
#asm.emu (Run ESIL emulation analysis on disasm)
e asm.emu = true
e asm.section.sub = true
e io.va=true

that was quite generic and the comments should tell ya whats happening. The following is camera specific it sets up memory regions and gives names to these regions.

Code Select Expand


S 0x00000000 0x00000000 0x00003fff tcmcode mrwx #00000000 - 00003FFF: eos.tcm_code
S 0x00004000 0x00004000 0x1FFFC000 eosram mrw- #00004000 - 1FFFFFFF: eos.ram
S 0x40000000 0x40000000 0x00004000 eosramuncached0 mrw- #40000000 - 40003FFF: eos.ram_uncached0
S 0x40004000 0x40004000 0x1FFFC000 eosramuncached mrw- #40004000 - 5FFFFFFF: eos.ram_uncached
S 0x80000000 0x80000000 0x00010000 tcmram mrw- #80000000 - 8000FFFF: eos.tcm_data
S 0xBFE00000 0xBFE00000 0x00200000 eosramextra mrw- #BFE00000 - BFFFFFFF: eos.ram_extra
S 0xc0000000 0xc0000000 0x20000000 eosiomem mrw- #C0000000 - DFFFFFFF: eos.iomem
S 0xfc000000 0xfc000000 0x20000000 eosrom1 mr-x #FC000000 - FDFFFFFF: eos.rom1
S 0xfe000000 0xfe000000 0x20000000 eosrom1m mr-x#FE000000 - FFFFFFFF: eos.rom1_mirror

the next lines will setup analysis and define some flags in memory taken from debugmsgs.gdb. r2 uses flags for everything and if I understand documentation right functions follow a fcn.<name> scheme. I have so far not been able to use the afn command to create functions but more later. It would be possible to define these flags as breakpoints and put a modified version of a1ex script for indentifiying functions here. Speaking of which.
I used the script of a1ex to create as described above in this thread an .idc file.
Here I modified the header as follows:

Code Select Expand


#include "stubshelper.h"

int  main(void)
{
  MakeAutoNamedFunc(0xFE0FD5C9, "LoadScript");


and another file stubhelper.h 

Code Select Expand


#include <stdio.h>


void MakeAutoNamedFunc(unsigned int ea ,char name[])
{
  printf("f %s = 0x%0X\n",name,ea);
}

void NSTUB(unsigned int ea ,char name[])
{
  printf("f %s = 0x%0X\n",name,ea);
}

compile and pipe the output to your load_db.r2
inside radare2 you can now use

Code Select Expand


af @@@f
s fcn.<name>
Vpp
to inspect a function.

Ideas:
- Radare provides a scripting interface. Use python script to search through memory for e.g. Frambuffer
- define Names for IO areas to have them marked in the assembly
- is it possible to use the signaturez function of radare to help speedup new firmware ports or new ports.
- ...

Questions:
- anyone got a better idea on how to define functions

Further reading:
- i found this Video of a talk very helpful where the inventor of radare describes how to use it to reverse an ARM based radio: http://radare.org/r/talks.html the talk in 2017. I have not yet looked into the possibility of emulation of io devices via the scripted breakpoints ...

Does this work on Mac, or it's back to square one?

Well no error and if this output is expected yes

Code Select Expand


./findstub.py 750D
Test run...
./run_canon_fw.sh 750D,firmware=";boot=0" -d calls,tail -display none -monitor stdio -serial file:uart.log
    call 0xFE3CDF44(fe1f845c "PowerMgr", 20, 400, fe1f82e9)                      at [init:fe1f837d:fe506533]

Task found

    211B CreateStateObject
    1775 register_interrupt
80001FC5 create_semaphore
    1E45 task_create
     ??? DebugMsg
     ??? create_msg_queue
FE445CB9 register_func


@dfort:
well lets do a "watch check":

Code Select Expand


$ ansi2txt -v
ansi2txt - version 0.2.2, compiled on May  1 2018 at 13:15:18.

$ bash --version
bash --version
GNU bash, version 4.4.19(1)-release (x86_64-apple-darwin16.7.0)

$ ggrep -V
ggrep -V
ggrep (GNU grep) 3.1
Packaged by Homebrew


I noticed that I already have an alias grep=... in my bash_profile so that might be a reason.
If I run the script I need to have a delay greater 30 seconds to get the stubs.

Hi a1ex,
it's a bit confusing for newbies like me that you are updating the original posts. I was looking in hg for the script and thought man what did I miss ... but found it on page 12
The alias for Mac doesn't work ... may I suggest the following

Code Select Expand


...
GREP=grep
if [ $(uname) == "Darwin" ]; then
    if [[ -n $(which ggrep) ]]; then
        export GREP=ggrep
    else
        echo
        echo "Error: you need GNU grep to run this script"
        echo "brew install grep"
        exit 1
    fi
...

and then a s/grep/\$GREP/g

Hey a1ex,
I got it working.
- As written before export TERM=ansi
- font to 11 and fullscreen does only work up to a point and the output will wrap on the middle of screen.
- I had to eliminate the monitor and nodisplay options and run qemu into a file (this way I discovered it would crash, but it was enough to get the task and other calls except mpu).
- put something like :

Code Select Expand

test_run=$(cat test_run.txt) in the script.

The weekend is full now but maybe I can post some progress on the 750D now on sunday night.

font :
nope ..
here is the output of the find  stub script

Code Select Expand


b *0xFE172BB2
task_create_log

# from 750D/debugmsg.gdb
b *0xFE52F980
assert_log

# from 750D/debugmsg.gdb
b *0x1774
register_interrupt_log

# from 750D/debugmsg.gdb
b *0xFE445CB8
register_func_log

# from 750D/debugmsg.gdb
b *0x...
mpu_send_log

# from 750D/debugmsg.gdb
b *0x...
mpu_recv_log

b *0xFE3CDFE4
create_semaphore_log

b *0x1C18
create_msg_queue_log

b *0x211A
CreateStateObject_log

for today I'm done ... I'll grab a beer and the camera and enjoy the nice weather and sunset out at the lake

Terminal full screen width.
And I've now even used ggrep and declared export TERM=ansi

Code Select Expand


      call 0xFE3CDE84(c0003, 60000053, 1, 5)
         at [SFRead:fe32bd4f:fe32a717]
       -> 0x186F                                                                           at [SFRead:fe3cde84:fe32bd53]

        call 0xFE3CDF94(90007, 0, 73, 0)
   at [TaskMain:fe1c1c7f:fe2eb9fb]
         -> 0x800020B3                                                                         at [TaskMain:fe3cdf94:fe1
c1c83]
         call 0x800056DC(2ee300, 0, 73,  0)
    at [TaskMain:800020bb:fe1c1c83]
          -> 0xFE172B85                                                                        at [TaskMain:800056dc:800


I thought I had left such problems back in 1998 ... 

I'm still figuring my way through radare2,

well maybe I've got something
try adapting the following to your specific camera layout

Code Select Expand


# Show comments at right of disassembly if they fit in screen
e asm.cmtright=true

# Shows pseudocode in disassembly. Eg mov eax, str.ok = > eax = str.ok
e asm.pseudo = true
# (Show ESIL instead of mnemonic)
# e asm.esil = true

# Selected: asm.describe (Show opcode description)
e asm.describe = false

#asm.emu (Run ESIL emulation analysis on disasm)
e asm.emu = true

# Solarized theme
eco solarized

# Use UTF-8 to show cool arrows
e scr.utf8 = true
e scr.utf8.curvy=true

# set arch and cpu type
e io.va = true
e asm.arch = arm
e asm.bits = 16
e asm.cpu=cortex
# anal.armthumb (aae computes arm/thumb changes (lot of false positives ahead))
e anal.armthumb=true

# initialize esil vm
#e esil.stack.addr = 0x20000000
#e esil.stack.size = 0x000f0000

e asm.section.sub = true
e io.va=true

#S ${esil.stack.addr} ${esil.stack.addr} ${esil.stack.size} ${esil.stack.size} ram mrwx

#00000000 - 00003FFF: eos.tcm_code
S 0x0000000 0x00000000 0x3fff 0x3fff tcmcode mrwx

#00004000 - 1FFFFFFF: eos.ram
S 0x00004000 0x00004000 0x1FFFBFFF 0x1FFFBFFF  eosram mrw-

#40000000 - 40003FFF: eos.ram_uncached0
S 0x40000000 0x40000000 0x3fff 0x3FFF  eosramuncached0 mrw-

#40004000 - 5FFFFFFF: eos.ram_uncached
S 0x40004000 0x40004000 0x1FFFBFFF 0x1FFFBFFF  eosramuncached mrw-

#80000000 - 8000FFFF: eos.tcm_data
S 0x80000000 0x80000000 0xffff 0xffff tcmram mrw-

#BFE00000 - BFFFFFFF: eos.ram_extra
S 0xBFE00000 0xBFE00000 0x1fffff 0x1fffff  eosramextra mrw-

#C0000000 - DFFFFFFF: eos.iomem
S 0xc0000000 0xc0000000 0x1fffffff 0x1fffffff  eosiomem mrw-


#FC000000 - FDFFFFFF: eos.rom1
#FE000000 - FFFFFFFF: eos.rom1_mirror
S 0xfc000000 0xfc000000 0x1fffffff 0x1fffffff  eosrom1 mr-x
S 0xfe000000 0xfe000000 0x1fffffff 0x1fffffff  eosrom1m mr-x

aa
aaa
aae
e anal.hasnext = true
# e io.sectonly = true
e search.in = io.sections.exec
#aac
dbe 0xFE020000


(taken from https://vimeo.com/211371081 and adapted to 750D)
then leave this open in a text editor
start qemu .... -S -s  and  radare with :

Code Select Expand


r2 -aarm -b16 -d gdb://localhost:1234

paste the commands above into radare (loading as a startup script does not seem to work with gdb option)
hit vv and start debugging.

hmm ...

Code Select Expand


9:1eb5]
   return 0 to 0x1EB5                                                                               at [init:80000d23:fe
0ce235]
  return 48000e to 0xFE0CE235                                                                                at [init:1e
81:80001735]
  call 0xFE3CDF44(fe0ce600 "TaskMain", 1d, 0, fe0cd4a9)

looks different

It found the task create at

Code Select Expand

b *0xFE172BB2
task_create_log
And no command line is:

Code Select Expand

./run_canon_fw.sh 750D,firmware="boot=0" -d debugmsg -s -S
Will try to reset to default task_create.

Okay I've started completely clean and I now get a lot more functions but still a lot of these:

Code Select Expand


  MakeAutoNamedFunc(0x00002404, "�F�F��V��_task");
  MakeAutoNamedFunc(0x0000240E, "�F�F��V��_task");
  MakeAutoNamedFunc(0x00002418, "�F�F��V��_task");
  MakeAutoNamedFunc(0x00002422, "�F�F��V��_task");


Okay thanks @dfort for testing.
Should I turn this script into a complete cross chain builder that in the end might even reside in the ML directory universe? That way we would have an reference compiler chain that should render the same results on all platforms (notice the should and not will ).

But back to the original topic on finding stubs. @a1ex I now get a lot of functions with weird binary names in the idc file. Is that normal or do I need to investigate?

Hey a1ex,
its a bit rough for start but it works. Seems like gdb 8 resolves the issue with the temporary breakpoints.

Code Select Expand


#!/bin/bash

# Mirror of gnu.org to be used.
MIRROR=https://ftp.gnu.org/gnu

#create Directory
mkdir ~/crossgcc
cd ~/crossgcc

mkdir src
cd src

# get a bunch of stuff
wget -c $MIRROR/gdb/gdb-8.1.tar.xz

# let's unpack
tar jxf gdb-8.1.tar.xz

# now build
# read about CC='gcc -m32' but also that newer gdb should handle 32 bit fine ...
mkdir build-gdb
cd build-gdb
../gdb-8.1/configure --target=arm-none-eabi --prefix=$HOME/crossgcc/
make all install 2>&1 | tee make.log
echo "Done, please add: "
echo $HOME/crossgcc/bin
echo "to your PATH"

Can someone with a mac verify.

oh you mean the warning with 64 bits and issues and stuff  never heard from that 
I'll look how to get a 32 bit gdb to work. From what I've read in the past it might be time consuming.

Hey dfort,
hmm strange I see your error when I run without the

Code Select Expand

2>&1 | ansi2txt portion,
but it seems to work ok when I add it.
I had to increase the time in the script to 60s to get most of the breakpoints right (still missing mpg_rec_log and mph_send_log) but otherwise it is working out.
Question:
When I now start qemu with -s -S and attach the debugger with -x debugmsg.gdb, the gdb will create a temporary breakpoint for each semaphore, msg_queue and so on. These breakpoints can not be stepped by with c only by disabling them? This is not happening while it is running over e.g. the function_register_log, how can I prevent this other than removing it from the .gdb file?

Some observations:
I got myself a cheap camera grip with battery that has the needle connections for the "maybe" serial IO equipped. I soldered some connections to it and with a hint from ant123 I've been able to identify some candidates

original thread

But so far I can't get it to talk to me properly.... so I watched the output of qemu with -d uart :

Code Select Expand


[UART]         at 0xFE0204F4:FE02013C ESC[1;33m[0xC0800010] <- 0x19     : ???
[UART]         at 0xFE020500:FE02013C ESC[1;33m[0xC0800018] <- 0x4       : interrupt flags?
[UART]         at 0xFE02050C:FE02013C ESC[1;33m[0xC0800008] <- 0x8081  : Flags?

After some reading on the arm website I suspect the UART to be similar to an IP core they call PL010, as the registers only match here and not the newer PL011. According to the doc the 0x19 in register 0x10 set the divider to 25 which doesn't make sense on a 3.988... clock as in the dock, but if they use a 4Mhz clock that would give exactly 9600 baud. But the other two registers are not to senseful (DCD enable, two stop bits? line return to 0 after send?).  As written above I can't get any senseful bytes out of it, at the moment I suspect my resistor based level shifter puts to much load on the interface.
Also by reading the docs I noticed that newer memory coupled devices on the AXI bus have something like an IDRegister so they can be identified in code. Maybe of interest with other function blocks.

for us mac fanboys

replace

Code Select Expand

|& with

Code Select Expand

2>&1 | in the script

go to source forge, download ansi2txt
untar and change the directories in Makefile to /usr/local/....

Code Select Expand

make && make installl

Code Select Expand

brew install grep
and replace grep with ggrep in the script

this should get the script running....

thanks ant123
I measured some pins to be 3.3 V so assumed that to be the right level... Two resistors later I'm back in the game.
So I think I have to pins which have some communication going on.
- the first is on the battery itself (BAT1), which seems to be logic as Canon can identify fake and third party batteries
- the second is the one I call Pin4 in the picture. Here I find something that could be like the output in qemu but at incorrect baud rate and bits have to investigate further...

Hi all,
has anyone ever got this to work? Here are my findings on the 750D.
I tried to use a cheap battery grip on my 750D and soldered a wire to all twelve pins and the two battery pins to get an outside connection.
Then I tried to hook up a buspirate http://dangerousprototypes.com/docs/Bus_Pirate and get a serial connection. To get a potential reaction I used a bootable card without the autoexec.bin file. But after probing all pins I get no connection. So if no-one has a good idea that I should try I will get rid of the wires and start using the grip again.

Hey space928,
maybe I go first and tell my understanding and a1ex can correct me  .
So lets start with a working autoexec.bin for the 750D, the SFDUMPER

I understand that there is a part in DryOS which looks for an autoexec.bin if the boot flag is enabled.
This happens after the Bootloader finished and some hardware is set up and the main kernel is being copied to RAM (we see later) .

enter minimal.c

this seems to be our main()

Code Select Expand


void
__attribute__((noreturn,noinline,naked))
copy_and_restart( int offset )
{

here we clean some memory with 0 values:

Code Select Expand

     zero_bss();

This part is well documented:

Code Select Expand



     // Copy the firmware to somewhere safe in memory
     const uint8_t * const firmware_start = (void*) ROMBASEADDR;
     const uint32_t firmware_len = RELOCSIZE;
     uint32_t * const new_image = (void*) RELOCADDR;

     blob_memcpy( new_image, firmware_start, firmware_start + firmware_len );

     /*
      * in cstart() make these changes:
      * calls bzero(), then loads bs_end and calls
      * create_init_task
      */
     // Reserve memory at the end of malloc pool for our application
     // Note: unlike most (all?) DIGIC 4/5 cameras,
     // the malloc buffer is specified as start + size (not start + end)
     // so we adjust both values in order to keep things close to the traditional ML boot process
     // (alternative: we could adjust only the size, and place ML at the end of malloc buffer)
     uint32_t ml_reserved_mem = (uintptr_t) _bss_end - INSTR( HIJACK_INSTR_BSS_END );
     INSTR( HIJACK_INSTR_BSS_END     ) += ml_reserved_mem;
     INSTR( HIJACK_INSTR_BSS_END + 4 ) -= ml_reserved_mem;


Now its becoming interesting we "bend" the vector for the init_task:

Code Select Expand


     // Fix the calls to bzero32() and create_init_task()
     FIXUP_BRANCH( HIJACK_FIXBR_BZERO32, my_bzero32 );
     FIXUP_BRANCH( HIJACK_FIXBR_CREATE_ITASK, my_create_init_task );

     // Set our init task to run instead of the firmware one
     INSTR( HIJACK_INSTR_MY_ITASK ) = (uint32_t) my_init_task;

     // Make sure that our self-modifying code clears the cache
     sync_caches();

and last we call the function:

Code Select Expand

     // We enter after the signature, avoiding the
     // relocation jump that is at the head of the data
     // this is Thumb code
     MEM(0xD20C0084) = 0;
     thunk __attribute__((long_call)) reloc_entry = (thunk)( RELOCADDR + 0xC + 1 );
     reloc_entry();

so at the moment we don't return from this but normally this would be just a call for a task in DryOS and the normal boot routine resumes at the vector we've bend above.

So the tasks at the moment:
- find the stubs (addresses) of the functions needed for the blind dump to work, as we experienced with the dumper these can hide in RAM or ROM as the kernel gets copied at startup (see above)
- with the stubs in place the firmware can resume booting and have our code as a task.
- we can dump the memory and search for whatever is needed

Question from me if ant123 is still reading on the CHDK M3 porting thread you mentioned finsig back in 2015 I haven't read all the 47 Pages yet but did you have any luck with the new finsig_thumb2? The M3 seems to be on the same DryOS release (55) as the 750D. If I try to generate stubs as described in the wiki it it will produce some warnings and then nothing more after 4 hours of generating sporadic high CPU Load I killed it.

space928 did you try https://bitbucket.org/t3r4n/magic-lantern/commits/da8cd6246673b1512749bd5919279ff956d9e62e?at=sf_dump_trial on your camera?