Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 05 Jan 2021, 19:37
I did with a hex editor and the checksum needs to be recalculated. Otherwise, DNL mode will not start and the update will fail.
MicroHacker Forum
Online community for electronics and microcontroller reverse engineering
https://microhacker.denkdose.de/
Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Page 3 of 4
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 05 Jan 2021, 20:07
Yes ... I translated the German language because it has longer words. But! it's not as simple as it might seem. For example, the words "Zieleingabe". This word is used in the announcement (throughout the sentence). But it is to this word that the address "Zieleingabe" of the Navigation menu is linked. So it is necessary to follow exactly the position, order and length of the word, otherwise you will get nonsense in the announcement sentence. It is not so clear to translate a completely different language. In addition, some English words are used in all languages. If you change them, they will also change in other languages. And to make matters worse, there is another inconvenience. Letters with accents have 2 bytes instead of one.DGAlexandru wrote: ↑05 Jan 2021, 18:47 German language usually has long words. Isn't it good enough?
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 05 Jan 2021, 20:20
I tried to replace fgs.dnl from version 841 with the Polish version 828. in the update CD sp 4.1. It works without problems. It is a good idea to translate the Polish language. But we will not have a dark theme. For a long time and unsuccessfully, I try to change the colors to dark. The Polish language is probably translated in a completely different (professional) way. There is also a Czech or Russian version with the dark theme. Does anyone have it?
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 06 Jan 2021, 09:37
Thanks guys, very interesting informations! But ti get any further we really need to understand the structure of the FGS file much better. I think in first we should void the DNL format and use the final flash memory contents.
I use some of my spare FX for such tests. Removing the Flash chip is fairly easy using hot-air-gun and a small wire as a triangle to pull the chip a little up on the heated side. After that, remove the tin from the pins and the board gently, using soldering braid.
To readout the content i use ab RT809H programmer with an TSOP-56 adapter. Also to program it. Soldering it back needs time, a small soldering iron, flux and a magnifying glas.
But this method is not good for testing as it must be repeated over and over... too much effort. The JTAG Port on the board is connected to the Altera Cyclone FPGA. An FPGA is NOT like a CPU, you cannot execute something directly on it. It "forms" a CPU by reading it's IP (intellectual property) from the external ECS4 eeprom. And then it is totally up to the developer if the JTAG is of any use in this stage. I never managed to gain access to the Flash through the Cyclone formed ARM CPU.
To get back to the structure of the text (messages). Look how a programmer would do this and next how a compiler puts this into bytes. Software will usually have messages as C-Strings (0-terminated string) or Pascal-Strings (with a lenght-byte in front). Here we find C-Strings. As messages are usually of variable length, there must be some other array which only contains pointers to each message first byte. A pointer is a memory location and of a fixed lenght (mostly 4 bytes here).
So if the application like to display a message it knows only the location of this pointer-table and the index inside this array. So the in my opinion, the key to have arbitrary length messages is to find this mapping array and be able to set own pointers.
I use some of my spare FX for such tests. Removing the Flash chip is fairly easy using hot-air-gun and a small wire as a triangle to pull the chip a little up on the heated side. After that, remove the tin from the pins and the board gently, using soldering braid.
To readout the content i use ab RT809H programmer with an TSOP-56 adapter. Also to program it. Soldering it back needs time, a small soldering iron, flux and a magnifying glas.
But this method is not good for testing as it must be repeated over and over... too much effort. The JTAG Port on the board is connected to the Altera Cyclone FPGA. An FPGA is NOT like a CPU, you cannot execute something directly on it. It "forms" a CPU by reading it's IP (intellectual property) from the external ECS4 eeprom. And then it is totally up to the developer if the JTAG is of any use in this stage. I never managed to gain access to the Flash through the Cyclone formed ARM CPU.
To get back to the structure of the text (messages). Look how a programmer would do this and next how a compiler puts this into bytes. Software will usually have messages as C-Strings (0-terminated string) or Pascal-Strings (with a lenght-byte in front). Here we find C-Strings. As messages are usually of variable length, there must be some other array which only contains pointers to each message first byte. A pointer is a memory location and of a fixed lenght (mostly 4 bytes here).
So if the application like to display a message it knows only the location of this pointer-table and the index inside this array. So the in my opinion, the key to have arbitrary length messages is to find this mapping array and be able to set own pointers.
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 06 Jan 2021, 10:49
Here is a full readout of the graphicsboard Flash (latest firmware)
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 06 Jan 2021, 11:57
A pointer-array could look like this:
You see many 4 Bytes values (DWORDs) all with ascending values. Remind we are on a Little-Endian order, so read values from right to left. But the targets don't make sense to me right now.
I picked up some messages and tried to find pointer addresses to them, but no luck so far. Maybe the Flash's content is relocated to some other base address, or copied into SD-RAM and so the addresses are different?
Code: Select all
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000BFBF0 53 44 00 00 28 0E 12 01 74 EE 09 01 80 EE 09 01 SD..(...tî..€î..
000BFC00 8C EE 09 01 98 EE 09 01 A8 EE 09 01 B8 EE 09 01 Œî..˜î..¨î..¸î..
000BFC10 CC EE 09 01 E0 EE 09 01 E0 EE 09 01 E0 EE 09 01 Ìî..àî..àî..àî..
000BFC20 E0 EE 09 01 EC EE 09 01 F4 EE 09 01 80 EE 09 01 àî..ìî..ôî..€î..
000BFC30 8C EE 09 01 98 EE 09 01 A8 EE 09 01 B8 EE 09 01 Œî..˜î..¨î..¸î..
000BFC40 CC EE 09 01 E0 EE 09 01 E0 EE 09 01 E0 EE 09 01 Ìî..àî..àî..àî..
000BFC50 E0 EE 09 01 FC EE 09 01 24 EF 09 01 F4 EE 09 01 àî..üî..$ï..ôî..
000BFC60 80 EE 09 01 54 EF 09 01 74 EF 09 01 84 EF 09 01 €î..Tï..tï..„ï..
000BFC70 94 EF 09 01 A0 EF 09 01 A8 EF 09 01 80 EE 09 01 ”ï.. ï..¨ï..€î..
000BFC80 28 0E 12 01 B4 EF 09 01 CC EF 09 01 DC EF 09 01 (...´ï..Ìï..Üï..
000BFC90 28 0E 12 01 80 EE 09 01 28 0E 12 01 E8 EF 09 01 (...€î..(...èï..
000BFCA0 CC EF 09 01 DC EF 09 01 28 0E 12 01 80 EE 09 01 Ìï..Üï..(...€î..
000BFCB0 28 0E 12 01 FC EF 09 01 20 F0 09 01 28 0E 12 01 (...üï.. ð..(...
000BFCC0 28 0E 12 01 80 EE 09 01 34 F0 09 01 48 F0 09 01 (...€î..4ð..Hð..
000BFCD0 58 F0 09 01 58 F0 09 01 60 F0 09 01 70 F0 09 01 Xð..Xð..`ð..pð..
000BFCE0 EC EE 09 01 F4 EE 09 01 84 F0 09 01 98 F0 09 01 ìî..ôî..„ð..˜ð..
000BFCF0 A8 F0 09 01 BC F0 09 01 D4 F0 09 01 E0 F0 09 01 ¨ð..¼ð..Ôð..àð..
000BFD00 F4 F0 09 01 00 F1 09 01 0C F1 09 01 1C F1 09 01 ôð...ñ...ñ...ñ..
000BFD10 34 F1 09 01 98 F0 09 01 58 F1 09 01 60 F1 09 01 4ñ..˜ð..Xñ..`ñ..
000BFD20 68 F1 09 01 68 F1 09 01 A8 F0 09 01 BC F0 09 01 hñ..hñ..¨ð..¼ð..
000BFD30 74 F1 09 01 28 0E 12 01 90 F1 09 01 9C F1 09 01 tñ..(....ñ..œñ..
000BFD40 A0 F1 09 01 28 0E 12 01 BC F1 09 01 CC F1 09 01 ñ..(...¼ñ..Ìñ..
000BFD50 28 0E 12 01 A0 F1 09 01 28 0E 12 01 BC F1 09 01 (... ñ..(...¼ñ..
000BFD60 DC F1 09 01 28 0E 12 01 28 0E 12 01 28 0E 12 01 Üñ..(...(...(...
000BFD70 EC F1 09 01 28 0E 12 01 28 0E 12 01 BC F1 09 01 ìñ..(...(...¼ñ..
000BFD80 08 F2 09 01 18 F2 09 01 38 F2 09 01 28 0E 12 01 .ò...ò..8ò..(...
000BFD90 D4 F0 09 01 58 F2 09 01 64 F2 09 01 6C F2 09 01 Ôð..Xò..dò..lò..
I picked up some messages and tried to find pointer addresses to them, but no luck so far. Maybe the Flash's content is relocated to some other base address, or copied into SD-RAM and so the addresses are different?
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 06 Jan 2021, 20:49
You found this array written in this S29GL064 flash that is next to Alterra FPGA or is it in fgs.dnl file?
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 06 Jan 2021, 23:28
53 44 00 00 is from other data which is before of this pointer database.
I found a similar table at 0x12FC54 in your flash dump. It has a length of 0x13B00 bytes
Right before it we have this readable data:
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_config/lsrns/gen/fgs_DataContainer.cpp
FGS_E8_TYPE_LIST_OF_ELEMENTSD==e8NSDType
poListOfReferencesElementSD->m_e8Type == FGS_E8_TYPE_ELEMENTSD
Guess what? 0x13B00 = 1920 x 42.
42 is number of e8type "things".
The 2 lines after the "code" window might be another property of this table.
.. but at the same time, this table contains a lot of "E8 0F 12 01" in an "not so easy to understand pattern"... the one you showed seems to have the same structure, but the repeating pattern looks to be "28 E0 12 01" .. EXACTLY in the same sequence: We also have this kind of strings:
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppMain/src/FgsAppMain.c
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/src/FgsAppHmi.cpp
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_base/fgs_coAnimation.cpp
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_base/fgs_coBoxBorder.cpp
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_base/fgs_coBoxEditLine.cpp
.
.
.
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_com/fgs_MsgSystem.cpp
Right from this last one we can see a lot of strings with words and sentences in a 4-byte formatted space, first all for Deutsch, then for English, then for other languages; they are in an IDX-TEXT format of maybe 19fgs_tclMsgTextLabel type.
I found a similar table at 0x12FC54 in your flash dump. It has a length of 0x13B00 bytes
Right before it we have this readable data:
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_config/lsrns/gen/fgs_DataContainer.cpp
Code: Select all
e8Type == FGS_E8_TYPE_BORDERLINESD
e8Type == FGS_E8_TYPE_BOXSD
e8Type == FGS_E8_TYPE_OFFSETBOXSD
e8Type == FGS_E8_TYPE_COLORSD
e8Type == FGS_E8_TYPE_FIXTEXTSD
e8Type == FGS_E8_TYPE_IDXTEXTSD
e8Type == FGS_E8_TYPE_VARTEXTSD
e8Type == FGS_E8_TYPE_TEXTSD
e8Type == FGS_E8_TYPE_SYMBOLSD
e8Type == FGS_E8_TYPE_SYMBOLPOISD
e8Type == FGS_E8_TYPE_GRAPHVALUESD
e8Type == FGS_E8_TYPE_LEDDESIGNSD
e8Type == FGS_E8_TYPE_COLORSTATESD
e8Type == FGS_E8_TYPE_SYMBOLSTATESD
e8Type == FGS_E8_TYPE_SYMBOLSTATELGSD
e8Type == FGS_E8_TYPE_BORDER3DSTATESD
e8Type == FGS_E8_TYPE_BORDERSTATESD
e8Type == FGS_E8_TYPE_BORDERSYMSD
e8Type == FGS_E8_TYPE_BORDERSYMSTATESD
e8Type == FGS_E8_TYPE_ELEMENTSD
e8Type == FGS_E8_TYPE_ELEMENTNSD
e8Type == FGS_E8_TYPE_FIXBOXBORDERSD
e8Type == FGS_E8_TYPE_FIXBOXSYMBOLSD
e8Type == FGS_E8_TYPE_FIXBOXTEXTSD
e8Type == FGS_E8_TYPE_FIXCLEARMASKSD
e8Type == FGS_E8_TYPE_BOXBORDERSD
e8Type == FGS_E8_TYPE_BOXEDITLINESD
e8Type == FGS_E8_TYPE_BOXGRAPHVALUESD
e8Type == FGS_E8_TYPE_BOXSYMBOLSD
e8Type == FGS_E8_TYPE_BOXODRSD
e8Type == FGS_E8_TYPE_BOXMAPSD
e8Type == FGS_E8_TYPE_BOXSPELLERSD
e8Type == FGS_E8_TYPE_BOXTEXTSD
e8Type == FGS_E8_TYPE_BOXTEXTFIELDSD
e8Type == FGS_E8_TYPE_BOXLISTSD
e8Type == FGS_E8_TYPE_BOXINFOLINESD
e8Type == FGS_E8_TYPE_CONTAINERLINESD
e8Type == FGS_E8_TYPE_BOXSLIDERSD
e8Type == FGS_E8_TYPE_FIXLINESD
e8Type == FGS_E8_TYPE_LINESD
e8Type == FGS_E8_TYPE_BOXLANEGUIDANCESD
e8Type == FGS_E8_TYPE_LIST_OF_POSITIONpoListOfReferencesElementSD->m_e8Type == FGS_E8_TYPE_ELEMENTSD
Guess what? 0x13B00 = 1920 x 42.
42 is number of e8type "things".
The 2 lines after the "code" window might be another property of this table.
.. but at the same time, this table contains a lot of "E8 0F 12 01" in an "not so easy to understand pattern"... the one you showed seems to have the same structure, but the repeating pattern looks to be "28 E0 12 01" .. EXACTLY in the same sequence: We also have this kind of strings:
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppMain/src/FgsAppMain.c
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/src/FgsAppHmi.cpp
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_base/fgs_coAnimation.cpp
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_base/fgs_coBoxBorder.cpp
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_base/fgs_coBoxEditLine.cpp
.
.
.
/cygdrive/c/AlteraWork/LS_Release/di_fgs_sw/Components/FgsAppHmi/fgs_com/fgs_MsgSystem.cpp
Right from this last one we can see a lot of strings with words and sentences in a 4-byte formatted space, first all for Deutsch, then for English, then for other languages; they are in an IDX-TEXT format of maybe 19fgs_tclMsgTextLabel type.
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 06 Jan 2021, 23:42
Dump structure might be like this:
0x000000 - BootLoader = FGMAGIC DNL -> FGS APP DNL
0x030000 - MainProgram = FGMAGIC TMG -> FGS APP TMG
0x070000 - MainAplication = FGMAGIC STD -> FGS APP STD
from 0x443270 we have only 0xFF
Each of them have a descriptor of 0xAF size... which means the Altera FPGA is instructed to actually "boot" from 0x0000B0, so there should be other chip that instructs this one on what to do - maybe the OMAP one.
Or ... is there an EEPROM or a SPI flash also? This one would be easy to have HW implementation so upon power supply on the Altera FPGA reads it then with the code it finds inside it configures itself and also initializes the flash; in this "ROM" would also find the pointer where to "boot" from.
All 3 blocks look like "normal" ASIC instructions to me - because they contain a lot of strings, at least. This chip being a FPGA, we should have found instructions on how to program the HW logic of a FPGA - ex: LUT tables for decisions, not strings... but I have no experience with FPGA so I might be wrong.
https://www.intel.com/content/dam/www/p ... cii5v1.pdf
https://web.archive.org/web/20120813074 ... a/fpga.pdf
This might mean that what is present in this Flash might be de instructions for the "software CPU" that is emulated over this FPGA so we have bigger chances to be able to understand more by being able to decompile the 3 blocks.
0x000000 - BootLoader = FGMAGIC DNL -> FGS APP DNL
0x030000 - MainProgram = FGMAGIC TMG -> FGS APP TMG
0x070000 - MainAplication = FGMAGIC STD -> FGS APP STD
from 0x443270 we have only 0xFF
Each of them have a descriptor of 0xAF size... which means the Altera FPGA is instructed to actually "boot" from 0x0000B0, so there should be other chip that instructs this one on what to do - maybe the OMAP one.
Or ... is there an EEPROM or a SPI flash also? This one would be easy to have HW implementation so upon power supply on the Altera FPGA reads it then with the code it finds inside it configures itself and also initializes the flash; in this "ROM" would also find the pointer where to "boot" from.
All 3 blocks look like "normal" ASIC instructions to me - because they contain a lot of strings, at least. This chip being a FPGA, we should have found instructions on how to program the HW logic of a FPGA - ex: LUT tables for decisions, not strings... but I have no experience with FPGA so I might be wrong.
https://www.intel.com/content/dam/www/p ... cii5v1.pdf
https://web.archive.org/web/20120813074 ... a/fpga.pdf
This might mean that what is present in this Flash might be de instructions for the "software CPU" that is emulated over this FPGA so we have bigger chances to be able to understand more by being able to decompile the 3 blocks.
Re: Understanding data structure of "fgs.dnl" file from Nav-FX Update-CD
Posted: 09 Feb 2021, 17:17