najlepsza praktyka dostarczania ukrytych funkcji wewnętrznych C API

Question

Napisałem bibliotekę C, która składa się z kilku plików .h i plików .c. Kompiluję go jako bibliotekę statyczną .a.

Chciałbym ujawnić użytkownikowi tylko niektóre funkcje, a resztę pozostać tak "mało zrozumiałą", jak to tylko możliwe, aby inżynieria wsteczna była dość trudna.

Idealnie moja biblioteka będzie składać się z:

1- jednym pliku .h tylko z funkcji narażonych użytkownikowi

2- myLibrary.a: jak un-reversengineerable możliwie

Co czy są to najlepsze praktyki? Gdzie powinienem szukać, czy jest gdzieś dobry poradnik/książka?

Dokładniej:

za - 1

mam już całe .h i .c pracy i chciałabym uniknąć zmieniając je dookoła, poruszając deklaracje funkcji z .h do .c i przejść do okrągłych odniesień potencjalnych pbs. Czy to jest możliwe?

Na przykład to jest dobry pomysł, aby utworzyć nowy plik .h, którego użyłbym tylko do dystrybucji z moim .a? To .h będzie zawierać kopie funkcji, które chcę eksponować i przekazywać deklaracje typów, których używam. Czy to dobry pomysł?

za - 2

a) co gcc flagi (lub Xcode) będę świadomy (do rozbiórki, nie mając symbole debugowania itp) b) dobry wskaźnik, aby dowiedzieć się, jak zrobić kodu zaciemniania?

Każda myśl pomoże,

Dzięki, baba

Answer 1

Powszechnie stosowaną praktyką jest upewnienie się, że każda funkcja i zmienna globalna, która jest przeznaczona tylko do użytku wewnętrznego dla niektórych modułów, jest zadeklarowana w tym module jako static. To ogranicza ekspozycję wewnętrznych szczegółów implementacji z jednego modułu.

Jeśli potrzebujesz wewnętrznych szczegółów implementacji, które znajdują się pomiędzy modułami, ale które nie są przeznaczone do publicznej konsumpcji, zadeklaruj jeden lub więcej plików .h, które są prywatne i nie są dostarczane użytkownikom końcowym. Nazwy obiektów zdefiniowanych w ten sposób będą nadal widoczne dla łącznika (i dla narzędzi takich jak objdump i nm), ale ich szczegółowe podpisy nie będą.

Jeśli masz strukturę danych, która jest dostarczana do użytkownika końcowego, ale która jest nieprzezroczysta, następnie rozważ, czy interfejs API dostarcza je jako wskaźniki do struct, który jest zadeklarowany przez nie zdefiniowany w publicznym pliku API .h. Pozwoli to zachować bezpieczeństwo typu, jednocześnie ukrywając szczegóły implementacji. Oczywiście pełna definicja struct znajduje się w prywatnym pliku .h.

Ostrożnie można zachować częściowo udokumentowany publicznie znany numer struct, który jest typową kalamburem dla prawdziwej definicji, ale który tylko eksponuje członków publicznych. Jest to trudniejsze do uaktualnienia, a jeśli to zrobisz, upewnię się, że istnieją pewne silne przypadki testowe, które potwierdzają, że wersja publiczna jest w rzeczywistości odpowiednikiem wersji prywatnej pod każdym względem, która ma znaczenie.

Naturalnie, użyj strip, aby usunąć segmenty debugowania, aby wewnętrzne szczegóły nie wyciekły w ten sposób.

Istnieją narzędzia, które mogą zaciemnić wszystkie nazwy przeznaczone wyłącznie do użytku wewnętrznego. Jeśli jest uruchamiany jako część procesu kompilacji, możesz pracować z wewnętrzną kompilacją debugowania, która ma sensowne nazwy dla wszystkiego, i wysłać kompilację, która nazwałaby wszystkie wewnętrzne funkcje i zmienne globalne nazwami, które tylko linker może kochać.

Wreszcie, przyzwyczaić się do tego, że każda osoba, która może użyć biblioteki będzie w stanie w pewnym stopniu wykonać inżynierię wsteczną. Istnieją środki antydebuggerowe, które mogą być podjęte, ale w ten sposób IMHO polega na szaleństwie i frustracji.

Answer 2

Usuwanie nagłówków dla tej funkcji, zrobić kilka zaciemniania w tabeli eksportu i się spakować swój kod i zastosować jakiś algorytm anty debuggera.

http://upx.sourceforge.net/

http://www.oreans.com/

Answer 3

nie mam szybką odpowiedź inną niż do zbadania możliwości korzystania z funkcji "statyczne". Poleciłbym czytać prace Miro Samka o czymś, co nazywa "C +". Zasadniczo zorientowany obiektowo ANSI C. Świetna lektura. Jest właścicielem oprogramowania do skoków kwantowych.