ready to help with 7d firmware
B. Cole
get the firmware unraveled so that it can be modified. I'm
particularly interested in getting the audio gain control modification
in place for the 7d. (I recently finished a film shoot with 2 7Ds and
4 audio systems and syncing the a/v systems together in post was a
royal pain).
I've read up on the 7d firmware progress and I've replicated the work
of using the symmetric XOR cipher on the 1.1.0 firmware flasher. (Had
to bug fix dissect_fw/decrypt_block for 64 bit, and also fix the IV
field in firmware.h).
I've also compiled ARM gcc,gdb,qemu for 64 bit linux, and have IDA pro
set up, so I think I'm fairly set to start working on images.
I've looked at the public magic lantern info and it seems most of the
pieces for the 7D progress so far are not released, or at least I
cannot find them. I notice that almost all of the magic lantern
technical conversation has been one way :), so hopefully this is just
a matter of nobody having asked yet. Do you think you could share:
the flasher's sha/hmac signing algorithm or the bypass for the
flasher's checks
changes to assemble_fw, etc. for dumping the ROM
the addresses/info you've discovered so far from the dumped rom
(hopefully for 1.1.0 firmware)
Any IDA .sig files you have for the dumped rom& flasher images (or
at least the routine addresses can be exported with an idc script)
Also I assume the current hang up is still that you can't jump back
into the eprom image as with the 5d?
Trammell Hudson
> [...] I've also compiled ARM gcc,gdb,qemu for 64 bit linux, and
> have IDA pro set up, so I think I'm fairly set to start working on
> images.
It sounds like you're in good shape to get started with development
then. Please send me the 64-bit patch for the code and I'll apply
it so that we can allow development on modern machines. My OS X
10.6 desktop won't build arm-elf-gcc, so I do all of the ML
development on my laptop.
> I've looked at the public magic lantern info and it seems most of the
> pieces for the 7D progress so far are not released, or at least I
> cannot find them.
I have been somewhat circumspect in describing it in too much detail
untl the new 5D Mark II firmware comes out, but at this point I
doubt that they would be able to make any major changes prior to the
(rumored) 17 March release.
What we know is that it is a combination of SHA1 and MD5 applied
multiple times to the firmware image and uses a 32-byte IV from the
ROM that is common to all cameras. "ARM Indy" has performed an
extensive analysis and produced a clean-room python program to
generate signatures. This will be part of the public release.
Interestingly, this scheme is the same used on a range of cameras,
including the 5D Mark II, 7D and 1D Mark IV.
Prior to that I was using qemu and gdb to run the firmware
validation code under emulation and putting a breakpoint following
the signature generation. Some gdb hackery would write out the
memory block and allow me to generate valid signatures.
I have spoken with counsel at the EFF regarding releasing the
signature scheme and IV/keys required, and believe that it will be
ok to do so.
For copyright reasons, however, I can not distribute the ROM dumping
binary. It contains extensive amounts of Canon code (indeed,
the entire firmware flasher program and DryOS). I can, however,
provide a binary diff that can be applied to the existing firmware
image to make one that wil dump the firmware to a file and enable
the DISKBOOT flags on the camera.
With this everyone will be able to make their own ROM image dumps
for analysis with IDA. The autoboot code will also allow
(hopefully) more rapid development since the 18 second firmware
verification step will not be necessary.
> [...] Also I assume the current hang up is still that you can't
> jump back into the eprom image as with the 5d?
That is exactly the problem. "ARM Indy" believes it might be due to
the second DIGIC. He might be right; the shutdown code in the
flasher appears to do a sio_write() with some command (unknown what
is contains) as part of the abort process. It might be that we need
to shutdown the second CPU before jumping back into the boot loader
at 0xFFFF0000.
I really, really need to update the wiki with the current 7D status.
My minor edit to the FAQ has started an enormous amount of
speculation on dvinfo, dvxuser and cinema5d. Everyone has been
playing amateur Kremlinogist to try to discern what I meant by my
changes.
--
Trammell
B. Cole
> then. Please send me the 64-bit patch for the code and I'll apply
> it so that we can allow development on modern machines.
Hunk 1: -mlong-calls argument required to avoid "relocation truncated to fit: R_ARM_PC24 against symbol `DebugMsg' defined in *ABS* section in magiclantern"
type errors in the build. I'm not sure if this is the "right" fix but it's
the first fix I came up with for my gcc 4.3.2 build environment environment.
I see that others have reported the same in this group.
Hunk 2: Required to allow host tools to build under linux
Hunk 3,4: Simple 64 bit fix (Yes, I've confirmed the tools produce the right
results with this change) Hunk 5,6,7: Duplicate declaration of data_len field
in structure; won't compile
on my host with gcc 4.4.2 without this fix.
> My OS X 10.6 desktop won't build arm-elf-gcc, so I do all of the ML
> development on my laptop.
thought there were two fixes posted here: 1 to just use 10.5.x binaries, or 2
a couple edit changes to the macports to fix things (posted by phroid, post
#25 in T1i firmware dump thread).
I prefer linux anyways so I didn't try very hard to patch the macports
version.
> I have been somewhat circumspect in describing it in too much detail
> untl the new 5D Mark II firmware comes out, but at this point I
> doubt that they would be able to make any major changes prior to the
> (rumored) 17 March release.
list if the development progress is secret? :)
> What we know is that it is a combination of SHA1 and MD5 applied
> multiple times to the firmware image and uses a 32-byte IV from the
> ROM that is common to all cameras. "ARM Indy" has performed an
> extensive analysis and produced a clean-room python program to
> generate signatures. This will be part of the public release.
> Interestingly, this scheme is the same used on a range of cameras,
> including the 5D Mark II, 7D and 1D Mark IV.
and md5 hashes that's good news. IMO that means canon is simply adding
image integrity checks (just like windows, linux distros do) not any sort of
intentional roadblock.
> I have spoken with counsel at the EFF regarding releasing the
> signature scheme and IV/keys required, and believe that it will be
> ok to do so.
sense to me if it's just an integrity check. More generally, I'd think the
opinion that would be most relevent would be canon's. Have you tried to
contact them directly?
> For copyright reasons, however, I can not distribute the ROM dumping
> binary. It contains extensive amounts of Canon code (indeed,
> the entire firmware flasher program and DryOS).
program.
> I can, however,
> provide a binary diff that can be applied to the existing firmware
> image to make one that wil dump the firmware to a file and enable
> the DISKBOOT flags on the camera.
> [...] Also I assume the current hang up is still that you can't
> jump back into the eprom image as with the 5d?
> That is exactly the problem. "ARM Indy" believes it might be due to
> the second DIGIC. He might be right; the shutdown code in the
> flasher appears to do a sio_write() with some command (unknown what
> is contains) as part of the abort process. It might be that we need
> to shutdown the second CPU before jumping back into the boot loader
> at 0xFFFF0000.
With the flasher piece out of the way I could move on and look at this
chainbooting-like process.
> I really, really need to update the wiki with the current 7D status.
> My minor edit to the FAQ has started an enormous amount of
> speculation on dvinfo, dvxuser and cinema5d. Everyone has been
> playing amateur Kremlinogist to try to discern what I meant by my
> changes.
end-users/testers (the 7d forum on cinema5d?) and direct folks there.
Trammell Hudson
> [...] Hunk 5,6,7: Duplicate declaration of data_len field
> in structure; won't compile
> on my host with gcc 4.4.2 without this fix.
How did that ever compile before? Weird.
Thanks for the patches. I'll apply them and test it out.
> [...] I couldn't find any reference to "ARM Indy"
And that is the way he likes it...
> but if it's just simple sha1 and md5 hashes that's good news. IMO
> that means canon is simply adding image integrity checks (just
> like windows, linux distros do) not any sort of intentional
> roadblock.
They are definitely doing HMAC, so it is not just integrity checks.
It is clearly a signature system, although a very convoluted one.
> [...] Have you tried to contact them directly?
The problem is determining who to try to reach at Canon. I have
attempted to connect with Tim Smith, who I am certain would be able
to put me in touch with the right people at Canon Japan, but have
never heard back from him.
Attached is the bsdiff output for the 7d00110.fir and my
7d-dumper.fir file. It changes 363 bytes in the file, as sumarized
by 'cmp -l' here. When patched, this firmware file will dump the
contents of memory from 0xFF00_0000 to 0xFF7F_FFF0 into ROM0.bin and
from 0xFF80_0000 to 0xFFFF_FFF0 to ROM1.bin. Unlike the 5D Mark II,
the 7D appears to start the ROM image at 0xFF01_0000 rather than
0xFF81_0000. The boot loader resides at 0xFFFF_0000 and selects
the entry vector for the application.
The new firmware will also set the DISKBOOT flag in the boot flag
region of the flash. With this set the boot loader will check to
see if the CF card is marked as bootable:
http://magiclantern.wikia.com/wiki/Autoboot
As a side note, it is no longer necessary to have the camera
routinely do memory dumps other than to capture the boot loader and
HMAC IV since we can directly decrypt the AES payload from a .FIR
file.
kremvax:~/build/7d: cmp -l 7d000110/7d000110.fir dumper.fir
33 125 317
34 174 162
105 127 255
106 246 300
107 217 264
108 313 116
109 365 117
110 170 104
111 55 360
112 234 311
113 146 331
114 313 24
115 103 32
116 342 204
117 160 77
118 341 246
119 47 252
120 174 367
121 200 301
122 312 153
123 172 36
124 130 370
19813 252 321
19814 14 114
19815 115 140
19816 127 124
19818 375 255
19819 102 342
19820 151 212
19822 72 172
19823 271 31
19824 143 200
19825 371 230
19826 5 7
19828 34 366
19829 107 271
19830 337 0
19831 376 241
19832 335 324
19833 311 315
19834 177 157
19835 270 65
19836 74 336
19837 77 363
19838 114 116
19839 76 241
19840 246 103
19843 107 327
19844 314 51
19845 322 204
19846 337 367
19847 262 115
19848 221 220
19849 110 274
19850 336 221
19851 52 232
19852 306 312
19853 346 21
19854 177 140
19855 325 372
19856 315 314
19857 24 1
19858 132 232
19859 141 214
19860 210 211
19863 372 247
19865 320 154
19866 364 324
19869 67 376
19870 147 220
19871 104 7
19872 41 50
19873 122 127
19874 150 110
19875 264 344
19877 125 127
19878 50 30
19879 223 316
19881 71 60
19882 346 306
19883 23 301
19884 241 240
19885 312 352
19886 100 201
19887 314 300
19888 22 140
19889 341 244
19890 2 40
19891 343 56
19892 133 124
19893 67 300
19894 372 312
19895 50 345
19896 40 57
19897 32 20
19898 205 245
19899 42 140
19900 131 121
19901 313 40
19902 224 244
19903 364 267
19904 123 133
19905 355 353
19906 263 222
19907 112 207
19908 36 21
19909 116 117
19910 42 23
19911 155 240
19912 47 50
19913 16 207
19914 222 73
19915 74 234
19916 22 33
19917 0 20
19918 365 324
19919 4 106
19920 164 174
19921 221 336
19922 264 205
19923 200 3
19924 370 360
19925 147 205
19926 15 122
19927 161 321
19928 44 55
19929 364 172
19930 131 310
19931 375 135
19932 30 21
19933 354 64
19934 251 42
19935 366 174
19936 144 154
19937 244 111
19938 261 220
19939 240 155
19940 253 244
19941 160 202
19942 4 65
19943 74 361
19944 275 262
19945 313 17
19946 163 122
19947 14 216
19948 324 334
19949 71 61
19950 200 262
19951 160 363
19952 353 343
19953 330 324
19954 364 246
19955 241 44
19956 152 142
19957 53 54
19958 343 321
19959 247 152
19960 170 167
19961 367 327
19962 11 133
19963 71 261
19964 151 143
19965 12 3
19966 121 161
19967 355 200
19968 373 377
19969 73 256
19970 160 317
19971 202 300
19972 153 154
19973 124 134
19974 107 127
19976 227 225
19977 134 325
19978 23 363
19980 375 377
19981 315 147
19982 34 44
19983 176 121
19984 271 263
19985 154 301
19986 43 273
19987 365 252
19988 53 43
19989 202 24
19990 144 152
19992 61 63
19993 3 22
19994 147 7
19995 64 166
19997 104 115
19998 147 47
19999 200 124
20000 37 36
20001 227 224
20002 253 213
20003 164 324
20004 20 353
20005 51 264
20006 320 277
20007 33 34
20008 305 307
20009 107 276
20010 76 72
20013 224 22
20014 271 311
20016 136 134
20017 50 221
20018 157 110
20019 151 311
20020 154 146
20021 171 253
20023 37 317
20024 20 32
20025 45 250
20026 74 0
20027 2 242
20028 30 21
20029 126 137
20030 126 146
20031 222 261
20032 205 204
20033 34 113
20034 370 152
20035 145 162
20036 206 203
20037 261 266
20039 167 126
20040 70 74
20041 130 163
20042 34 372
20043 37 277
20044 21 33
20045 127 117
20046 307 170
20047 345 152
20049 321 340
20050 365 305
20051 102 266
20053 177 176
20054 51 31
20055 364 71
20056 115 242
20057 305 310
20060 21 23
20061 240 227
20062 54 336
20063 73 4
20064 2 6
20065 103 126
20066 374 3
20067 35 263
20068 326 322
20069 116 110
20070 51 10
20072 357 355
20073 326 264
20074 141 133
20075 353 304
20076 100 103
20078 366 306
20080 51 53
20081 114 312
20082 375 215
20084 216 214
20085 322 170
20086 164 123
20087 60 220
20088 365 377
20089 237 227
20090 252 127
20091 356 136
20092 34 30
20093 355 352
20095 344 324
20096 37 33
20097 334 323
20098 105 245
20099 101 261
20100 264 266
20101 76 52
20102 342 35
20103 66 31
20104 146 215
20105 105 323
20106 261 237
20109 64 362
20110 305 373
20111 46 206
20112 140 150
20113 105 115
20114 335 275
20115 175 137
20116 176 175
20117 13 15
20118 301 373
20119 131 216
20120 0 1
20121 355 350
20122 53 33
20123 334 137
20124 115 247
20125 113 104
20126 144 204
20128 145 147
20129 164 223
20130 210 146
20131 66 206
20132 327 323
20133 75 366
20134 37 41
20135 204 245
20136 40 46
20137 146 162
20138 156 116
20139 155 100
20140 343 340
20141 134 333
20142 316 321
20143 312 306
20145 143 156
20146 200 72
20147 30 62
20148 131 130
20149 44 254
20150 332 333
20153 145 365
20154 21 106
20155 273 232
20156 355 343
20157 244 143
20158 114 344
20159 23 231
20160 61 72
20161 166 143
20162 303 311
20163 2 35
20164 105 102
20165 24 20
20166 131 171
20167 370 310
20168 124 122
20169 161 132
20170 202 142
20171 276 236
20172 245 246
20173 33 173
20174 274 111
20175 251 206
20176 42 50
20177 64 75
20178 173 311
20179 320 357
20180 107 103
20181 64 75
20183 34 54
20184 56 52
20186 320 0
20187 21 34
20189 255 333
20190 322 127
20191 160 315
20192 104 107
--
Trammell
B. Cole
I will of course not be able to experiment with any changes on the camera until I can make my own checksums or bypass the check.
Trammell Hudson
> Thanks, with the binary dumper patch and the pre-made sha1 sum, I was able
> to dump the rom images successfully.
Excellent! I'm glad to hear that it didn't brick the camera.
> I will of course not be able to experiment with any changes on the camera
> until I can make my own checksums or bypass the check.
I'm working on packaging up the python script that generates the
signature with a wrapper that will also fixup the CRC, etc.
It will replace the assemble-fw Perl script that I wrote a while
ago.
Until then, you can play with a bootable CF card now:
http://magiclantern.wikia.com/wiki/Autoboot
If you search the ROM1.bin image for DISKBOOT you will find the code
that loads the AUTOEXEC.BIN file and jumps into it at 0x80_0000.
I'm not sure what all happens at that point since I have not been
able to get the 7D to move beyond the bootup. I had tried
relocating the startup code from 0xff01_0000 to 0x80_0000, but it
did not seem to wake up the camera.
--
Trammell
B. Cole
Excellent! I'm glad to hear that it didn't brick the camera.
I've spent some time looking at the 2 different bootloaders, and
the magic lantern bootstrapping.
I think maybe I've found something, but this is just based upon
inspection so maybe I ran off into the weeds somewhere here.
Maybe you can correct me where I'm wrong...
You write:
"Unlike the 5D Mark II, the 7D appears to start the ROM image at
0xFF01_0000 rather than 0xFF81_0000. The boot loader resides at
0xFFFF_0000 and selects the entry vector for the application. "
"I had tried relocating the startup code from 0xff01_0000 to
0x80_0000, but it did not seem to wake up the camera."
On the 5d:
ROM0 image copied from F800,0000->FF80,0000
DryOS code starts 0x1,0000 bytes from beginning
On the 7d:
ROM0 image copied from F800,0000->7f,0000
DryOS code starts 0x1,0000 bytes from beginning
I do note that the dryos code enforces the start address by embedding the
address into the data (ie the code is not relocatable without change):
5d:
constant at offset c4 into image: ff01000c, thus enforcing
load address of ff01,0000
ff010000: e59ff0bc ldr pc, [pc, #188] ; ff0100c4
...
ff0100c4: ff01000c
7d:
constant at offset c4 into image: 80012c, thus enforcing load
address of 80,0000
800000: e59ff0bc ldr pc, [pc, #188] ; 8000c4
...
8000c4: 0080012c
So it seems to me the 7d code expects dryos to use 0x80,0000 as
the load address, but with the bootloader on the 5d&7d both
loading autoboot.exe to 0x80,0000 you can't just jump into the
dryos code without addressing this collision.
B. Cole
So it seems to me the 7d code expects dryos to use 0x80,0000 as
the load address, but with the bootloader on the 5d&7d both
loading autoboot.exe to 0x80,0000 you can't just jump into the
dryos code without addressing this collision.
// We enter after the signature, avoiding the
// relocation jump that is at the head of the data
thunk reloc_entry = (thunk)( RELOCADDR + 0xC );
So you are addressing the dual use of 0x80,0000 by skipping the first instruction.
I assume you already tried this with the skip offset updated to 0x12c for the 7d.
B. Cole
I take it all back, I was accidentally looking at my dump of the
flasher
code not the final dryos code when I thought the code was expecting a
relocation address of 0x80,0000.
Sorry for the confusion.
Trammell Hudson
> >ROM0 image copied from F800,0000->7f,0000
>
> I take it all back, I was accidentally looking at my dump of the
> flasher
> code not the final dryos code when I thought the code was expecting a
> relocation address of 0x80,0000.
I'm glad to hear that I wasn't missing something. I went back to
the bootstrap code to try to make sure that I wasn't missing a
memory copy.
--
Trammell
Pelican
How we can do that?
I can only do the XOR work but the firmware payload remains still
encrypted.
I've dumped the 1.1.0 fw from the camera using your patch and I've got
the two bin files.
Where the ROM1.bin come from? I mean from what address?
Thanks in advance,
pel
On Mar 1, 12:10 am, Trammell Hudson <hud...@osresearch.net> wrote:
> As a side note, it is no longer necessary to have the camera
> routinely do memory dumps other than to capture the boot loader and
> HMAC IV since we can directly decrypt the AES payload from a .FIR
> file.
http://magiclantern.wikia.com/
To post to this group, send email to ml-d...@googlegroups.com
To unsubscribe from this group, send email to ml-devel+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en
B. Cole
On Apr 20, 6:09 pm, Pelican <p...@pel.hu> wrote:
> Can we?
> How we can do that?
> I can only do the XOR work but the firmware payload remains still
> encrypted.
published.
So effectively, no you can't, unless you want to replicate the work of
reading the decrypt algorithm out of the flasher code...
>
> I've dumped the 1.1.0 fw from the camera using your patch and I've got
> the two bin files.
> Where the ROM1.bin come from? I mean from what address?
rom0
and address 0xFF800000 len 0x007FFFF0 for rom1.