Respostas:
Existem 3 maneiras que eu conheço. Essas são apenas algumas especulações, já que não trabalho na equipe de revisão da Apple.
otool -LIsso listará todas as bibliotecas às quais o aplicativo está vinculado. Algo claramente que você não deve usar, como IOKit e WebKit, pode ser detectado por isso.
nm -uIsso listará todos os símbolos vinculados. Isso pode detectar
UITouch._phase(que pode ser a causa da rejeição de aplicativos baseados no Three20 nos últimos meses).stringsOs seletores Objective-C são armazenados em uma região especial do binário e, portanto, a Apple pode extrair o conteúdo de lá e verificar se você usou alguns métodos Objective-C não documentados, como -[UIDevice setOrientation:].
Como os seletores são independentes da classe com a qual você está enviando mensagens, mesmo que sua classe personalizada seja -setOrientation:irrelevante para UIDevice, haverá a possibilidade de serem rejeitados.
Você pode usar o APIKit de Erica Sadun para detectar rejeição potencial devido a (falsos alarmes de) APIs privadas.
(Se você realmente realmente deseja contornar essas verificações, pode usar recursos de tempo de execução como
-valueForKey:; object_getInstanceVariable, object_getIvar, etc.para obter essas bibliotecas privadas, classes, métodos e ivars. )
Você pode listar os seletores em um programa Mach-O usando o seguinte one-liner no Terminal:
otool -s __TEXT __objc_methname "$1" |expand -8 | cut -c17- | sed -n '3,$p' | perl -n -e 'print join("\n",split(/\x00/,scalar reverse (reverse unpack("(a4)*",pack("(H8)*",split(/\s/,$_))))))'Digamos que você queira usar alguma API privada; o objetivo C permite que você construa qualquer SEL a partir de uma string:
SEL my_sel = NSSelectorFromString([NSString stringWithFormat:\
@"%@%@%@", "se","tOr","ientation:"]);
[UIDevice performSelector:my_sel ...];Como um robô ou uma varredura de biblioteca pode detectar isso? Eles teriam que detectar isso usando alguma ferramenta que monitora acessos privados em tempo de execução. Mesmo se eles construíram uma ferramenta de tempo de execução, é difícil de detectar porque essa chamada pode estar oculta em algum caminho raramente exercitado.
Eu imagino que eles olhem para todos os símbolos que seu binário está tentando importar (informações sem dúvida facilmente disponíveis para eles na tabela de símbolos) e avisam você se algum desses símbolos for encontrado em sua "lista de API privada". Muito fácil de automatizar, na verdade.
Um executável não é exatamente uma caixa preta. Se você chamar uma biblioteca, é uma coisa fácil de encontrar. É por isso que lamento a perda das linguagens assembly nas modernas escolas de ciência da computação. =] Ferramentas como o ldd dirão a você o que você vinculou, embora eu não me lembre de qual encarnação do ldd chegou ao mac iPhone dev kit.
além da investigação do símbolo ...
apple poderia muito facilmente ter uma versão do sdk que verifica cada uma das pilhas de métodos privados quando chamado para garantir que foi inserido a partir de um dos métodos designados.
Mesmo se você estiver vinculando estaticamente, na pior das hipóteses, eles poderiam pegar amostras do código das APIs privadas em sua lista e pesquisar seu binário nelas (também relativamente fácil de automatizar).
Conhecendo a Apple, aposto que eles têm um sistema abrangente e automatizado, e qualquer incerteza provavelmente é negada ou revisada manualmente.
No final do dia, acho que provavelmente não vale a pena tentar enganar a Apple.
Este aplicativo de desktop, App Scanner , pode escanear arquivos .app para uso privado de API, separando o arquivo Mach-O Binary. Se puder, a Apple também pode!
Existem muitas ferramentas para engenharia reversa que permitem inspecionar um código
nm - lista os símbolos dos arquivos objeto objdump - exibe informações de arquivos de objeto.otool- visualizar o conteúdo dos executáveis Mach-O [Sobre]strings - isso vai te dar todas as cordas.Você pode encontrar exemplos / representação do uso desses comandos em gists para Objective-C e Swift