Reverse engineer eines NOR-Flash Filesystems

[Olli Z. (z80freak)]

Hallo! Ich habe hier einen Flash-Dump (32MB) von einem S29GL NOR-Flash. 
Dieser hat in der hinteren Hälfe massenweise 0x200 Blöcke in dieser Art:

01683A00  49 4E 4F 44 22 01 00 00 8C 00 00 00 00 00 00 00  INOD"...Œ.......
01683A10  00 D1 9A B6 F9 1E 01 00 40 2D F7 DA FA 1E 01 00  .Ñš¶ù...@-÷Úú...
01683A20  40 2D F7 DA FA 1E 01 00 00 01 01 00 13 00 00 20  @-÷Úú.......... 
01683A30  EB FF FF FF 01 00 00 00 00 00 00 00 28 00 6A 40  ëÿÿÿ........(.j@
01683A40  0A 5B 43 4F 4E 46 49 47 46 49 4C 45 5F 56 45 52  .[CONFIGFILE_VER
01683A50  53 49 4F 4E 5D 0A 4D 41 4A 4F 52 56 45 52 53 49  SION].MAJORVERSI
...

Alle fangen mit "INOD" an. Das Dump kommt aus einem Bosch 
Navigatonssystem FX mit einem OMAP-Prozessor auf dem ein Nucleus RTOS 
läuft.

Jetzt würde ich gern den Aufbau des Filesystems erkennen. Wo Inodes 
sind, muss ja auch irgendwo ein Index sein und Blocks und Partitionen, 
etc. bis hin zu einem Filesystem.

Hat jemand Tipps für mich wie ich vorgehe um herauszufinden wie das 
aufgebaut ist oder welches Filesystem da drin steckt?

[c-hater (Gast)]

Olli Z. schrieb:

> Alle fangen mit "INOD" an.

So what? Das beweist oder zeigt erstmal rein garnix. Allenfalls könnte 
man mal nach Filesystemen suchen, die eben dieses Magic verwenden.

Das überlasse ich dir, denn: bei dir wird Google genauso funktionieren 
wie bei mir, aber es ist DEIN Problem...

> Jetzt würde ich gern den Aufbau des Filesystems erkennen. Wo Inodes
> sind, muss ja auch irgendwo ein Index sein und Blocks und Partitionen,
> etc. bis hin zu einem Filesystem.

Naja, ich halte das für ein recht gewagte Annahme. Längst nicht alles, 
was sich als "INOD" ausgibt muss auch ein INode in dem von dir 
angenommenen Kontext sein...

> Hat jemand Tipps für mich wie ich vorgehe um herauszufinden wie das
> aufgebaut ist oder welches Filesystem da drin steckt?

Denken, testen. Selber.

[aiaiai (Gast)]

Olli Z. schrieb:
> Hat jemand Tipps für mich wie ich vorgehe um herauszufinden wie das
> aufgebaut ist oder welches Filesystem da drin steckt?

Zuerst mal schauen ob fdisk (linux) damit was anfangen kann:

losetup -f raw_image.bin
fdisk -l /dev/loop0

[Felix U. (ubfx)]

Wie wärs mit binwalk?

[Hmmm (Gast)]

Olli Z. schrieb:
> Jetzt würde ich gern den Aufbau des Filesystems erkennen.

Könnte Reliance sein:
https://hackspire.org/index.php/Internal_Filesystem#INOD_header

[Olli Z. (z80freak)]

aiaiai schrieb:
> Zuerst mal schauen ob fdisk (linux) damit was anfangen kann:
Gute Idee, hatte ich auch schon versucht, aber das wäre fast zu einfach 
gewesen:

Disk /dev/loop0: 33 MB, 33554432 bytes
255 heads, 63 sectors/track, 4 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfd86f000

Disk /dev/loop0 doesn't contain a valid partition table

Es ist ja so das am Anfang des Flash eine ARM Vector-Tabelle steht, dann 
kommt ein Bootloader, vermutlich der Kernel und irgendwo dahinter das 
Filesystem. Ich bin mir nicht sicher ob fdisk einfach mal so durchsucht 
bis es was gültiges findet.

[Olli Z. (z80freak)]

Hmmm schrieb:
> Könnte Reliance sein:
> https://hackspire.org/index.php/Internal_Filesystem#INOD_header

Jaaa, das kommt schon hin! An ein Reliance FS habe ich auch gedacht...
eine sehr gute und informative Website die Du da gefunden hast!

[aiaiai (Gast)]

Olli Z. schrieb:
> Es ist ja so das am Anfang des Flash eine ARM Vector-Tabelle steht, dann
> kommt ein Bootloader, vermutlich der Kernel und irgendwo dahinter das
> Filesystem. Ich bin mir nicht sicher ob fdisk einfach mal so durchsucht
> bis es was gültiges findet.

Nein das nicht, du kannst dem losetup ein offset mitgeben. Das musst du 
aber selbst herausfinden.
Bei 32MB ist das aber auch nicht schwer, alle Adressen einfach 
durchzuprobieren.

[Olli Z. (z80freak)]

Felix U. schrieb:
> Wie wärs mit binwalk?

Gute Idee

$ binwalk fx_flashdump.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
1310752       0x140020        ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
1311328       0x140260        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
1351872       0x14A0C0        Unix path: /dev/registry/LOCAL_MACHINE
1370352       0x14E8F0        Unix path: /dev/ffd/CD_PARAM
1394524       0x15475C        Unix path: /dev/ffs/FC_DOWNLOAD_VER.DAT
1400528       0x155ED0        Unix path: /dev/ffd/CD_PARAM
1405992       0x157428        Unix path: /dev/fgs/dim
1437636       0x15EFC4        Unix path: /dev/adc/7
1441568       0x15FF20        Unix path: /dev/ffs2/FC_SPM_ENG.dat
1443820       0x1607EC        Unix path: /dev/card/em_trace.bin
1448356       0x1619A4        Unix path: /dev/ffd/TTFIS
1517876       0x172934        Unix path: /dev/ffs/mif/mif01.cfg
1519156       0x172E34        Unix path: /dev/ffs/mif
1520320       0x1732C0        Unix path: /dev/ffs/CRDSHARE.DAT
1634480       0x18F0B0        Copyright string: "Copyright (c) 2003 - 2005 Datalight, Inc."
2095836       0x1FFADC        Copyright string: "Copyright (c) 2003 - 2005 Datalight, Inc."
2387584       0x246E80        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/BASE/DOWNLOAD/CHINASIBD
2418955       0x24E90B        Copyright string: "Copyright MGC 2003 - Nucleus PLUS v. 1.14.5 - ARM926T TI OMAP5912 RVCT 2.0.1"
2427712       0x250B40        CRC32 polynomial table, little endian
2444640       0x254D60        Unix path: /dev/adc/0
2481652       0x25DDF4        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT
2490324       0x25FFD4        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
2507828       0x264434        Unix path: /dev/ffs/FC_DOWNLOAD_LMM.DAT
2508672       0x264780        Unix path: /dev/registry/LOCAL_MACHINE
2509996       0x264CAC        Unix path: /dev/ffs/FC_DOWNLOAD_FEA.DAT
2513944       0x265C18        Unix path: /dev/registry/LOCAL_MACHINE
2515404       0x2661CC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/NAVAPP
2520176       0x267470        Unix path: /dev/ffs/cfg/navdreg.reg
2524604       0x2685BC        Unix path: /dev/ffs/FC_DOWNLOAD_CRC.DAT
2526836       0x268E74        Unix path: /dev/ffs/DnlSrcUSB.set
2528768       0x269600        Unix path: /dev/registry/LOCAL_MACHINE
2537168       0x26B6D0        Unix path: /dev/ffs/DSDSE.CFG
2541572       0x26C804        Unix path: /dev/ffs/download.off
2543580       0x26CFDC        Unix path: /dev/ffs/ffsbat.ena
2547964       0x26E0FC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
2565196       0x27244C        Unix path: /dev/registry/LOCAL_MACHINE
2568072       0x272F88        Unix path: /dev/ffs/chinasi.cfg
2571508       0x273CF4        Unix path: /dev/ffs/DnlSrcUSB.set
2574892       0x274A2C        Unix path: /dev/fgs/download
2579000       0x275A38        Unix path: /dev/rp_if/download
2605532       0x27C1DC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS
2610976       0x27D720        Unix path: /dev/ffs2/FC_SPM_LMM.dat
2640488       0x284A68        Unix path: /dev/ffs2/FC_SPM_ENG.dat
2651532       0x28758C        Unix path: /dev/ffs2/FC_SPM_LMM.dat
2661392       0x289C10        Unix path: /dev/rp_if/power
2662772       0x28A174        Unix path: /dev/registry/LOCAL_MACHINE
2677180       0x28D9BC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/NAVAPP
2678540       0x28DF0C        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/SDS
2683752       0x28F368        Unix path: /dev/ffs2/base.reg
2685612       0x28FAAC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/SYSTEM
2686832       0x28FF70        Unix path: /dev/ffs2/FC_SPM_LMM.dat
2689460       0x2909B4        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/BASE
2691804       0x2912DC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
2694004       0x291B74        Unix path: /dev/fgs/system
2724700       0x29935C        Unix path: /dev/ffs/Bluetoothtest.bin
2725584       0x2996D0        Unix path: /dev/ffs/dabtest.bin
2726844       0x299BBC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS/
2728156       0x29A0DC        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/NAVAPP/
2728928       0x29A3E0        Unix path: /dev/ffs/FC_DOWNLOAD_VER.DAT
2737984       0x29C740        Unix path: /dev/registry/LOCAL_MACHINE
2768532       0x2A3E94        Unix path: /dev/registry/LOCAL_MACHINE
2789948       0x2A923C        Unix path: /dev/registry/LOCAL_MACHINE/software/blaupunkt/process/navapp/data_server/app_config
2792032       0x2A9A60        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/BASE/SPM/APP_THREAD
2798496       0x2AB3A0        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS/BASE_SW_VERSION
2799952       0x2AB950        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/BASE/SPM/APP_THREAD
2800116       0x2AB9F4        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/PROCESS/BASE/SPM/AIF_CONFIG
3027871       0x2E339F        Copyright string: "Copyright (c) 1993-2005 Datalight, Inc."
5503142       0x53F8A6        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
5768812       0x58066C        Unix path: /dev/cryptcard/RT2/RT3.TXT'
6207992       0x5EB9F8        Unix path: /dev/ffs2/burnin
6260754       0x5F8812        Unix path: /dev/ffs/FC_AUDIOPL_LMM.DAT
6418819       0x61F183        Unix path: /dev/ffs/VD_DIMMING_LMM.DAT
6680854       0x65F116        Unix path: /dev/ffs/UAM_LMM.DAT
6735014       0x66C4A6        Unix path: /dev/ffs2/bHA
7562448       0x7364D0        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
8124681       0x7BF909        Unix path: /dev/ffs/PDATA_MNGR_LM.DAT
8277662       0x7E4E9E        Unix path: /dev/registry/LOC#`w
8505172       0x81C754        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
8641485       0x83DBCD        Base64 standard index table
9660287       0x93677F        Unix path: /dev/ffs/rcerr_%03d.log
12836002      0xC3DCA2        Unix path: /dev/ramdisk/fcsina2L
13107224      0xC80018        Unix path: /bin/nucleus/arion/release/ -IY:/build/nucleus_core/init/nucleus/arion/startup_r/release/ -IY:/build/nucleus_core/init/nucleus/a
16906438      0x101F8C6       Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
17172108      0x106068C       Unix path: /dev/cryptcard/RT2/RT3.TXT'
17611288      0x10CBA18       Unix path: /dev/ffs2/burnin
17664050      0x10D8832       Unix path: /dev/ffs/FC_AUDIOPL_LMM.DAT
17822115      0x10FF1A3       Unix path: /dev/ffs/VD_DIMMING_LMM.DAT
18084150      0x113F136       Unix path: /dev/ffs/UAM_LMM.DAT
18138310      0x114C4C6       Unix path: /dev/ffs2/bHA
18965744      0x12164F0       Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
19527977      0x129F929       Unix path: /dev/ffs/PDATA_MNGR_LM.DAT
19680958      0x12C4EBE       Unix path: /dev/registry/LOC#`w
19908468      0x12FC774       Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
20044781      0x131DBED       Base64 standard index table
23611146      0x168470A       Unix path: /dev/acousticout/speech/0
24419594      0x1749D0A       Unix path: /dev/acousticout/speech/0
24703242      0x178F10A       Unix path: /dev/acousticout/speech/0
25321738      0x182610A       Unix path: /dev/acousticout/speech/0
25753354      0x188F70A       Unix path: /dev/acousticout/speech/0
25829130      0x18A1F0A       Unix path: /dev/acousticout/speech/0
26294538      0x191390A       Unix path: /dev/acousticout/speech/0
26782986      0x198AD0A       Unix path: /dev/acousticout/speech/0
28001546      0x1AB450A       Unix path: /dev/acousticout/speech/0
29254410      0x1BE630A       Unix path: /dev/acousticout/speech/0
29594378      0x1C3930A       Unix path: /dev/acousticout/speech/0
29674494      0x1C4CBFE       MySQL ISAM index file Version 1
32208138      0x1EB750A       Unix path: /dev/acousticout/speech/0

[Olli Z. (z80freak)]

"Copyright (c) 2003 - 2005 Datalight, Inc." - Die vertreiben ein RTOS. 
Da gibt es einen Flash-Treiber namens "Reliable Edge"
"Nucleus PLUS v. 1.14.5" - Das OS
"ARM926T TI OMAP5912 RVCT 2.0.1" - Die Hardware Plattform (was bedeutet 
"RVCT"?)
"CRC32 polynomial table, little endian" - Damit ist dann die 
Prüfsummenberechnung klar
"MySQL ISAM index file Version 1" - Das bezweifle ich ;-)

[void (Gast)]

Olli Z. schrieb:
> (was bedeutet "RVCT"?)

https://developer.arm.com/documentation/dui0205/f/introduction/about-rvct

[Horst72 (Gast)]

Olli Z. schrieb:
> Hat jemand Tipps für mich wie ich vorgehe um herauszufinden wie das
> aufgebaut ist oder welches Filesystem da drin steckt?

Du könntest Dich ja auch 'mal bei freetz
umsehe und ggf. das dort als weitere "Inspiration"
benutzen
https://freetz.github.io/wiki/help/howtos/development/flash.html
:-)

[Olli Z. (z80freak)]

Danke, ich denke das Flash welches ich hier vor mir habe hat mit einem 
Linuxuiden Aufbau wenig zu tun. Das RTOS bietet zwar wohl sowas wie ein 
Filesystem, geht damit aber scheinbar ganz anders um.

Ein wichtiger Unterschied ist wohl auch noch die Flash-Technologie, denn 
ein NAND hat ganz andere Betriebsparameter als ein NOR-Flash, welches in 
dem Gerät verbaut ist. Auch das wird einen Einfluss auf die Nutzung 
haben.

In Summe finde ich das aber sehr spannend und Aufschlußreich :-)

https://www.pentestpartners.com/security-blog/how-to-do-firmware-analysis-tools-tips-and-tricks/

[Thomas Z. (usbman)]

Datalight ist bekannt für diverse Flash File Systeme die bieten auf der 
HP auch Downloads. Die haben auch das RomDos gebaut was früher sehr oft 
im Einsatz war.

[Olli Z. (z80freak)]

Das heißt sich da mal versuchen schlau zu machen. Muss nochmal nachlesen 
was die Ausgabe mit "Unix-Path: ..." bedeutet, ob binwalk da 
zusammenhängende Dateien erkannt hat und diese extrahieren könnte...
Auch die Frage ob in dem ganzen Verschlüsselung und Compression noch 
eine Rolle spielen könnten.

[Olli Z. (z80freak)]

Eine Sache bei binwalk verstehe ich noch nicht. Er durchkämmt das 
gesamte Dump, findet aber letztlich "nur" ein ELF:

1310752       0x140020        ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
1311328       0x140260        Unix path: /dev/registry/LOCAL_MACHINE/SOFTWARE/BLAUPUNKT/VERSIONS
1351872       0x14A0C0        Unix path: /dev/registry/LOCAL_MACHINE
1370352       0x14E8F0        Unix path: /dev/ffd/CD_PARAM
...

Das ist sicherlicht nicht bloß 512 Byte groß (bis zum anfang des "Unix 
path"). Also vermute ich das alles was danach kommt noch zu diesem ELF 
gehört. Sehr wahrscheinlich ist binwalk so ohne weiteres nicht im Stande 
das was vor dem ELF liegt, also vermutlich der Kernel des RTOS 
(Nucleus?) zu erkennen. Ich denke der Aufbau des Flash ansich ist damit 
eher "klassisch", also:
[bootloader (SBL)]
[kernel image]
[application image (ELF)]
[filesystem image]

ELF ist ja nun ein bekanntes Format und ich hätte fast erwartet das ein 
"binwalk -e flashdump.bin" mit dieses separat rausspielt. Aber nix da.

[Thomas Z. (usbman)]

Olli Z. schrieb:
> ELF ist ja nun ein bekanntes Format und ich hätte fast erwartet das ein
> "binwalk -e flashdump.bin" mit dieses separat rausspielt. Aber nix da.

Dem wird auch so sein nur dass dir das FlashFileSystem da sehr 
wahrscheinlich einen Streich spielt. Die Organisation wird da wesentlich 
von den üblichen Strukturen abweichen. Da muss ja wearing und Blockgröße 
des Flashs verwurstelt werden.

[Hmmm (Gast)]

Olli Z. schrieb:
> Eine Sache bei binwalk verstehe ich noch nicht. Er durchkämmt das
> gesamte Dump, findet aber letztlich "nur" ein ELF

Evtl. steckt im Kernel ein Filesystem-Image, und das System läuft dann 
aus einer Ramdisk.

[Olli Z. (z80freak)]

Thomas Z. schrieb:
> wahrscheinlich einen Streich spielt. Die Organisation wird da wesentlich
> von den üblichen Strukturen abweichen. Da muss ja wearing und Blockgröße
> des Flashs verwurstelt werden.

Gut möglich. Es ist ja aber ein über einen Segger JFlash gezogenes 
Image, also nicht wirklich direkt vom Flash-Chip. Der Segger sendet ja 
einen Custom-Code ins SRAM vom OMAP und der wiederrum führt die Befehle 
aus die über JTAG gesendet werden. Ich hätte jetzt daher erwartet das 
ich da wirklich nur die Nutzdaten erhalte und mich nicht um die 
Organisation innerhalb vom Chip kümmern muss. Aber genaues weiss ich 
auch nicht...

[Olli Z. (z80freak)]

So hat es funktioniert mit dem Extrakt:

binwalk -D 'elf' flashdump.bin

Das hat mir ein Unterverzeichnis erstellt und dort die Datei "140020" 
abgelegt. Diese ist 0x1EBFFE0 (32243680) Bytes groß, also genau alles 
bis zum Ende des Flashdumps.

Ok, ein "readelf" ergibt mir das:

root@ubuntu:~/readelf -a 140020
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x90000000
  Start of program headers:          3846632 (bytes into file)
  Start of section headers:          3845512 (bytes into file)
  Flags:                             0x4000016, Version4 EABI, <unknown>
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         28
  Section header string table index: 27

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] SDRAM_INIT        PROGBITS        90000000 000034 000040 00  AX  0   0  8
  [ 2] SDRAM_RO          PROGBITS        90000040 000074 1181ac 00  AX  0   0  8
  [ 3] PADDING1          PROGBITS        901181ec 118220 001000 00  WA  0   0  1
  [ 4] DOE_SDRAM_RO      PROGBITS        901191ec 119220 054f58 00  AX  0   0  4
  [ 5] PADDING2          PROGBITS        9016e144 16e178 001000 00  WA  0   0  1
  [ 6] SDRAM_RW          PROGBITS        9016f144 16f178 04ba30 00  WA  0   0  8
  [ 7] SDRAM_ZI          NOBITS          901bab74 1baba8 1a3458 00  WA  0   0  8
  [ 8] RAMDISK_NOINIT    PROGBITS        9035dfcc 1baba8 000110 00  WA  0   0  4
  [ 9] DOE_SDRAM_RW      PROGBITS        9035e0dc 1bacb8 0018a8 00  WA  0   0  4
  [10] DOE_SDRAM_ZI      NOBITS          9035f984 1bc560 000bd8 00  WA  0   0  4
  [11] SDRAM_STACK_ZI    NOBITS          9036055c 1bc560 00e030 00  WA  0   0  8
  [12] DSP_IMAGE_RO      PROGBITS        a0000000 1bc560 0aba1c 00  AX  0   0  4
  [13] TESTCODE_RO       PROGBITS        a1000000 267f7c 01b9e0 00  AX  0   0  4
  [14] PADDING_TESTCODE  PROGBITS        a101b9e0 28395c 001000 00  WA  0   0  1
  [15] TESTCODE_RW       PROGBITS        a101c9e0 28495c 003e18 00  WA  0   0  8
  [16] TESTCODE_ZI       NOBITS          a10207f8 288774 03a2e4 00  WA  0   0  8
  [17] BB_DSP_ZCLD_ZI    NOBITS          9e000004 288774 000010 00  WA  0   0  4
  [18] CC_DSP_SHARED_POO NOBITS          9e000014 288774 000c00 00  WA  0   0  4
  [19] DD_DSP_SHARED_SEM NOBITS          9e000c14 288774 016000 00  WA  0   0  4
  [20] FF_DSP_SHARED_ZCL PROGBITS        9e016c14 288774 000004 00  WA  0   0  4
  [21] GG_DSP_SHARED_POO PROGBITS        9e020000 288778 000004 00  WA  0   0  2
  [22] HH_DSP_SHARED_SPE NOBITS          9e120000 28877c 00c350 00  WA  0   0  1
  [23] POWER_MODE        PROGBITS        20004000 28877c 000108 00  AX  0   0  4
  [24] IDLE_ENTRY        PROGBITS        20003000 288884 0001ec 00  AX  0   0  4
  [25] .note             NOTE            00000000 288a70 000070 00      0   0  4
  [26] .comment          PROGBITS        00000000 288ae0 122134 00      0   0  0
  [27] .shstrtab         STRTAB          00000000 3aac14 000174 00      0   0  0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  y (purecode), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000034 0x90000000 0x90000000 0x288a3c 0x497ce0 RWE 0x8

 Section to Segment mapping:
  Segment Sections...
   00     SDRAM_INIT SDRAM_RO PADDING1 DOE_SDRAM_RO PADDING2 SDRAM_RW SDRAM_ZI RAMDISK_NOINIT DOE_SDRAM_RW DOE_SDRAM_ZI SDRAM_STACK_ZI

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Displaying notes found in: .note
  Owner                Data size        Description
  ARM                  0x00000060       Unknown note type: (0x40000000)
   description data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Die Einsprungadresse sieht mir nach externem SD-RAM aus, welches am OMAP 
angeschlossen ist (128 MB). Ich vermute also das der Bootloader oder der 
Kernel dieses ELF wirklich ins RAM lädt und dort zur Ausführung bringt. 
Das externe SD-RAM fängt in der Konfiguration des OMAPs ab 0x8000 0000 
an.

Da das Segment "SDRAM_INIT" heißt wirkt es aber als wenn es erst da 
gemacht würde?

Versuche mich auch gerade mal etwas zum Thema ELF aufzuschlauen: 
https://linux-audit.com/elf-binaries-on-linux-understanding-and-analysis/