Discussion of the PSAR file format

[Guest]

*** 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 -

Code: Select all

 First 16 bytes of the PSAR file
00 to 03 == "PSAR"   (magic for this file)
04 to 07 == 01 00 00 00
08 to 0B == NN NN NN NN
0C to 0F == 01 00 00 00

Where NN NN NN NN == Size of the archive file (not including the PSAR header)

The following C structs represent the latest research in attempting to ascertain the data structures in the file.

Code: Select all

struct PSARmemHdr
{
        u_int8_t        rfu00[0xB0];    // Unknown
        u_int32_t       memDataSize; // Unpadded
        u_int8_t        rfu01[0x04];    // [0] always 0x80 ??
        u_int8_t        rfu02[0x18];    // [*] Always 0x00 ??
        u_int8_t        rfu03[0x04];    // [3] always 0x06 ??
        u_int8_t        rfu04[0x0C];    // Unknown
};

struct PSARmemTrl
{
        u_int8_t        rfu04[0x70];    // Unknown
};

struct PSARmember
{
        struct PSARmemHdr       memHdr;
        struct PSARmemTrl       memTrail;
       // It is yet unknown memTrail precedes or follows the data.

        u_int8_t                memData[];
       // memData padded to 16 bytes alignment. 
       // A "type 1" member is always 0x110 bytes
       // A "type 2" is variable.
};

There are 2 kinds of archive members, one always preceding the other.
The first type is always 608 bytes (0x260) in length, with its member data always 272 bytes (0x110). The second type is variable length. Like nearly every PSP file seen, the data is 16-bite aligned.

Code: Select all

The file is layed out like this:
1. PSAR Header
2. Archive member type 1
    a. Header
    b. Data
3. Archive member type 1
    a. Header
    b. Data
4. Archive member type 2
    a. Header
    b. Data
....
N-1. Archive member type 1
    a. Header
    b. Data
N. Archive member type 2
    a. Header
    b. Data

The first two archive members are "type 1" followed by a "type 2". After this, it alternates "type 1" and "type 2".

Type 1 : 272 bytes (0x110) data
Type 2 : Variable data

[Guest]

*** 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:

Code: Select all

 
Num   Offset     Size Pad
  0       10      110 0
  1      270      110 0
  2      4d0      2a7 9
  3      8d0      110 0
  4      b30      3d8 8
  5     1060      110 0
  6     12c0      24c 4
  7     1660      110 0
  8     18c0      2a9 7
  9     1cc0      110 0
  a     1f20      3d2 e
  b     2450      110 0
  c     26b0      244 c
  d     2a50      110 0
  e     2cb0      2a1 f
  f     30b0      110 0

[...]

1a0   a4b080     8576 a
1a1   a53750      110 0
1a2   a539b0     8cd7 9
1a3   a5c7e0      110 0
1a4   a5ca40    31464 c
1a5   a8e000      110 0
1a6   a8e260      e1c 4
1a7   a8f1d0      110 0
1a8   a8f430     2025 b
1a9   a915b0      110 0
1aa   a91810    18b07 9

[Guest]

[deleted]

[Guest]

[deleted]

[pixel]

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:

Code: Select all

-rw-r--r--    1 pixel    pixel         608 Jan  7 13:18 000-000000E0-00000260.raw
-rw-r--r--    1 pixel    pixel         608 Jan  7 13:18 001-00000340-00000260.raw
-rw-r--r--    1 pixel    pixel        1024 Jan  7 13:18 002-000005A0-00000400.raw
...

Then, huh, two headers have some bytes in common, except for that first one. Please look at 001 and 003. You will see a lot of common bytes between the twos. Even more: you will see blocks of 128 bytes which are completely similar. Look between offsets 0x190 and 0x210. This may tell the file is composed of separated blocks, crypted individually. And ALSO that we have a 16 bytes headers in the file which causes the shift (what I call shift is that 0x190 and 0x210 "should" be at 0x180 and 0x200 to make full sense)

So, here is one of my assumption: what you are calling "headers" is a hierarchical directory tree. The first one beeing a "directory entry", the root, and the other ones, file entries.


Something else. Did you pay attention to the end of the files ? I did. For the PSAR's header:

Code: Select all

000000c0  10 01 00 00 80 00 00 00  00 00 00 00 00 00 00 00  |................|

File 000:

Code: Select all

00000240  10 01 00 00 80 00 00 00  00 00 00 00 00 00 00 00  |................|

File 001:

Code: Select all

00000240  a7 02 00 00 80 00 00 00  00 00 00 00 00 00 00 00  |................|

File 002:

Code: Select all

000003e0  10 01 00 00 80 00 00 00  00 00 00 00 00 00 00 00  |................|

File 003:

Code: Select all

00000240  d8 03 00 00 80 00 00 00  00 00 00 00 00 00 00 00  |................|

File 004:

Code: Select all

00000510  10 01 00 00 80 00 00 00  00 00 00 00 00 00 00 00  |................|

Etc... Someone should write a quite software that would check the final bytes but with a quick look, I can already tell there's a huge lot of 10 01 00 00 80 00 00 00 which can't be a coincidence. End marker ? The way the bytes are organized makes me think of a bitstream then, but that would be strange to ALWAYS have the bitstream ending with that specific sequence.

[ooPo]

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]

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*

I think you are onto something. Note that many savegames include small video clips to play when the savegame is highlighted in the browser. So I will check some of my savegame files that I have managed to copy OFF the PSP before I cried.

[uspual]

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*

icon1.pmf file is the small movie clip played right after icon0.png is highlighted. (same as savefiles)

[ooPo]

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

Oh well. :)

[uspual]

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

Oh well. :)

As you could guess, different savefiles show different movie clips without UMD inserted. It was a pleasant surprise. ;)

[ooPo]

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

[ooPo]

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]

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.

I filled whole PSAR block with NULL (except for the first 5 bytes : PSAR[0x01] ) and tested.
The movie clip was played as the same as before.
Booting and update procedure (including update/licence text) was the same as before.
I did not progress to the real update though. :)

So, in this case, it is clear that PSAR part is not effective before we really write the flash memory.

[pixel]

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.

[uspual]

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.

more tests

1. I filled every bytes (including first five bytes) of PSAR block with NULL.

- The movie clip was played as the same as before.
- Booting was ok
- "This disc cannot be loaded." message appeared right after I see the message "PSP system software version 1.00"
- reboot to the system menu

my guess : PSAR part is treated as a disc file system when we boot from the PBP file.

2. I filled every bytes of RIFF block with NULL.

- sound did not played.
- every other things (movie, booting, update procedure...) were ok

[ooPo]

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

Good work shooting down my ideas, though. :)

[Guest]

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]

1. I filled every bytes (including first five bytes) of PSAR block with NULL.

- The movie clip was played as the same as before.
- Booting was ok
- "This disc cannot be loaded." message appeared right after I see the message "PSP system software version 1.00"
- reboot to the system menu

my guess : PSAR part is treated as a disc file system when we boot from the PBP file.

Uspual, this is fantastic work you are doing. Very much look forward to seeing more! :)

As soon as I get another PSP, I will be playing around more. In the mean time, I will continue to analyze data. ;)

[ooPo]

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:

Code: Select all

PSAR
0x01000000 (version number?)
11183200 (which is the total filesize - 16)
0x01000000 (version number?)

...are you sure about the main header size being 224 bytes?

There's also 214 occurances of 0x1001000080000000.

[ooPo]

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:

Code: Select all

10864632 3C20 8529 E801 E20E < .&#41;....
10864640 3E23 3B5E 0883 A2B6 >#;^....
10864648 E304 477B 2078 F03C ..G&#123; x.<
10864656 C956 F504 C28D E0FF .V......
10864664 AE65 2896 670B A4A5 .e&#40;.g...
10864672 2EE0 0336 64A6 ED48 ...6d..H
10864680 AB35 C4CB ADB4 0777 .5.....w
10864688 0BFD 7CCD 8A5C CD39 ..|..\.9
10864696 C1F5 CF28 0174 CE30 ...&#40;.t.0
10864704 55D2 66B9 7954 0124 U.f.yT.$
10864712 89C5 EF37 79F7 AF84 ...7y...
10864720 F42B 527F 8720 B849 .+R.. .I
10864728 1688 7217 FC41 4751 ..r..AGQ
10864736 XXXX XXXX XXXX XXXX ........
10864744 XXXX XXXX XXXX XXXX ........
10864752 XXXX XXXX XXXX XXXX ........
10864760 XXXX XXXX XXXX XXXX ........
10864768 XXXX XXXX XXXX XXXX ........
10864776 XXXX XXXX XXXX XXXX ........
11081312 1001 0000 8000 0000 ........  <--- note the 1001000080000000
11081320 0000 0000 0000 0000 ........
11081328 0000 0000 0000 0000 ........
11081336 0000 0000 0000 0000 ........
11081344 0000 0006 XXXX XXXX ........
11081352 XXXX XXXX XXXX XXXX ........
11081360 XXXX XXXX XXXX XXXX ........
11081368 67A7 C36A B474 F686 g..j.t..
11081376 16BA D2AF 2CA3 3CCA ....,.<.
11081384 C749 EF0B 105D 655E .I...&#93;e^
11081392 3ED7 A95F 9046 95F8 >.._.F..
11081400 EE58 62A2 CD59 29E3 .Xb..Y&#41;.
11081408 33E5 1FFF 4FAD 620B 3...O.b.
11081416 3854 01B3 D3EE 5DA3 8T....&#93;.
11081424 EAA4 F8D1 EA78 2870 .....x&#40;p
11081432 55AE 8A69 8059 BA8F U..i.Y..
11081440 0B1C 3B6A 0352 679E ..;j.Rg.
11081448 0C75 8AE3 EDF8 1859 .u.....Y

Only the XXXX numbers changed, the rest were the same each and every time. There's also a large block of numbers before the 1001000080000000 that don't change as well... but they scroll off the top of the screen and are hard to read with my quick-scroll method here. :)

So... interesting? Yes.

[ooPo]

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

It starts as 67A7, for one block:

Code: Select all

00000192 1001 0000 8000 0000 ........
00000200 0000 0000 0000 0000 ........
00000208 0000 0000 0000 0000 ........
00000216 0000 0000 0000 0000 ........
00000224 0000 0006 XXXX XXXX ........
00000232 XXXX XXXX XXXX XXXX ........
00000240 XXXX XXXX XXXX XXXX ........
00000248 67A7 C36A B474 F686 g..j.t..

Then changes to 263A for a while:

Code: Select all

00000800 1001 0000 8000 0000 ........
(etc)
00000856 263A 5595 EB91 E4B3 &:U.....

Then to something I call F0E8:

Code: Select all

04646416 1001 0000 8000 0000 ........
(etc)
04646472 F0E8 3152 4766 63D7 ..1RGfc.

Then back to 67A7 for a little while:

Code: Select all

10127776 1001 0000 8000 0000 ........
(etc)
10127832 67A7 C36A B474 F686 g..j.t..

Here's how often each variant shows up:
67A7: 20 times
263A: 92 times
F0E8: 102 times

Anyway, its time for bed for me...

[Guest]

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]

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]

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]

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]

Little more my findings and guess for your interest.

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

Code: Select all

(Tbl.nem.1)
ofs in header  size  
+0x000..+0x07f  128  COMMON1   same between some headers, random number
+0x080..+0x0af   48  RND1      completely different, random number
+0x0b0..+0x0b3    4  DATASIZE  dword, must be "archive member data size"
+0x0b4..+0x0cf   28  FIX1      0x80 and zeros
+0x0d0..+0x0d3    4  FIX2      0x00 0x00 0x00 0x06
+0x0d4..+0x0e7   20  RND2      completely different, random number
+0x0e8..+0x0ef    8  COMMON2   same between some headers, random number
+0x0f0..+0x12f   64  COMMON3   same between some headers, random number
+0x130..+0x13f   16  COMMON4   same between some headers w/datasize 0x110, random number
+0x140..+0x14f   16  RND3      completely different, random number

Then, which archive member shares same binary? There's some interesting result. Note that member number is 0..426 in this discussion.

Code: Select all

(Tbl.nem.2)
members w/DATASIZE==0x00000110, i.e. member 0, 1, 3, 5, ... 421, 423, 425  
  GROUP_A   1, 3, ... 181, 183          COMMON1, COMMON2, COMMON3, COMMON4
  GROUP_B   185, 186, ... 385, 387      COMMON1, COMMON2, COMMON3, COMMON4
  GROUP_C   389, 391, ... 423, 425, 0   COMMON1, COMMON2, COMMON3, COMMON4
Note that DATASIZE is all same in these members by definition.

members w/DATASIZE!=0x00000110, i.e. member 2, 4, 6, ... 422, 424, 426
  2..12         COMMON1, COMMON2, COMMON3
  14..42        COMMON1, COMMON2, COMMON3
  44..52        COMMON1, COMMON2, COMMON3
  54..78        COMMON1, COMMON2, COMMON3
  80..166       COMMON1, COMMON2, COMMON3
  168..230      COMMON1, COMMON2, COMMON3
  232..316      COMMON1, COMMON2, COMMON3
  318..338      COMMON1, COMMON2, COMMON3
  340..384      COMMON1, COMMON2, COMMON3
  386..406      COMMON1, COMMON2, COMMON3
  408..426      COMMON1, COMMON2, COMMON3

Note that FIX1, FIX2 is same in all members.
RND1, RND2, RND3 is completely different between each member, excluding member 290/300.

There is some exceptional match in header as follows.

Code: Select all

(Tbl.nem.3)
DATASIZE match on members w/DATASIZE!=0x00000110
  memb#  30   00006200..00006760 +00B0 VAR         000062B0: 0A 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 
  memb#  36   00007940..00007EA0 +00B0 VAR         000079F0: 0A 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 
  memb#  38   00008100..00008660 +00B0 VAR         000081B0: 0A 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 

DATASIZE match on members w/DATASIZE!=0x00000110
  memb# 106   00373B30..00375400 +00B0 VAR         00373BE0: 71 17 00 00 80 00 00 00 00 00 00 00 00 00 00 00 
  memb# 248   004F0D80..004F2650 +00B0 VAR         004F0E30: 71 17 00 00 80 00 00 00 00 00 00 00 00 00 00 00 

COMMON4 match on members w/DATASIZE!=0x00000110
  memb#  30   00006200..00006760 +0130 VAR         00006330: C3 48 62 39 ED 0C 6A 0F E9 D2 04 E1 EC 44 39 63 
  memb#  36   00007940..00007EA0 +0130 VAR         00007A70: C3 48 62 39 ED 0C 6A 0F E9 D2 04 E1 EC 44 39 63 
  memb#  38   00008100..00008660 +0130 VAR         00008230: C3 48 62 39 ED 0C 6A 0F E9 D2 04 E1 EC 44 39 63 

All header match
  memb# 290
  memb# 300

member 30,36,38, which is in GROUP_A, have same datasize and they have same COMMON4, but member 106 and 248, which is in GROUP_A and GROUP_B respectively, have same datasize and they have different COMMON4.
member 290 and 300 is ALL SAME, not only member header but also member data.
I'll discuss regarding these later.


Next, archive member data match. There's less match.

Code: Select all

(Tbl.nem.4)
Member data match on members w/DATASIZE!=0x00000110 i.e. member 2, 4, 6, ... 422, 424, 426
  memb# 290 and 300    all data is same

Member data match on members w/DATASIZE==0x00000110 i.e. member 0, 1, 3, 5, ... 421, 423, 425  
GROUP_A
  memb#   1.. 39  +0x00..0x0f  36 11 F1 1E 9F 7D 97 80 D3 52 1B 37 DA 27 DA 96 
          1..  5  +0x10..0x1f  68 4F 6C 28 2D 0D 1C 3B A7 10 C0 7B 3D B3 D5 59 
          7.. 11  +0x10..0x1f  CA 50 5D 72 E9 5B AE F6 A8 BC 16 17 72 7D 46 DE 
         13.. 17  +0x10..0x1f  C9 5C 05 23 D0 AC 6C 2D B5 83 26 10 36 2F 61 DF 
         19,  21  +0x10..0x1f  49 51 38 95 83 A5 5C 9A E3 A5 97 AE 47 A4 22 5A 
  memb#  41.. 51  +0x00..0x0f  2A 27 AB 47 08 E4 3C CC E2 55 37 08 2F 68 E4 C6 
  memb#  53.. 85  +0x00..0x0f  73 18 F8 F2 28 4E 36 05 57 1B BF 9B F2 92 65 FA 
  memb#  87.. 91  +0x00..0x0f  5B 35 DA 21 23 8E F1 45 96 96 5F 39 58 6C 3D FF 
  memb#  95..101  +0x00..0x0f  0B 96 4A D4 C8 B1 18 CD 3B 07 5A 77 E8 DD 54 41 
  memb# 103..107  +0x00..0x0f  D6 97 D3 B1 46 84 FE 7C F8 84 81 24 07 7E A5 6C 
  memb# 109..113  +0x00..0x0f  1A 3B 3F BA 9F 76 83 58 04 4D 5A 60 56 91 0A E8 
  memb# 117, 119  +0x00..0x0f  FC BE AE 18 97 55 47 D2 CD B1 3A 3C 03 BC F6 3D 
  memb# 123..137  +0x00..0x0f  F3 3F 26 BF 08 FB 18 8D E6 48 A8 65 B7 E6 95 75 
  memb# 139..159  +0x00..0x0f  26 EC B1 AA 15 38 DD 04 4C F7 7E D7 07 D0 B0 C3 
  memb# 161..183  +0x00..0x0f  98 25 88 31 87 D8 45 DD 8D C7 80 E6 46 0C B9 EE 

GROUP_B
  memb# 185..191  +0x00..0x0f  82 DC D7 F8 AE DC DD 94 15 E2 77 7F 85 5E A0 B3 
  memb# 195..227  +0x00..0x0f  E1 F3 27 20 FD A4 18 7F BD BF 51 A5 AB 9D A1 81 
  memb# 229..237  +0x00..0x0f  FE 9D AF 9E E5 4E A4 19 AC 23 C4 18 26 C4 A4 BF 
  memb# 239..255  +0x00..0x0f  6F EE 9C A3 46 CF 3C 83 AF CD C3 9D 93 BE 83 7D 
  memb# 259..279  +0x00..0x0f  A4 02 E4 E3 4D 5C FF A4 4D BB 47 04 8B 0E 8C F2 
  memb# 281..285  +0x00..0x0f  5E 7A 3F EA 8B 8A F8 DA 1C C5 B3 6F 61 19 82 95 
  memb# 289..387  +0x00..0x0f  9F E4 11 BE E7 D3 2D 17 4B 9C DB 79 BD 77 13 23 
        343..347  +0x10..0x1f  A0 93 8C 41 04 5A 40 32 78 05 37 5D FD 1C 4E 79 

GROUP_C
  memb# 389..423  +0x00..0x0f  7B 35 23 BF 49 8D DA 9F 7C 51 2F C0 DB 54 E0 CA 
        407, 409  +0x10..0x1f  EC 5D F4 77 71 C8 89 EF 74 E5 24 7D 2F F5 2A CF 
        413..417  +0x10..0x1f  67 D2 E8 58 58 5B 26 FF 4F 17 28 A9 4F C7 BB 73 

Interesting?
(revised)

[nem]

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]

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]

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

[ooPo]

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