Klasa C++ w kodzie maszynowym

Witam,
Sprawa wygląda tak - mam deklarację interfejsu i dlla, który przypuszczalnie z tego kożysta. Chciałbym znaleźć kod tej klasy i wiedzieć gdzie są zaimplementowane poszczególne metody (wirtualne). Cel: sprawdzenie czy ktoś komu podam deklarację mojego interfejsu w prosty sposób znajdzie implementację kodu na ukryciu którego mi zależy.

Jak to zrobić? Używam OllyDbg.

Cel: sprawdzenie czy ktoś komu podam deklarację mojego interfejsu w prosty sposób znajdzie implementację kodu na ukryciu którego mi zależy

Jasne, że znajdzie...

...ale zaraz, Ty kod maszynowy chcesz ukrywać? Po jaką cholerę?

Bo to jest kod którego modyfikacji chcę uniknąć. Nie chcę żeby jakiś typek mi modyfikował to prostą delegacją (nowa klasa która przerabia jedną funkcję a resztę odsyła do oryginalnej).
Chciałbym tylko wiedzieć jak "oni" to znajdują, a o to żeby znalezienie implementacji metody niewiele dało już sam zadbam.

Nie ma jedynej słusznej metody - mając dostęp do instancji klasy ma się vtable podane na tacy. Poza tym nie eksportujesz przypadkiem metod bezpośrednio? Ta metoda robi coś konkretnego? Bo po samych odwołaniach do API, stringów etc. można ją zlokalizować wtedy...

Zadbasz o ochronę przed crackerami? Znaczy się co, kupujesz protector? Jak tak to faktycznie się zastanów przy wyborze, bo inaczej odstraszysz tylko kilku leszczy. Jak nie - wrzuć swoje rozwiązanie na forum, zobaczymy co to warte.

Ogólna idea jest taka że robię interfejs wtyczkowy. Wtyczki <ort>kożystają </ort>z mojego "systemu". Oprócz tego są też moje "podsystemy" które wtyczka może ładować na zasadzie CreateInterface (ale to nie jest COM, po prostu funkcja zwraca void* klasy implementującej interfejs który zna autor wtyczki). Te podsystemy są w osobnych dllach i obawiam się że jakiś za przeproszeniem ktoś zrobi własnego dlla na podstawie mojego i delegując go "przeciąży" funkcję np. odpowiedzialną za reklamy.

Wiem że to głupie i to nie jest projekt komercyjny ale jak się starałem o pracę to mi kazali szukać sposobów na zabezpieczanie aplikacji. Na uczelni się tego nie nauczę a jak będę to umiał to następnym razem może się uda z pracą.

Napisałem prosty projekt w Visualu, uruchomiłem debugger i włączyłem okno kodu maszynowego, bo on tam pokazuje linijki kodu. Zauważyłem że jest taka sekcja:

@ILT+395(_strncpy):
00281190  jmp         strncpy (281B0Ch) 
@ILT+400(__decode_pointer):
00281195  jmp         _decode_pointer (283ADCh) 
@ILT+409(__invoke_watson):
0028119A  jmp         _invoke_watson (283AC4h) 
CTest::A:
0028119F  jmp         CTest::A (2815D0h) 
_RTC_GetSrcLine:
002811A4  jmp         _RTC_GetSrcLine (2834F0h) 
@ILT+420(__CRT_RTC_INITW):
002811A9  jmp         _CRT_RTC_INITW (282BB6h) 
@ILT+425(_GetTickCount@0):
002811AE  jmp         GetTickCount (283B48h) 
@ILT+430(__IsNonwritableInCurrentImage):
002811B3  jmp         _IsNonwritableInCurrentImage (283340h) 
@ILT+435(_HeapAlloc@12):
002811B8  jmp         HeapAlloc (283B66h) 
@ILT+440(__amsg_exit):
002811BD  jmp         _amsg_exit (2830E0h) 
@ILT+445(__XcptFilter):
002811C2  jmp         _XcptFilter (283208h) 
@ILT+450(__CrtSetCheckCount):
002811C7  jmp         _CrtSetCheckCount (28321Ah) 
@ILT+455(_InterlockedExchange@8):
002811CC  jmp         InterlockedExchange (283AE8h) 
@ILT+460(_UnhandledExceptionFilter@4):
002811D1  jmp         UnhandledExceptionFilter (283B36h) 
CTest::B:
002811D6  jmp         CTest::B (281660h) 
type_info::type_info:
002811DB  jmp         type_info::type_info (281A30h) 

Wywołanie z kodu skacze tutaj a dopiero z tąd do właściwego kodu. Co to jest? Czy jest jakaś zasada na podstawie której można tu znaleźć CTest::A() nie wiedząc gdzie jest wywoływane?

tablica importów ?

Chciałbym tylko wiedzieć jak "oni" to znajdują, a o to żeby znalezienie implementacji metody niewiele dało już sam zadbam.

ciekawe,, chcesz ukryć coś czego nie możesz znaleźć .. [green]

Aha, znaczy kolega z TlenTeam?

A poważnie - akurat debugger Visuala podaje informacje zwykle niedostępne reverse engineerowi podczas analizy. Mimo wszystko zwracany interface można przedebugować, na spokojnie pod disassemblerem obejrzeć i ustalić co jest co, za co odpowiada itd.

http://4programmers.net/Forum/viewtopic.php?id=149972 - mały przykład, jak łatwo się wtyczki itd. rozkłada. Różnica jest taka, że u Ciebie nazwy metod z vtable nie będą znane, ale wierz mi, to nic nie zmienia w praktyce.

Zabezpieczenie to bardzo trudna sprawa - w końcu ten kod musi się wykonać, musi także zostać wywołany, prawda? Napisz co dokładnie chcesz osiągnąć w tej kwestii, i jak wiele pracy/dodatkowych narzędzi byłbyś gotów w to włożyć. Jak widać po grach - nawet najlepsze i najbardziej zaawansowane zabezpieczenia gwarancji nie dają.

Generalnie to tak:

• utrudnić użycie debuggera (wykrywanie, blokowanie itd.) - trudniej grzebać;
• obfuskacja kodu - przestanie być czytelny (czytelny dla tej nienormalnej części ludzkości przynajmniej);
• podpisywanie plików - trudniej podmienić;
• sumy kontrolne itd. - trudniej zmodyfikować (także w pamięci)
  ...a każdy element ma słabe punkty.

@dzejo, to nie importy - część z nich to elementy wlinkowane w binarkę bezpośrednio, poza tym calle do importów są grupowane w podobny sposób jak elementy IAT. Trudno powiedzieć co to bez dokładniejszego obejrzenia binarki. Poza tym to, że autor tego znaleźć nie potrafi...