Live data from Hacker News

Reverse-Engineering Apple Dictionary (2020)

fmentzer.github.io

11–20 of 61 posts

Re: Reverse-Engineering Apple Dictionary (2020)

#11
Thank you for posting this code on Github! There has been some reverse-engineering done on the language dictionaries bundled with Mac OS, and it's nice to know that the same model is being used on the Apple Watch! I look forward to seeing your dictionary app.

https://josephg.com/blog/reverse-engineering-apple-dictionar...

There's also a command-line tool that can query the dictionary:

https://github.com/takumakei/osx-dictionary

Something I haven't yet reverse-engineered is Apple's word segmentation. I can get the word breaks in Chinese by pressing option + right arrow + space, repeatedly. But I have no idea how the backend for that works.

Re: Reverse-Engineering Apple Dictionary (2020)

#12

This is fun. I have another idea: I'd be interested on calling Siri from the command line. Even if using private APIs. (But without hacky fake drivers, or accessibility tools)

The closest I've managed to this has been through AppleScript (which likely violates your "no accessibility tools" criteria): https://forum.keyboardmaestro.com/t/type-to-siri/13328/17

Re: Reverse-Engineering Apple Dictionary (2020)

#13
Another approach for this is to explore the format through Apple's tools for building dictionaries – as they provide a "Dictionary Development Kit" in Xcode's downloadable "Additional Tools" package (which has documentation for the XML format and a bunch of scripts/binaries for building the bundle).

I wound up doing this a while ago for a similar toy project. After some poking around, it turned out that dictionary bundles are entirely supported by system APIs in CoreServices! The APIs are private, but Apple accidentally shipped a header file with documentation for them in the 10.7 SDK [1]. You can load a dictionary with `IDXCreateIndexObject()`, read through its indices with the search methods (and the convenient `kIDXSearchAllMatch`), and get pointers to its entry data with `IDXGetFieldDataPtrs()`.

It takes a bit of fiddling to figure out the structure (there are multiple indices for headwords, search keywords, cross-references, etc., and the API is a general-purpose trie library) and request the right fields, but those property lists in the bundle are there to help! (As the author of this article discovered, the entries are compressed and are proceeded with a 4-byte length marker.)

[1] https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10...

Re: Reverse-Engineering Apple Dictionary (2020)

#14
post #5

I assume one reason Apple has made it more challenging to extract the dictionary resources is in order to satisfy licensing constraints with the dictionary authors. I wonder if they'd block an app like this through the App Store submission process, if submitted.

That’s highly unlikely. The author is incorrect about it being a Zip file, it’s actually a simple gzip/zlib stream. Because it’s not possible to seek within such a stream, they are always chunked in any file that requires random access. Elsewhere there will be an index file which maps words to their corresponding chunks, so that the definition can be quickly loaded without having to decompress the entire file - or even load it all into memory. This is very normal stuff in the world of file formats.

Re: Reverse-Engineering Apple Dictionary (2020)

#16
I have thought about building a vocabulary learning tool for learning Japanese on top of Apple Dictionary. My idea is simple: user collects dicitionary items and the tool offers lookup / spaced-repetition.

However, I'm concerned that the dictionary is copyrighted. Is there any precedent that says whether such a tool would be legal/illegal?

Re: Reverse-Engineering Apple Dictionary (2020)

#17
post #6

Earlier quoted context omitted.

I’d definitely assume this would be a copyright problem if used in an app.

Yes, a lot of people involved in dictionary processing are worried about copyright! After I wrote my post about Apple's dictionary files, I got a mysterious email showing up in my inbox. The email was from someone who's spent some time writing code to do the same thing, but doesn't want to post it under his own name in case he falls fowl of his country's DMCA equivalent. Crazy. He said I could post his code under the…

I have helped with the writing and editing of a number of dictionaries over the years. It's difficult, highly specialized work. For some of the jobs, the only compensation has been a share of the royalties from future sales. I doubt if many people like me are enthusiastic about the dictionary data becoming accessible for free.

Re: Reverse-Engineering Apple Dictionary (2020)

#18
post #12

This is fun. I have another idea: I'd be interested on calling Siri from the command line. Even if using private APIs. (But without hacky fake drivers, or accessibility tools)

The closest I've managed to this has been through AppleScript (which likely violates your "no accessibility tools" criteria): https://forum.keyboardmaestro.com/t/type-to-siri/13328/17

Yeah, I guess another requirement, it should be as "invisible" as possible. So you could programmatically interact with Siri in the background and perhaps not notice.

Re: Reverse-Engineering Apple Dictionary (2020)

#19
post #16

I have thought about building a vocabulary learning tool for learning Japanese on top of Apple Dictionary. My idea is simple: user collects dicitionary items and the tool offers lookup / spaced-repetition. However, I'm concerned that the dictionary is copyrighted. Is there any precedent that says whether such a tool would be legal/illegal?

If your tool doesn't come with bundled data from Apple, extract data in local and doesn't leak it to another party it's probably safe to do so (like emulators).

Re: Reverse-Engineering Apple Dictionary (2020)

#20
post #12

Earlier quoted context omitted.

The closest I've managed to this has been through AppleScript (which likely violates your "no accessibility tools" criteria): https://forum.keyboardmaestro.com/t/type-to-siri/13328/17

Yeah, I guess another requirement, it should be as "invisible" as possible. So you could programmatically interact with Siri in the background and perhaps not notice.

The knowledge part is powered by Wolfram Alpha, which has an API, I believe
Post reply on HN