Kilka pytań o cracking

[sennin]

Witam wszystkich serdecznie, jako, ze jest to mój pierwszy post. Mam kilka pytań. Po pierwsze co się stało z crackerską sceną czemu nie działa strona ctrl-d,ani woodmann? Drugie pytanie jest poważniejsze i mam nadzieje, że znajdzie się ktoś kto pomoze.

Jak wiadomo mnemoniki asemblerowe tlumaczone sa na ich odpowiedniki szesnastkowe tzw opcody. Wiadomo tez, ze korzystając z wielopostaciowości języka i wskakiwania w srodek instrukcji można tworzyc samomodyfikujacy sie kod. Dla przykladu:

00400000: jmp 00400001
00400002: mov al,93

Wykonanie tej sekwencji spowoduje ze instrukcja mov al,93 zostanie zinterpretowana jako xchg eax,ebx. Gdyż instrukcja mov ma opcody: B0 93, natomiast z uwagi, że przeskakujemy pierwszy bajt zostaje nam 93 czyli własnie xchg eax,ebx.

Mam nadzieje, ze zbytnio nie gmatwam

Problem jest taki, że przygotowałem sobie malutkie crackme. Osiedziałem się chwile, żeby kilka linijek same się modyfikowało. I teraz chce to zakodzic. Oczywiście nie mgoe tego zrobić w RadAsm, gdyz na moje oko tammoge zrobic jmp etykieta, a nie jmp adres. W RadAsm wiec dalem sobie troche nopów. Odpaliłem Olly'ego i wstukałem w miejsce nopów te instrukcje. Po naciśneiciu ctrl-A (analiza kodu). Olly robi, no rzeczy dziwne. Nici z smc w kazdym razie. Pomyslalem ze oszukam olly'ego i wstukalem w mijesca tych nopow odpowiednie wartosci bezposrednio w HexEdytorze, ale wtedy Olly zinterpretowal to tak jak bylo czyli bez efektu SMC (samomodyfikowalnosci kodu) a zbedne bajty wykryl jako dane:

db 83
db f0

itd

Takze bardzo nie dobrze. Zauwazylem ze wszystko w ollym jest ok pokazuje instrukcje tak jak trzeba nawet najbardziej kosmiczne w stylu mov, eax, dword ptr[ebp + esi*8 + 25d5f5cch] zgodnie z tym jak je umyslilem opcodami ale zaczyna sie sypac w momencie napisania dowolnej instrukcji skoku (jmp, je, jnz, jg itd.). Jak olly wykryje odwolanie do srodka instrukcji automatycznie wszystkie pominiete bajty zmienia w dane a z reszty robi zwykle instrukcje i psuje w ten sposob caly efekt SMC:/

Mam nadzieje, ze ktos mnie zrozumie Pozdrawiam

PS. Dałem taki post także na innym forum, przepraszam jeśli głupio to wygląda, ale nei chce mi sie dwa razy pisać tego samego na inny sposób

[Eragon Argetlam]

Witam wszystkich serdecznie, jako, ze jest to mój pierwszy post. Mam kilka pytań. Po pierwsze co się stało z crackerską sceną czemu nie działa strona ctrl-d,ani woodmann?

Według mnie jest to dział o asembler a nie o crakingu. Polecałbym przeczytać faq Michała Semeniuka "Nim rozpoczniesz nowy wątek". A co do rzeczonych stronek to sam ich znaleźć nie moge, ale tobie polecam jeden miły adres: WWW.GOOGLE.PL

[ble34]

tak tak nieznam odpowiedzi to powiem że złe jest pytanie
sory ja niewiem ale musiałem to zkomentowac jakoś

[TQM]

Co do assemblera to duzo nie pomoge ale zwrocilbym uwage, ze zadales jedno pytanie (o strony) a drugie ehmmm... jst opis sytuacji ale nie ma pytania

Czy chodzi o to dlaczego olly sie tak zachowuje czy o cos innego? Prosciej chyba byloby znalezc kogos kto odpowie gdyby pytanie bylo zamkniete

Niestety tylko tyle moge poradzic. Dalej moja wiedza jest juz za mala.

[kaspsior]

..................... ...

[SARS]

a możesz mi napisać jaka instrukcja jest pod adresem 00400001 ?

[Nikow]

Jest przesunięcie skoku... od -128 do +127...

[wbart]

Samomodyfikujący się kod powoduje,że coś innego jest w pamięci,a czego innego się spodziewa debuger,dodatkowo niektóre debugery przejmują przerwanie int 03 i wstawiają jednobajtową instrukcję w kod tworząc breakpoint ,następnie zapamiętują adres wstawienia.Po wywołaniu przywracają odpowiednią wartość,np przestawiając int 03h za następną instrukcję.Zniszczy to samomodyfikujacy się kod powodując dziwne zachowanie.

Wydaje mi się,że problemy dla debugera może wywołać to,że wykonujący się kod jest w cache procesora,do którego debuger nie ma dostępu i jeżeli tam wystąpią instrukcje,których na podstawie pamięci nie przewidział debuger,to mogą nastąpić problemy(kiedyś dawno czytałem o wykorzystaniu tego do zakłócenia pracy debugera i częstości synchronizacji cache procesora oraz pamięci).

Nie wiem jaki wpływ na przerwanie int 01 może mieć samomodyfikujący się kod,ale pewnie tu też można jakoś zakłócić,zerując znacznik pracy krokowej.

Ogólnie to podobno niektóre os'y,programy antywirusowe itp traktują samomodyfikujący się kod wrogo i próbują go blokować.

[Nikow]

Samomodyfikujący się kod powoduje,że coś innego jest w pamięci,a czego innego się spodziewa debuger,dodatkowo niektóre debugery przejmują przerwanie int 03 i wstawiają jednobajtową instrukcję w kod tworząc breakpoint ,następnie zapamiętują adres wstawienia.Po wywołaniu przywracają odpowiednią wartość,np przestawiając int 03h za następną instrukcję.Zniszczy to samomodyfikujacy się kod powodując dziwne zachowanie.

Wydaje mi się,że problemy dla debugera może wywołać to,że wykonujący się kod jest w cache procesora,do którego debuger nie ma dostępu i jeżeli tam wystąpią instrukcje,których na podstawie pamięci nie przewidział debuger,to mogą nastąpić problemy(kiedyś dawno czytałem o wykorzystaniu tego do zakłócenia pracy debugera i częstości synchronizacji cache procesora oraz pamięci).

Nie wiem jaki wpływ na przerwanie int 01 może mieć samomodyfikujący się kod,ale pewnie tu też można jakoś zakłócić,zerując znacznik pracy krokowej.

Ogólnie to podobno niektóre os'y,programy antywirusowe itp traktują samomodyfikujący się kod wrogo i próbują go blokować.

Której wypowiedzi to dotyczy? Bo niczym tutaj nie zabłysnełeś...

[wbart]

Bo niczym tutaj nie zabłysnełeś...

Mam tak przez większość życia.Uczę się.

Której wypowiedzi to dotyczy?

A jakie były pytania?
Mam nadzieję,że dodając opis działania SMC(tak jak to rozumiem,zamiast odsyłać do google)bardzo Cie nie uraziłem i nie zostanę posądzony o nabijanie postów i odgrzewanie starych kotletów.
W przeciwnym razie banuj śmiało.