has anybody looked further into NJB3 files on its drive? I already noticed its formatted in MiniFS,
just like the Zen Xtra that supajerk and wuggles were reversing 2yrs
ago, but I don't have too much time to fiddle with it more now:|

if not, I'll try to write a linux module that handles the filesystem,
basing on the fs' reverse posted here.. well.. read-only at first, as I
dont have necessary disk space to backup whole my NJB3 disk, but later
I think I'll make support for writing, too

I
cann't find anywhere any serious info on the filesystem! I would swear
that there was something here, more than few hexdumps, and I was sure
that supajerk and wuggles (at least I think they did) put the collected
info on the fs' file allocation table somewhere.. darn, where is it??

until I find it (or reverse myself) I'll try to unlock some
originally locked files.. you remember, NJB3 just from the factory had
some files like "Welcome.mp3" or few gigs of ClassicalMusic that were
'locked', that is, no one were able to download them from player
(software and/or firmware did not allow you to do so). That were so
many files, that surely information about them was'n stored in
firmware:) It is just a matter of finding the right flag in the DB's
descriptor. If i manage to find it, we will of course also be able to
lock files, too

Well.. with BMKL=>BOOB change, nothing other could have
happened, as supajerk temporarily damaged the masterblock's magic bytes
- "MBLK", the 'MasterBLocK" remember about the byteswap as NJB3 is least-byte-first! I included some info about it in see-also's, too

Logically,
it seems that the user-space part of the disk is 'seen' as sequence of
clusters of 16 sectors (8kB). I don't know how it is with system-space.

The datafile-to-clusters relation is typical - in one cluster may
reside only one file, and a file may cover any number of clusters.
Therefore, anything that is put into user-space, may start ONLY at the
beggining of the cluster, that is, it's absolute offset will be a
multiplicity of 0x2000. That simplifies a bit the searching..

Moreover, I already noticed that there are lots of 2-cluster series
of 0xFFFFFFFF, and some of them are partially filled with sequence of
numbers. Those are chains that describe the layout of the file. I dont
know how the numbers are mapped to cluster-id, but it is not hard, just
takes time as for now I only found *deleted* directory entries and the
data they point to has been already trashed.

All the directory entries I have stumbled upon, have a 'magic byte' on the very start of the cluster.
0x01000100 - root directory (all the old rootdirs I have found)
0x3BBE0AD9 - two subfolders I have created in the rootdir

"3BBE" look like another funny magicstring, note the 'mirror' 3B-BE, but it may be just accidential form

I launched a search for clusters that begin with those signatures, and as I'm writing this, the search has just finished:

clusters starting with 0x01000100 - 9 found
clusters starting with 0x3BBE0AD9 - 114 found
on the disk that has 488376 clusters

there's more - their id's are grouped around few values, so it is almost sure they are related somehow.

Now..
File(1), full of zeroes, contains only 1 entry (where,blah,filename) pointing at sg00.log - file(2).
File(2), is a list of all the songs uploaded onto device _as_songs_
File(3), that with the strange name - is DATA's root directory info
File(4),(7),(,(9),(10)
are the files I uploaded. Please note that DATA files has as directory
their destination, while MUSIC files have stored their source
directory!!
File(5),(6) are DATA's subdirectories info. ..However they are
totally empty. ALL THE DATA files are stored in DATA's root directory!

I have to go now, I discovered far more, but have no time to write about it now..
The biggest problem is that I dont know how system-space is connected to file(1) and file(4)..

After
another day of hexediting throughout the disk, I have found out that,
in the user-space, there are two types of directories.. I'll call them
'sys-dir' and 'user-dir' from now on. Both types of directories are
stored in the same way as regular files. Music is stored as regular
files, too. The only distinction is what 'category' of the file is
written into file record.

I have also found user-space's root sys-dir, and discovered inside it more sys-subdirectories:

Code:

archieves
playlists
recordings
songs
system

'archieves' - sys-dir with entries of all files ever stored (as
datafiles) on the device. surely somewhere must be a flag whever the
file is deleted or not, but I didnt look at it yet.

'playlists' - sys-dir to a file, that all the names of the
playlists reside, surely - links to the playlists it self must be
there, too

'recordings' - sys-dir with two files (deleted), I think they were temporary files for recording audio from mic.

'songs' - sys-dir with all the files uploaded as songs. It is very
like the sg00.log file from the user-dirs, but in the latter (which is
a file, not directory) there's also metada included

'system' - in this sys-dir there's only one file.. the sg00.log

Moreover, I have found out in the of the user-space:
* something that is very likely to be a cluster-usage bit map. IF it is really a bit map (bit-map, not image
), it can cover the information of usage of 0x02600000 sectors, while
there are .. 0x02542980 physical sectors, and a bit less in CFS. Having
in mind that the bitmap is cluster-aligned as everything in the CFS -
it is really really likely that this is just what I think.
* a link to the root of the user-directories (those with the
uploaded datafiles' structure), almost just before the bit map. There
is another linkage to this root-dir *inside* the CFG1 section of the
*system-space*
* that there is no reference to the root of sys-directories..
however.. the descriptor of this directory is exactly just after the
bit map! therefore, knowing the size of the CFS in sectors (from the
masterblock record), it's really trivial to localte this descriptor.
* a very long and very tempting index of something unknown. the
file has very regular structure and had.. 3711kB!! 3.7meg of index!
what a big bastard must it have been, before being unlinked when I
cleaned up the jukebox before starting the research.. For now, I
haven't found its new version, and this fact really confuses me.. it
really looks like some firmware or PC-software clusters database..

*the system-space contains:
-lots of something that looks like fonts (5 'packages')
-few char tables
-lots of strings in all languages (2 'packages')
-one up-to-date CFG1 section (with profiles and link to root user-dir), and 2 old ones
-some chains, similar to those describing files in the user-space
-strange record "[0xFE 0xFF]P2P=1 VMX=1"
-two CENC sections - no idea what that now

I'm not sure whever I can manage to find more interesting things in
the system-space.. it is all very mixedup.. I hope that those few
chains are related to the filelist from the sector 0x0C11 (attribs.db,
..) Darn!!! the CFG1 section must be the pm.cfg and those two old a
pm.cbk (Configuration BacKup)!! Heh, now I know what I'll look at this
night

Anyways, I'm so sure about what I already know about the
user-directories' structure, that surely I'm able to write a 'simple'
driver that will list the contents.. *but* there are still few things I
just wantto know to be completely sure, and maaannyyyy things I have to
know to be able to safely write my own things to the disk and have it
be still readable to the firmware and PC software..

definitely, I have found user-space's cluster usage bitmap, and what I already knew about the user-dir was true, too
I have put a file, and checked what had changed on the disk, and all
the places I suspected to get changed really were different and
matching new structure.

About the system-space, strangely enough, the pm.cfg and pm.cbk
files were *exchanged* as I sent one datafile to the player. They
didn't change their locations, only they were swapped. Literally..
renamed. The pm.cfg became cm.cbk, pm.cbk became pm.cfg and got
updated.

Another strange thing is, that the pm.cbk wasn't pointing to any of
the 2 old CFG1 sections I have found on the disk, but was actually
pointing to some complete rubbish left by old songslist. Maybe a bug or
some old write failrue? I don't know. Now, pm.cbk points at the CFG1
section from before addind the file, and pm.cfg point at current CFG1
section.

I cant recall whever I wrote it already.. in the end of the CFG1
section, there is an uint32 pointing at current root user-dir, and all
the files uploaded are stored in the root user-dir, even if they are
logically put into folder, and even if the folder logically exists in
the jukebox's user-space. I mean, literally:
*the folder "mydata" is created:
--> on the disk, in the root dir, a "\mydata\" file is created,
with directory field (in file's metadata) set to "\" (directories on
the disk are stored as files, but interpreted differently)
*the file "myfile" is uploaded to the "mydata" folder
--> on the disk, in the root dir, a file "myfile" is created, with the metadata directory field set to "\myfolder\"

so... it seems that the device stored everything as-is-given in the
root dir, with complete no directory-tree-support other than filtering
the shown contents.. when PC request contents of "\myfile", the device
reads *all* uploaded files' metadata, then selects those which has the
(metadata) directory field set to the given, and then returns the
contents.. (for the root, the "\" is the dir filter) files for
user-created folders are created to inform the browser they are that
very filters possible to choose on the device, and show later to user
as folders, so he can apply that filters thinking he opens a
directory..

summarizing - rotfl I wouldn't ever suspected, that the filesystem that fully handles
directory-tree operations and file metadata will be used to store in
sucha.. not-smart way :} the file created for folder '\myfile\' from
the example uses the same amount of disk space and is as hard to handle
as a regular directory entry in other sections of the device..
well.. if there is *small* total number of datafiles uploaded onto
the jukebox, this "solution" allows faster acces to them.. but if the
number gets growing.. eh! without serious accelerations from the PCside
or jukeboxOS side, the speed would be *cough* not good

I
can confirm it works that way. When you access data files across the
USB protocol you get a list of all files and have to filer out the dir
and contents you want to show by strplit on "\". The same goes for
downloading a file, you just set its name to "\foo\bar.txt" to place
"bar.txt" in the "foo" subdirectory.

Great work, will you make a formal writeup? I can put it into HACKING from libnjb if you want it there.

wows..
I thought that the player at least filters the entries, not just sends
the whole list! On the player the files are logically grouped by info
in metadata.. Now, knowing what you said, it seems that that player
completely ignored that meta-information attached to file..

about putting that altogether - sure, as I said, I want to write a
module for linux kernel to be able to handle both of the filesystems of
the Jukepox (minifs and cfs), I will surely write full article about everything I found:)

I have found more, and I can tell you already that whats written in the
HACKING about metadata is quite close. What was marked as timestamp, is
actually a little-endian standard C-timestamp but with bytes order
messed up. If the field states 0xF743B3FC, that the actual value is
0xB3FCF743 = "02-19-2006 05:05:55" (yes, I am a night creature
)... A metadata postID is actually a physical disk's cluster ID where
the descriptor of the file is stored, and with it comes the metadata
and first few entries of the files' clusterchain
(rest of the chains is stored extrenally, in full 2 clusters per file -
I still dont know what-if the file is even bigger to fit in it) I've
got far more revelations about the FS but I cant find much time now,
and if I have some I spend it on the research..

As for documenting the FS, I believe that some graphics will be more
than required, I'll try to provide some. I am not an artist though All I need is lots of time to spare

I think I know about 90% of the structure of the CFS needed to write readonly FS driver, as for the MINIFS part - 30%.

For write-supporting driver.. wellllll... heeh... heheh.. I'm not in a
mood ($$ neither) for buying new HDD especially for fulldisk backup and
I have no idea how I will manage to find 20gig on my disks.. I'll think
about something later..

I'd be getting back to work better, it's getting late again eh..

[edit]
Holy.. what a mistake.. the byte order I provided is for FILE
DESCRIPTOR not the DIRECTORY ENTRY!! In the HACKING, the 'filedatabase'
is actually a fragment of the root directory. Here, the order is
different.
blahblahblah, thus the date provided in HACKING:

Code:

0x00006 | 0x0016 | 0x78ca7441

is literally what is written, and is little-endian C-date: "10-19-2004 08:04:08"

I wrote at first that I'll try unlocking a 'locked' file, so.. I tried :]

It seems that the 'locked' state is not mantained by FS flags and
fields (though, I think there is flag that indicates it here, too) - I
compared descriptors of a two 'locked' files and three 'normal' ones,
and tried changing the descriptor of the one of the locked, wherever it
was posible and sane (I mean, neither in the timestamp nor in the
cluster chains, nor few other places such a flag would be) no effect, the file was locked all the time.

I got mad, took the cluster chain, and downloaded the file manually
(Beethover-Romance in F, file that comes with brand new player, as do
2gigs of other classic music, and all of that files are 'locked' an
undownloadable by Creative's software).

Well.. the difference was that my 3 'unlocked' files had the Copyright tag not set.. and the 'locked' file had it set.

It seems that the player (or software) parses mp3 tags and checks
for that flag. The downloaded file doesnt have ID3 mp3 tags, it has
some other tag format. Nethertheless, I completely dont know how to
change that flag, so I could test more with it.. I mean, if I knew, I
would change the flag on-device, and check if the file became
'unlocked'..

Ony one of you guys and girls know about flags and tag's bits of
the mp3's? I'd be grateful for some well-documented materials or links
to..

The mp3 flags are stored throughout the file. Removing all of the
copyright flags does nothing. Changing or even damaging totally first
header gives nothing. Darn, the player would have parse whole file if
it were to check the flags! Even winamp only reads the first frame
header and omitts the rest. It would be soo loong to read all of the
headers from all of the files to check the flags in the runtime, that
this is *SURE* that either the player helds somewhere a database with
the is-the-file-locked flag, and ignores the mp3 purely-informative
flags in the runtime..

Why I haven't found it in the file's metadata..? Actually, I have
noticed 2 difference between the RomanceInF and few mp3's of mine, but
I removed the difference, and the file was still locked.. I doubt that
the flag would be watermarked somehow in the metadata.. It has to lie
somewhere, I just didn't notice it somehow