Dit is een versie van http://nomadness.net/modules.php?name=Forums&file=viewtopic&t=19142&view=previous zoals opgeslagen in het cachegeheugen van G o o g l e op 11 feb 2008 06:54:44 GMT.
G o o g l e's cache is de momentopname die we van deze pagina hebben gemaakt toen we het web doorzochten.
De pagina kan ondertussen gewijzigd zijn. Klik hier voor de huidige pagina zonder selectie
Deze in cache opgeslagen pagina bevat mogelijk koppelingen naar afbeeldingen die niet meer beschikbaar zijn. Klik hier voor de in cache opgeslagen tekst.
Gebruik de volgende URL om deze pagina aan je Favorieten toe te voegen of ernaar te linken: http://www.google.com/search?q=cache:B7XFIJ28ESgJ:nomadness.net/modules.php%3Fname%3DForums%26file%3Dviewtopic%26t%3D19142%26view%3Dprevious+site:nomadness.net+minifs&hl=nl&ct=clnk&cd=2&gl=be&client=firefox-a

Google heeft geen banden met de auteurs van deze pagina en is niet verantwoordelijk voor de inhoud ervan
 Deze zoektermen werden geselecteerd: minifs

 - Home - News Archive - Player Info - Forums - Nomad Newsgroup - FAQ - Reviews - Articles - Web Links - Downloads - IRC Chat - Members List - Your Account - Stats - Top 10 - Cartoon - Feedback - AvantGo - Submit News

 Search

 Our Supporters

 User Info
 Welcome, Anonymous Nickname Password (Register) Membership: Latest: jackinthebox New Today: 0 New Yesterday: 2 Overall: 15521 People Online: Visitors: Members: Total: 0

 Help to help us

 NJB3 filesystem Goto page 1, 2, 3  Next
Author Message
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Sun Feb 12, 2006 1:05 am    Post subject: NJB3 filesystem my 2.5"-to-usb adapter just arrived 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:|
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Sun Feb 12, 2006 12:00 pm    Post subject: Mounting Creative's MiniFS filesystem did anybody succeed in mounting the MiniFS under any OS? 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
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Mon Feb 13, 2006 7:47 pm    Post subject: uh oh 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
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

Posted: Mon Feb 13, 2006 8:28 pm    Post subject:

due to http://cvs.sourceforge.net/viewcvs.py/*checkout*/libnjb/libnjb/HACKING?rev=HEAD&content-type=text/plain the Zen Xtra has following files ("with some variations"), and newer players have lots more similar files
 Code: attrs.db   jukebox2.jrm   jukebox2.jrs   unicjkl.nft   kanji.dct   fhandle.db   btree.db   pm.cfg

well.. my NJB3 has:
 Code: attrs.db   jukebox2.jrm   jubebox2.jrs   unicjk.nft   uni8x12.nft   wruniji.nft   kanji.dct   fhandle.db   btree.db   pm.cfg   pm.cbk   (emptyentry)   (emptyentry)   jukebox.opt   unicjkl.nft
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Wed Feb 15, 2006 12:57 am    Post subject: A bit about sector 0 Maybe some of you remember how supajerk player with the BMKL letters on the very start of his disk (changed them to BOOB), and the firmware immediately went into RescueMode? I managed to find out few things about sector 0x00000000, please check http://80.55.243.202:2002/explore.php?base=FS for details. 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
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Wed Feb 15, 2006 1:17 pm    Post subject: Sectors and clusters 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. Again, it can't be too hard, but I need some time..
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Wed Feb 15, 2006 7:53 pm    Post subject: Bit more complicated The "Why the pair of bytes are swapped?" was outdated and *WRONG* I 'm preparing new version and will put it in minutes!
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

Posted: Thu Feb 16, 2006 11:37 am    Post subject: There are more files than it was known:)

I have extracted most of the user-space directory structure and found out what the field are! I'm know almost everything about the structure of the user-space part of the disk now:)

\
....\myfile_1st
....\myfolder1\myfile_2nd
....\myfolder2\myfile_3rd

Then, I have uploaded those into MUSIC:
D:\origfolder1\mymp3_1st.mp3
D:\origfolder2\mymp3_2nd.mp3

On the disk I have found those files:
 Code: number     'directory'      'file' 1                                <-- really, there _is_ such a file 2                         sg00.log 3                      \              02250301D909FF74170D9442D909FF74 <--thats filename 4                      \              myfile_1st 5                 \myfolder1\   <0x002E>    <--|2-byte file name. 6                 \myfolder2\   <0x002E>    <--|first byte:0x2E, second:0x00 7                 \origfolder1\  mymp3_1st 8                 \origfolder2\   mymp3_2nd 9                 \myfolder1\   myfile_2nd 10                \myfolder2\   myfile_3rd

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)..
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

Posted: Sat Feb 18, 2006 12:05 am    Post subject: More and more new things:)

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..
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Sun Feb 19, 2006 10:11 am    Post subject: 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
linus
Regular

Joined: Jan 21, 2002
Posts: 406
Location: Sweden

 Posted: Sun Feb 19, 2006 9:13 pm    Post subject: 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.
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

Posted: Mon Feb 20, 2006 12:17 am    Post subject:

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

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"
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Mon Feb 20, 2006 2:38 am    Post subject: locked music files on Jukebox 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.. wow.. 3.40AM again..*yawn* seeya
quetzalcoatl
Regular

Joined: Feb 28, 2004
Posts: 43

 Posted: Mon Feb 20, 2006 3:05 pm    Post subject: I have googled the http://jicyshout.sourceforge.net/oreilly-article/java-streaming-mp3-pt2/java-streaming-mp3-pt2.html out of the web.. according to that, the private,original and copyright flags are stored in each of the mp3's frames' header.. thousands of it. I took the RomanceInF and checked - about 8000 frame headers. I have changed them all (on the disk) removing all of the copyright flags, and heh, the file is still locked.. 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
linus
Regular

Joined: Jan 21, 2002
Posts: 406
Location: Sweden

 Posted: Mon Feb 20, 2006 8:35 pm    Post subject: I think the locking feature is kinda subtle. The metadata or the file itself does not contain it for sure, it's somewhere in the metadata, possibly hidden in some mirror structure.
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First
 All times are GMTGoto page 1, 2, 3  Next Page 1 of 3