|Home » Learning Curve » Developers Workshop
Timmie playing peekaboo.
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.
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!
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...
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.
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
GDE: Got root?
Developers Workshop: .DocumentRevisions-V100
Wikipedia: PRISM (surveillance program)
applehelpwriter: Keeping OS X's nose out of your data
Developers Workshop: Apple Rooting Their Own Systems?
Developers Workshop: GDE-FAQ
Developers Workshop: Getting Around HFS+ Private Data
Developers Workshop: GDE Screenshots
Developers Workshop: Red Pill
Developers Workshop: Red Pill Screenshot 2
Developers Workshop: Red Pill Screenshot 3
Apple Examiner: OS X Folder Layout - Part 1
Apple Examiner: OS X Folder Layout - Part 2
Learning Curve: Apple and the Myth of Unix
Industry Watch: Apple File System Denial of Service
Developers Workshop: HFS: The Good & The Bad
The Technological: 'the english is not great ... interesting none the less'