file_conventions.html
5.91 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>BB Flash File Conventions</title>
</head>
<body>
<h1>
<p align="center"> BB Flash File Conventions </p>
</h1>
This document specifies the internal format for BB Card files shared
by the player and depot/servers. As a general rule, whenever a data structure
is stored in binary format within a file, big-endian byte layout is used.
<p> The depot use model for these files is defined <a
href="http://intwww.routefree.com/rf/doc/bbdocs/Designs/1.0/Depot/BB-Card-Operations.html">
here</a>. </p>
<p> </p>
<h2>File Contents Specifications</h2>
<i>id.sys</i>
<blockquote> This file contains, in order:
<ol>
<li> BBID, 32 bit unsigned long </li>
<li> BB HWREV, 32 bit unsigned long (though at most 10 bits are
useful) </li>
<li> BB Cert, of the appropriate certificate type (BbEccCert or
BbRsaCert), in binary format. </li>
</ol>
There is no padding between elements.
<p> NOTE: if there is an error reading this file, the BBID may be
obtained using a special file-system function call (i.e., something
like getBbId()). </p>
</blockquote>
<i>crl.sys</i>
<blockquote> This file contains the binary data structures for Content,
License, and CA CRLs (<i>once the structure names are known they will
be added here</i>). There is no ordering requirement for the various
CRLs, but no additional padding may be inserted between them (the
total number of bytes may be determined using the file-system meta
data associated with the file). </blockquote>
<i>cert.sys</i>
<blockquote> This file contains the binary data structures for Content,
License, and CA Certs (each will be represented by an appropriate BbEccCert
or BbRsaCert). There is no ordering requirement for the various Certs,
but no additional padding may be inserted between them (the total number
of bytes may be determined using the file-system meta data associated
with the file). </blockquote>
<i>tickets.sys</i>
<blockquote> This file contains binary format BbTicket ticket structures,
one per ticket, with no inter-ticket padding. Since the tickets are
fixed size, the number of tickets may be computed from the total
number of bytes in the file. </blockquote>
<i>XXXXXXXX.app<br>
XXXXXXXX.rec<br>
</i>
<blockquote>Content file. The format of a content file is not specified here.
The name, XXXXXXXX, is the ascii representation of the 32-bit CID as
nibble-encoded hex, right justified and left-padded with zero (equivalent
to <i>sprintf(name, "%08x.app", cid)</i>). When files are initially
added to a cartridge, the "<i>app</i>" extension is used to indicate that
the content has not yet been reencrypted for the specific player. Once
the reencryption has been done, the file will be renamed with the same CID
and the "<i>rec</i> " extension. </blockquote>
<i>XX.pak</i>
<blockquote> This file contains the controller pak data (game state)
which is shared by all games. The format is the same as used by libultra.
There can be at most 12 of these files, each 32KB in size. Signatures
for <i>.pak</i> files are stored in the file <i>sig.db</i>.<br>
<br>
</blockquote>
<i>pak.bnd</i><br>
<blockquote>Controller pak binding file. Specifies which pak are currently
bound to which games. The viewer sets these bindings as the user requests.
The file consists of an array of 12 records, each one consisting of
the content ID of a game and a controller ID to identify the file.<br>
<p> </p>
</blockquote>
<i>XXXXXXXX.sta</i>
<blockquote> Per-game state file which is identified by the name, which
uses the same convention as XXXXXXXX.app (i.e., the XXXXXXXX terms match
for the game's .app and .sta files).
<p> The contents of this file under definition. The file will hold
all types of storage that were present on the cartridge of an n64 game.
A method will be proposed to delineate the various portions. As a
preleminary guess, this could be just a 16-bit length field for each
cartridge storage type, followed by the binary data of each type concatenated
with no padding.<br>
<br>
Signatures for game state files are stored in the file <i>sig.db</i>.<br>
</p>
</blockquote>
<i>sig.db</i><br>
<blockquote>Signature file: contains signatures for all the controller
pak and game state files. The format of the file is an array of records,
each one consisting of the file name in the format in which it appears in
the FAT table (16 bytes) and an ECC signature consisting of 16 u32s.<br>
</blockquote>
<i>XXXXXXXX.u0?</i><br>
<blockquote>Additional game state files created under game control directly
using the <i>osBbAuxDataSave</i> call. The name space limits the number
of these files per <i>cid</i> to 16, but a policy limit lower than that will
be applied by the <i>libultra</i> code that creates these files.<br>
</blockquote>
<i>depot.sys</i>
<blockquote> A file of maximum size 16KB used by the depot. Management
and contents are purely the depot responsibility. More information
on contents may be found <a
href="http://intwww.routefree.com/rf/doc/bbdepot/software/BB-Card-Operations.html">
here</a>. </blockquote>
<p> </p>
<h2>Other Open Issues, Comments</h2>
There is no file to represent the system area files, and these are just
a single opaque blob to the depot. File-system apis will be provided specifically
to handle writing this blob.
<p> If we have a depot.sys file, do we still need a timestamp in the ticket
file? </p>
<p> If we're <i>really</i> tight on space the depot.sys contents may be appended
to the id.sys file, but that's a design tradeoff we may consider later.
</p>
<br>
</body>
</html>