Dobra inżynieria oprogramowania a bezpieczeństwo

Question

Wytyczne Security and Design dokładają wszelkich starań, aby utrudnić atakującemu wdrożenie zasad fakturowania w aplikacji.

Szczególnie zauważalne jest to, jak łatwo można odwzorować plik .apk, nawet jeśli jest on zaciemniony przez Proguard. Dlatego nawet zalecają modyfikację wszystkich przykładowych kodów aplikacji, szczególnie "znanych punktów wejścia i punktów wyjścia".

Co znajdę brakuje wszelkie odniesienia do owijania pewnych metod weryfikacji w jednej metody, jak statycznej Security.verify() która zwraca boolean: Dobrą praktyką projektowania (kod zmniejszenie powielanie, wielokrotnego użytku, łatwiejsza do debugowania, samodokumentujące, etc .) ale wszystko, co atakujący musi teraz zrobić, to zidentyfikować tę metodę i sprawić, by zawsze zwracała true ... Tak więc bez względu na to, ile razy jej użyłem, opóźniłem lub nie opóźniłem, losowo lub nie, po prostu nie ma to znaczenia.

Z drugiej strony Java nie ma makr takich jak w C/C++, co pozwala ograniczyć duplikację kodu źródłowego, ale nie ma jednego punktu wyjścia dla funkcji verify().

więc moje pytania:

Czy istnieje nieodłączne rywalizacji pomiędzy znanymi inżynierii oprogramowania/praktyk kodowania i projektowania dla tzw zabezpieczeń? (w kontekście Java/Android/co najmniej bezpieczne transakcje)

Co można zrobić, aby złagodzić skutki uboczne "projektu dla bezpieczeństwa", który wydaje się "strzelanie sobie w stopę" pod względem nadmiernego komplikowania oprogramowanie, które mogłoby być prostsze, łatwiejsze w utrzymaniu i łatwiejsze do debugowania?

Czy możesz polecić dobre źródła do dalszego studiowania tego przedmiotu?

Answer 1

Jak zwykle, jest to kompromis. Uczynienie kodu trudniejszym do inżynierii wstecznej/pęknięcia powoduje, że staje się on mniej czytelny i trudniejszy w utrzymaniu. Ty decydujesz, jak daleko się posunąć, na podstawie przewidywanej bazy użytkowników, własnych umiejętności w obszarze, czasu/kosztów itp. Nie dotyczy to tylko systemu Android. Oglądaj this Google I/O presentation dla różnych etapów zaciemniania i zabezpieczania przed naruszeniem kodu. Następnie zdecyduj, jak daleko chcesz się posunąć w swoich własnych aplikacjach.

Z drugiej strony, nie musisz zaciemniać/stwardnieć, itp. wszystkie kodu, tylko część, która zajmuje się licencjonowaniem, itp. Jest to zazwyczaj bardzo mała część całego kodu i tak naprawdę nie musi się to często zmieniać, więc prawdopodobnie mógłbyś żyć z tym, że trudno to podążać/konserwować, itp. Po prostu zachowaj kilka uwag o tym, jak to działa, więc przypomnij sobie 2 lata później :).

Answer 2

Wydajność licznika, którą opisujesz, to wierzchołek góry lodowej ... Żadne oprogramowanie nie jest w 100% wolne od błędów w momencie premiery, więc co robisz, gdy użytkownicy zaczynają zgłaszać problemy?

W jaki sposób rozwiązywać problemy z polami lub rozwiązywać ich problemy po wyłączeniu rejestrowania, śledzenia stosów i wszelkich innych informacji, które pomagają inżynierom inżynierów odwrotnych, a także pomagają legalnym zespołom programistycznym?

Answer 3

Jakkolwiek trudne są metody zaciemniania, zawsze istnieje sposób ich odwrócenia. Chodzi mi o to, że jeśli twoje oprogramowanie zyska popularność wśród społeczności hakerskiej, w końcu ktoś spróbuje go odtworzyć.

Obfuskacja jest tylko metodą, która sprawia, że ​​proces inżynierii wstecznej jest trudniejszy.

Więc jest pakowanie.Myślę, że wiele metod pakowania jest dostępnych, ale tak samo jest z procesem ich inżynierii wstecznej.

Możesz sprawdzić www.tuts4you.com, aby zobaczyć, w jaki sposób dostępne są tony prowadnic.

Nie jestem ekspertem, jak wielu innych, ale to jest moje doświadczenie w procesie uczenia się inżynierii wstecznej. Niedawno widziałem wiele przewodników dla aplikacji z systemem Android w zakresie inżynierii wstecznej. Widziałem nawet w Nullc0n (nie jestem pewien) CTF, była tam aplikacja w Reversing Android. Jeśli chcesz, mogę wspomnieć o stronie po wyszukiwaniu.