New stubs/signature finder (gensig2/finsig2) for DryOS cameras. - page 10 - General Discussion and Assistance - CHDK Forum  

New stubs/signature finder (gensig2/finsig2) for DryOS cameras.

  • 103 Replies
  • 32597 Views
*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #90 on: 30 / August / 2013, 19:13:31 »
Advertisements
Revision 3049 (trunk) includes these updates to finsig_dryos.c:
- Unused functions not written to stubs_entry.S
- Two new files created:
    - funcs_by_name.csv = all detected function names and addresses sorted by name
    - funcs_by_address.csv = all detected function names and addresses sorted by name
- A lot more functions detected (searches for all calls to ExportToEventProcedure and RegisterEventProcedure)

Functions found with the new detection code are written with '_FW' at the end of the name. This is to avoid clashes with the older detection which may find a different function; but use the same name- e.g. EngDrvIn and EngDrvIn_FW.

In some cases the address passed to ExportToEventProcedure or RegisterEventProcedure will just be a branch instruction to another address. In this case two entries are written, the first one to the branch will have 'j_' added at the start of the name.
Thanks, and sorry about not noticing that patch.

There are several functions whose names are not known (for example many members of the EngDrv family), and it isn't always easy to work out what they do exactly. Can you suggest a naming scheme for these?

Can you give me some examples?

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4426
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #91 on: 31 / August / 2013, 08:17:24 »
Can you give me some examples?
Sure.
I haven't yet added these to the sigfinder, so addresses only.
a470, 102c
After the non-eventproc version of EngDrvBits
sub_ffc12b80
sub_ffc12bc8
sub_ffc12be0
sub_ffc12bf8
sub_ffc12c24
sub_ffc12c38
sub_ffc12c58

Actually, there are names available for a few of these in DSLR dumps, but that code is different enough to make identification harder (the DSLR code is using a different EngDrv lib). One could come up with names based on the known EngDrv related function names, but that would require some functional analysis.
There are other widely used functions without any hint to their name - for example the ones located in Canon's PropertyCase.c library. Could some generic naming scheme be used for these? Something like propcase_function_1 which can later get a more sensible name?

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #92 on: 31 / August / 2013, 08:41:59 »
Can you give me some examples?
Sure.
I haven't yet added these to the sigfinder, so addresses only.
a470, 102c
After the non-eventproc version of EngDrvBits
sub_ffc12b80
sub_ffc12bc8
sub_ffc12be0
sub_ffc12bf8
sub_ffc12c24
sub_ffc12c38
sub_ffc12c58

Actually, there are names available for a few of these in DSLR dumps, but that code is different enough to make identification harder (the DSLR code is using a different EngDrv lib). One could come up with names based on the known EngDrv related function names, but that would require some functional analysis.
There are other widely used functions without any hint to their name - for example the ones located in Canon's PropertyCase.c library. Could some generic naming scheme be used for these? Something like propcase_function_1 which can later get a more sensible name?

The trick is identifying the start and end of the 'library' - if we can do that then the unknown functions could get generic library based names.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4426
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #93 on: 31 / August / 2013, 08:54:45 »
The trick is identifying the start and end of the 'library' - if we can do that then the unknown functions could get generic library based names.
That could be a bit difficult in some cases. In case of EngDrv, the library starts with the function preceding the non-eventproc EngDrvOut and ends with the last function in the above list.
One more problem with this: some libraries can get (and lose) functions during their life, one has to choose a starting point, so that my_unknown_lib_func_1 always identifies the same function.


*

Offline reyalp

  • ******
  • 13456
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #94 on: 01 / September / 2013, 15:05:35 »
Regarding the eventproc listing, I once did something similar (semi-manually) to find (almost) all propcase related calls. This is very handy for finding the actual sizes of propcases and where there are get/set in the canon firmware. See posts in this thread http://chdk.setepontos.com/index.php?topic=2722.msg53483#msg53483
There are a whole family functions like the setprop/getprop functions we use. I am not clear on the differences.

I'm definitely not suggesting this should be a part of finsig, but a smarter version of this could probably be built on the infrastructure finsig uses. It might also be possible to automatically determine if a camera uses a known propset, or even generate the propset.h file values, e.g. a known function refers to propcase_shooting, get the propcase ID from the call.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4426
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #95 on: 12 / September / 2013, 19:38:56 »
I have taken a look at finsig_vxworks and the old sigs. Looks like they are almost compatible (some structs are expanded in finsig_dryos). Could it be possible to somehow integrate its functionality into either finsig_dryos or into a separate sigfinder that is based on finsig_dryos code? I'm perfectly fine with suggestions, I intend to do the vxworks-specific work anyway.
There are several issues currently that desperately need automatically found data - expanding finsig_vxworks is pointless, introducing +1 sigfinder for additional vxworks stuff is also pointless.

*

Offline srsa_4c

  • ******
  • 4426
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #96 on: 01 / November / 2013, 13:54:09 »
Some notes before I forget about them.
In changeset 3194, I have introduced a new function in firmware_load.c: ALUop2a(), as a slightly modified version of ALUop2(). The original function failed on instructions like the following (the only affected firmware was the ixusw_sd430).
Code: [Select]
ff830c38: e3a06163 mov r6, #0xc0000018If it turns out that the modified function is always working correctly, it can of course replace the original one.
If it's desirable to collect helper functions like isBL() in one place, they can be moved into firmware_load.c (or I'll move them). I have recently created a few, but left them finsig_vxworks code (I found them too specific).

*

Offline nafraf

  • *****
  • 1308
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #97 on: 14 / November / 2013, 19:19:15 »
I have seen about 20 models with get_flash_params_count() returning a value different of that detected by signature finder.  Assuming that it is a bug in the port, maybe c&p error, maybe port was done before automatic detection.  I'd like to suggest define flash_params_count in stubs_entry.S and create a generic function that uses it and delete function from platform/*/lib.c.  That would prevent that type of bug on future ports and would fix the existing ones.

 I'm not sure if this function should go in platform/generic/wrappers.c:
Code: [Select]
int get_flash_params_count(void) {
    extern int flash_params_count;
    return flash_params_count;
}

If accepted, I can create the patch.


*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #98 on: 14 / November / 2013, 19:43:10 »
I have seen about 20 models with get_flash_params_count() returning a value different of that detected by signature finder.  Assuming that it is a bug in the port, maybe c&p error, maybe port was done before automatic detection.  I'd like to suggest define flash_params_count in stubs_entry.S and create a generic function that uses it and delete function from platform/*/lib.c.  That would prevent that type of bug on future ports and would fix the existing ones.

 I'm not sure if this function should go in platform/generic/wrappers.c:
Code: [Select]
int get_flash_params_count(void) {
    extern int flash_params_count;
    return flash_params_count;
}

If accepted, I can create the patch.

Haven't tested it; but I think that will treat the 'flash_params_count' value as an address and return the int value stored at that address.
The DEF for 'flash_params_count' should be set to the address where the value is stored, and the get_flash_params_count function should return (flash_params_count & 0xFFF) + 1.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4426
Re: New stubs/signature finder (gensig2/finsig2) for DryOS cameras.
« Reply #99 on: 10 / February / 2014, 18:27:01 »
I have added detection for LEDs on DryOS cameras (to complete what I started). It's not the finest piece of code I admit, but it seems to do the job.
Not all LEDs are found, only the ones that appear in the LED table initializer function I'm evaluating. It's also not known which address corresponds to which physical LED.

 

Related Topics