Analizador de código estático de iPhone

Question

Un consenso en desarrollo entre la comunidad de desarrolladores de iPhone es que Apple recientemente comenzó a usar una herramienta de análisis de código estático para detectar el uso de llamadas API no documentadas.

Solo por el argumento, me pregunto si sería posible solucionar esta herramienta generando la invocación en tiempo de ejecución de esta manera:

NSString *const aMethod = @"doStuff:withStuff:";
SEL aSelector = NSSelectorFromString(aMethod);
NSMethodSignature *aSignature = [targetObject methodSignatureForSelector:aSelector];
NSInvokation *anInvokation = [NSInvokation invocationWithMethodSignature:aSignature];
[anInvokation setTarget:targetObject];
[anInvokation setSelector:aSelector];
[anInvokation setArgument:&firstArg atIndex:2];
[anInvokation setArgument:&secondArg atIndex:3];
[anInvokation invoke];

Esto parece casi demasiado fácil, así que me pregunto: ¿qué me estoy perdiendo? ¿Cómo puede Apple detectar esto usando análisis de código estático en el ensamblaje?

Un par de puntos:

1. Soy consciente de que el nombre del método ser almacenado en el binario como estático cuerda. Sin embargo, sería trivial para generar el nombre del método en tiempo de ejecución también usando stringWithFormat: u otro tipo de ligera ofuscación (suficiente para confundir el analizador estático).
2. Sé que este truco sería revelado incluso por el análisis de tiempo de ejecución más trivial usando gdb. Comprendo que Apple analiza el binario en sí, y tal vez estoy completamente equivocado al respecto.

Answer 1

¿Por qué importa? Se supone que no debes usar una API privada por una buena razón: Apple podría romper fácilmente tu aplicación en cualquier momento, molestando a tus usuarios.

Dicho esto, el uso de NSInvocation, -performSelector: o cualquier otra técnica similar es probablemente suficiente para evitar ser detectado por un analizador estático.

Answer 2

Supongo que has leído este artículo . También es interesante este . Mi interpretación es que el analizador estático de Apple genera falsos positivos solo porque algunas personas usan métodos que tienen el mismo nombre que los métodos privados. Esto no habría sucedido si el analizador hubiera realizado un análisis de tiempo de ejecución o una verificación exhaustiva de qué selector de clases se ha llamado. Por lo tanto, parece que principalmente buscan cadenas o selectores coincidentes en su binario. Creo que usar NSInvocation combinado con alguna ofuscación de cadenas lo ayudará a superarlo. Sin embargo, todavía recomendaría no confiar en API privadas.

Answer 3

¡Hay una manera fácil de averiguarlo!

¡Cree una aplicación que use deliberadamente una API oculta a través del método en su pregunta y vea si se acepta!

Sam

PD: Si lo averigua, asegúrese de informarnos; ¡a todos nos gustaría saberlo con seguridad y Apple seguramente no nos lo dirá!