forums.ps2dev.org

Guest · Last edited by Guest on Sat Jan 15, 2005 10:06 pm; edited 7 times in total

*** 2nd major update 15/01/2005 ***

The 8th file in the PBR file format mentioned in the same thread is a PSAR file. It appears to be a file archive used in memory stick games / firmware updates.

PSAR File header -

Guest · Posted: Mon Jan 10, 2005 6:26 pm Post subject:

*** 2nd MAJOR UPDATE 15/01/2005 ***

After splitting the PSAR file into its members, the delta of the offset between the members, and the sizes defined in the 4 four bytes, are listed here. In full, there are 427 archive members plus the archive magic header, but I will list the first and last 16 here:

Guest · Posted: Mon Jan 10, 2005 6:37 pm Post subject:

[deleted]

Guest · Posted: Mon Jan 10, 2005 6:46 pm Post subject:

[deleted]

pixel · Joined: 30 Jan 2004 Posts: 791

Remembers me. Could you please write a small test which would measure the bytes's apparition percentages ? I mean, well, just count down every time you see a "00", every time there is a "01" etc, and just display the results, sorted by counter. Would help telling to which extend the bytes are supposedly crypted.

Anyway, you left out some important details: There is a big header at the beginning of the PSAR file which has no 00 00 00 06 header, but rather a 01 00 00 00 one, and is unaligned.

Next, your "header" is twice at the beginning:

ooPo · Posted: Tue Jan 11, 2005 7:30 am Post subject:

Looking at the video of how the update appears in the menu:

http://game.memopad.jp/special/psp/images/PSP_0001.wmv

I notice there's a video playing beside the text. It makes me wonder where in the update this data is found. It would make sense that compressed video would appear similar to the structure of the PSAR file - a keyframe of static length followed by some compressed data for the next X frames, repeated...

It would mean that the entire update is located in the UNKNOWN.PSP file though, and that's only aroud 3MB.

*shrug*

Guest · Posted: Tue Jan 11, 2005 11:34 am Post subject:

uspual · Joined: 10 Jan 2005 Posts: 15

ooPo · Posted: Tue Jan 11, 2005 12:32 pm Post subject:

You know, I always thought that movie was actually coming from the UMD itself...

Oh well. :)

uspual · Joined: 10 Jan 2005 Posts: 15

ooPo · Posted: Tue Jan 11, 2005 1:50 pm Post subject:

Having only one game and a braindead PSP, guessing would be about all I can do. :)

ooPo · Posted: Tue Jan 11, 2005 11:51 pm Post subject:

I got access to another PSP and was able to do something I wanted to see.

Memorystick inserted with Ridgeracers savegame, no UMD = small, barely animated icon. Just some moving red stripes on a static background.

When I insert the UMD, it changes to a nice little icon showing a lengthy movie of actual gameplay, with music.

That icon1.pmf may be a small animation, and it still reads a bigger animation from the UMD... as for the update, did you take a look at the video? Its like a home video with a puppy...

So, its possible the PSAR may still be a video of some sort.

uspual · Joined: 10 Jan 2005 Posts: 15

pixel · Joined: 30 Jan 2004 Posts: 791

Remember there was a RIFF file somewhere too. I did check it only roughly though. A .wav file, huh ? Headers are broken, and contents is also highly compressed or crypted (still the same high-entropy in the bytes).

upsual: could you try to zero-kill the RIFF file in there ? it's the 6th file (if starting count from 1), and in the update file, it starts at 0x49763 and contains 0x154ac bytes.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

uspual · Joined: 10 Jan 2005 Posts: 15

ooPo · Posted: Wed Jan 12, 2005 4:10 am Post subject:

Bah. I have to pick up another PSP...

Good work shooting down my ideas, though. :)

Guest · Posted: Thu Jan 13, 2005 1:53 pm Post subject:

I should note.

The original conclusions reached by myself and Pixel about the format of the PSAR file is now very much in doubt. We believe we hit near the mark, but some things are not logical. Expect more discussion on the theories. But I just wanted to get the word out there that the original conclusion is no longer supported. :)

Guest · Posted: Thu Jan 13, 2005 1:57 pm Post subject:

ooPo · Posted: Thu Jan 13, 2005 4:31 pm Post subject:

Myria suggested running a histogram, so I did. It seems to be a very even distribution of values throughout the whole file with a little more 00 than other values... Tyranid tells me that this means its probably either encrypted or random data.

So anyway, I noticed this at the front of the file:

ooPo · Posted: Thu Jan 13, 2005 4:40 pm Post subject:

Hitting the down arrow and quickly scrolling through the list of these 214 matches (hex workshop centers the matched string in the center of the screen), I noticed large sections were exactly the same for EVERY one of these occurences:

ooPo · Posted: Thu Jan 13, 2005 4:53 pm Post subject:

Actually, looking more carefully I see that they do change... but there's only three variants:

It starts as 67A7, for one block:

Guest · Posted: Thu Jan 13, 2005 6:16 pm Post subject:

Yes, I have seen that too, probably spent untold hours on it, I just haven't had time for several days to write a program to do a proper analysis and write it up ;)

The similarlities occur at specific locations in the two types of chunks of the: the header and the data (to use my previous terminology). From this, one can infer some things about the internal structure of those sections.

The implication here, if we follow the current thesis that the file represents a filesystem image, is that the data inside the data structures of the file system is encrypted, but the actual format/layout of the filesystem is not encrypted. This would explain why certain strings of data reappear in a variety of locations.

Since rumour exists that the data stored on UMD disk is encrypted (along with any transmitted data, such as network packets from playing games), it would make sense that the same is true for a game filesystem image, which this may very well represent, based on Uspual's research.

Guest · Posted: Sat Jan 15, 2005 1:41 am Post subject:

I updated my first two postings in this thread to reflect new information and correct old information, and hopefully present it a little better. Very interesting stuff. ;) I will also update the later posts. The reason for editing out the earlier posts rather than adding a new post with the new information is that I didn't want people to have to dig for it and possibly get confused. My apologies to anyone that might have been interested in the historical info. :)

nem · Joined: 13 Jan 2005 Posts: 73

My guess regarding PSAR archive structure is :

PSAR Archive Header 16byte
Archive Member
Header : 0x150 byte
Data : varies in size, Header+0xb0(DWORD)

Archive member data size is aligned by 16 bytes. If there's fractional
data less than 16bytes, something is added to align.

This is more simple, isn't it?

Guest · Posted: Sat Jan 15, 2005 10:12 pm Post subject:

Actually, I had just updated my first posting in the thread with newer research showing essentially the same thing, at the same time your post came through.

I noticed this possibility when the very last archive member didn't follow the 0x150+ rule, instead showing a difference of 0xa0. By moving the offsets of each archive member down by the same amount, everything starts right after the 16 byte file magic header. So I have been all day in the process of writing code and updating information. :)

Keep at it and hopefully we all can get the internals figured out. :)

nem · Joined: 13 Jan 2005 Posts: 73

Little more my findings and guess for your interest.

Some archive member header shares same binary in part. In detail,

nem · Joined: 13 Jan 2005 Posts: 73

PSAR archive member header's size must be 0x150(336) bytes, and there's some coincidence.
Refer to PSP file. Offset +0x28 and +0x2c must be size or something, and its difference is also 0x150(336).
Looking into them, you'll find some funny things to think about.

Pikoro · Joined: 13 Jan 2005 Posts: 56

I'm betting that the PSP file is the flash update utility and the PSAR is the flash rom itself. That being said, It sounds like all these semi-repetitive structures inside the PSAR file perhaps correspond to the blocks that need to be flashed during the update? Sort of a ROM mapping of some kind?
Only reference I can think of is like the Journal on ext3 or jfs.

Just a thought.

Also, thinking that if the psp file is the actual firmware flash utility, perhaps it could be used to read the existing flash and back it up to the memory stick?

fashidus · Joined: 27 May 2005 Posts: 34

this topic needs to be resurrected.... where did the discussion go on the PSAR file system?

ooPo · Posted: Wed Jun 01, 2005 5:29 am Post subject:

It is impolite to bump an old topic without adding anything new to the conversation.