About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Home » Industry Watch » The Technological

'the english is not great ... interesting none the less'

Why hacking inodes is a contradiction in terms. Why if you really don't know nothing can be clear to you. What awaits over the ocean.


Buy It

Try It

1. Try to get a map somewhere. See if you can locate New York City on it. Call your local travel bureau and arrange for transport there. When you get there seek out what is known as an 'airport'. What you want to buy is a ticket on an airline that can make it across what's known as the Atlantic Ocean.

Ask specifically for destinations in a country known as ENG-Land. In that country the people speak a language known as ENG-Lish. They do funny things like say 'the audience are' instead of 'the audience is' and so forth. They also like to take the Mickey on you from time to time.

Their accents can be very nice.

2. You don't really want that application simply because it looks cool. It's an experiment only. It shows you files you don't ordinarily see. Considering most of you are running TFF there's a lot of files you won't ordinarily see already. The application is a full fledged file manager but still and all - this is a file manager of a different colour.

And it's got nothing to do with inodes. Crash course in Unix file systems is recommended.

What's at stake is that there are two user land APIs for accessing directories. And the one calls the other. The higher level more practical one is called readdir(). It's got a manpage so look it up.

DIRECTORY(3)             BSD Library Functions Manual             DIRECTORY(3)

NAME
     opendir, readdir, readdir_r, telldir, seekdir, rewinddir, closedir, dirfd
     -- directory operations

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <sys/types.h>
     #include <dirent.h>

     DIR *
     opendir(const char *filename);

     struct dirent *
     readdir(DIR *dirp);

     int
     readdir_r(DIR *dirp, struct dirent *entry, struct dirent **result);

     long
     telldir(DIR *dirp);

     void
     seekdir(DIR *dirp, long loc);

     void
     rewinddir(DIR *dirp);

     int
     closedir(DIR *dirp);

     int
     dirfd(DIR *dirp);

DESCRIPTION
     The opendir() function opens the directory named by filename, associates
     a directory stream with it and returns a pointer to be used to identify
     the directory stream in subsequent operations.  The pointer NULL is
     returned if filename cannot be accessed, or if it cannot malloc(3) enough
     memory to hold the whole thing.

     The readdir() function returns a pointer to the next directory entry.  It
     returns NULL upon reaching the end of the directory or detecting an
     invalid seekdir() operation.

     readdir_r() provides the same functionality as readdir(), but the caller
     must provide a directory entry buffer to store the results in.  If the
     read succeeds, result is pointed at the entry; upon reaching the end of
     the directory result is set to NULL.  readdir_r() returns 0 on success or
     an error number to indicate failure.

     The telldir() function returns the current location associated with the
     named directory stream.  Values returned by telldir() are good only for
     the lifetime of the DIR pointer, dirp, from which they are derived.  If
     the directory is closed and then reopened, prior values returned by
     telldir() will no longer be valid.

     The seekdir() function sets the position of the next readdir() operation
     on the directory stream.  The new position reverts to the one associated
     with the directory stream when the telldir() operation was performed.

     The rewinddir() function resets the position of the named directory
     stream to the beginning of the directory.

     The closedir() function closes the named directory stream and frees the
     structure associated with the dirp pointer, returning 0 on success.  On
     failure, -1 is returned and the global variable errno is set to indicate
     the error.

     The dirfd() function returns the integer file descriptor associated with
     the named directory stream, see open(2).

     Sample code which searches a directory for entry ``name'' is:

           len = strlen(name);
           dirp = opendir(".");
           while ((dp = readdir(dirp)) != NULL)
                   if (dp->d_namlen == len && !strcmp(dp->d_name, name)) {
                           (void)closedir(dirp);
                           return FOUND;
                   }
           (void)closedir(dirp);
           return NOT_FOUND;

SEE ALSO
     close(2), lseek(2), open(2), read(2), dir(5)

HISTORY
     The opendir(), readdir(), telldir(), seekdir(), rewinddir(), closedir(),
     and dirfd() functions appeared in 4.2BSD.

BSD                              June 4, 1993                              BSD

What's not mentioned there is that readdir() actually gets its data from a lower level API called getdirentries(). Look that up too.

GETDIRENTRIES(2)            BSD System Calls Manual           GETDIRENTRIES(2)

NAME
     getdirentries -- get directory entries in a filesystem independent format

SYNOPSIS
     #include <sys/types.h>
     #include <sys/dirent.h>

     int
     getdirentries(int fd, char *buf, int nbytes, long *basep);

DESCRIPTION
     Getdirentries() reads directory entries from the directory referenced by
     the file descriptor fd into the buffer pointed to by buf, in a filesystem
     independent format.  Up to nbytes of data will be transferred.  Nbytes
     must be greater than or equal to the block size associated with the file,
     see stat(2).  Some filesystems may not support getdirentries() with
     buffers smaller than this size.

     The data in the buffer is a series of dirent structures each containing
     the following entries:

           u_int32_t       d_fileno;             /* file number of entry */
           u_int16_t       d_reclen;             /* length of this record */
           u_int8_t        d_type;               /* file type, see below */
           u_int8_t        d_namlen;             /* length of string in d_name */
           char            d_name[MAXNAMELEN + 1]; /* see below */

     The d_fileno entry is a number which is unique for each distinct file in
     the filesystem.  Files that are linked by hard links (see link(2)) have
     the same d_fileno.  Users of getdirentries() should skip entries with
     d_fileno = 0, as such entries represent files which have been deleted but
     not yet removed from the directory entry.  The d_reclen entry is the
     length, in bytes, of the directory record.  The d_name entry contains a
     null terminated file name.  The d_namlen entry specifies the length of
     the file name excluding the null byte.  Thus the actual size of d_name
     may vary from 1 to MAXNAMELEN + 1.  d_type is a integer representing the
     type of the directory entry.  The following types are defined in
     <sys/dirent.h>:

           #define DT_UNKNOWN       0
           #define DT_FIFO          1
           #define DT_CHR           2
           #define DT_DIR           4
           #define DT_BLK           6
           #define DT_REG           8
           #define DT_LNK          10
           #define DT_SOCK         12
           #define DT_WHT          14

     Entries may be separated by extra space.  The d_reclen entry may be used
     as an offset from the start of a dirent structure to the next structure,
     if any.

     The actual number of bytes transferred is returned.  The current position
     pointer associated with fd is set to point to the next block of entries.
     The pointer may not advance by the number of bytes returned by
     getdirentries().  A value of zero is returned when the end of the direc-
     tory has been reached.

     Getdirentries() writes the position of the block read into the location
     pointed to by basep.  Alternatively, the current position pointer may be
     set and retrieved by lseek(2).  The current position pointer should only
     be set to a value returned by lseek(2), a value returned in the location
     pointed to by basep, or zero.

RETURN VALUES
     If successful, the number of bytes actually transferred is returned.
     Otherwise, -1 is returned and the global variable errno is set to indi-
     cate the error.

ERRORS
     Getdirentries() will fail if:

     [EBADF]            fd is not a valid file descriptor open for reading.

     [EFAULT]           Either buf or basep point outside the allocated
                        address space.

     [EIO]              An I/O error occurred while reading from or writing to
                        the file system.

SEE ALSO
     open(2), lseek(2)

HISTORY
     The getdirentries() function first appeared in 4.4BSD.

BSD                              June 9, 1993                              BSD

Now one might say the chief task of getdirentries is to separate the wheat from the chaff - to surrender only the data readdir() can be presumed to be interested in. But on Apple systems this becomes more complex because Apple's favourite file system HFS is not compatible with Unix file systems or even Unix philosophy. So certain concessions must be made.

Which is what happens here. getdirentries() as implemented (rewritten from the original FreeBSD source) by Apple will also conceal a lot of the hacks they've used to sort of force their square peg file system into round hole Unix.

There are TNs available online that explain in detail how this works. And even TFF is involved, given 'FileInfo' data that theoretically places the 'icons' for these items somewhere in East Jesus.

3. GDE (which of course is an acronym for 'get dir entries' has not been available in the Xfile Test Drive but because you asked for it - and because you're such clever chaps - it now is. [But not yet in the Xfile product. We're working on that. Ed.]

There's also the special Red Pill edition of Xfile but yet again: this isn't something you want to look at all the time. But admittedly it's cool.

PS. The price of the Xfile package is dropping sometime this weekend.

True sophistication is absolute simplicity.
 - 'rtmac'
It's clear to me exactly what's trying to be communicated at the linked page. I think it's something about some sort of tool for examining inodes directly, rather than looking at the higher level view of the filesystem as files...but I don't really know and am reluctant to download and run something from a page advertised by people who are a bit too smug in their broken English while talking about hidden files and rootkits.
 - 'Anonymous' 'North of the State of Jefferson'

See Also
GDE: Got Rootkit?
x704.net: the english is not great ... interesting none the less

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.