Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - srsa

Pages: [1]
1
Couldn't trigger it on M2 or 200D - don't know if it's supposed to work there
No, those are fully EOS models codebase-wise.
I posted this in the DIGIC 8 thread because this kind of scripting is expected to work on the mixed codebase models (mostly EOS with some Powershot legacy). Those are the newer Powershots (sx740, sx70, g5xII, g7xIII) and EOS M cameras (M50, M200, M6II). I'm sure about the M50 and sx740 (having seen their firmware), the rest is speculated. No idea about the other DIGIC 8 cameras.
If someone happens to have a firmware dump for any untested models, the presence of some strings ("extend.m", the keywords, etc) may indicate this feature.

I should note that only keywords and syntax are common between the PowerShot and EOS version of Canon Basic, most event procedures are different, the examples from that wiki will not work here.

As for the dump, thanks, but I already have all CHDK-supported fw dumps.

I did not mention it yet, but setting the camera bootflag(s) should also be possible from a script, without requiring an encrypted binary. Executing fw functions (named or not) is also possible.

2
Simple and slow dumper script for cameras with Powershot-legacy (EOS M, PowerShot). It works on at least one model. Whether Canon intends to keep scripting is to be found out.

About the language. Card setup. Note that some people have problems making a usable script card. If that happens, try again.

As usual, please do not post ROM dumps publicly.

Code: [Select]
' hex dumper
dim start = 0xe0000000
dim length = 0x100000

private sub save_as_hex(fn,addr,size)
f = OpenFileCREAT(fn)
CloseFile(f)
f = OpenFileWR(fn)
p = addr
' 1MB ~ 64 sec
do while p < (addr+size)
p1 = *p
p = p + 4
p2 = *p
p = p + 4
p3 = *p
p = p + 4
p4 = *p
p = p + 4
p5 = *p
p = p + 4
p6 = *p
p = p + 4
p7 = *p
p = p + 4
p8 = *p
p = p + 4
WriteFileString(f,"%08x%08x%08x%08x%08x%08x%08x%08x\n",p1,p2,p3,p4,p5,p6,p7,p8)
loop
CloseFile(f)
end sub

private sub Initialize()
save_as_hex("B:/ROM.TXT",start,length)
end sub
I have not been able to find "normal" read()- and write()-like event procedures, thus the hex dump. You may want to adjust 'start' and 'length' at the beginning of the script, but note the time requirement. Camera user interface will be locked up while the script runs.
Any error in the script will crash the camera and require a battery pull.
It appeared to me that these file operations happily make multiple files with the same name when used repeatedly, so be careful.

A C program to turn the word based hex dump to binary:
Code: [Select]
#include <stdlib.h>
#include <stdint.h>
#include <stdio.h>

const char *usage = "Decode hex files made with CBasic EOS dumper (LE words)\n"
"\nUsage: %s <input> <output>\n\n";

int32_t hex2char(uint8_t a) {
if (a<0x30) {
return -1;
}
else if (a<=0x39) {
return a-0x30;
}
a = a & 0xdf;
if (a<0x41) {
return -1;
}
else if (a<=0x46) {
return a - 0x41 + 10;
}
return -1;
}

int hex2uint32(FILE *f, uint32_t *u) {
int32_t n,m;
uint8_t c;
int ret = 0;
*u = 0;
for (n=7; n>=0; n--) {
int r;
c = 0;
r = fread(&c,1,1,f);
if (c == '\n') {
r = fread(&c,1,1,f);
}
if (r<1) {
ret = -1;
break;
}
m = hex2char(c);
if (m>=0) {
*u |= ((uint32_t)m)<<(n*4);
}
}
return ret;
}

FILE *fil;
FILE *filp;

int main(int ac, const char **av) {

if (ac < 3) {
fprintf(stderr, usage, av[0]);
exit(0);
}

const char *fi = av[1];
const char *fp = av[2];

filp = fopen(fp, "w+b");
if (!filp) {
fprintf(stderr,"Failed to open output file\n");
return -1;
}
fil = fopen(fi, "r+b");
if (!fil) {
fprintf(stderr,"Failed to open input file\n");
fclose(filp);
return -2;
}

uint32_t u;
while ( !hex2uint32(fil, &u) ) {
fwrite(&u, 1, 4, filp);
}

fclose(filp);
fclose(fil);

exit(0);
}

3
General Development Discussion / Re: Getting started with development
« on: February 24, 2020, 06:01:01 PM »
So main question for me now is which source branch should i use now as entry point (unified, vxworks, or ...) ?
For some reason, the most obvious candidate wasn't mentioned yet.
The 40D port is in active development. The 40D is a DIGIC III model running VxWorks, with live view. Just like the 1000D.

4
Assuming these questions are still unanswered, I'll try to answer some of them.
In vram.c, vram_update_luts(), which gets called indirectly from call_init_funcs(), there's a loop that initialises a cache of screen coordinates:
A disassembled version of the compiled code could give more hints. The reason of crash is not necessarily related to that piece of code, it could be that RAM gets corrupted somewhere (stack, heap, ML code/data).
Quote
Memory alignment
Should not be a problem from C (unless you try hard) and this core seems to cope with unaligned words anyway.
Quote
Could sizeof(int) be 2 due to Thumb
No. It's 32 bits, regardless of ARM/Thumb.

Quote
I was working on doing some jump hooks around that location
Is that platform/200D.101/jump_hooks.c?

5
Aaand, of course I managed to find a good example immediately after posting that.  In theory, I can do this:

    LDR PC,[PC,-4]
    #0x12345678

It compiles in Thumb, shall try it soon.
The offset used in that instruction depends on several factors. Your example is valid in ARM state. In thumb state, the offset is 0 if your LDR PC instruction is on a word aligned address, and 2 if it isn't word aligned. See the ARM literature about the value of PC. There's also this, although I don't think I've encountered problems with that.

edit:
Of course, you also need to use the the correct thumb bit in the destination address (bit0 is zero for an ARM target, 1 for Thumb target).

6
Camera-specific discussion / Re: Canon 40D
« on: November 27, 2019, 06:57:55 PM »
Ghidra shows no direct reference to lvGetResource, but alot of function is'nt called directly but indirectly just like lvGetResource, but in most cases I am able to find a pointer to the function, being passed as a argument to another function, but again with lvGetResource I ran out of luck.
Assuming lvGetResource is the function that references the "[LV] lvGetResource 0x%lX (0x%lX)" string, there are 4 data references pointing to it (= the function's address appears 4 times). These references are a few kBytes "above" the function. It looks like Ghidra doesn't automatically notice references like that. I found them by placing the cursor to the function's first instruction and choosing "Search" -> "For direct references" in the CodeBrowser's menu. I then had to turn those bytes into pointers (P button). The references all appear to be part of a huge struct, and that struct is referenced from a function. I'm not familiar with this style of code as PowerShots implement state machines differently.

7
Camera-specific discussion / Re: Canon EOS M
« on: November 26, 2019, 08:25:54 PM »
It constantly deactivated the shutter release so I unable to start recording or taking a photograph without restarting sometimes multiple times.
That's probably the "shutter bug". You can read about it here and also search in the print view of the current thread.

8
Camera-specific discussion / Re: Canon 40D
« on: November 22, 2019, 07:31:48 PM »
I'v had troubles in the past with cache hacks on 40D
I've had similar experience on PowerShots.
I found that the firmware's (and CHDK's) cache manipulation functions counter-act cache hacks. The locked part of cache remained locked, but the content vanished from time to time.
The real solution (IMHO) would be a rewrite of all offending cache manipulation functions, so that they don't touch the locked part. A less reliable way would be re-adding the hacks at the end of each such function.
I chose an even less reliable solution: I re-added the hacks every 10ms, using a task that cycles once every 10ms. It was good enough for doing research.

As far as I know, some ML ports and modules rely on cache hacks - I have no idea how they get away without experiencing similar issues.

One more tip: If I see it correctly, lvGetResource only has data references (no b or bl targets it directly). You could get away just by patching those references using the data cache.

9
Camera-specific discussion / Re: Canon 40D
« on: November 12, 2019, 07:56:05 PM »
I would like to get that call tree.
In case qemu can't get that far, you could also try using cache hacks (src/cache_hacks.h) on the camera.

10
It appears to use the same file format as EOS R/RP and 250D.
Thanks. That means, reversing the new format will be mandatory before any serious development effort on these new (and future) models.

11
Canon has released a firmware update for the recent PowerShot G7X III. Can someone take a look at the FIR and tell whether the current decoder/decrypter can still cope with it?

http ://gdlp01.c-wss.com/gds/6/0400005076/01/psg7xm3-v110-win.zip

12
upon clicking next, the camera shows blank screen, and on the computer it shows "Press SET button to continue installing the firmware"
I believe that's a feature of the latest (1.3.6) firmware. It was introduced in response to this recently published "Missing authorization vulnerability". I would imagine most of the camera's buttons are blocked when an USB connection is active. Don't know whether removing the cable would allow dismissing that dialog, or cause some sort of problem.

13
General Development Discussion / Re: when to use task_create?
« on: July 07, 2019, 06:50:08 PM »
If you start do_stuff() the first way, it will obviously execute in the same task.

If you launch it as a new task, it will run independently, in parallel. Also, you get to specify the task priority (0x1e), and the amount of stack space (0x1000).

14
Camera-specific discussion / Re: Canon EOS R / RP
« on: April 27, 2019, 09:54:36 PM »
Simple registering here (...)
gives you enough information.
Those who wish to work on ML in the future may want to read the terms & conditions, especially the section "Confidentiality". Their stuff is not open source.

15
Module writing Q&A / Re: use canon icons in module
« on: March 13, 2019, 07:47:32 PM »
last time I checked, the RBF editor required an old version of Qt. We may have to dust off some old VM just for editing the fonts, unless someone updated the editor meanwhile.
I have made another RBF editor (with its own quirks), currently available as Win32 binary (Wine compatible).

16
Just FYI, Canon has released firmware updates for
EOS M50 (1.0.2)
PowerShot SX740 (1.0.1)
PowerShot SX70 (1.1.0)

17
Reverse Engineering / Re: MFA on 60D - reversing calibration
« on: February 24, 2019, 12:13:56 PM »
I guess it can't hurt if you make a ROM dump before sending it in and another after receiving it.
https://www.magiclantern.fm/forum/index.php?topic=16534.0
But that of course doesn't guarantee anyone will jump and implement any calibration related feature.

18
Not sure where to post this as it's both DIGIC 7 and 8 related.
I've noticed that D7 and D8 ports still have
Code: [Select]
-march=armv7-rin platform/(cam)/Makefile.platform.default
"armv7-r" means ARM Cortex R. The Cortex R supports integer divide instructions in Thumb mode, whereas the Cortex A9 does not. To avoid getting undefined instruction exceptions in the future, I'd suggest using
Code: [Select]
-march=armv7-ainstead.

19
Camera-specific discussion / Re: Canon 80D
« on: February 06, 2019, 12:28:23 AM »
Theory:
- there is a frame buffer in the main RAM (like before, just with a different image format: uyvy; previous models were palette-based)
On D6 PowerShots, the overlay uses two buffers at the same time: one uyvy plus one "opacity" (1 byte per pixel). The opacity buffers are usually located close to the uyvy ones. If these cameras have the same display config, and you're planning to write to the uyvy buffers, you'll need to write the opacity buffers too.
Quote
- the frame buffer address only changes when the GUI subsystem goes into some different mode (e.g. from shooting mode to Canon menu)
On newer D6 Powershots, buffers are switched continuously when there are animations on screen.

20
General Help Q&A / Re: Recover .DAT movie file from camera?
« on: January 16, 2019, 06:40:10 PM »
Try recover_mp4. It's a Windows command-line utility, also runs on Linux with Wine.

21
I know what it is, but not spoiling the game.
@a1ex Can it save files yet?

22
sorry, but I didnt have success on my M50, I prepared the Card with EOSCard after true formating in the M50
(but with my M50 I also did not have success with the dumper scripts)
Thanks for trying. I guess we'll know more when emulation of the M50 becomes possible.
EOScard?
Is there a bootflag enabler for the real (not emulated) M50 body?
Wondering if I missed something ...
EOSCard can also set PowerShot-related flags, in this case the SCRIPT signature.

23
After exploring the D8 disassembly I have (I was given a reconstructed M50 dump) I decided to publish my findings here.

- The camera does appear to have the scripting language we (@CHDK) refer to as Canon Basic.
- I have the impression that the card setup is the same as described here: http://chdk.wikia.com/wiki/Canon_Basic/Card_Setup
- Event procedures (short: eventproc) do exist, the eventproc handling firmware routines seem to be the same as on PowerShots.
- There seems to be support for extend.m and autotest.m scripts, but their invocation may differ from what's described here: http://chdk.wikia.com/wiki/Canon_Basic#Starting_the_script

- Now, the differences:
 - Most event procedures that appear in CHDK related scripts do not exist. That means, CHDK scripts will not work on D8 cams.
 - Many event procedures seem to be pre-registered, so registration functions such as System.Create() are not necessarily needed.
 - In file names, the card root is B:/
 - I have not yet found an eventproc to write binary files from script, or, to write text on screen.
 
Problem is, I can't say for sure whether using a prepared script card is enough to run scripts. So, everything below is speculation.

Script support seems to be enabled when the cam is in factory mode - the factory mode flag is at 0xE1FF802C.
I think it is also enabled when there's a script named "AutoTest.m" in the root of the card. The code I found loads "AutoTest.m" automatically at the end of the startup procedure.

The following minimal script should make a hex dump of the first 0x40000 bytes of ROM. I'm not certain that my WriteFileString interpretation is correct.
For a first try, name the script "AutoTest.m".

Code: [Select]
dim startadr=0xe0000000
dim romsize=0x40000
dim fname="B:/ROM.TXT"

private sub Initialize()
    p = startadr
    f = OpenFileCREAT(fname)
    do while p < (startadr+romsize)
        WriteFileString(f,"%08X: %08x %08x %08x %08x\n",p,*p,*(p+4),*(p+8),*(p+12))
        p = p + 16
    loop
    CloseFile(f)
end sub

This script is not camera specific, so it can be tried on any D8 cameras (assuming that all D8 cams share the same codebase):
EOS M50, R; PowerShot SX740, SX70

To make sure the card is correctly prepared for scripting, get any older PowerShot (2005...2017) and use the universal dumper script (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper) to check.

I can't guarantee success, but I think it's worth to try this route.

24
General Development Discussion / Unused (unnecessary) firmware tasks
« on: January 04, 2017, 04:01:07 PM »
I read that some ports (EOS M) experience a shortage of tasks. If this is related to the hardcoded limit of DryOS tasks, the following might help. Quoting an old post of mine:
Quote
Looking at the output of 'extask' (extended task information for DryOS), I noticed that a task named EvShel (event shell) has unusually large stack space (0x8000 bytes aka 32kB). This task is only used for debugging over the UART, but it's sitting idle in all cameras used by ordinary people - waste of RAM.
As an experiment, I have prevented this task from starting (on the a470) - it's usually started from the last BL in the 'CommonDrivers' task. Side effect is that this prevents two other tasks from being started (ConsoleSvr, LowConsole) - these would be started by EvShel itself.
That was a PowerShot cam. If cameras on the EOS codebase also survive if those 3 tasks are missing, ML could start 3 tasks more.
I only verified that the above task names are present in the 550d dump. Somebody will have to check if Evshel task's creation can indeed be removed from the boot process, without penalties.

Just an idea.

25
General Chat / Re: 19Lights / GingerHDR gone forever?
« on: August 15, 2015, 12:01:27 PM »
Some site content is available from archive.org: https://web.archive.org/web/*/19lights.com
Last captured content
Downloads

Pages: [1]