bueno os pongo mas de lo que he encontrado si alguien sabe traducir algo mejor que mejor.
actualizacion diciembre del 2006
Dump of file December2006.xex
FILE HEADER VALUES
1 module flags
title module
92000000 load address
AB5000 image size
FFFFFFFF game region
North America
Japan
rest of Asia
Australia/New Zealand
rest of Europe
rest of world
10000000 image flags
4KB pages
4 allowed media types
DVD/CD
XGD2 media ID: 00000000000000000000000000000000
Signature digest: A8EACCCF B7E821EE 88AD02DB 2EE45C2E 18B603D1
D number of optional header entries
OPTIONAL HEADER VALUES
92000000 image base address
92018EE0 entry point
000CA54F image checksum
457DD57D image timestamp
40 number of TLS slots
00010000 default stack size
COMPRESSED, ENCRYPTED
Original PE image name: installupdate.exe
Image includes Xbox 360 Logo
LAN key: 00000000000000000000000000000000
EXECUTION ID
1746B9BF media ID
20139600 version (2.0.5014.0)
20139600 base version (2.0.5014.0)
FFFEFFFE title ID
0 platform
0 executable type
0 disc number
0 discs in set
00000000 save game ID
SYSTEM IMPORT LIBRARIES
xam.xex version 2.0.3215.0 (minimum 2.0.1861.0)
xboxkrnl.exe version 2.0.3215.0 (minimum 2.0.1861.0)
xam.xex version 2.0.3215.0 (minimum 2.0.1861.0)
LIBRARY VERSIONS
XAPILIB 2.0.3215.0 [expired]
LIBCMT 2.0.3215.0 [expired]
XBOXKRNL 2.0.3215.0 [expired]
D3D9 2.0.3215.1 [expired]
D3DX9 2.0.3215.0 [expired]
XUIRUN 2.0.3215.0 [expired]
XUIRNDR 2.0.3215.0 [expired]
XAUD 2.0.3215.0 [expired]
XGRAPHC 2.0.3215.0 [expired]
RESOURCE SECTION #1
UPDATES name
920CA000 base address
9DB0BC size
RESOURCE SECTION #2
MEDIA name
92AA5100 base address
F620 size
y este otro:
XUIKeyboard example program compiled using the
K360
Dump of file xuikeyboard.xex
FILE HEADER VALUES
1 module flags
title module
82000000 load address
350000 image size
FFFFFFFF game region
North America
Japan
rest of Asia
Australia/New Zealand
rest of Europe
rest of world
0 image flags
64KB pages
8000605 allowed media types
hard disk
DVD/CD
SMB filesystem
direct-from-RAM
Live-signed package
XGD2 media ID: 00000000000000000000000000000000
Signature digest: 4793FEA6 99BEF6FC D3A7B8C3 9F4782F7 D2B21DF3
A number of optional header entries
OPTIONAL HEADER VALUES
82000000 image base address
82091E98 entry point
0034D751 image checksum
4582AFBE image timestamp
40 number of TLS slots
00040000 default stack size
NOT-COMPRESSED, ENCRYPTED
Original PE image name: XuiKeyboard.exe
LAN key: 00000000000000000000000000000000
SYSTEM IMPORT LIBRARIES
xam.xex version 2.0.4929.0 (minimum 2.0.1861.0)
xboxkrnl.exe version 2.0.4929.0 (minimum 2.0.1861.0)
LIBRARY VERSIONS
D3D9 2.0.4929.0 [approved]
D3DX9 2.0.4929.0 [approved]
XAPILIB 2.0.4929.0 [approved]
XBOXKRNL 2.0.4929.0 [approved]
XUIRUN 2.0.4929.0 [approved]
XUIRNDR 2.0.4929.0 [approved]
LIBCMT 2.0.4929.0 [approved]
XGRAPHC 2.0.4929.0 [approved]
XACT 2.0.4929.0 [approved]
XAUD 2.0.4929.0 [approved]
X3DAUD 2.0.4929.0 [approved
Personally I'm trying to get my hands on the Key.bin, plus figure out the password so that I can compile using the
K360 so my programs will run on the retail kit. Developer Kits are quite expensive and in short supply atm, so development on the hardware is very slow especially with a number of programmers using the same DevKit. Having a realistic alternative would be very valuable to me.
Especially as I was hoping to create a game for my lass for christmas, and due to my retarded ISP not supported by Microsoft using XNA just isn't an option (until they put the creators club runtime on xbox.com to download).
ironically, if these two aspects were figured out it would be possible to alter the xdk recovery iso so that it would install to xbox 360 retail premium packs (or any xbox360 with a HDD)
si alguien entendido puede sacar algo en claro mejor jejej gracias y un saludo que quiero que no se duerma el hilo sino que se debata cosas.
"¿alguien me puede decir donde conseguir el xexdump?"GRACIAS
bueno os pongo nuevas cosas para los entendidos:
A small update:
During power on the 360 loads the base Kernel from the "CB" section (could this also contain the dreaded Hypervisor?) examines the 2 patch slots (specifically the header of the "CF" sections) and selects the most recent to apply to the base Kernel. The address of the patch slot is in the first 512 byte page, the second slot occurs 0x10000 bytes later, typically these are at:
0x6c000 and 0x7c000 for "CB" section (version 1888, length 0x61E0) or
0x70000 and 0x80000 for "CB" section (version 1903, length 0x9310, even though "CB" section header indicate version 1903 the dash reports BK as 1888)
So what's in the rest of the flash and how does the correct data get loaded?
Quote from GaryOPA:
"The 16mb NAND flash is not completely encrypted, it basically is a Microsoft compressed ROMDISK system.
It contains a small header, then a "encrypted" loader, and then a number of stored files in a "compact flash" file system, these files match byte for byte the updated files in the "system_update", and are basically the dashboard files in stored signed-XEX2 file format."
So how does the 360 find it's ROM file syatem?
Within my Flash dump I can see a total of four "root directories" at:
0xD9C000
0xD98000
0xABC000
0xA20000
During the boot process (shortly after the most upto date patch is selected and loaded) the 360 scans it's entire ROM from 0xFFC000 to 0x000000 in 0x4000 byte or NAND flash block sized chunks. When it finds something "interesting" in the first page of that block it reads the whole 0x4000 bytes in page sized chunks. In my 360 I see the following "interesting" blocks being read:
D9C000 Start of FS root? Contains xex, xexp2 & xttp2 files
AC0000 Start of Dashboard Settings? (hehe, the dashboard video resolution is visible in here)
A20000 Start of FS root? Contains xex, xexp1, xexp2, xttp1 & xttp2 files
91C000 Unknown
Note: Every time the dashboard settings are modified (I changed video settings) a new 3*512 block is appended to the end of the list starting at 0xAC0000, presumably the 360 scans this list and picks the last valid one. How the FS root is selected is currently unknown and FFS
When an update is applied the patch data is copied to the "CF" section and encrypted (applying the same patch twice results in different data, presumably the encrytion key changes each time, the associated "CG" section appears to remain the same). The xexp files found in the system update folder are copied to the ROM FS and renamed either xexp1 or xexp2. It seems that the xexp1/2 file extension is selected based on the patch slot. In my case slot 1 (0x6c000) was to be populated and xexp patch files are renamed xexp1 when copied to the ROM FS.
When a file, such as bootanim.xex is read from the ROM filesystem a check appears to be made and if a patch is being applied the corresponding xexp1/2 file is also read (there is speculation with a fair degree of certainty that these two files are then combined in RAM to give the correct version). The choice of xexp1 or 2 is fixed by the patch slot selected
fuente:xboxhacker
no se si seran cosas interesnates pòrque no entiendo ni jota pero si alguien nos lo resume se agradeceria.GRACIAS