Problem z Hex edytorem
 

Witam wszystkich forumowiczów ... tak, mam kolejny problem. Tym razem nietypowy, a pytanie kieruję do "znafcóf" :D

Już przechodze do meritum
Wyobraźcie sobie, że mam plik. Otwieram ten plik w Hex edytorze (korzystam z hex workshop'a).

Powiedzmy, że mamy takie coś:
4023 2523 2424 235E 2425 5E26 2425 4241
445A 4957 4945 265E 2A5E 2A5E 262A 2123
2140 2321 4023 262A 3739 2600 0000 0000

Posługując się opcją replace podmieniam "4241 445A 4957 4945" na "4241 445A 4945 5749 45"
W efekcie całość mi się przesuwa o offset w dól a program nie działa :(

Co z tym fantem zrobić? (plik jest bardzo duży, a ja już nie pamiętam gdzie się pomyliłem, także go nie wytnę).

Temat jest dla mnie naprawdę bardzo ważny. Dobrzy ludzie pomóżcie [!]

Chodzi tylko o znalezienie tej pomyłki? - Jeżeli tak to kombinuj;). No kurcze, nie wiem, otwórz stary i nowy plik i w nowym wyszukuj ciągi które zmieniałeś i porównuj wartości i pozycje (no jeżeli nie pamiętasz co na co zmieniałeś to nie poradzę).

Plik ma prawie 300MB.

Nie, nie,.. chodzi mi o to by program działał (w sumie to nie jest program, ale mniejsza o to) :) Bez szukania tego offset'u. Słyszałem coś o zmianie jakiś sum kontrolnych, ale ja się na tym wogóle nie znam.

Plik ma pewnie w sobie moduł CRC. Wylicza sume kontrolną pliku np. X921387X817283 [przykład ;p] i jak zmienisz jeden bit to od razu zmiana jest wykrywana i program się nie uruchamia lub działa niepoprawnie bo procedura jest wykonywana na samym początku programu. Coś w stylu niezgodności treści programu z nagłówkiem.
Ale jak to obejść to nie mam pojęcia..

@Piterniel
To mnie zmartwiłeś :(

Ok. to nie jest program. To jest zbiór plików upakowanych jakimś goownem. Program się do tego odwołuje (w moim przypadku gra). Jest tam wszystko od muzyki, tekstur, aż po txt.

Wziąłem się za tłumaczenie tej gry i w hex'ie zmieniam, podmieniam znaki (inaczej nie potrafię). Pomyliłem się i niezauważyłem, że plik zmienił swoją objetość.

Teraz doopa bo nie wiem nawet jak znaleźć błąd a porównywanie wszystkich offset'ów jest ponad moje siły (300MB).

Może to nie jest koniecznie CRC :)
Ale przy edytowaniu w Hex rozmiar nie może się zmienić. Jeżeli się zmieni cały program się wyypuje...
[ http://emu.makii.pl/zapytaj.php3?akcja=answer&id=33 ] - Tutaj może coś znajdziesz ciekawego
Polecam ksiązke, tylko nie wiem gdzie ją znaleść :)
http://www.lideria.pl/img_big/31652.jpg

Piterniel

:D Jak to gdzie? :D

- dzieki

hmm... jeżeli Berion mówi (pisze), że to nie jst program czyli plik wykonywany to wydaje mi się że nie może sprawdzać swoich sum kontrolnych, ale to tylko moje domysły może to ktoś potwierdzi lub zaprzeczy.... :) ja uważam, że poprostu Berion poprełnił błąd i zamienił złe dane i dlatego to coś ;) nie śmiga...

Mogą występować CRC w romach np. do GameBoy a w lepszych konsolach prawie napewno są :)

Wystarczy, że jest byle jaki skok w programie (lub jak tu - do niego) i już nie będzie hulać, poza tym przesunięcie całości o jeden bajt zrobi z programu lub pak'a totalną sieczkę, chyba że nie kompilowany skrypt.

@Berion chyba nie zmieniałeś tego w 50 różnych miejscach - nie wiem czy jest opcja wyszukaj w hexWorkshop - chyba powinna. Jak nie - mówi się trudno.

Ps. Inny pomysł - jeżeli teksty są w kupie spróbój skrócić ostatni, zobacz też czy nie są przedzielane jakiąś szczególną wartością - jeżeli tak to wstaw ją gdzieś w środku tekstów - wyjdą bzdury, ale jak będzie działał prog to łatwiej znajdziesz błąd.

A więc dokładnie sprawa wygląda tak:
Jest to gra na PSX'a.

Bigfile*.big -> w tym badziewiu jest wszystko, od txt aż po gfx. Edytując go, gdzieś się pomyliłem, ale gdzie i przy jakich znakach nie pamiętam.

resztę plików pominę bo nie są istotne...

*.exe -> żądzi wszystkim, odwołuje się do poszczególnych plików (czyli standard). Obawiam się że odwołuję się również do określonych offset'ów w bigfile'u (bo raczej wątpię, aby szukał pliku po nagłówku, PSX ma tylko 2RAM i ~33MHz procesor) i dlatego nie działa :(

pliki tekstowe (czy jak tam je nazwać, nie wiem) na konsolach wyglądają tak:

FF-> koniec linijki
00 -> przerwa
0D -> przerwa lub kolejne "okienko dialogowe"

@MQs
Jest (ctr+F) tyle, że ja nie wiem czego szukać :(

No, ale ja też nie wiem ;) (tego co zmieniałeś).

Nie wiem czy słusznie założyłem, że:
- znasz rozmiar pierwotnego pliku co do bajta (jeżeli nie to nawet nie czytaj dalej i powiedz papa plikowi, chyba że metoda "prób i błędów"+"na oko")
- zmieniałeś teksty lub wiesz jaki ciąg wpisywałeś,
- masz pierwotny plik (i jeżeli to nie tekst i nie wiesz co wpisałeś wiesz przynajmniej jaki ciąg nadpisałeś),
- tylko w jednym miejscu jest błąd (jeżeli nie sposób (2) ma szansę zadziałania tylko przy wariancie wszystkich tekstów w jednej "sekcji")

Sposów (1) - Spełnione trzy piewsze założenia:
wtedy tego masz szukać co zmieniałeś/nadpisywałeś (no, chyba że to tekstowa gra typu Fallout :) ) i porównanie w danym miejscu (adresie) wartości za zmianą

Sposób (2): Pod warunkiem, że zmieniałeś teksty, które są wszystkie razem, albo ew. w kilku tylko miejscach - nazwę to "sekcjach":
W (tylko) jednej z "sekcji" (może być potrzeba sprawdzać dla każdej "sekcji") tekstowej wyciąć literki (najlepiej końcowe) do rozmiaru pierwotnego pliku - jest szansa że program będzie chodził - ustawią się adresy skoków do "sekcji" nie tekstowych, a teksty są czytane od adresu skoku do znaku końca tekstu, a nie od nagłówka do nagłówka. Co do nagłówka (0D) - może być też potrzeba dodania go na końcu sekcji (np. jeżeli w innych sekcjach są)

Temat wyczerpany. Cudów nie ma. Pozdrawiam.

Jasne, że znam. Mam go jeszcze przed modyfikacją (kopia)

Problem w tym, że bardzo dużo zmian wprowadzałem i nie jestem w stanie określić co dokładnie, tym bardziej w którym miejscu.

Raczej tak ... Różnica dwóch bajtów, ... czyli jeden znak?

Hmm... tyle, że plik wygląd mniej więcej tak:

coś-coś-txt-coś-txt-coś-coś-txt-coś

Jeśli zmiany dotyczyły tylko "pierwszego txt", skoro się tam pomyliłem to wycięcie jakiegoś 00 na koncu pliku chyba nic nie da (o ile dobrze Ciebie zrozumiałem).

Hmm... ... zgadzam się z drugim stwierdzeniem :)

Chodzi o to, że trzeba usunąć końcówkę tekstu w tym "txt", gdzie może być błąd, a nie pliku. Jeżeli jest dużo tych oddzielnych "txt" to dałbym spokój - sposób dosyć niepewny.

Ps. Dwa bajty to dwa znaki (ASCII), chyba że jakieś inne kodowanie.

hmm... dam chyba za wygraną :(

ehh... trudno. Dzięki wszystkim!