Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve » Developers Workshop

_getdirentries_is_not_available...

Timmie playing peekaboo.

Get It

Try It

'_getdirentries_is_not_available_when_64_bit_inodes_are_in_effect' There it is. We've been trying - off and on for weeks now - to get past Apple's new last line of defence. They simply don't want to let people see what they're doing under the bonnet. Perhaps you remember how we hunted down the entrance to that 'HFS+' directory at root? They put funky characters in the name to thwart us, but we found a way - and uncovered their secret cache of orphaned 'multi-linked' files. Then they changed their hiding place and method, and again, and again, and again. Remember? Now we're running 64-bit code. The lowest level API was getdirentries() before the move, and getdirentries64() after the move, then WHOOSH the latter just disappeared! O RLY? No. Of course not. getdirentries() is the 'non-filter' API below the more commonly used readdir() and it's there for a reason, and that reason exists to this day, no matter what smokescreen Apple will toss your way. There are several reasons to not (normally) list everything in a directory (and no not like what Apple's 'file browser' thinks are reasons). It's these special cases that Apple exploited to hide the ugly stuff. For example: an inode of 0 normally means that a file is being deleted. Looking at it as an outsider, you can ask yourself why these soon-to-be-unlinked items never show up in Xfile, which otherwise goes as deep down as is possible. And the reason is *there's another level* - the level of getdirentries(). Directories used to be readable. No not in that way. But READABLE. From the command line. You could use od to read them. BWK had a tutorial about it (UNIX Programming Environment?) and we tested it, and yup - od could do that. You could literally see the directory structure - possibly zero-terminated strings of up to 16 bytes. (If the filename was 16 bytes then the zero byte was implied.) (And it was a great tutorial.) But you can't do that today. Oh no. Try.

$ hexdump /
hexdump: /: Is a directory

We have no idea if it's blocked in other flavours, but Apple definitely have it blocked. So in other words: Apple are still up to their old tricks. So we've tried, over and over again, to get past their last line of defence. For they have a way of getting down there. getdirentries64() is still found in three instances in /usr/lib. It may be at kernel level today, and, if we have to go to kernel level to get at the bastards, we'll do it. They're hiding stuff, not for an acceptable reason, and people need to see it. So how about just getting the 64-bit inode from a standard call to lstat()? Ah. What happens is in the title. They see that you're going for the jugular and they cut you off - at build time. We've even put the code to extract the 64-bit inode in the ACP framework and tried calling it from GDE - no way: it senses that you're after the 64-bit inode and turns off access to getdirentries(). The binary is marked with it, to prevent 64-bit access. And if that isn't the shite... But somehow we'll get down there. It looks like it might have to be kernel access...

Bonus!

As it's still online, and as it's such a wealth of pure enjoyment, it's been archived for all time. Click the link and see.

http://archive.is/MINtK

Now a few words on looking for things. When you go looking for something specific, your chances of finding it are very bad. Because of all the things in the world you're only looking for one of them. When you go looking for anything at all your chances of finding it are very good. Because of all the things in the world you're sure to find some of them.
- Daryl Zero