Comment les fonctions non documentées sont-elles découvertes? [fermé]

Je me suis toujours demandé comment trouver une API non documentée / privée ?

Exemple d' API Apple non documentée / privée, Play Station , Windows Phone 7 , noyau Win32 , API Windows , rappel caché , etc ...

Quels outils les pirates informatiques utilisent-ils pour découvrir les fonctions privées et non documentées?

Où puis-je lire sur les expériences des gens plongeant dans les API privées et les techniques de rétro-ingénierie qui révèlent les secrets qui sont normalement expliqués dans la documentation des API?

merci,
A

Il y a deux façons de penser:

1. Réflexion. Ici, vous obtenez un objet et lui demandez de révéler des informations sur lui-même, comme les méthodes, les propriétés, etc. Avec les bonnes options (selon la langue), vous pouvez révéler des informations qui ne sont pas "publiques".

2. Décompilation. Cela régénère (une version) de la source utilisée pour créer le binaire. Encore une fois, cela pourrait révéler des parties non publiques de l'API.

Vous pouvez également ajouter "par accident" à la liste. Un appel / commande mal orthographié qui fonctionne, ou un écran d'aide qui révèle trop d'informations.

Outils normaux que vous utilisez pour développer des logiciels :)

Habituellement, les fonctions d'API non documentées ne sont que des secrets non documentés et pas vraiment soigneusement cachés.

La conception d'une API à l'épreuve du temps est difficile - vous pouvez facilement ajouter des éléments dans l'API, mais il est vraiment difficile de supprimer quoi que ce soit (sans casser certains clients). Ainsi, vous faites très attention lorsque vous ajoutez quoi que ce soit dans l'API. C'est pourquoi il peut y avoir des fonctions supplémentaires (pour les tests, en développement, un hack rapide?) Dans l'API, qui ne sont pas documentées et sans garantie de travailler ou d'être là dans la prochaine version.

Ces fonctions non documentées peuvent être trouvées assez facilement, étant donné que vous savez comment fonctionnent les compilateurs, les éditeurs de liens, les bibliothèques et les débogueurs (programmation système). La connaissance du langage d'assemblage de l'architecture cible ne fera pas de mal. Si votre IDE / compilateur peut créer des exécutables qui fonctionnent, vous pouvez également le faire "manuellement", et en gardant les yeux ouverts sur ce chemin, vous découvrirez peut-être des fonctionnalités cachées :)

Exemple dans un environnement Unix: Un scénario où nous n'avons de documentation que pour la fonction printf et aimerions savoir s'il existe d'autres fonctions semblables à printf . Le train de pensée pourrait aller quelque chose comme:

1. Vérifier les fichiers d'en-tête

$ grep printf /usr/include/stdio.h | head -5
extern int fprintf (FILE *__restrict __stream,
extern int printf (__const char *__restrict __format, ...);
extern int sprintf (char *__restrict __s,
extern int vfprintf (FILE *__restrict __s, __const char *__restrict __format,
extern int vprintf (__const char *__restrict __format, _G_va_list __arg);

2. Vérifier la bibliothèque

$ nm /usr/lib/libc.a | grep printf | head -5
         U __asprintf
         U __fwprintf
         U __asprintf
         U __fwprintf
         U __printf_fp

3. Démonter la fonction de bibliothèque

    $ objdump -S /usr/lib/libc.a | grep -A 10 '_fwprintf' | head
00000000 <__fwprintf>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   8d 45 10                lea    0x10(%ebp),%eax
   6:   83 ec 0c                sub    $0xc,%esp
   9:   89 44 24 08             mov    %eax,0x8(%esp)
   d:   8b 45 0c                mov    0xc(%ebp),%eax
  10:   89 44 24 04             mov    %eax,0x4(%esp)
  14:   8b 45 08                mov    0x8(%ebp),%eax
  17:   89 04 24                mov    %eax,(%esp)

Ou quelque chose comme ça...

Avertissement: j'aime la réponse de ChrisF. Cela laisse de côté quelques approches, je pense. S'il est placé dans les commentaires de la réponse sur la façon dont ils sont couverts, je supprimerai ma réponse.

Il pourrait en quelque sorte tomber sous décompilation:

La recherche d'autres API non documentées peut également se faire par le débogage d'un outil fourni par le fournisseur qui fait ce que vous voulez et le suivi des appels entre bibliothèques. De cette façon, vous pouvez avoir une idée du type de données envoyées à quel endroit.

D'autres outils "personnalisés" peuvent ensuite être écrits pour jouer avec ces API non documentées en utilisant python et CTYPES ou ruby ​​avec sa version de quelque chose de similaire jusqu'à ce que vous découvriez exactement ce qu'il fait ou fuzzing pour les plantages. Ce sujet est traité en profondeur par Aaron Portnoy dans le: http://pentest.cryptocity.net/reverse-engineering/ et certains de ses autres discours lors de conférences (je semble me souvenir qu'il en parle directement lors d'un discours au Brésil ). Il est lié à RE, mais je ne pense pas que ce soit exactement juste RE général. Remarque: les vidéos sur pentest.cryptocity.net ne sont PAS SEULEMENT ce sujet. Ils couvrent d'autres domaines plus en profondeur, c'est juste abordé. Je pense que c'est souvent quelque chose que les testeurs gardent car "les étapes exactes seraient de révéler nos secrets".

Merci d'avoir lu tous les commentaires appréciés.

edit: un outil qui peut s'avérer utile pour cela du côté des fenêtres est couvert de manière minimale ici: http://breakingcode.wordpress.com/2010/08/24/winappdbg-1-4-is-out/
détournement d'appel pour java épais clients aux services réseau personnalisés fuzz sont couverts ici:
http://www.securitytube.net/JavaSnoop-How-to-hack-anything-written-in-Java-video.aspx

ce dernier n'est que d'une pertinence minimale, mais pourrait s'avérer pertinent pour savoir où le questionneur va finalement. en utilisant des API que vous ne possédez pas pour faire ... peu importe.

Le piratage semble assez romantique, l'espionnage industriel, les fuites, les pots-de-vin, le vol et la chance ordinaire ne le font pas. Je ne les compterais pas cependant.