let's see what comes out of this.... :rolleyes:
Very interesting video :P
keep up the work
keep up the work
Quote:
|
To portably describe object modules, ELF files start with a file header and zero or more program or section headers. The file header also contains the information needed to read the program or section headers; these headers might change a little depending on architecture, so the file header has to indicate their size.
The file header starts with four magic numbers: 0x7F, 0x45, 0x4c, and 0x46, in that order. (This corresponds to an ASCII DEL, and the word "ELF.") This is not a four-byte magic number; it is four one-byte magic numbers. If it were a four-byte magic number, there would be endianness problems and the format wouldn't be all cool and portable. The next few bytes indicate the ELF specification revision, the architecture "class" (32-bit or 64-bit, which affects the size of fields in program and section headers), the data-storage format (either big-endian or little-endian two's complement), and information about what ABI to use. There is some divergence in documentation about the remainder of these bytes: some of them are padding, but some implementations document extensions here which may or may not be in use. Various tools use the ELF file header, ranging from linkers to program loaders, to figure out what a file is and what to do with it. Users rarely interact with it. Developers mostly use it through tools, ranging from file to various other types of linkers. PowerPC users will be very glad to note that the header distinguishes between endianness and processor architecture. The ET_CORE file type is only partially specified. Such a file is a core file and while it uses the ELF format at least partially (for instance, an ELF core file should contain sections with standard section headers), there is no detailed specification of how to handle things like register dumps. Program headers are used only in shared libraries and executable programs -- section headers, by contrast, are used in everything. Program headers are needed to create a process image; there might be multiple program headers containing information about a program. Program headers might contain hints about needed dynamic libraries, instructions on where to find a suitable loader, and so on. Dynamically linked executables specify an interpreter (for instance, /lib64/ld-linux-x86-64.so.2 on an x86_64 Linux system or the more prosaic /lib/ld.so.1 on a generic PowerPC Linux). Static executables have simpler program headers because they're self-contained files. For instance, this output from NetBSD's readelf program shows the program headers of a static binary: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x08048000 0x08048000 0x3ecb14 0x3ecb14 R E 0x1000 LOAD 0x3ed460 0x08438460 0x08438460 0x1e63c 0x289608 RW 0x1000 NOTE 0x000094 0x08048094 0x08048094 0x00018 0x00018 R 0x4 This indicates two sections to be loaded: One read-only section of executable code and one read-write section of initialized data. The NOTE section is purely informative. The offset and filesize values indicate the location and size of the data in the object file (or executable); the memory size and address indicate where to store it at runtime and how much space to allocate. In some cases, the amount of space reserved at runtime may be much larger than the space taken up on disk; this would typically reflect a lot of memory which has been initialized to all zeroes. Section headers serve similar functions to program headers, containing information needed by a program loader, such as actual data or code (code is often called "text" just to confuse you). Many specific types are provided for, such as symbol tables, string tables, or even "array of constructors." Nonetheless, the essential contents are similar. |
The test file is a simple yaboot image for booting another Os, but then you try to run it Ps3 crashes to yelov and then to blinking red light. Just uzip it to usb flash, boot to otherOs and run it.
why are you saying that ps3 doesn't support downgrade ? :) for example: for the test unit there are fw capable of downgrade :>
downgrade on debug consoles supported, but on retail it might be possible but i`m not sure at 100%. Downgrade is made for applying patches. We will see what we can do :)
I can be wrong but.... nothing that wasn't known already...
http://www.ibm.com/developerworks/power/library/pa-spec12/
http://www.ibm.com/developerworks/power/library/pa-spec12/
Well its interesting, but in practice the SELF header is required so the system will know how to decrypt it. There are "flags" in the header that tell it what type of file and how to decrypt - if I had to guess, the system may be crashing due to the fact that it can't parse the resulting (encrypted) elf correctly.
Quote:
|
Originally Posted by Hosted
The test file is a simple yaboot image for booting another Os, but then you try to run it Ps3 crashes to yelov and then to blinking red light. Just uzip it to usb flash, boot to otherOs and run it.
|
I also removed your "test.zip" file since this isn't in the PS3 Dev area now.. if you are OK with readding it we can, I think it's fairly harmless myself so let me know. :wacky:
This was a PITA to reorder, so for future reference it's best to Submit news/videos and then they will get copied to the Forums when they go live... versus trying to make a post like this in the PS3 Dev forum where few people will ever see it unless it's auto-copied from the main page.
Quote:
|
Originally Posted by CJPC
Well its interesting, but in practice the SELF header is required so the system will know how to decrypt it. There are "flags" in the header that tell it what type of file and how to decrypt - if I had to guess, the system may be crashing due to the fact that it can't parse the resulting (encrypted) elf correctly.
|
Quote:
|
Originally Posted by CJPC
Well its interesting, but in practice the SELF header is required so the system will know how to decrypt it. There are "flags" in the header that tell it what type of file and how to decrypt - if I had to guess, the system may be crashing due to the fact that it can't parse the resulting (encrypted) elf correctly.
|
Need a way to recreate a parsable elf from self, someone should be working on reproducing encrypted self files/signing files? which i suppose its a big task if Sony's process is unknown.
I don't know much about the topic, but im guessing thats the only way this could become useful.
And in the other thread about libtiff, someone already mentioned the CELL's protection to block unsupported code, (someone would have to help me out on this) which im guessing wouldnt work in a hard crash. or "locking out" hv or tricking it/time attack.
Wouldnt it have been great for Sony to release launch JAP model without the elevated administrator level/hv? A lot more would be known. So this post is pretty vague (because im bored) :) but would recreating the tiff exploit ala psp work with the ps3 (obv different), or not because of the hw? would it need someone specialised in libtiff etc (as mentioned on the other post about the soft crash)...
is there any room for explotation on the boot process/trust chain?
i might be completely wrong though... not very ps3 tech.
I don't know much about the topic, but im guessing thats the only way this could become useful.
And in the other thread about libtiff, someone already mentioned the CELL's protection to block unsupported code, (someone would have to help me out on this) which im guessing wouldnt work in a hard crash. or "locking out" hv or tricking it/time attack.
Wouldnt it have been great for Sony to release launch JAP model without the elevated administrator level/hv? A lot more would be known. So this post is pretty vague (because im bored) :) but would recreating the tiff exploit ala psp work with the ps3 (obv different), or not because of the hw? would it need someone specialised in libtiff etc (as mentioned on the other post about the soft crash)...
is there any room for explotation on the boot process/trust chain?
i might be completely wrong though... not very ps3 tech.
This may seem like nothing to others, but it's more information about the ps3.
Eventually (hopefully) it'll be hacked.
There's been quite a bit of new stuff found out on the ps3 this week :tup:
Keep up the work.
Anything is possible :P
Eventually (hopefully) it'll be hacked.
There's been quite a bit of new stuff found out on the ps3 this week :tup:
Keep up the work.
Anything is possible :P
I'm confused! :confused:
If the self ISN'T a PS3 file, surely the encryption would make no difference as it won't be recognised by the PS3?
If it is a PS3 file, why is the outcome (flashing yellow then red) of any interest? Is that particular light sequence telling us that the code has overflowed in some way?
If the self ISN'T a PS3 file, surely the encryption would make no difference as it won't be recognised by the PS3?
If it is a PS3 file, why is the outcome (flashing yellow then red) of any interest? Is that particular light sequence telling us that the code has overflowed in some way?
Sorry, i don't understand all (i don't speak english regularly). What can we do with this ?
This is just the first step to hacking the ps3. When we find the decoder sequence we'll be onto something.
nice work, very interesting..
