[tr13]

It seems that at 0x006D3890 in decrypted K-7's firmware is something like a bitmap data.
I've included simple plot of the data from that address.
Plotted data is 441600 bytes long (at least i plotted it as 8 bit bytes).
Since i have no idea of the dimensions (if it is bitmap at all - could be some look up table aswell) i choose dimensions to be 32*13800 so the gradients can be visible.
...
Where do you expect menu item bitmaps to be located?

Interesting strings:
[Exposure OB]...[Dark OB]...[K Value (X128)]....[DFS Offset]....PB..B...C:\Main.jpg.C:\Sub.jpg..C:\Thumb.jpg....C:\Comp.raw.C:\Debug.txt....C:\Bayer1.raw...C:\Bayer2.raw...C:\Dark.raw.C:\PreBayer.raw.C:\PreDark.raw..C:\DevI%03d.jpg.
At 6CF030.

You must make simple utility with switchable modes (1-2-4-8-16-14-32 bits) and adjustable size.
PhUp must jump one screen up, PgDn - down.
Cursor-Up/Down - one string movement.
Ctrl-Cursor - one element move (from 1 to 32 bits)
Space - switch various palettes.
Enter - place offset with parameters and entered comment to log file.

Normally this is the only way to find bitmaps inside binary file.

Contact me by email if you want complete specification :-). In normal life I am also project leader and GUI designer, so I can make it :-)

[tr13]

It looks like entries from REALOS/FR file system. So maybe there's a chance to mount it and see more interesting files.

I am quite unsure about REALOS/FR thing. As they could use simple proprietary embedded OS. Nikon D300 is based on similar chip and uses REALOS, but it have copyright string at least.
P.S. And this is just file names, not related to OS.

[falconeye]

Some interesting strings from the K-7 image (sure tr13 knows them all ):

(my comments are marked in italic)

Copyright (C) HOYA CORPORATION
UPDATING DSP FIRMWARE
DETECTED DSP F/W FILE
DETECTED CPU F/W FILE
DETECTED BOTH F/W FILE
DETECTED ETC F/W FILE

so, there are two processors with separate firmware, CPU and DSP!

SetBatteryCheckInformationData
SetStateInformationData
SetCpuSwitchInformationData
SetModeInformationData
SetAeInformationData
SetAfInformationData
SetLensInformationData
SetStrobeInformationData
SetLvInformationData
SetPreALvInformationData
SetPreBLvInformationData
SetBvadDiffInformationData
SetVersionInformationData
SetBvdInformationData
SetDebugInformationData
SetReleaseCountsInformationData
SetTemperatureInformationData
SetBvadInformationData
SetILcdAdjustInformationData
SetICcdOffsetInformationData
SetAfPintShiftInformationData
SetPowerOnInformationData
SetShakeReductionInformationData
SetLensCpuInformationData
SetAutoHorizontalInformationData
SetCameraSpecInformationData
SetAdjustInformationData
STOREDEFECTPIXELDATA
FORCE_FINE_SHARPNESS
DISABLE_AFE_CLAMP_CLIP
DISABLE_AFE_CLAMP_AVEEX
ENABLE_DEBUG_LCD_OFF
DAC_DEBUG_MODE_BREAK
ENABLE_PHASE_CTL_GUI
ENABLE_ROLLING_CAPTURE
ENABLE_ROLLING_STILL
BayerFrameOperation
*** CAutoExposureConfig ***
[Current] Gain / ExpUs
[FlickerExpUs] MaxAnti / HalfAnti / IndexMax
[Basic] ResetLoop / BasicGain / StExpUs
[IsoGain] HBinningIsoGain / FullIsoGain
[Calc] NextAvd / CalcLvd
[Av] Min / Max / MinShift
--- PreProWaveDetect ---
[PrePro Window] H / V
*** CImageTuningReferInfo ***
----- CameraInfo fixed before LiveView -----
[Lens] MinDistance(Dv10) / IsRingAPosition
[P-Line] IsNoLens / IsPermitAvRing
EFlickerFreq 0:NoDe 1:50Hz 2:60Hz 3:Unkn

So, there seems to be a 50/60Hz flicker detection in movie recording! Unfortunately, it doesn't seem to work as videos recorded in Europe at 30fps show flicker. A setting with shutter set at 1/50s would fix it.

[Other] EFlickerFreq / TempSaturationLevel
----- CameraInfo changed during LiveView -----
[Lens] Distance / FocalLength
[Lens] m_wDistanceCm / m_wMv8
[Lens] Vignetting6 / Vignetting12
EAfMethod 0:Cont 1:Pass 2:Manu
[AF] EAfMethod / AfOk
[AE] AeMeteringMode / GetXvData
ESensorMode 0:HBin 1:HFul 2:9Mix
[P-Line] ESensorMode / LvPreview / AvPhotometry
[Zoom] IsZoom / HMag100 / VMag100
[Face] IsDetect / Number / MainIndex
[Track] IsTrack / HMag100 / VMag100
[ContrastAf] IsContrastAf / HMag100 / VMag100
[CPU]HEX CurrentCpuPdBvd
*** CAutoExposureService ***
[LinearityCorrect256]
[VignettingCorrectQuaterEv256]
[VNT] m_iFocalLengthMag
[Cosine4CorrectQuaterEv256]

A Cosine4 correct would affect every lens, independent of lens calibration info!

[TotalVignettingCorrectEv256]
[TotalVignettingCorrectFullEv256]
[Av] MinAv8 / MaxAv8 / CurrentAv8
[Zoom] StartX / StartY / SizeH / SizeV
[MainFace] StartX / StartY / SizeH / SizeV
[Face] StartX / StartY / SizeH / SizeV
[Track] StartX / StartY / SizeH / SizeV
[ContrastAf] StartX / StartY / SizeH / SizeV
----- Result of LiveViewAE Calc -----
[Calc] m_dwAeTarget256 / m_dwAeAverage256
iBv8 = iAv8 + iTv8 - iXv8 - iSv8 - iLogMag8
[Ev]iBv8 / iAv8 / iTv8 / iXv8 / iSv8 / iLogMag8
[Calc]HEX Bv8 / LvDash8 / LvDash32
----- Multi LiveViewAE Calc -----
[1] BvMin / BvMax / FullScreenAve
[2] BvTop / BvBottom / BvLeft / BvRight / BvMiddle / MiddleCenter
[4] OffsetByLv / OffsetByHist
[5] FaceAve / FaceRatio10000 / OffsetByFace
[Other] InTheMid / BasicGain
[Other2] AfMethod / Distance / Ah / AfLink / AfOk
[10] BackLightMag / ObjectNum / CenterMaxTarget
[11] ClipEv256 / FullScreenAveClipped / BvAve6x6Clipped
[m_ardwFirstBvAverage6x6]
[m_ardwBvAverage6x6]
[m_ardwDetectData256]
--- <TEMPERATURE> ---
Kl4(BackEndContractor)
[Bulb Exposure Interval Time (ms)]
[Bulb Exposure Time (ms)]
[Bulb Exposure Last Time (ms)]
[Exposure Interval Count]
[Bulb ReadOut DownGain Index]
[ISO1600 ReadOut DownGain Index]

What the heck do they special with ISO1600?

[ALL ReadOut DownGain Index (x8192)]
[Exposure Start Temperature (X10)]
[Exposure End Temperature (X10)]
[Dark Temperature (X10)]
[Bulb Dark Interval Time (ms)]
[Bulb Dark Last Time (ms)]
[Bulb Dark Time (ms)]
[DecideLongExposureReadoutDownGain]
[CheckBulbReadoutDownGain]
[INTERVALTime (msec)]
[SENSOR TEMP (x10)]

Temperature is called sensor temp! We had the discussion in the green line thread if EXIF temperature is sensor, processor or board temperature ...

[BULB SUBST RATIO (CNT) X4096 R/Gr/Gb/B]
[BULB SUBST RATIO (TMP) X4096 R/Gr/Gb/B]
"SerialNo(UID)","FwVersion","TryCount","DacDustCount","DacDustMax","Judge","DaDustCount"
===LENS CPU F/W UPDATE===

There is a lens cpu?

VER.%01d.%02d.%02d.%02d
VER.%01d.%02d.%02d.%02d
[OK] Start [LEFT] Stop
LENS_COMUNICATION_CHECK
COLOR_PINT_COR_CLEAR
Create Recovery Firmware
DEBUG MODE <EN>
DEBUG MODE <DIS>
CARDDOOR OPEN <EN>
CARDDOOR OPEN <DIS>
WRITE CARD VNDR <EN>
WRITE CARD VNDR <DIS>
SCRIPT EN MODE <EN>
SCRIPT EN MODE <DIS>
AUTO TEST MODE <EN>
AUTO TEST MODE <DIS>
USR DAT CLEAR
REGION CODE <%02X>
SWITCH TEST
RELEASE AGING <MAN >
RELEASE AGING <AUTO>
LENS COM CHECK
AF PINT DISP
CAMERA LOG DISP
DSP ADJ DAT CAMERA=>SD
DSP ADJ DAT SD=>CAMERA
CPU ADJ DAT CAMERA=>SD
CPU ADJ DAT SD=>CAMERA
CAMERA LOG CAMERA=>SD
CPU ROM DAT CAMERA=>SD
DSP ROM DAT CAMERA=>SD
LENS ROM DAT SD=>CAMERA
LENS ROM DAT CAMERA=>SD
LENS ROM EDIT R/W
LENS CPU FWUP
(((DUST REDUCTION)))
BOARD VER
DSP CHIP VER
DUST REDUCTION TEST
MEDIA TEST
DISPLAY TEST
MEMORY TEST
I-CCD PINT OFF CLR...
COLOR PINT COR CLR...


(TrackObjectPipeService)
[Contrast AF Area Center Li
[Detect End Focus Pulse]
[AF Complete Over Pulse]
[Search Step Pulse]
[Lens Pulse Position] [Co
(ContrastAfDetection)
(FaceDetectPipeService)
(DigitalFilterAfterCare)
(DigitalFilterBaseMake)
(DigitalFilterCross)
(DigitalFilterCustom)
(DigitalFilterExtractColor)
(DigitalFilterMonotone)
(DigitalFilterPastel)
(DigitalFilterRetro)
(DigitalFilterWaterColor)
(DigitalFilterMiniature)
(DigitalFilterFreeRectRotation)
(DigitalFilterBubble)
(DigitalFilterToyCamera)
(CombineHighDynamicRangeImage)

Ok, here is the HDR function

CLcdCoreDriver::CheckRegister()
CLcdDmaDriver::CheckRegister()
CVideoCoreDriver::CheckRegister()
CVideoDmaDriver::CheckRegister()
(DigitalFilterSoftFocus)
(DigitalFilterColor)
(DigitalFilterFishEye)
(DigitalFilterHighContrast)
CON,PRN,NUL,AUX,LPT1,LPT2,LPT3,LPT4,COM1,COM2,COM3,COM4

traces of the FAT32 file system

Copyright (c) 2005-2009 by FotoNation. All rights reserved.
Face Detection Library v.1.2.118.4

So, we now know where Pentax got their face detection from: FotoNation FaceTools

end of strings


All the strings of the menu entries (about 100 strings for 20 languages, maybe ~200kB with UTF-16) may be in a compressed in-memory localization file, uncompressed after language selection only.

[rparmar]

Lpt4... Lol!

[tr13]

if you look at LSI scheme at my site you'll find that LSI have dual processors - one is slower CPU) and one is faster (DSP).

And as for Fotonations library - as I understand they are simply the best now.
Most cameras use them. P&S are just better suited for this task.

[Class A]

The Magic Lantern Firmware Wiki links to tr13's hack site.

If you haven't seen it yet, check out this .

BTW, do firmwares come with a legal note that forbids reverse engineering? I don't remember ever having seen one but many pieces of software do come with such a disclaimer.

[jamesm007]

[Bulb ReadOut DownGain Index]
[ISO1600 ReadOut DownGain Index]

What the heck do they special with ISO1600?

Because the function is near the bulb mode it may have something to do with the bulb mode having an upper iso limit of 1600. I believe the function reads the iso and prevents it from going over 1600 in bulb mode.

[tr13]

BTW, do firmwares come with a legal note that forbids reverse engineering? I don't remember ever having seen one but many pieces of software do come with such a disclaimer.

I don't want to go to legal side of things, as it is complete waste of time. But even if such legal note exists it is located in separate text file and is written in foreign language, so, it don't have any legal meaning :-)

[tr13]

[Bulb ReadOut DownGain Index]
[ISO1600 ReadOut DownGain Index]

What the heck do they special with ISO1600?

Because the function is near the bulb mode it may have something to do with the bulb mode having an upper iso limit of 1600. I believe the function reads the iso and prevents it from going over 1600 in bulb mode.

I believe that they play games with actual ISO. Down gain means just lover amplifier gain.
I won't be surprised that actual ISO is temperature dependant even :-)

[tr13]

If anyone want to help.
I think that we must start to look at firmware loader.
Approach of Hudson Trammel (author of 5DII hack) is based on loader analisis.
We also need to look at checksum calculation.
Related data seems to start at 0x8000 offset (for GX20 firmware image).

[infosyn]

Interesting thing is that I don't see menu strings inside K7 firmware :-)

Right. I'd take a guess that the menu strings are localized for a specific language, and stored somewhere separate from the "firmware" code. If the firmware itself were already localized, there'd have to be 5 or more different versions of each firmware release. No?

I have not checked your disassembled code to confirm, but this (storing menu strings as a resource separate from code) is a pretty standard approach in software.

[tr13]

Right. I'd take a guess that the menu strings are localized for a specific language, and stored somewhere separate from the "firmware" code. If the firmware itself were already localized, there'd have to be 5 or more different versions of each firmware release. No?

I have not checked your disassembled code to confirm, but this (storing menu strings as a resource separate from code) is a pretty standard approach in software.

It is not normal for firmware.
And I don't see any problems with localization, look at K10D and K20D firmware images.
If you add any function or change menu you won't have any method to change menu strings. I see no point here.
Also K-m image is full 16Mb image and is equal to flash size.
Strings could be either encoded or replaced by bitmaps.

[tr13]

Firmware disassembly hints:

Loading address is 0x10000000 (at file it is 0x00 offset);

Vector tables (see my site for full K10 table):
GX20 TBR - at 0x3C00
K-m TBR - at 0x3C00
K7 TBR - at 0x1C00

Preferably use FR80 disassembler, but FR60 and FR65 will do.

[froeschle]

There is a lens cpu?

Features and Operation of the Kaf2 Mount

KAF2 lenses without power zooming feature a 4-bit CPU that is virtually identical to that used by the KAF lenses, but it supports also MTF transferral. Lenses with power-zooming feature an 8-bit CPU that additionally supports the power-zooming functionality. The body's central processing unit (CPU) and data processing unit (DPU) interface with the lens' CPU are responsible for controlling the digital communication.

DAs/DFAs may have additional features (e.g. because of SDM).

Google found: INTERCHANGEABLE LENS - Patent - which can communicate with a camera body to which the interchangeable lens is detachably attached to exchange data of the

[tr13]

One interesing thing is that Pentax don't see platform quite interesting advantage.
I mean cheap Power Zooms.
Implementation of script and button controlled zooming (as well as focusing) is very useful for serious filming.
I see this as special script language, so each new stage could be activated by IR or button.