Come vengono scoperte le funzioni non documentate? [chiuso]

Ci sono un paio di modi in cui posso pensare:

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

2. decompilazione. Questo rigenera (una versione) della fonte utilizzata per creare il binario. Anche in questo caso potrebbe rivelare parti non pubbliche dell'API.

Potresti anche aggiungere "per sbaglio" alla lista. Un call / comando fallito che funziona o una schermata di aiuto che rivela troppe informazioni.

Strumenti normali che utilizzi per sviluppare software:)

Solitamente le funzioni API non documentate sono solo quelle, non documentate e non nascoste con cura.

Progettare un'API a prova di futuro è difficile - puoi facilmente aggiungere cose nell'API, ma è davvero difficile rimuovere qualsiasi cosa (senza rompere alcuni client). Quindi, stai molto attento quando aggiungi qualcosa all'API. Ecco perché potrebbero esserci alcune funzioni extra (per testare, in fase di sviluppo, un attacco rapido?) In API, che non sono documentate e non hanno garanzie di lavorare o di essere presenti nella prossima versione.

Queste funzioni non documentate possono essere trovate abbastanza facilmente, dato che sai come funzionano compilatori, linker, librerie e debugger (materiale di programmazione di sistema). Sapere che il linguaggio di assemblaggio dell'architettura di destinazione non farà male. Se il tuo IDE / compilatore può compilare eseguibili funzionanti, puoi farlo anche manualmente, e tenendo gli occhi aperti su quel percorso potresti scoprire alcune caratteristiche nascoste:)

Esempio in ambiente Unix: uno scenario in cui abbiamo documentazione solo per la funzione printf e vorrei sapere se ci sono altre funzioni printf -like. Il treno del pensiero potrebbe essere qualcosa del tipo:

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 libreria

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

3. Disassembla 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 del genere ...

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

Potrebbe cadere sotto la decompilazione:

La ricerca di altre API non documentate può avvenire anche tramite il debug di uno strumento fornito dal fornitore che esegue il tipo di ciò che si desidera e il tracciamento delle chiamate interbibliote. 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 non documentate usando python e CTYPES o ruby con la sua versione di qualcosa di simile fino a quando non si scopre esattamente che cosa sta facendo o si confonde con gli arresti anomali. Questo argomento è trattato in modo approfondito da Aaron Portnoy nel: link e alcuni dei suoi altri discorsi a conferenze (mi sembra ricordare che ne parla direttamente in un discorso in Brasile). È collegato 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 viene semplicemente toccato. Penso perché è spesso qualcosa che i tester guardano come "i passi esatti darebbero via i nostri segreti".

Grazie per aver letto qualsiasi feedback apprezzato.

modifica: uno strumento che può rivelarsi utile per questo dal lato Windows è coperto in minima parte qui: link
il dirottamento delle chiamate per i client thick java ai servizi di rete personalizzati fuzz viene coperto qui:
link

quell'ultima è solo minimamente rilevante, ma potrebbe rivelarsi pertinente a dove finirà l'interrogante. utilizzando le API che non sei autorizzato a fare ... qualunque cosa.

L'hacking suona piuttosto romantico, spionaggio industriale, perdite, tangenti, furti e semplice fortuna no. Però non li conterei.