Startup Error

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open iphonebrowser with iPhone 3G connected
2. Connect iPhone 3G with iphonebrowser running
3.

What is the expected output? What do you see instead?
Recognize phone. 

iPhoneBrowser has encountered a problem and needs to close.  We are sorry
for the inconvenience.
"If you were in the middle of something, the information you were working
on might be lost."

What version of the product are you using? On what operating system?
Version 1.7 on XP Pro SP3

Please provide any additional information below.
The iPhone is sync'd to a computer other than this one, if it matters.

Original issue reported on code.google.com by jess...@gmail.com on 9 Sep 2008 at 9:52

[GoogleCodeExporter]

What version of iTunes?

Original comment by NetMage....@gmail.com on 11 Sep 2008 at 6:11

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

That was with 7.7.1, I can try 8.0 now that it's out but i doubt it makes a
difference. Like i said, this is on a computer that the iPhone is not sync'd to.

Original comment by jess...@gmail.com on 11 Sep 2008 at 6:18

[GoogleCodeExporter]

Using iTunes 8 will also require installing iPhoneBrowser 1.8.

Let me know if it still crashes and if you can, please post a crash log.

Original comment by NetMage....@gmail.com on 11 Sep 2008 at 6:47

[GoogleCodeExporter]

it works great for me now so thanks.

Original comment by yas...@gmail.com on 11 Sep 2008 at 9:21

[GoogleCodeExporter]

v1.8 is working for me, thank you!

Original comment by jess...@gmail.com on 11 Sep 2008 at 2:17

[GoogleCodeExporter]

I think that 16 bytes for unknown3 in AMDevice is not enough. Program crashes
randomly at AMDeviceConnect. When I've expanded it to 80 bytes, everything 
normalized.

Original comment by bozhe...@gmail.com on 12 Sep 2008 at 5:44

[GoogleCodeExporter]

Hi,I'm using itune 8 and iphonebrowser 1.8. but the same message (as described 
above) comes up and doesn't let the program run

Original comment by rkows...@gmail.com on 12 Sep 2008 at 9:14

[GoogleCodeExporter]

Guys at http://i-funbox.com/blog/2008/09/ discovered that even 80  extra bytes 
are
not enought - they use following layout:
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
};

Don't be such a scrooge - add some extra bytes.

Original comment by bozhe...@gmail.com on 14 Sep 2008 at 7:26

[GoogleCodeExporter]

After second thought, this will definitely lead to crash in Tunes 7.x. I've 
decided
to change the whole approach. Instead of AMDevice struct, use 
[StructLayout(LayoutKind.Sequential, Pack = 1)]
    public struct AMDevicePtr
    {
        internal IntPtr dev_ptr;
        public AMDevice dev
        {
            get
            {
                return (AMDevice)Marshal.PtrToStructure(this.dev_ptr, typeof(AMDevice));
            }
        }
    }
like this:

    internal struct AMDeviceNotificationCallbackInfo
    {
        public AMDevicePtr dev_ptr;
        public NotificationMessage msg;
    }

and then 

        [DllImport("iTunesMobileDevice.dll", CallingConvention=CallingConvention.Cdecl)]
        public static extern int AMDeviceConnect(AMDevicePtr device);

and so on. In this case you use only pointer and do not care about size of the 
memory
it points to.
Don't forget to revert changes in AMDevice (size of unknown3) back to 
pre-iTunes8 state. 
You can look at modified version of Manzana here:
http://rapidshare.com/files/145324330/manzana.zip.html
(It's decompiled version since you doesn't provide modified sources). I would 
prefer
to change iPhone.Device and ConnectEventArgs.Device to AMDevicePtr, but then it
require rebuild existing iPhoneBroser binaries.

For all who has crash, try to put file ipbManzana\bin\Debug\Manzana.dll from 
archive
to iPhonebrowser folder. It should help.

Original comment by bozhe...@gmail.com on 14 Sep 2008 at 10:35

[GoogleCodeExporter]

I don't particular need the fields so that's ok for me, but general Manzana 
users
might want to be able to access the device_id, etc. Why should increasing the
structure size cause an iTunes 7.x incompatibility as long as the unknown fields
aren't accessed?

Original comment by NetMage....@gmail.com on 14 Sep 2008 at 11:33

[GoogleCodeExporter]

I used the Funbox.com version. Please see if v1.81 helps.

Original comment by NetMage....@gmail.com on 15 Sep 2008 at 4:29

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by NetMage....@gmail.com on 15 Sep 2008 at 4:30

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

When you call Marshal.PtrToStruсt, .Net allocates new memory block and tries 
to copy
data there, starting ptr and size of struct. If there were allocated less than
specified amount at the source location, it'll crash. You can try it by 
yourself -
change size of unknown3 to 1000 and see access violation exception. So if 
there luckily is some other memory past amdevice structure, everything will go 
ok,
otherwise it will crash. In my solution, you store pointer to struct only and 
pass it
directly to iTunes functions. I suppose that Apple considers amdevice field in
notification event struct as an abstract handle. Otherwise it should provide 
some way
to know it's size. If user (btw who the f$ck is user of 
your private copy of manzana?) is curious enough to query serial, he can try to 
cast
this pointer to amdevice without any warranty of success.

Original comment by bozhe...@gmail.com on 15 Sep 2008 at 8:29

[GoogleCodeExporter]

I think I've got it. AMDevice has grown only 4 extra bytes. iPB 1.80 crashed 
when
there were no extra memory past amdevice. So will 1.81. When I've changed 
unknown3
size to 80, memory allocation somehow changed and lucky enough memory became
continuous. Funbox author calculated new size incorrectly. Compare old and new
version of AMDeviceConnect here - 
http://rapidshare.com/files/145527652/1.zip.html 
Note that result of lockdown_connection_create is stored in unknown3 and in new
version lpCriticalSection is stored in device + 48, meaning 4 extra bytes, not 
8 as
you did, not 72 as I did and not 105 as funbox did. 

To avoid this mess completly, don't copy contents of structure. To safely get 
serial
there is AMDeviceCopyDeviceIdentifier function, for device_id -
AMDeviceGetConnectionID. Note, DiskAid survived 7 to 8 transfer. Try to guess - 
why?

Original comment by bozhe...@gmail.com on 15 Sep 2008 at 6:03

[GoogleCodeExporter]

Hm. Not right. It allocates 76 bytes for am_device in iTunes 8. In
iTunesMobileDevice.dll 7.8.118.0 (not sure from which iTunes, I think from 
7.7.1)
there were 52 bytes. In 7.3.85.0 - 48 bytes, as in Manzana header.

BTW, to release memory allocated for AMDevice, use AMDeviceRelease.

Original comment by bozhe...@gmail.com on 15 Sep 2008 at 6:51

[GoogleCodeExporter]

Seems like you need to tone it down a little.

BTW, should I be using AMDeviceRetain to match AMDeviceRelease - neither of 
which are
in Manzana.

Thanks for pointing out the Manzana source wasn't being uploaded, I have fixed 
the
SVN to include it.

Original comment by NetMage....@gmail.com on 15 Sep 2008 at 9:50

[GoogleCodeExporter]

Sorry :) This change in iTunes 8 has also broken my app. I knew that Manzana was
poorly written, but hoped that a year of open source development would clean up 
most
obvious bugs from it. I was mistaken… 

About Retain, it increases reference counter stored in unknown2 (see here -
http://rapidshare.com/files/145611749/1.zip.html ). AMDeviceRelease decreases 
this
number and frees resources when zero is reached. When am_struct is transferred 
to
callback there already “2” in that field. So I don’t think that you 
should call
AMDeviceRetain once again. On the other hand I think that you can safely allow 
small
resource leak each time the phone is connected/disconnected and not call
AMDeviceRelease at all.

By the way, I've updated mobiledevice.h info at geohot's wiki:
http://www.theiphonewiki.com/wiki/index.php?title=MobileDevice_Library#MobileDev
ice_Header_.28mobiledevice.h.29

Original comment by bozhe...@gmail.com on 15 Sep 2008 at 11:31

[GoogleCodeExporter]

I modified my Manzana some to try to help while making iPhoneBrowser work with 
iTunes
8.2, but the internal API calls appear to expect the caller to allocate memory 
for
the structure (i.e. not using pointer to pointer as handle) so I just allocated 
extra
memory in structure and removed all internal types.

Original comment by NetMage....@gmail.com on 12 Jun 2009 at 8:22

• Changed state: Fixed