Come vengono scoperte le funzioni non documentate? [chiuso]

Mi sono sempre chiesto come trovi API non documentate / private ?

Esempio di API non documentate / private Apple , Play Station , Windows Phone 7 , kernel Win32 , API di Windows , callback nascosto , ecc ...

Quali strumenti usano gli hacker per scoprire funzioni private e non documentate?

Dove posso leggere le esperienze delle persone approfondendo le API private e le tecniche di reverse engineering che rivelano i segreti che sono normalmente spiegati nella documentazione delle API?

grazie,
A

Ci sono un paio di modi a cui posso pensare:

1. Riflessione. Qui ottieni un oggetto e gli chiedi di rivelare informazioni su se stesso, come metodi, proprietà, ecc. Con le giuste opzioni (a seconda della lingua) puoi rivelare informazioni che non sono "pubbliche".

2. Decompilazione. Questo rigenera (una versione) del sorgente usato per creare il binario. Ancora una volta questo potrebbe rivelare parti non pubbliche dell'API.

È inoltre possibile aggiungere "per caso" all'elenco. Una chiamata / comando errato che funziona o una schermata di aiuto che rivela troppe informazioni.

Strumenti normali che usi per sviluppare software :)

Di solito le funzioni API non documentate sono solo segreti nascosti e non documentati .

Progettare un'API a prova di futuro è difficile: puoi facilmente aggiungere elementi all'API, ma è davvero difficile rimuovere qualsiasi cosa (senza rompere alcuni client). Quindi, fai molta attenzione quando aggiungi qualcosa nell'API. Ecco perché potrebbero esserci alcune funzioni extra (per test, in sviluppo, un hack rapido?) Nell'API, che non sono documentate e senza garanzie di funzionamento o presenza nella prossima versione.

Queste funzioni non documentate possono essere trovate in qualche modo facilmente, dato che sai come funzionano compilatori, linker, librerie e debugger (roba di programmazione del sistema). Conoscere il linguaggio di assemblaggio dell'architettura target non farà male. Se il tuo IDE / compilatore è in grado di creare eseguibili funzionanti, puoi farlo anche "manualmente" e, tenendo gli occhi aperti su quel percorso, potresti scoprire alcune funzionalità nascoste :)

Esempio in ambiente Unix: uno scenario in cui abbiamo documentazione solo per la funzione printf e vorrei sapere se ci sono altre funzioni simili a printf . Il treno del pensiero potrebbe andare come:

1. Controlla i file di intestazione

$ 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. Controlla la libreria

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

3. Disassemblare la funzione di libreria

    $ 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)

O qualcosa di simile...

disclaimer: mi piace la risposta di ChrisF. Tralascia un paio di approcci, credo. Se viene inserito nei commenti alla risposta su come sono coperti, eliminerò la mia risposta.

Potrebbe cadere in una sorta di decompilazione:

La ricerca di altre API non documentate può anche avvenire tramite il debug di uno strumento fornito dal fornitore che fa il tipo di ciò che si desidera e il monitoraggio delle chiamate interbibliotecarie. In questo modo, puoi avere un'idea di quale tipo di dati viene inviato a dove.

Altri strumenti "personalizzati" possono quindi essere scritti per giocare con queste API prive di documenti usando python e CTYPES o ruby ​​con la sua versione di qualcosa di simile fino a quando non scopri esattamente cosa sta facendo o fuzzing per gli arresti anomali. Questo argomento è trattato in modo approfondito da Aaron Portnoy in: http://pentest.cryptocity.net/reverse-engineering/ e alcuni altri suoi discorsi alle conferenze (mi sembra di ricordare che ne parla direttamente durante un discorso in Brasile ). È correlato a RE, ma non penso che sia esattamente solo RE generale. Nota: i video su pentest.cryptocity.net non sono SOLO questo argomento. Coprono altre aree in modo più approfondito, questo è appena toccato. Penso perché è spesso qualcosa che i tester custodiscono come "i passi esatti sarebbero rivelare i nostri segreti".

Grazie per aver letto qualsiasi feedback apprezzato.

modifica: uno strumento che può rivelarsi utile per questo sul lato di Windows è trattato minimamente qui: http://breakingcode.wordpress.com/2010/08/24/winappdbg-1-4-is-out/
call hijacking per thick java i client per fuzz servizi di rete personalizzati sono coperti qui:
http://www.securitytube.net/JavaSnoop-How-to-hack-anything-written-in-Java-video.aspx

l'ultimo è solo minimamente rilevante, ma potrebbe rivelarsi pertinente a dove sta andando l'interrogante. usando le API che non possiedi fare ... comunque.

L'hacking suona piuttosto romantico, lo spionaggio industriale, le perdite, le tangenti, i furti e la semplice fortuna no. Non li conterei però.