GH1 IDA Pro database research

What is IDA 4.9 Pro and how will this help to progress the hacking of the camera? What goals do you have with this and what goals do you still feel are obtainable that have not already been accomplished with GH1? I have been away from forum for a couple weeks and saw this new post. Feel free to delete or move if necessary, I understand you guys are busy.
 
Last edited:
Vitaliy,

I got the files from you - thanks. I have a fully licensed version of IDA Pro Advanced v5 - which has some nice new features. Unfortunately, the MN103 module doesn't work with it. I can get the source code for the module. Any idea what I might be in for if I try to update it?

Chris
 
Generally we try to stay on 4.9 Free version due to fact that it is free and format is different from 5.0.

One real difference is build-in graph view. Not much.
Try modified WinGraph with 4,9 and you'll find that it is very usable.
 
Is there some kind of protocol we should follow with this? For example, can we put snippits of the code here, or will that cause legal issues? Also, I assume that we can't simply patch the firmware to try things out because it has to be re-packaged with some sort of checksum. Is that correct?

Chris
 
Is there some kind of protocol we should follow with this? For example, can we put snippits of the code here, or will that cause legal issues?

Just post screenshots of Ida screen with your questions or description.
I'll remove them or make closed thread in case of complains.

Also, I assume that we can't simply patch the firmware to try things out because it has to be re-packaged with some sort of checksum. Is that correct?

I'll later add support for external patch definitions to ptool.
But do not reccomend it, as bricking is possible.
 
Last edited:
I added requested patches to latest PTool.

Generally we must work on tables more and bitrate related routines logic reconstruction.

As I understand, bitrate is determinated with 0x66 size tables (it is 0x33 words).

0x33 is constant defining maximum possible quality.

If you look at logic, different tables are used according to settings and fps.
 
Vitaliy,

I've been back-tracing these routines and there are two things I would like to look at. The constant shown in Screen 1, below, shows 6000 (I changed it to decimal, I think your version still shows it in hex) being loaded into a register. Can you put in a patch for this? I can't figure out what it is for and it does appear in the basic setup routine, so I would like to be able to experiment with it.

The second request is shown in Screen 2, below. I've noticed that the codec behaves differently in some fundamental ways for frame rates below 30 fps. I've looked everywhere for conditional statements that might be related to this and this is the only one I've found so far that seems appropriate. I would like to be able to experiment with this as well. I know it looks odd that the comparison is against 0x30 rather than 0x3000, but a compiler would produce such an optimization.

I'm studying the tables you pointed out to me. I believe there is something more basic going on that needs to be fixed first - that is, why 25p behaves so differently when it is wrapped in the interlaced frame - the streams should look virtually identical and they don't. After that is resolved then I think playing around with the codec tables will make more sense. I'm afraid that with this more fundamental problem in the way changing the tables will be too confusing.

Chris
 

Attachments

  • Screen 1.jpg
    Screen 1.jpg
    39.6 KB · Views: 0
  • Screen 2.jpg
    Screen 2.jpg
    32.3 KB · Views: 0
Last edited:
OK. Will be added.
As for conditional jump, I think you need two variants (to unconditional and nops).

I'll try to implement ability to make your own patches via INI files in next releases.
Working on this.
 
Thanks, that would be great. For the 0x30 compare, just making it possible to change the number would be fine for now. I'll just set it 0x00 if I want to always go one way and 0xFF for the other (obviously won't work if at 0xFF, but I don't care for now).

Chris
 
Last edited:
I was wondering. Obviously the AVCHD codec portion of the firmware is capable of things the camera isn't. Are there any other Panasonic cameras that actually use these capabilities? If they share a common library it might be worth having a look at other firmware, if we can get it.

I've looked at the H.264 reference software and haven't been able to find any hints there.

Chris
 
Both patches added to PTool.
Download new release, please.

As for comparison.
Main bitrate related functions have many such comparisons and I don't see reason why you selected this specific one. Can you explain it?
 
Because the codec behaves differently above 30fps. It's just a speculation at this point, probably won't go anywhere.

Chris
 
Because the codec behaves differently above 30fps. It's just a speculation at this point, probably won't go anywhere.

No, I asked why you choosed this branch :-)
Plus FPS is defined in three ways - movie mode, 4 digit encoder value and encoder code. I do not see any two digit numbers among these.
 
Oh, I see. Well, I picked it because I don't understand what it is doing. As for the two digit thing - that could be just because of the compiler. Like I said - it probably won't mean anything, but maybe I'll understand why it's there.

Chris
 
Well, so far this is turning out to be sort of a bust. I don't see where either setting makes any difference at all - even with big changes.

I can only shoot low light right now - and everything tends to be better behaved under these circumstances. Tomorrow I'll test out the scenes that typically break the codec (they require daytime shooting) and see what happens.

Funny, in low light the Native 24p patch works just great.

Ughhh! I hope I haven't wasted your time.

Chris
 
I tested with the high detail daylight scene - no luck. Damned if I can figure out what these settings do. I guess I'll have to dig a lot deeper.

Chris
 
Last edited:
Back
Top