How can I tell of which type the argument for a private framework method has to be?

Question

I'm currently playing around with private frameworks, mostly for the sake of it. To give it a little sense, I have set myself the goal of getting a ringtone installer (just like Garage Band is able to install ringtones) to work on a non-jailbroken device.

So I've been browsing classdumps and found the ToneLibrary.framework and the TLToneManager (See classdump) to look promising. Within TLToneManager, the -(void)importTone:(id)arg1 metadata:(id)arg2 completionBlock:(/*^block*/ id)arg3 looks like it might do what I want.

It appeared to be kind of obvious for that method to expect an TLITunesTone object as arg1, so I created one, initialized it with a m4r file which is in my apps bundle and passed it in. That leads to a 'NSInvalidArgumentException', reason: '-[TLITunesTone writeToFile:atomically:]: unrecognized selector sent to instance 0x15551770' though. So it expects something else - obviously something that implements writeToFile:atomically:, maybe NSData or NSDictionary.

Before I continue experimenting blindly, I'd like to know - is there a way (other than trial and error) to find out what type of argument needs to get passed in a private method? (I do realize that even if I knew the type, I still might lack knowledge about the required contents, in the case of a dictionary for example)

Thanks!!

Answer 1

1. Find application/daemon that uses API you're interested in and hook method/function calls with CydiaSubstrate or theos/logos. That way you can NSLog argument types.
2. Disassembling. You will not find exact argument types but there may be some clues like which methods are called on argument (like writeToFile:atomically: in your case), where arguments are passed later etc.
3. Find someone elses code that uses the APIs.

That's about it. Of course, you can guess arguments types like you did but that will probably take longer. In some cases you will not be that lucky to get exception. Application will just crash with segmentation fault which is pretty much useless. Even crash log may not give you much information. It's especially difficult in case of C functions like CoreTelephony APIs or C++ classes. Many APIs expect pointers to CoreFoundation objects, C structures, some internal objects. Wrong argument - segmantation fault. In these cases only disassembly will help you.