Jak wykrywane są nieudokumentowane funkcje? [Zamknięte]

Zawsze zastanawiałem się, jak znaleźć nieudokumentowane / prywatne API?

Przykład nieudokumentowanego / prywatnego interfejsu API Apple , Play Station , Windows Phone 7 , jądra Win32 , Windows API , ukrytego wywołania zwrotnego itp.

Z jakich narzędzi korzystają hakerzy, aby dowiedzieć się o funkcjach prywatnych i nieudokumentowanych?

Gdzie mogę przeczytać o doświadczeniach ludzi zagłębiających się w prywatne interfejsy API i techniki inżynierii odwrotnej, które ujawniają sekrety normalnie wyjaśnione w dokumentacji API?

dzięki,
A

Jest kilka sposobów, o których mogę myśleć:

1. Odbicie. Tutaj otrzymujesz obiekt i prosisz go o ujawnienie informacji o sobie, takich jak metody, właściwości itp. Dzięki odpowiednim opcjom (w zależności od języka) możesz ujawnić informacje, które nie są „publiczne”.

2. Dekompilacja Powoduje to regenerację (wersji) źródła użytego do utworzenia pliku binarnego. Ponownie może to ujawnić niepubliczne części interfejsu API.

Możesz również dodać „przypadkiem” do listy. Błędne połączenie / polecenie, które działa lub ekran pomocy, który ujawnia zbyt wiele informacji.

Normalne narzędzia, których używasz do tworzenia oprogramowania :)

Zwykle nieudokumentowane funkcje API to tylko nieudokumentowane i niezbyt starannie ukryte tajemnice.

Zaprojektowanie przyszłego API jest trudne - możesz łatwo dodawać różne elementy do API, ale naprawdę trudno jest cokolwiek usunąć (nie psując niektórych klientów). Dlatego bardzo ostrożnie dodajesz cokolwiek do API. Dlatego mogą istnieć dodatkowe funkcje (do testowania, rozwoju, szybki hack?) W API, które nie są udokumentowane i nie mają gwarancji działania lub bycia w następnej wersji.

Te nieudokumentowane funkcje można znaleźć dość łatwo, biorąc pod uwagę, jak działają kompilatory, konsolidatory, biblioteki i debuggery (programowanie systemu). Znajomość języka asemblera architektury docelowej nie zaszkodzi. Jeśli Twój IDE / kompilator potrafi budować działające pliki wykonywalne, możesz to zrobić również „ręcznie”, mając oczy otwarte na tej ścieżce, możesz odkryć pewne ukryte funkcje :)

Przykład w środowisku Unix: scenariusz, w którym mamy dokumentację tylko dla funkcji printf i chcielibyśmy wiedzieć, czy są jakieś inne funkcje podobne do printf . Ciąg myśli może przebiegać następująco:

1. Sprawdź pliki nagłówków

$ 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. Sprawdź bibliotekę

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

3. Zdemontować funkcję biblioteki

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

Czy jakoś tak...

zastrzeżenie: Podoba mi się odpowiedź ChrisF. Myślę, że pomija kilka podejść. Jeśli zostanie umieszczony w komentarzach do odpowiedzi, w jaki sposób są one objęte, usunę moją odpowiedź.

Może to w pewnym sensie ulec dekompilacji:

Znalezienie innych nieudokumentowanych interfejsów API może odbywać się również poprzez debugowanie narzędzia dostarczonego przez dostawcę, które wykonuje określone czynności i śledzenie połączeń międzybibliotecznych. W ten sposób możesz zorientować się, jaki typ danych jest wysyłany do miejsca.

Następnie można napisać inne „niestandardowe” narzędzia do grania z tymi nieudokumentowanymi interfejsami API za pomocą Pythona i CTYPES lub ruby ​​z jego wersją czegoś podobnego, dopóki nie dowiesz się dokładnie, co robi lub nie działa w przypadku awarii. Temat ten jest szczegółowo opisany przez Aarona Portnoya w: http://pentest.cryptocity.net/reverse-engineering/ i niektórych innych jego wystąpieniach na konferencjach (wydaje mi się, że pamiętam, że mówił o tym bezpośrednio podczas przemówienia w Brazylii ). Jest związany z RE, ale nie sądzę, że jest to po prostu ogólna RE. Uwaga: filmy na pentest.cryptocity.net nie są TYLKO tym tematem. Obejmują one inne obszary bardziej szczegółowo, jest to tylko poruszone. Myślę, że ponieważ jest to często coś, czego testerzy strzegą jako „dokładne kroki ujawniają nasze tajemnice”.

Dziękujemy za przeczytanie wszelkich docenionych opinii.

edycja: jedno narzędzie, które może okazać się przydatne do tego po stronie systemu Windows, jest minimalnie omówione tutaj: http://breakingcode.wordpress.com/2010/08/24/winappdbg-1-4-is-out/
przejmowanie połączeń dla grubej Java klienci korzystający z niestandardowych usług sieciowych Fuzz są tutaj:
http://www.securitytube.net/JavaSnoop-How-to-hack-anything-written-in-Java-video.aspx

ten ostatni jest jedynie minimalnie istotny, ale może okazać się istotny w odniesieniu do tego, dokąd ostatecznie zmierza pytający. używając interfejsów API, których nie masz do zrobienia ... cokolwiek.

Hakowanie brzmi dość romantycznie, szpiegostwo przemysłowe, wycieki, łapówki, kradzież i zwykłe szczęście nie. Nie liczyłbym ich jednak.