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 - g3gg0

Pages: [1] 2 3 ... 109
Nightly Builds / Re: Nightly Builds - try the very latest stuff here
« on: January 09, 2018, 12:39:19 AM »
hmm. odd.
what does "no success" mean? any error message appearing?

Reverse Engineering / Re: Reverse EFS Lens firmware
« on: January 07, 2018, 07:05:35 PM »
really a great idea :)
keep us informed

which CPU MCU is it?

General Development Discussion / Re: Helpfull Software for debugging
« on: January 03, 2018, 11:14:45 PM »
tried retdec when it was released, and am not impressed too much.
probably helpful for someone without IDA pro (to be more specific: hexrays decompiler).
works, but setting up and decompiling is a bit pain in the ass with moderate output.

tried it for plain arm (camera firmware) and the result was hard to interpret.

as said, better than nothing :)

" is the first TV channel broadcasting on the Blockchain. Using Livepeer’s decentralised live-streaming platform, based on Ethereum, we are soon live-streaming from Canon EOS 5D Mkii."

i simply dont get it.
whats all that about? techincally please.

General Chat / Re: Apertus Axiom Beta
« on: December 27, 2017, 01:46:01 AM »
thanks for the pointer :)

Feature Requests / Re: Assign lens focal length and name for non cpu lenses
« on: December 20, 2017, 01:17:06 AM »
can you also update mlv_dump? it should show you the serial as plain number.

Feature Requests / Re: Assign lens focal length and name for non cpu lenses
« on: December 19, 2017, 10:57:30 PM »

Is this a valid way to copy value from lens_info struct?

can you try the latest patches, please?

Scripting Q&A / Re: Loading scripts in order
« on: December 03, 2017, 04:41:24 PM »
so it would probably be helpful to sort by filename before loading?
the order then can be dictated by adding digits in front of the file name.

General Chat / Re: Apertus Axiom Beta
« on: November 15, 2017, 08:47:41 PM »
thanks for the update ;)

Camera-specific discussion / Re: Canon 7D Mark I
« on: November 01, 2017, 11:53:25 PM »
Can anyone enlighten us on this mysterious platform?

various patches/changes have to be made on the master digic.
but autoexec.bin is executed on the slave only.

luckily FIR files get executed on both master and slave, so we can put ML code in a FIR if we need to patch stuff on master.
so the MASTER part is meant to implement the necessary stuff ML needs to be patched and then packed into the FIR along with "real" ML for the slave.

only when executed through a "firmware update", ML is then able to patch this stuff. think it was only cache hack related stuff.
IIRC only the high bitrate video hack used these features.

short: not really needed

Share Your Videos / Re: Halloween Short Film shot on 5D Mark III
« on: October 31, 2017, 01:04:57 AM »
very impressive indeed :)

General Development Discussion / Re: Portable ROM dumper
« on: October 27, 2017, 05:58:36 PM »
wondering why it failed in the first place.
maybe some counter overflowing? hmmm

General Development Discussion / Re: Portable ROM dumper
« on: October 26, 2017, 08:58:20 PM »
well my personal favorite is:
leave it as a swiss army knife - you can never make it fit for every purpose.
people who are into dumping cameras, will know how and what to change.
(dont know if alex agrees on this)

but it is absolutely a good idea to make it "detecting" if the portable dumping failed and then show the dot-dumper.

General Development Discussion / Re: Portable ROM dumper
« on: October 25, 2017, 08:46:27 PM »
woohooo, thats quite fast :D
no, it should be slower by a factor of 10 or so...

which camera model? 80D?

General Development Discussion / Re: Portable ROM dumper
« on: October 23, 2017, 07:32:12 PM »
btw, the reason why i made this weird dumper...

i wanted to dump the 5Ds and i didnt want to use a GPIO to toggle a LED that is sampled with a LDR, then fed into a sound card, then saved as audio, then reconstruct the data.
with a data rate that is smaller than snail mail ;)

the QR code experiment tend to have failed because binary transfers are a pain in the ass and the decoders were even more pain in the ass.
(thats why i will close this branch soon)

and if we have such a nice display and soooooo many light sensitive sensor elements in a camera (the image sensor...), why then not use them along with a module that decodes the data?

possible ToDos:
 - not only OOK (on off keying), but also use color and brightness (0%, 50%, 100% for each RGB) gives 9 possible states and thus ~3 bits of information per pixel
 - compress the binary data, which would imply we are no longer block aligned

General Development Discussion / Re: Portable ROM dumper
« on: October 23, 2017, 04:47:22 PM »
okay thanks for your feedback!

so on the EOS M the module fails to find the C0-dot in the raw area. maybe i am missing some code to init raw buffer access.
never checked how to do that on EOS M.

good to hear that it finally worked :)

General Development Discussion / Re: Portable ROM dumper
« on: October 22, 2017, 06:54:33 PM »
okay then it is experimenting with stuff, got it :)

General Development Discussion / Re: Portable ROM dumper
« on: October 22, 2017, 06:05:58 PM »
hmh why then run the rom dumper - you can simply run ML ?

General Development Discussion / Re: Portable ROM dumper
« on: October 22, 2017, 10:51:32 AM »
So the 7D "master" is set up and working properly because it is displaying the patterns. I thought something was wrong, then again I didn't wait 4 hours for it to finish running "The Matrix" like code.
wondering what you want with the 7D - do you mean 7D2?

I take it that the "slave" can be another ML enabled camera and doesn't have to be the same model, all that's need is for it to run the "rom_dump" module. That rom_dump module is in the recovery branch but you're saying it needs to be compiled in the unified branch--Hum, ok. Is the EOSM a fully supported camera? I've got power supplies for both the 7D and EOSM.

exactly, any camera where the raw backend works, should be fine.
i used the raw backend because of the resolution you get there. HD bufs could also work, but i felt like raw is the more supported choice ;)

just try it and report :)

when starting the module, it needs a possibly pitch black image. at least everything should have the same dark color.
it then does a full-screen averaging to get the base (off) color. then it waits for some dots to appear. 16 dots to be exact.
the significant jump in brightness is considered as "on" level.

after all 16 dots were located, they are used to communicate the dimensions of the matrix.
and then the matrix size is determined. etc.

General Development Discussion / Re: Portable ROM dumper
« on: October 22, 2017, 01:33:36 AM »
there is an advanced display based dumper available, allowing reasonable transfer speeds.

here a vid:
the current implementation is quite a bit faster and doesnt take so long during dot calibration iirc.

how it works:
"master" camera booted in dumper, displays some patterns.
"slave" camera, in video mode, scans the screen and waits for the dots to appear.
after they went through setup, ROM content is shown on screen and slave camera writes a plain ROM image to its card structured dump file, that must be "assembled" on PC later.

how to use:
- get the recovery branch and build the dumper (make sure disp_dump() is being called) for your camera to dump (lets call it master)
- save the "rom_dump" module sources
- switch to unified and compile the "rom_dump" module there
- put it into your fully supported camera (lets call it slave)
- master: boot rescue system
- slave: aim your lens towards the master camera
- slave: fine tune the focus to get a good separation between dots (check corners too!)

hint: if the "all dot" display time on master is too short for proper lens setup, reboot it and do one more phase.
generally its a good idea to simply let the master run its dumping process and checking on slave that all positions (4 corners and center)
give a proper white dot and close to black lines inbetween

- as soon the "all dot" display has fully faded on master and you have a black screen, start the module on slave (Debug -> Dump memory)
- slave: waits for the first 16 "setup dots" to appear one after another
- slave: waits for corner dots to calculate dimensions
- slave: waits for all dots

then it should work.
later when you are done with dumping, use the unpack_block (gcc -o unpack_block -c unpack_block.c) utility to re-assemble a proper ROM file.

- i worked with a zoom lens which worked fine
- disable IS (!!) as it will slightly move all the time
- use a power supply, it will take some time ;)  (dont remember, maybe 4 hours?)
- when you ran out of battery, modify the dump area in the dumper and start where it ended before
- when you have multiple partial rom dumps (DUMP.BIN) due to some troubles, just concatenate all files using e.g. cat command and pass it to unpack_block
- unpack_block will only pick blocks that weren't damaged and have a valid CRC
- if a fly passes by, then you might miss a block or two ;)
- if you constantly have trouble due to lens quality or a scratch in display, head to disp_dump.c and play with the values (e.g. increase BIT_WIDTH/BIT_SPACING and decrease BIT_COUNT_* so all will fit on screen)
- when modifying parameters in the dumper, the module will autodetect these changes (transmitted via setup dots)

- Even better - g3gg0 figured out how to emulate the real-time clock! This change superseded a bunch of GDB scripts - no more need to patch the date/time dialog!

for the record, got information from ricoh that the 5D3 chip is a R2262K
(thanks, guys!)

well. that code was made ages ago. but probably it is helpful.

maybe there is some useful info in

rewrote the magic lantern sound code to allow full control and proper playback and recording.
even added a mp3 player and easy sound recording.

Share Your Photos / Re: Outer Space with the help of ML
« on: September 27, 2017, 07:17:15 PM »
really impressive shots :)

and this shot in germany? nice.

Pages: [1] 2 3 ... 109