pomocy :)

[sys]

2006-08-16 16:25:19 slackXman napisał:

> 2006-08-16 14:45:50 zbysiup napisał:
 >  > Tez tak mysle ze stabilnosc i bezpieczenstwo systemu w duzej mierze zalezy od
 > uzytkownika.
 >  > Linux jednak oprocz innych zalet ma jednak jeszcze ta przewage ze ma otwarte zrodla,
 > milionom
 >  > ludzi latwiej dostrzec blad lub dziure w systemie, niz zamknietemu gronu programistow
 >  > Microsoftu.
 >  >
 >
 > Ja otwartego kodu nie uważam za zalete, wręcz przeciwnie.
 > Zamknięte źrudło jest pewną polityką bezpieczeństwa.
 > Dużo łatwiej znaleść błąd/luke w Open-Source niż w binarnym kodzie.
 > "Zamknięte programy" są czasem bardzo trudne w analizie wziąwszy pod uwage
 > anty-dumpery, anty-dbg, ant-dasm, SMC, kompresory, szyfatory i wiele wiele innych. Z otwartym
 > źrudłem nie ma takich problemów.
 > Człowiek nie jest doskonały, więc to co robi również pozostawia wiele do życzenia. Jeśli masz
 > "otwarte źrudło", masz "otwarty program".
 >
 > Pozdrawiam

ŹrÓdło proszę pana jak już
To nie jest dyskusja o wyższości jednych świąt nad drugimi, po prostu nie ma skopanego systemu, tylko skopany użySzkodnik (tylko, że dziwnym trafem brak jednego pliku .dll w Win kładzie cały system).
Miejmy nadzieję, że nasz kolega okienkowy juz dawno postawił system od nowa i nie będzie zmuszony pytać u konkurencji jak sobie poradzić z leżącym systemem

A co do otwartych źrÓdeł, to szybciej można reagować na błedy i je poprawiać na bieżąco, a nie jak łaskawie programiści wypuszczą nową wersję po iluś tam mcach

[slackXman]

2006-08-16 16:33:44 sys napisał:
 > A co do otwartych źrÓdeł, to szybciej można reagować na błedy i je poprawiać na bieżąco, a nie
 > jak łaskawie programiści wypuszczą nową wersję po iluś tam mcach
 >

Jak również szybciej pisać "szkodniki" na owe błędy...

Pozdrawiam

[Maciek_Rutecki]

2006-08-16 16:25:19 slackXman napisał:

 > Dużo łatwiej znaleść błąd/luke w Open-Source niż w binarnym kodzie.

To chyba dobrze, nie?

Powtarzasz teksty ze strony "Get the facts" Microsoftu, słowo w słowo... tylko, że oni się skompromitowali tą akcją.

BTW znaleŹć

--
Maciek

[benyo]

>
 > Jak również szybciej pisać "szkodniki" na owe błędy...
 >
 > Pozdrawiam

Rzeczywiscie wystarczy porownac zamkniety WIndows i otwarty Linux pod katem pisania 'szkodnikow'

[slackXman]

2006-08-16 18:53:59 Maciek_Rutecki napisał:

> 2006-08-16 16:25:19 slackXman napisał:
 >
 >  > Dużo łatwiej znaleść błąd/luke w Open-Source niż w binarnym kodzie.
 >
 > To chyba dobrze, nie?
 >
 > Powtarzasz teksty ze strony "Get the facts" Microsoftu, słowo w słowo... tylko, że
 > oni się skompromitowali tą akcją.
 >
 > BTW znaleŹć
 >
 > --
 > Maciek

Nic nie powtarzam bo nie czytałem tego...

[slackXman]

2006-08-16 19:10:22 zbysiup napisał:

>  >
 >  > Jak również szybciej pisać "szkodniki" na owe błędy...
 >  >
 >  > Pozdrawiam
 >
 > Rzeczywiscie wystarczy porownac zamkniety WIndows i otwarty Linux pod katem pisania
 > 'szkodnikow'
 >

Linux również ma "szkodniki", a dzięki temu, że coraz to większe grono osób zaiteresowanych tą platformą rośnie, ilość "szkodników" będzie coraz większa.

[benyo]

 > Linux również ma "szkodniki", a dzięki temu, że coraz to większe grono osób
 > zaiteresowanych tą platformą rośnie, ilość "szkodników" będzie coraz większa.
 >

Zainteresowanie ta platforma juz jest ogromne, pomijajac fakt ze system Unix powstal jakies kikanascie lat wczesniej niz Windows (jakies lata 60te), ale jakos nie idzie to w parze z zainteresowaniem tworcow 'szkodnikow' na platformy *nixowe, a bylo sporo czasu zeby troche tych szkodnikow napisac, a jednak tak nie jest, z czegos to chyba wynika.

[Maciek_Rutecki]

Ludzie, ta dyskusja nie prowadzi do niczego. Przyjrzyjcie się postom slackXmana i zastanówcie się czy warto.

Proponuję EOT

--
Maciek
unixy.pl

[benyo]

2006-08-16 21:02:51 Maciek_Rutecki napisał:

> Ludzie, ta dyskusja nie prowadzi do niczego. Przyjrzyjcie się postom slackXmana i zastanówcie
 > się czy warto.
 >
 > Proponuję EOT
 >
 > --
 > Maciek
 > unixy.pl

Oj Macku, wakacje sa, daj se pogadac:)

[slackXman]

2006-08-16 21:02:51 Maciek_Rutecki napisał:

> Ludzie, ta dyskusja nie prowadzi do niczego. Przyjrzyjcie się postom slackXmana i zastanówcie
 > się czy warto.
 >
 > Proponuję EOT
 >
 > --
 > Maciek
 > unixy.pl

Mnie nikt nie przekona, przede wszystkim dla tego, że analizą zabezpieczeń/bezpieczeństwa kodu (programów) zajmuje się już od dawna, posiadam pewne doświadczenie i wiedze.

Tak, masz racje ta dyskusja do niczego nie prowadzi.

Linux jak i Windows to bardzo dobre systemy i żaden z nich nie jest idealny i nie przewyższa drugiego.


Pozdrawiam

[Maciek_Rutecki]

2006-08-16 21:38:39 slackXman napisał:


 >
 > Mnie nikt nie przekona, przede wszystkim dla tego, że analizą zabezpieczeń/bezpieczeństwa kodu
 > (programów) zajmuje się już od dawna, posiadam pewne doświadczenie i wiedze.
 >

"dla tego" inaczej się pisze. Szkoda, że nie poświęciłeś równie dużo czasu ortografii, bo już jestem kolejną osobą, która zwraca Tobie na to uwagę. Ale mniejsza z tym. Na czym polega Twoja "analiza zabezpieczeń/bezpieczeństwa kodu"?

--
Maciek
unixy.pl

[slackXman]

2006-08-16 21:49:27 Maciek_Rutecki napisał:

> 2006-08-16 21:38:39 slackXman napisał:
 >
 >
 >  >
 >  > Mnie nikt nie przekona, przede wszystkim dla tego, że analizą zabezpieczeń/bezpieczeństwa
 > kodu
 >  > (programów) zajmuje się już od dawna, posiadam pewne doświadczenie i wiedze.
 >  >
 >
 > "dla tego" inaczej się pisze. Szkoda, że nie poświęciłeś równie dużo czasu
 > ortografii, bo już jestem kolejną osobą, która zwraca Tobie na to uwagę. Ale mniejsza z tym. Na
 > czym polega Twoja "analiza zabezpieczeń/bezpieczeństwa kodu"?
 >
 > --
 > Maciek
 > unixy.pl

Nigdy nie przywiązywałem - i nie przywiązuje - wagi do jakiś wymyślonych błędów (każdy rozumny człowiek wie o co chodzi no chyba że żaba i rzaba to co innego, to strasznie przepraszam).

A na czym może polegać analiza kodu po względem bezpieczeństwa (-> źrudłowego, no i na końcu wykonywalnego/maszynowego)?
Myśle, że tu nie trzeba nic dodać.

[Maciek_Rutecki]

2006-08-16 22:18:23 slackXman napisał:

 >
 > Nigdy nie przywiązywałem - i nie przywiązuje - wagi do jakiś wymyślonych błędów (każdy rozumny
 > człowiek wie o co chodzi no chyba że żaba i rzaba to co innego, to strasznie przepraszam).

No cóż...

 >
 > A na czym może polegać analiza kodu po względem bezpieczeństwa (-> źrudłowego, no i na końcu
 > wykonywalnego/maszynowego)?
 > Myśle, że tu nie trzeba nic dodać.
 >

Ja jednak nalegam, przecież można maluczkim wytłumaczyć? :-)

--
Maciek
unixy.pl

PS. źrÓdłowego

> Nigdy nie przywiązywałem - i nie przywiązuje - wagi do jakiś wymyślonych błędów (każdy rozumny
 > człowiek wie o co chodzi no chyba że żaba i rzaba to co innego, to strasznie przepraszam).
 >
 > A na czym może polegać analiza kodu po względem bezpieczeństwa (-> źrudłowego, no i na końcu
 > wykonywalnego/maszynowego)?
 > Myśle, że tu nie trzeba nic dodać.
 >

Wydaje mi się że analiza kodu pod względem bezpieczeństwa polega na tym, że trzeba sprawdzić czy jakiś palant napisał (w pseudojęzyku np.) "rzaba" zamiast "żaba" i przez to powstała ogromna luka w zabezpieczeniach po procesor tego się nie czepiał tylko przyjął i wykonał jak leci .

Maciek daj spokój, on pewnie analizuje bezpieczeństwo pod kątem ściągania cracków do gier windowsowych

[slackXman]

2006-08-16 22:45:58 Maciek_Rutecki napisał:

> 2006-08-16 22:18:23 slackXman napisał:
 >
 >  >
 >  > Nigdy nie przywiązywałem - i nie przywiązuje - wagi do jakiś wymyślonych błędów (każdy
 > rozumny
 >  > człowiek wie o co chodzi no chyba że żaba i rzaba to co innego, to strasznie
 > przepraszam).
 >
 > No cóż...
 >
 >  >
 >  > A na czym może polegać analiza kodu po względem bezpieczeństwa (-> źrudłowego, no i na
 > końcu
 >  > wykonywalnego/maszynowego)?
 >  > Myśle, że tu nie trzeba nic dodać.
 >  >
 >
 > Ja jednak nalegam, przecież można maluczkim wytłumaczyć? :-)
 >
 > --
 > Maciek
 > unixy.pl
 >
 > PS. źrÓdłowego


Ale ja tu nikogo za maluczkiego nie uważam, jeśli tak wyszło, to przepraszam nie chciałem...

Analiza:

I
1) kodu (binarny/źródłowy)
 [poziomy]
  a) wdrażania
  b) poprawy
  c) integralność
  d) kontroli
2) kompatybilność
3) przeniośność (cross-p )

II
kod wykonywalny ["dostosowywanie"]
1) dostosowanie do projektu
2) sterowniki, moduły, wykonywalne itp (exe, elf, pe, dll, sys, vxd, i386, lib, .o [a/so], inne interpretowalne)
3) wspułdziałanie

III
zabezpieczenia
1) źrudeł (jeszcze w fazie testów/programowania I.1)
2) kody binarne
[analiza pod względem:]
 - spujności
 - bezpieczeństwa (anty; dbg dasm i podobne; SMC, BP, BPX, itd. [sterowniki/moduły osobna analiza z powodu wspułdziałania/zależności])

IV
zadania kończące:
tutaj przede wszystki testy t.j.:
1) "brutalne" testy (moje nazewnictwo:P ) czyli robienie wszystkoego, aby dana "rzecz" padła i monitorowanie (sytuacja podobna do  II.1 II.3 i III)
3) zasoby (żadko w tym punkcie)
4) anliza zebranych danych (tutaj stawia się decyzje, czy projekt wymaga dalszego "sprawdzania" )

To jest bardzo pobieżna lista.

Pozdrawiam