🚀 go-pugleaf

W dniu 28.06.2011 18:47, Remek pisze:
> Witam
>
> Czy ma ktos namiary na SoftIce, albo inny debugger o podobnej
> funkcjonalności pod Windows XP? Znalazłem w sieci i ściągnąłem SoftIce for
> XP, a co okazało się trojanem. Mam GoBug, który pod XP nie chce się
> uruchomić.
Co rozumiesz przez "podobnej"? Że rezydentny w kernelu? Imo w większości 
przypadków klasyczny debugger starcza - czy OlyDbg, czy IDA (wersja demo 
nie pozwala zapisywać, ale debugg  dla hobbisty wystrarczy).


> A z innej beczki. Jest jakaś procedura w assemblezrze służąca do
> pierwiastkowania?
Może być fsqrt?

-- 
Pozdrawiam
Michoo

Użytkownik "Michoo" napisał:

> Co rozumiesz przez "podobnej"?

Możliwości i sposobu obsługi (drugorzędne).

> Imo w większości przypadków klasyczny debugger starcza - czy OlyDbg, czy
IDA (wersja demo
> nie pozwala zapisywać, ale debugg  dla hobbisty wystrarczy).

To ja teraz zapytam. Co to znaczy "klasyczny debuger"? Dla mnie klasyczne są
dwa. Debug i SoftIce :) SoftIce to niedościgniona potęga. Podobno IDA
dorównuje, a nawet przewyższa. Mało używałem IDA, bo mam za mało
dokumentacji, a jak dla mnie obsługa jest skomplikowana. Reszta tej parze
nie dorasta nawet do pięt, chociaż czasem wystarcza. Np. GoBug ma tę zaletę,
że nie kładzie łapy na całym systemie i nie przeszkadza w pracy innym
programom.

> > w assemblezrze służąca do  pierwiastkowania?

> Może być fsqrt?

To jest instrukcja koprocesora, a mnie chodzi o "ręczną" procedurę dla CPU.
Takie procedury stosuję w swoim kalkuratorze. Mogę np. dzielić duże liczby
bez ograniczenia dzielnika do wielkości rejestru. A tego nie da się zrobić
przy pomocy div. Jakiś czas temu ktoś na grupie podrzucił mi kawałek takiej
procedury dzielenia z wykorzystaniem przesunięć i obrotów. Jest genialna i
co ciekawe nie spotkałem jej nigdzie w literaturze, czy tutorialach w sieci.
Nie do końca rozumiem jej działanie, ale co najważniejsze nie ma
ograniczenia dzielnika. Mogę dzielić liczby dowolnej (w sensownych
granicach) wielkości. Póki co rozbudowałem kalkulator do dzielenia liczb 128
bajtowych.

Remek

W dniu 29.06.2011 04:51, Remek pisze:
> Użytkownik "Michoo" napisał:
>
>> Co rozumiesz przez "podobnej"?
>
> Możliwości i sposobu obsługi (drugorzędne).
>
>> Imo w większości przypadków klasyczny debugger starcza - czy OlyDbg, czy
> IDA (wersja demo
>> nie pozwala zapisywać, ale debugg  dla hobbisty wystrarczy).
>
> To ja teraz zapytam. Co to znaczy "klasyczny debuger"? Dla mnie klasyczne są
> dwa. Debug i SoftIce :)
Klasyczny uruchamia się jako proces w systemie i debuguje odpalony przez 
siebie inny proces (lub dołącza się do niego). Kernel mode debuger 
ładuje się jako sterownik i może pracować w RT - m.i. debugować system 
operacyjny, śledzić wywołania "głębiej".

> SoftIce to niedościgniona potęga.
Zaczynałem od softice i w sumie nie wspominam go jako specjalnie dobrego 
debuggera - było to przydatne narzędzie w crackowaniu, ale samo 
debuggowanie wspominam jako upierdliwe.

> Podobno IDA
> dorównuje, a nawet przewyższa. Mało używałem IDA, bo mam za mało
> dokumentacji, a jak dla mnie obsługa jest skomplikowana.
IDA ma taką funkcjonalność jak choćby rysowanie grafów przepływu 
sterowania - bywa to bardzo przydatne w zrozumieniu "jak ten kod działa".

Niestety ostatnio bardziej niskopoziomowo na x86 grzebałem w liceum, 
więc jak dokładnie wygląda teraz sytuacja na rynku debuggerów ciężko mi 
powiedzieć.

>>> w assemblezrze służąca do  pierwiastkowania?
>
>> Może być fsqrt?
>
> To jest instrukcja koprocesora, a mnie chodzi o "ręczną" procedurę dla CPU.
Możesz użyć funkcji wykładniczej - jeżeli masz ją już zaimplementowaną.
Jeżeli nie to istnieje kilka metod iteracyjnych - np metoda babilońska:
http://pl.wikipedia.org/wiki/Metody_obliczania_pierwiastka_kwadratowego

-- 
Pozdrawiam
Michoo

Użytkownik "Michoo" napisał:

> http://pl.wikipedia.org/wiki/Metody_obliczania_pierwiastka_kwadratowego

Dzięki za ten link. Ciekawy materiał. Wymaga czasu do przestudiowania. Póki
co w moim kalkulatorze zastosowałem pierwszą metodę tzn. wstępnego
szacowania. Działa, ale przy większych liczbach widać wyraźne wydłużenie
czasu działania. Sądz, że teoretycy matematycy - informatycy opracowali już
bardziej wydajne (szybsze) algorytmy. Upieram się przy poszukiwaniu metody
wykorzystującej przesunięcia i obroty. Takie procedury sąa bardzo szybkie.

Drugą (babilońską) metodę mam zaimplementowaną, ale tylko do liczby o
wielkości rejestru. Może da się ja rozbudować.

Remek

W dniu 30.06.2011 15:00, Remek pisze:
> Upieram się przy poszukiwaniu metody
> wykorzystującej przesunięcia i obroty. Takie procedury sąa bardzo szybkie.
Dla liczb całkowitych liczysz w czasie liniowym względem liczby bitów:
- lecisz od najstarszego bitu do najmłodszego
- jeżeli wynik podniesiony do kwadratu jest mniejszy od wejścia to go 
zostawiasz, jak większy - gasisz. przechodzisz do następnego.

-- 
Pozdrawiam
Michoo

Użytkownik "Michoo" napisał:

> jeżeli wynik podniesiony do kwadratu jest mniejszy od wejścia to go
> zostawiasz, jak większy - gasisz. przechodzisz do następnego.

I tu mam zagwozkę. Dla liczby o wielkości dword mam "cmp", a jak porównywać
większe liczby? W tych wspomnianych przeze mnie procedurach robione to jest
jakos tak, że równolegle obracane i przesuwane są dzielnik i dzielna (w
procedurze dzielenia) i sygnałem do zakończenia działania jest odpowiednie
ustawienie flag. Nie jestem w stanie tego przeanalizować.

Remek

W dniu 30.06.2011 17:25, Remek pisze:
> Użytkownik "Michoo" napisał:
> 
>> jeżeli wynik podniesiony do kwadratu jest mniejszy od wejścia to go
>> zostawiasz, jak większy - gasisz. przechodzisz do następnego.
> 
> I tu mam zagwozkę. Dla liczby o wielkości dword mam "cmp", a jak porównywać
> większe liczby? W tych wspomnianych przeze mnie procedurach robione to jest
> jakos tak, że równolegle obracane i przesuwane są dzielnik i dzielna (w
> procedurze dzielenia) i sygnałem do zakończenia działania jest odpowiednie
> ustawienie flag. Nie jestem w stanie tego przeanalizować.


http://rudy.mif.pg.gda.pl/~bogdro/dos/a_kurs14.htm

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org   www.TorProject.org   Soft (EN): miniurl.pl/bogdro-soft

Użytkownik "Bogdan (bogdro)" napisał:

> http://rudy.mif.pg.gda.pl/~bogdro/dos/a_kurs14.htm

Chodzi o to?

cmp eax, [arg2+12] ; porównujemy najstarsze części

Chyba telepatycznie mi to przekazałeś, bo w kilka minut po zadaniu pytania
sam na to wpadłem :) Dziwne jak czasem umykają najbardziej oczywiste reguły.
W przypadku mojej procedury wystarczy porównać najstarsze bajty w buforach.

To jeśli chodzi o porównywanie, bo przesunięcia i obroty mam opanowane.
Tyle, że to za mało aby je sprawnie implementować w procedurach konwersji,
dzielenia, mnożenia, czy pierwiastkowania.

Dzięki za odzew.

Remek

PS Na wskazanej stronie pod hasłem ROL jest kilka instrukcji, ale ROL nie
ma. Poza tym warto byłoby opisać różnice w działaniu ROL i RCL. Dokładniej
co prawda omówione są na stronie:

http://rudy.mif.pg.gda.pl/~bogdro/linux/linux13.html

ale jeśli ktoś sam w debuggerze nie zobaczył tych różnic, to z opisu
niekoniecznie zrozumie w czym rzecz.

W dniu 01.07.2011 10:39, Remek pisze:
> Użytkownik "Bogdan (bogdro)" napisał:
> 
>> http://rudy.mif.pg.gda.pl/~bogdro/dos/a_kurs14.htm
> 
> Chodzi o to?
> 
> cmp eax, [arg2+12] ; porównujemy najstarsze części
> 
> Chyba telepatycznie mi to przekazałeś, bo w kilka minut po zadaniu pytania
> sam na to wpadłem :)

 Tak, o to chodzi :)

> Dziwne jak czasem umykają najbardziej oczywiste reguły.
> W przypadku mojej procedury wystarczy porównać najstarsze bajty w buforach.

 To nie najgorzej.

> To jeśli chodzi o porównywanie, bo przesunięcia i obroty mam opanowane.
> Tyle, że to za mało aby je sprawnie implementować w procedurach konwersji,
> dzielenia, mnożenia, czy pierwiastkowania.
> 
> Dzięki za odzew.
> 
> Remek
> 
> PS Na wskazanej stronie pod hasłem ROL jest kilka instrukcji, ale ROL nie
> ma.

 Zgadza się. Jest tak dlatego, gdyż rotacja bitów w liczbach
wielokrotnej precyzji nie jest implementowana przy pomocy instrukcji
ROL. Potrzebujemy flagi CF do trzymania bitów "w pamięci", dlatego ROL
dla takich liczb implementuje się za pomocą kombinacji SHL+RCL i
dopisania ostatniego bitu.

> Poza tym warto byłoby opisać różnice w działaniu ROL i RCL. Dokładniej
> co prawda omówione są na stronie:
> 
> http://rudy.mif.pg.gda.pl/~bogdro/linux/linux13.html
> 
> ale jeśli ktoś sam w debuggerze nie zobaczył tych różnic, to z opisu
> niekoniecznie zrozumie w czym rzecz.

 Idąc po kolei w kursie, strona z wielokrotną precyzją jest tuż po tej
stronie, ale przy wejściu bezpośrednio do części 14. rzeczywiście coś
więcej można byłoby powiedzieć. Pomyślę nad tym. Na razie wpadłem na
to, aby w części 14. podać link do części 13, ale zobaczę, czy i jak
to dokładnie zrobić.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org   www.TorProject.org   Soft (EN): miniurl.pl/bogdro-soft

Użytkownik "Bogdan (bogdro)" napisał:

> > Na wskazanej stronie pod hasłem ROL jest kilka instrukcji, ale ROL nie
> > ma.

> Zgadza się. Jest tak dlatego, gdyż rotacja bitów w liczbach
> wielokrotnej precyzji nie jest implementowana przy pomocy instrukcji
> ROL.

Mam tzw. mieszane odczucia :) ROL to ROL - instrukcja procesora. Jak
instrukcje procesora implementować w procedurze i po co? Tym bardziej jeśli
chodzi o ROL to w procedurach wielokrotnej precyzji ma raczej małe
zastosowanie. I o to min. chodzi w opisie różnic. Np. ROR a R(Carry flag)R.

Remek

W dniu 03.07.2011 15:55, Remek pisze:
> Mam tzw. mieszane odczucia :) ROL to ROL - instrukcja procesora.
ROL to operacja na liczbie.

> Jak
> instrukcje procesora implementować w procedurze i po co?
Bo na liczbie długości podwojonego słowa procesora ROR na na składowych 
nie zrobi tego o co chodzi.

> Tym bardziej jeśli
> chodzi o ROL to w procedurach wielokrotnej precyzji ma raczej małe
> zastosowanie.
No a jak ktoś jednak potrzebuje taką funkcjonalność?


-- 
Pozdrawiam
Michoo

Użytkownik "Michoo" napisał:

> > Jak
> > instrukcje procesora implementować w procedurze i po co?

> Bo na liczbie długości podwojonego słowa procesora ROR na składowych
> nie zrobi tego o co chodzi.

W związku z tym stosuje się procedurę wykorzystującą właściwe instrukcje.
Czy to oznacza implementację ROL???

> > Tym bardziej jeśli
> > chodzi o ROL to w procedurach wielokrotnej precyzji ma raczej małe
> > zastosowanie.

> No a jak ktoś jednak potrzebuje taką funkcjonalność?

Jak potrzebuje to zastosuje. Mógłbyś rzucić jakiś przykład operacji
wielokrotnej precyzji wykorzystującej ROL?

A co do porównywania dużych liczb. Procedura podana przez Bogdana nie
sprawdza się w mojej implementacji. Czego nie rozumiem? Pokazuję źródło.
Jest to próba sprawdzenia, czy wynik mnożenia jest większy od liczby na
wejściu.

 mov eax, dword ptr [wynikmn+8]
 cmp eax, dword ptr [wejscie+8]
 ja  obl_reszt

 mov eax, dword ptr [wynikmn+4]
 cmp eax, dword ptr [wejscie+4]
 ja  obl_reszt

 mov eax, dword ptr [wynikmn]
 cmp eax, dword ptr [wejscie]
 ja  obl_reszt

I jak to działa. Jeśli pierwsze sprawdzenie daje wynik negatywny to ja nie
jest wykonany. Kolejne sprawdzenie daje wynik pozytywny i ja jest wykonany.
I to jest błąd bo:

wejście = 8A9F 0F8C 33C4
wynikmn = 0A9F 2F8C 33C4

Podzieliłem to na dwordy, aby było lepiej widoczne. Liczby są przypadkowe,
ale obrazują problem. jak zrobić, aby było dobrze?

Remek

W dniu 04.07.2011 15:16, Remek pisze:
> Użytkownik "Michoo" napisał:
> 
>>> Jak
>>> instrukcje procesora implementować w procedurze i po co?
> 
>> Bo na liczbie długości podwojonego słowa procesora ROR na składowych
>> nie zrobi tego o co chodzi.
> 
> W związku z tym stosuje się procedurę wykorzystującą właściwe instrukcje.
> Czy to oznacza implementację ROL???

 Nie, bo ROL jest zaimplementowana w procesorze. To oznacza
implementację "operacji rotacji bitów na liczbie nie mieszczącej się w
rejestrze". Natomiast na procesorach nie posiadających instrukcji
robiącej to, co ROL na x86, oznaczałoby to implementację "operacji
rotacji bitów (która na procesorach x86 przyjmuje postać instrukcji ROL)".
 Nie implementujesz instrukcji procesora, bo od tego są producenci
procesorów. Piszesz procedurę, która imituje funkcjonalność pewnej
instrukcji procesora, dlatego, że ta ma swoje ograniczenia (np.
rozmiar lub typ rejestru), które trzeba w danym przypadku jakoś
przeskoczyć. Piszesz procedurę, która robi to, co zrobiłaby ta
instrukcja, gdyby mogła. Jest to, w jakimś sensie, implementacja
(oczywiście programowa) pewnej innej, "rozszerzonej" wersji
instrukcji, ale nie samej instrukcji.

>>> Tym bardziej jeśli
>>> chodzi o ROL to w procedurach wielokrotnej precyzji ma raczej małe
>>> zastosowanie.
> 
>> No a jak ktoś jednak potrzebuje taką funkcjonalność?
> 
> Jak potrzebuje to zastosuje. Mógłbyś rzucić jakiś przykład operacji
> wielokrotnej precyzji wykorzystującej ROL?

 Przesuwanie bitów w generowaniu liczb pseudolosowych (np. coś w stylu
LFSR)?

> A co do porównywania dużych liczb. Procedura podana przez Bogdana nie
> sprawdza się w mojej implementacji. Czego nie rozumiem? Pokazuję źródło.
> Jest to próba sprawdzenia, czy wynik mnożenia jest większy od liczby na
> wejściu.
> 
>  mov eax, dword ptr [wynikmn+8]
>  cmp eax, dword ptr [wejscie+8]
>  ja  obl_reszt
> 
>  mov eax, dword ptr [wynikmn+4]
>  cmp eax, dword ptr [wejscie+4]
>  ja  obl_reszt
> 
>  mov eax, dword ptr [wynikmn]
>  cmp eax, dword ptr [wejscie]
>  ja  obl_reszt
> 
> I jak to działa. Jeśli pierwsze sprawdzenie daje wynik negatywny to ja nie
> jest wykonany.

 Zgadza się.

> Kolejne sprawdzenie daje wynik pozytywny i ja jest wykonany.
> I to jest błąd bo:
> 
> wejście = 8A9F 0F8C 33C4
> wynikmn = 0A9F 2F8C 33C4
> 
> Podzieliłem to na dwordy, aby było lepiej widoczne. Liczby są przypadkowe,
> ale obrazują problem. jak zrobić, aby było dobrze?

 Po każdym JA dodajesz "JNE nie_obl_reszt". Aby "iść dalej" w
porównywaniu, na starszych pozycjach nie może być różnicy. W ten
sposób dla tych dwóch liczb, porównywanie skończy się po pierwszym
kroku, ale pierwszy skok JA nie zostanie wykonany. Jeśli miałbyś liczby:

wejście = 0A9F 0F8C 33C4
wynikmn = 0A9F 2F8C 33C4

to po pierwszym porównaniu nie zostaje wykonany ani JA, ani JNE i
porównywane są kolejne DWORDy, co doprowadzi do prawidłowej
odpowiedzi. Ale przyznaję się - nie napisałem tego w kursie, a raczej
powinienem był. W najbliższym czasie się poprawię.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org   www.TorProject.org   Soft (EN): miniurl.pl/bogdro-soft

Użytkownik "Bogdan (bogdro)" napisał:

> > Podzieliłem to na dwordy, aby było lepiej widoczne. Liczby są
przypadkowe,
> > ale obrazują problem. jak zrobić, aby było dobrze?

> Po każdym JA dodajesz "JNE nie_obl_reszt". Aby "iść dalej" w
> porównywaniu, na starszych pozycjach nie może być różnicy. W ten
> sposób dla tych dwóch liczb, porównywanie skończy się po pierwszym
> kroku, ale pierwszy skok JA nie zostanie wykonany. Jeśli miałbyś liczby:
>
> wejście = 0A9F 0F8C 33C4
> wynikmn = 0A9F 2F8C 33C4

> to po pierwszym porównaniu nie zostaje wykonany ani JA, ani JNE i
> porównywane są kolejne DWORDy, co doprowadzi do prawidłowej
> odpowiedzi.

To sprawdzenie mam w procedurze pierwiastkowania dużych liczb. Wygląda to
tak:

========================================

mnoz_dalej:

 call mnozenie
 jc  obl_reszt  ; to zabezpiecza program przed nieskończoną pętlą

 mov eax, dword ptr [wynikmn+4]
 cmp eax, dword ptr [wejscie+4]
 ja  obl_reszt
 jb  mnoz_dalej

 mov eax, dword ptr [wynikmn]
 cmp eax, dword ptr [wejscie]
 ja  obl_reszt

  .........

==========================================

I to działa z wyjątkiem przypadku kiedy oba dwordy są sobie równe :) Co
wtedy? Sprawdzę tak:

========================================

mnoz_dalej:

 call mnozenie
 jc  obl_reszt  ; to zabezpiecza program przed nieskończoną pętlą

 mov eax, dword ptr [wynikmn+4]
 cmp eax, dword ptr [wejscie+4]
 ja  obl_reszt
 jb  mnoz_dalej

 mov eax, dword ptr [wynikmn]
 cmp eax, dword ptr [wejscie]
 ja  obl_reszt

 jmp obl_reszt
  .........

==========================================

Czy to wystarczy? Przepraszam za trucie d..., ale ja nie potrafię analizować
kodu "na sucho", a przećwiczenie wszystkich reakcji programu na dane
wejściowe to robota dla jakiegoś programu, nie dla człowieka. Mam
kalkulator, który bez zarzutu działał przez dwa lata. Przypadkiem okazało
się, że wynik dzielenia 704/4 to zero??? Błąd w procedurze. Młodszy bajt
jest równy zero i cmp bajt, 0 powodowało wyjście z pętli. Paranoja. Trzeba
było odwrócić procedurę i sprawdzać od najstarszego bajtu.

> nie napisałem tego w kursie, a raczej
> powinienem był. W najbliższym czasie się poprawię.

Bez przesady :) Nie da się przewidzieć i opisać wszystkich zastosowań. Coś
jednak można wspomnieć.

Pozdrawiam  Remek

W dniu 05.07.2011 18:01, Remek pisze:
> Użytkownik "Bogdan (bogdro)" napisał:
> 
>>> Podzieliłem to na dwordy, aby było lepiej widoczne. Liczby są
> przypadkowe,
>>> ale obrazują problem. jak zrobić, aby było dobrze?
> 
>> Po każdym JA dodajesz "JNE nie_obl_reszt". Aby "iść dalej" w
>> porównywaniu, na starszych pozycjach nie może być różnicy. W ten
>> sposób dla tych dwóch liczb, porównywanie skończy się po pierwszym
>> kroku, ale pierwszy skok JA nie zostanie wykonany. Jeśli miałbyś liczby:
>>
>> wejście = 0A9F 0F8C 33C4
>> wynikmn = 0A9F 2F8C 33C4
> 
>> to po pierwszym porównaniu nie zostaje wykonany ani JA, ani JNE i
>> porównywane są kolejne DWORDy, co doprowadzi do prawidłowej
>> odpowiedzi.
> 
> To sprawdzenie mam w procedurze pierwiastkowania dużych liczb. Wygląda to
> tak:
> 
> ========================================
> 
> mnoz_dalej:
> 
>  call mnozenie
>  jc  obl_reszt  ; to zabezpiecza program przed nieskończoną pętlą
> 
>  mov eax, dword ptr [wynikmn+4]
>  cmp eax, dword ptr [wejscie+4]
>  ja  obl_reszt
>  jb  mnoz_dalej
> 
>  mov eax, dword ptr [wynikmn]
>  cmp eax, dword ptr [wejscie]
>  ja  obl_reszt
> 
>   .........
> 
> ==========================================
> 
> I to działa z wyjątkiem przypadku kiedy oba dwordy są sobie równe :) Co
> wtedy? Sprawdzę tak:
> 
> ========================================
> 
> mnoz_dalej:
> 
>  call mnozenie
>  jc  obl_reszt  ; to zabezpiecza program przed nieskończoną pętlą
> 
>  mov eax, dword ptr [wynikmn+4]
>  cmp eax, dword ptr [wejscie+4]
>  ja  obl_reszt
>  jb  mnoz_dalej
> 
>  mov eax, dword ptr [wynikmn]
>  cmp eax, dword ptr [wejscie]
>  ja  obl_reszt
> 
>  jmp obl_reszt
>   .........
> 
> ==========================================
> 
> Czy to wystarczy?

 Prawdopodobnie tak. Jeśli wynik mnożenia jest równy wejściowej
liczbie, to "obl_reszt" (co pewnie oznacza obliczanie reszty) powinno
zapewne zwrócić zero, więc powinno być dobrze. Ale mogę czegoś nie
wiedzieć, więc przetestuj choć dla jednego przypadku.

> Przepraszam za trucie d..., ale ja nie potrafię analizować
> kodu "na sucho", a przećwiczenie wszystkich reakcji programu na dane
> wejściowe to robota dla jakiegoś programu, nie dla człowieka.

 Po to właśnie robi się testy :) Ale nie takie, że ktoś wpisuje coś do
programu (choć te też), tylko raczej podstawia się dane i uruchamia
procedury "ręcznie".

> Mam
> kalkulator, który bez zarzutu działał przez dwa lata. Przypadkiem okazało
> się, że wynik dzielenia 704/4 to zero??? Błąd w procedurze. Młodszy bajt
> jest równy zero i cmp bajt, 0 powodowało wyjście z pętli. Paranoja. Trzeba
> było odwrócić procedurę i sprawdzać od najstarszego bajtu.

 Zdarza się. I w bardziej, i w mniej profesjonalnych programach.

>> nie napisałem tego w kursie, a raczej
>> powinienem był. W najbliższym czasie się poprawię.
> 
> Bez przesady :) Nie da się przewidzieć i opisać wszystkich zastosowań. Coś
> jednak można wspomnieć.

 Już wspomniałem :)

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org   www.TorProject.org   Soft (EN): miniurl.pl/bogdro-soft

jak to jest kurdę, te pedały mają same szósteczki na Politechnice 
Warszawskiej a zadają takie kretyńskie pytania - jak to zrobić? przecież 
podał Ktoś tu link wiki 

W dniu 16.07.2011 17:28, identifikator: 20110701 pisze:
> jak to jest kurdę, te pedały
Podrywaj potencjalnych partnerów na prv, a nie na publicznych grupach, ok?

> mają same szósteczki na Politechnice
> Warszawskiej
Masz poważny problem z myśleniem - zdaje się, że dyskusja się toczy 
między Łodzią, Gdańskiem i Poznaniem.

> a zadają takie kretyńskie pytania - jak to zrobić?
Ty zazwyczaj zadajesz kretyńskie pytania.

> przecież
> podał Ktoś tu link wiki
Jak jesteś za głupi, żeby zrozumieć o czym jest aktualna dyskusja to idź 
sobie na inną grupę, co?

-- 
Pozdrawiam
Michoo

sory, już cichnę 

odgrzewam kotleta, jest jakiś dobry debuger pod Win32/64? 

W dniu 17.02.2014 17:54, tusk, donald tusk pisze:
> odgrzewam kotleta, jest jakiś dobry debuger pod Win32/64?

 Już nie pamiętam, jakie odpowiedzi padły w tym wątku, ale OllyDbg?
GoBug (Go Tools)? Z płatnych pewnie IDA Pro?
 Osobiście używałem troszkę OllyDbg, dawał radę. Widać było wywołania
WinAPI na przykład.


-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):            http://bogdro.ciki.me
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org  Soft(EN): http://bogdro.ciki.me/soft

Bogdan (bogdro) <bogdan@poczta.gazeta.pl>:
>  W dniu 17.02.2014 17:54, tusk, donald tusk pisze:
> > odgrzewam kotleta, jest jakiś dobry debuger pod Win32/64?
>
>   Już nie pamiętam, jakie odpowiedzi padły w tym wątku, ale OllyDbg?
>  GoBug (Go Tools)? Z płatnych pewnie IDA Pro?
>   Osobiście używałem troszkę OllyDbg, dawał radę. Widać było wywołania
>  WinAPI na przykład.

OllyDBG to raczej standard przy analizie kodu asm, jak i IDA Pro zresztą. Można jeszcze pokusić się o polecenie Microsoftowego WinDBG [1], którym można debugować też kod ring0.

[1] - http://msdn.microsoft.com/en-us/windows/hardware/hh852365