libimobiledevice – A cross-platform library to communicate with iOS devices(libimobiledevice.org)
libimobiledevice.org
libimobiledevice – A cross-platform library to communicate with iOS devices
http://www.libimobiledevice.org/
5 comments
This is also used by Google's ios-webkit-debug-proxy: https://github.com/google/ios-webkit-debug-proxy
What I want to know is, does it support Ipod Nano 7th generation.
It's been years since that model was released and I've still not found a way to mount it under Linux and transfer songs.
It's been years since that model was released and I've still not found a way to mount it under Linux and transfer songs.
The answer appears to be yes if this [0] is to be believed:
> UPDATED April 06 2015, to include the latest underlying libraries - libplist, usbmuxd, and libimobiledevice. libimobiledevice is now at version 1.2.0, which means gtkpod should now support iOS 8 devices, including the latest iPhone 6/6+, iPad Mini 3/Air 2 and Apple TV 2G/3G. Although for music-sync to work with these newer devices it's necessary to install an additional "libhashab" file. See the "Special Requirements" section below for details. This situation applies to these models:
> - iPhone4/5/6
> - iPod Touch 4gen, 5gen
> - iPad 3gen, 4gen, Air, Air 2, Mini 1/2/3gen
> - Nano 6gen, 7gen
[0] http://www.murga-linux.com/puppy/viewtopic.php?t=94022
> UPDATED April 06 2015, to include the latest underlying libraries - libplist, usbmuxd, and libimobiledevice. libimobiledevice is now at version 1.2.0, which means gtkpod should now support iOS 8 devices, including the latest iPhone 6/6+, iPad Mini 3/Air 2 and Apple TV 2G/3G. Although for music-sync to work with these newer devices it's necessary to install an additional "libhashab" file. See the "Special Requirements" section below for details. This situation applies to these models:
> - iPhone4/5/6
> - iPod Touch 4gen, 5gen
> - iPad 3gen, 4gen, Air, Air 2, Mini 1/2/3gen
> - Nano 6gen, 7gen
[0] http://www.murga-linux.com/puppy/viewtopic.php?t=94022
What I want to know is: can it get logs?
Can you be more specific? You can use 'idevicesyslog' to view onscreen logs. You can also use commands like 'idevicediagnostics' to retrieve state information (e.g. power cycles of the battery) and 'idevicecrashreports' for crash data.
There is full FS access, and I imagine it'd be trivial to figure out the location of the logs.
Unfortunately iOS 9's new 'rootless' feature is going to break a lot of stuff in this.
In what way? All I've seen so far about "rootless" or what Apple is actually going to implement or what it will mean for users is just pure speculation from tech sites.
The only factual piece of information I know of that is likely related to "rootless" is from a WWDC 2013 session[1] about kexts, in which an Apple engineer said this:
> I'm Jerry Cottingham, I'm an engineer on the Core OS IO team
> ...
> And another warning I'll throw out here is in the future as we start to lock down the /System folder, you might actually get write errors. So when you try to install a kernel extension into the /System folder, the write itself may fail.
[1] http://asciiwwdc.com/2013/sessions/707
The only factual piece of information I know of that is likely related to "rootless" is from a WWDC 2013 session[1] about kexts, in which an Apple engineer said this:
> I'm Jerry Cottingham, I'm an engineer on the Core OS IO team
> ...
> And another warning I'll throw out here is in the future as we start to lock down the /System folder, you might actually get write errors. So when you try to install a kernel extension into the /System folder, the write itself may fail.
[1] http://asciiwwdc.com/2013/sessions/707
That seems to be about OS X. He also says, "So if you're trying to write a kext for iOS, we don't allow that." Did they ever allow third-party kexts on iOS? I'd be surprised, but maybe they approve it for some peripheral drivers or something.
That session happens to be about OS X kexts yes, but it's just where that piece of info happened to slip out. Clearly they've been planning to do at least that much for quite a while now. I wouldn't be at all surprised if they start using a completely separate system partition on OS X like they already do on iOS now.
As far as I know the release versions of the iOS kernel don't support kext loading at all. Most likely, MFI participants are encouraged/required to use standard interfaces or request inclusion of specific functionality if it isn't there already.
As far as I know the release versions of the iOS kernel don't support kext loading at all. Most likely, MFI participants are encouraged/required to use standard interfaces or request inclusion of specific functionality if it isn't there already.
As I understand it, this uses the same protocols iTunes uses (or can use even if currently doesn't), so unless Apple breaks iTunes, these should either continue to work as is, or with modifications that will require adaptation.
Actually this lets you do more than what iTunes lets you. iOS 8.3 has already prevented tools like iFunBox (which also uses this IIRC) to access the app sandbox directory.
Then it must have exploited some leftover, or Apple just moved stuff around. If backup is possible, then access to sandboxes is still allowed one way or another.
house_arrest used to allow direct access to the documents and container of any app. It's used by the Xcode "installed applications" list, to allow you to download and upload container contents. In 8.3 they changed it to only allow VendDocuments access to apps which actually have document sharing enabled in their Info.plist (and VendContainer access for ad-hoc provisioned apps, iirc).
Backup is done via a completely separate service.
iOS releases do tend to arbitrarily change the security policy of these services, but it's not clear that "Rootless" is anything more than business as usual. Guess we'll find out Monday.
Backup is done via a completely separate service.
iOS releases do tend to arbitrarily change the security policy of these services, but it's not clear that "Rootless" is anything more than business as usual. Guess we'll find out Monday.
[1] http://robovm.com