iTunesMobileDevice.dll Changed in iTunes 8.0

Many users reported iFunBox crashes after iTunes was updated to v8.0. We found the USB communication runtime library (iTunesMobileDevice.dll) was changed which cause iFunBox failure. The problem has been fixed in the newly released iFunBox v0.6.199.35.

More precisely, the memory layout of the structure am_device was extended 105bytes. The structure is used in many fundamental call for communicating with iPhone via USB port. Though the meaning of these addtional bytes is not clear to us, fortunately we don’t need to know that. The structure is created by the runtime library and feeded to other calls.

The updated am_device structure is defined as:
struct am_device {
unsigned char unknown0[16]; /* 0 - zero */
unsigned int device_id; /* 16 */
unsigned int product_id; /* 20 - set to AMD_IPHONE_PRODUCT_ID */
char *serial; /* 24 - set to AMD_IPHONE_SERIAL */
unsigned int unknown1; /* 28 */
unsigned char unknown2[4]; /* 32 */
unsigned int lockdown_conn; /* 36 */
unsigned char unknown3[8]; /* 40 */
unsigned char unknown4[6*16+1]; // + in iTunes 8.0, by iFunbox.dev
unsigned char padding[8]; // + in iTunes 8.0, by iFunbox.dev
};

11 Responses to “iTunesMobileDevice.dll Changed in iTunes 8.0”

  1. Redart Says:

    It seems to me that 6*16+1+8=105, not 109 extra bytes as you wrote. Please, explain, how you’ve got such a number, I’m very curious about it… Why 16*6?

  2. admin Says:

    Typo, I’ve fixed it, it is 105bytes.
    I checked the memory of the am_device structure feeded by the callback function set via [AMDeviceNotificationSubscribe]. 6*16bytes block is ended with the serial number (in C string with one byte for terminator). That is [unknown4]. The [padding] member is always a constant. I noticed these bytes are belong to am_device structure because these values is not equal to the default value of the allocated buffers and varys on connecting different devices.

  3. Redart Says:

    Hmm… For me unknown4 reads for one phone with 2.0.2 firmware
    “x3????\a\v?b52c2c87feaafbe1741826b76600000000000000\a(” where 0b52c2c87feaafbe1741826b76600000000000000 is also value of am_device.serial.
    and padding is
    [0] 2
    [1] 84
    [2] 4
    [3] 40
    [4] 2
    [5] 84
    [6] 4
    [7] 0
    [8] 0
    and for other phone with firmware 1.1.4 unknown4 is
    “?/????\a\v|aeb4d30da0f2057cb85426acce00000000000000\n\a{\f?”, where aeb4d30da0f2057cb85426acce00000000000000 is serial, and padding is
    [0] 196
    [1] 79
    [2] 4
    [3] 192
    [4] 5
    [5] 0
    [6] 0
    [7] 120
    [8] 53

    Something may be wrong with yours arithmetics…
    And, just curiuos, why do you store contents of those structures, not just pointers to it? In that case there would be no problem with new version of iTunes…

  4. Redart Says:

    Wordpress has eaten some of characters in strings. Here for 1.1.4 phone:
    [0] 240
    [1] 47
    [2] 16
    [3] 1
    [4] 255
    [5] 255
    [6] 255
    [7] 255
    [8] 0
    [9] 0
    [10] 0
    [11] 0
    [12] 0
    [13] 0
    [14] 0
    [15] 0
    [16] 0
    [17] 0
    [18] 0
    [19] 0
    [20] 0
    [21] 0
    [22] 0
    [23] 0
    [24] 0
    [25] 0
    [26] 0
    [27] 0
    [28] 0
    [29] 0
    [30] 0
    [31] 0
    [32] 7
    [33] 0
    [34] 11
    [35] 0
    [36] 124
    [37] 1
    [38] 15
    [39] 0
    [40] 97 <- serial starts
    [41] 101
    [42] 98
    [43] 52
    [44] 100
    [45] 51
    [46] 48
    [47] 100
    [48] 97
    [49] 48
    [50] 102
    [51] 50
    [52] 48
    [53] 53
    [54] 55
    [55] 99
    [56] 98
    [57] 56
    [58] 53
    [59] 52
    [60] 50
    [61]
    [62]
    [63]
    [64]
    [65]
    [66]
    [67]
    [68]
    [69]
    [70]
    [71]
    [72]
    [73]
    [74]
    [75]
    [76]
    [77]
    [78]
    [79] 97 <- serial ends
    [80] 0
    [81] 0
    [82] 0
    [83] 0
    [84] 0
    [85] 0
    [86] 0
    [87] 0
    [88] 10
    [89] 0
    [90] 7
    [91] 0
    [92] 123
    [93] 1
    [94] 12
    [95] 0
    [96] 172

    and for 2.0.2 phone:

    [0] 128
    [1] 146
    [2] 15
    [3] 1
    [4] 255
    [5] 255
    [6] 255
    [7] 255
    [8] 0
    [9] 0
    [10] 0
    [11] 0
    [12] 0
    [13] 0
    [14] 0
    [15] 0
    [16] 0
    [17] 0
    [18] 0
    [19] 0
    [20] 0
    [21] 0
    [22] 0
    [23] 0
    [24] 0
    [25] 0
    [26] 0
    [27] 0
    [28] 0
    [29] 0
    [30] 0
    [31] 0
    [32] 7
    [33] 0
    [34] 11
    [35] 0
    [36] 191
    [37] 1
    [38] 15
    [39] 0
    [40] 98 <-serial starts
    [41] 53
    [42] 50
    [43] 99
    [44] 50
    [45] 99
    [46] 56
    [47] 55
    [48] 102
    [49] 101
    [50] 97
    [51] 97
    [52] 102
    [53] 98
    [54] 101
    [55] 49
    [56] 55
    [57] 52
    [58] 49
    [59] 56
    [60]
    [61]
    [62]
    [63]
    [64]
    [65]
    [66]
    [67]
    [68]
    [69]
    [70]
    [71]
    [72]
    [73]
    [74]
    [75]
    [76]
    [77]
    [78]
    [79] 55 <-serial ends
    [80] 0
    [81] 0
    [82] 0
    [83] 0
    [84] 0
    [85] 0
    [86] 0
    [87] 0
    [88] 22
    [89] 0
    [90] 7
    [91] 0
    [92] 0
    [93] 16
    [94] 0
    [95] 0
    [96] 40

  5. admin Says:

    Thanks for your information, it’s weird. My iphone 1.1.4 + iTunes 8.0 feeds me as the following:
    0×0B0E7460 40 c1 1a 00 ff ff ff ff @…….
    0×0B0E7468 00 00 00 00 00 00 00 00 ……..
    0×0B0E7470 00 00 00 00 00 00 00 00 ……..
    0×0B0E7478 00 00 00 00 ab ab ab ab ……..
    0×0B0E7480 ab ab ab ab ee fe ee fe ……..
    0×0B0E7488 00 00 00 00 00 00 00 00 ……..
    0×0B0E7490 09 00 0d 00 6c 07 1f 00 ….l…
    0×0B0E7498 36 35 66 63 36 33 36 38 65fc6368
    0×0B0E74A0 64 65 30 30 33 63 63 32 de003cc2
    0×0B0E74A8 34 34 66 33 31 36 63 61 44f316ca
    0×0B0E74B0 61 39 66 39 36 34 33 63 a9f9643c
    0×0B0E74B8 64 65 33 38 66 31 34 66 de38f14f
    0×0B0E74C0 00 ab ab ab ab ab ab ab ……..
    0×0B0E74C8 ab fe ee fe ee fe ee fe ……..

    serial number ends at [96].

    I made a copy of the am_device structure instead of assuming the pointer provided is available out of the scope of the callback.

  6. Redart Says:

    Probably we are looking at some other memory allocated for other purposes in the address space following amdevice struct, and struct itself ends at ff ff ff ff (or 00 00 00 … 00). Who cares.

    Author of http://code.google.com/p/iphonedisk/ stores just pointer to struct. So did I in my application last night (you can take a look at it here - http://code.google.com/p/iphonebrowser/issues/detail?id=52). I suppose that it should be safe enought. How do iTunes know size of struct? One can trace iTunes calls but I’m almost sure it doesn’t make a copy in AMDeviceNotification. You can check it out if you like…

  7. iTunes Music Blog Says:

    I think you nailed it on the head!! That\’s the point that everyone here has failed to make, nice work!! I am going to place a link to you on my blogroll, ok?

  8. admin Says:

    Sure. It’s nice.

  9. iTunes Music Blog Says:

    I can\’t believe no one has made that point yet!!! Good work on really nailing down the correct approach. I\’m going to link to this from my blog roll, ok?

  10. alex Says:

    could you give the iTunesMobileDevice.dll function list to me ?i need this list very much ,thanks.

  11. Robin Says:

    Anyone knows how the sync of addressbook is done via iTunes?

    Does it also use afc service and itunesmobiledevice.dll for syncing adressbook and calendar… in not jailbroken OS 3 devices?

    Thanks for reply!

Leave a Reply