There's no secret software the police have that will suck all the info off an iPhone with a 6-digit PIN.
There are the scary tools at http://www.iosresearch.org/ (for one brand of phone under certain circumstances).
There are the scary tools at http://www.iosresearch.org/ (for one brand of phone under certain circumstances).
Let's put it this way: it is absurd to believe that the iPhone's filesystem is encrypted with the PIN number. When the phone turns on, it is already booted up, and applications like MobileMail, Skype, and Latitude are already in the background running with your data. You can receive text messages and phone calls, which are stored as notifications and in the appropriate databases: you don't need to unlock it first.
Meanwhile, none of the jailbreaking tools (which often operate while the phone is in "DFU" mode, after it has been rebooted and without any other human interaction) require you to type in your PIN, yet make tons of filesystem modifications to both partitions (the system one with the firmware from Apple, and the user partition with the data for each user), which should be a pretty obvious clue that you don't need anything from the user to get access to any of that data.
Instead, all of the data is simply encrypted with a key derived from the device, which therefore means that all you need is "virtually any exploit" on the device, whether it be userland (send a fancy SMS message to the device which crashes CommCenter or SpringBoard) or bootloader (attacking it over USB in DFU mode, stealing the keys directly; something we currently can do for all Apple devies but the iPad 2), in order to get access to the personal data (even stuff you recently deleted, of course, due to how filesystems work) which is on it.
(I am frequently wrong even about things I know well; how iPhone device encryption works is not one of those things).
No, it doesn't. That's only 60 million combinations. Writing the code would take longer than the brute force search. Of course, there are already commercial applications that do all that.
Now, as for the tools, saurik is entirely correct. The PIN code is, for the most part, just a GUI lock - think of it as a screen saver lock. The file system is encrypted on the chip, but applications need to be able to read and write from the file system. If you read the FAQ, I make no secret about how this works: we boot a custom RAM disk (from DFU mode) that mounts the disk. The kernel takes care of the decryption and because we're not actually booting the OS on disk, we don't have any pesky screen saver lock or anything else to even content with, though if we did, the forensic imaging process runs entirely in the background, and has the same level of access (root) that most of Apple's processes do.
As for encryption, what IS encrypted on disk that you can't get from the file system includes keychain passwords, HFS journal (to undelete files, thanks to Jean-Baptiste's most awesome code), and files protected with iOS' data-protection classes. These files are few and far between. In fact, a vast majority of the evidence you'll find on an iPhone is entirely unencrypted. For the files that ARE encrypted, Jean-Baptiste's brute forcing and decryption tools allow us to extract the master encryption keys from the device. Each keychain password is encrypted with its own key ("AES wrap"); we apply the device's keys to this wrap, decrypt the password's key, then use that key to decrypt the password. Apple's data-protection classes are about the same. Each file is wrapped and we use one of the class keys to ultimately decrypt the file. This includes the few files on the device that are encrypted, such as email + attachments, and some third party data files using this encryption.
Once you unwrap that, you'll find that even applications using their own encryption code are storing keys in the keychain - so once the keychain is decrypted, the keys to these third party crypto stores are equally exposed.
The moral of the story here is that the only GOOD way to protect files is 1. To encrypt them (something Apple really doesn't do very well), 2. To have the encryption depend on a very complex key that only the owner has knowledge of and must supply in order to decrypt the files, and finally 3. To protect the device in such a way that the key cannot be intercepted by trojans or other malware. Unfortunately, iOS fails on all of these counts, making it very easy (thanks to many world class hackers contributing code) to defeat all of the encryption on the device, and MOST of the encryption even when the device is password locked.
Scary? What's scary here is just how neglected security is on mobile devices, and how easy it would be for me, or Saurik, or anybody who can use code.google.com to steal all of the data on your device in just a few minutes.