Fanatyk LEGO Island nie powiedział jeszcze ostatniego słowa.

  • naur@tech.pr0n.plMPolski
    1·
    3 days ago

    Dekompilacja tej gry została wykonana bez dostępu do pilków symboli?
    Nieźle, większość takich projektów powstaje na podstawie wycieków developerskiego builda.

    • サぺル@tech.pr0n.plPolski
      1·
      3 days ago

      Przecież ludzie siedzą przy narzędziach do rewersu i starają się sami zrozumieć, nadając odpowiednie nazwy funkcjom. Jeśli coś zostało napisane z użyciem popularnych bibliotek, frameworku lub silnika, to ułatwia.

      • naur@tech.pr0n.plMPolski
        1·
        1 day ago

        Tak, ludzie siedzą nad takimi grami, ale to wymaga ogromnego samozaparcia.

        Stare gry mają chyba stosunkowo mało kodu opartego na zewnętrznych zależnościach.
        Zdecydowana większość funkcji zawiera pewnie implementację “gameplayu”.

        Popatrz chociażby na ten plik. Nie ma tam prawie wcale wywołań zewnętrznych API. Pomijając kilka odwołań do stringów, cała logika opiera się na żonglowaniu wartościami liczbowymi i flagami.
        Jak rozpoznałbyś w tych regułach zachowanie określonego typu przeciwnika?

        Na dodatek spora część gier jest oparta na customowej maszynie wirtualnej i kod trzeba analizować na dwóch “poziomach abstrakcji”. Wtedy nawet standardowy debugger ma ograniczoną użyteczność.

        • サぺル@tech.pr0n.plPolski
          1·
          1 day ago

          Uznałem, że skrypty i vm ułatwiają. Wymagają interfejsów, które są bardziej czytelne.

          Oglądałem kiedyś jakąś sesję dekompilacji gry. Nie starano się tam dokładnie wszystkiego rozpracować. Rozpracowywano to co byli w stanie/co było potrzebne. To czego nie byli, oznaczali jako niewiadoma z sugestiami, że jakieś wartości powodują coś. Ale nie wiadomo z czego to wynika.

          W przykładzie który podałeś ułatwieniem są entity. Trzeba śledzić wartości i patrzyć co powoduje zmiany podczas gry.

          • naur@tech.pr0n.plM
            1·
            1 day ago

            VM jest ułatwieniem, jeśli masz rozpracowane opcode’y i narzędzia do analizy.
            Do tego czasu analiza jest moim zdaniem znacznie trudniejsza, bo widzisz funkcje, które przetwarzają jakiś strumień danych (w postaci wirtualnego kodu maszynowego).

            Nie wiem, czy już kiedyś to wklejałem (wyszukiwarka niczego nie znalazła), ale widziałem ostatnio ciekawe rozwiązanie do RE gier dosowych.
            Kolesie napisali w C# emulator i debugger trybu rzeczywistego x86 z możliwością przekierowania wywołań kodu do funkcji C#.

            • サぺル@tech.pr0n.plPolski
              1·
              24 hours ago

              @lacky mógłby opowiadać, ale chyba zagląda tu raz na miesiąc.

              Jakiś rozpieszczony ostatnio jesteś jeśli chodzi o re. Zdeterminowany człowiek będzie czytał deasm jak książkę, na poziomie abstrakcyjnych powtarzalnych bloków i idiomów. Bo chyba sam nie masz problemu ze zrozumieniem wygenerowanego asma z własnego kodu?

              • Lacky@tech.pr0n.plOP
                1·
                12 hours ago

                Już częściej ;-) Miałem ostatnie 1-2 miesiące mocno napięty grafik. Ciężko mi polecić cokolwiek konkretnego nakierowanego na RE w DOS. Chyba jedynie debugger wbudowany w Dosbox.