Newsgroup: it.comp.programmare.win32
Titolo: Far esplodere Win !! :-)

No, a parte gli scherzi, cerco un modo per far comparire un errore di Win,
ma un errore di quelli cattivi: (schermo blu, pulsante che blocca tutto...
ecc ecc)
Speravo in qualche vostro consiglio... [magari qualche istruzioncina in asm
per mandare in crash il sistema o almeno creare un po' di casino]...
Preciso subito due cose:
- non ho intenzione di scriverci un virus...
- non sono uscito pazzo, nel senso che non è che voglia rendere ancora +
instabili i miei programmi... devo solo fare un esperimento... :-)
Ciao
(¯`·.¸¸.·´¯`·.¸¸.-> Andrea <-.¸¸.·´¯`·.¸¸.·´¯)

Smanetta con l' ASM (che anche sotto win non è morto), e soprattutto con la
memoria...
fai casini di tutti i tipi soprattutto con gli array.
Ciao by Tdx

    Devi generare un errore di protezione generale: scrivi in ring 0, ad eg.
prova a corrompere il drive di una periferica.
Happy programming, Fabio

 wrote in message
7ps0eh$9lh$1...@fe2.cs.interbusiness.it...


Vorrei ringraziarvi tutti per le risposte... :-)
Dunque, avevo dimenticato un po' di dettagli nel mio primo msg: io programmo
in genere in Delphi (al limite riesco a scrivere qualcosina in Java, VB
(puàh ...)  e C [proprio poco però])...
Pensavo quindi di inserire qualche istruzioncina asm per far piantare tutto
il sistema, piccoli problemi:
1) non so praticamente nulla di asm (a parte qualche istruzione di mov, xor,
e poco altro non ho mai usato l'asm) ricordo che lo usavo per impostare
delle modalità grafiche in VGA sotto Turbo Pascal ma è passato troppo tempo
e l'ho usato si e no 2 volte... :-(
2) putroppo la FatalAppExit non fa al caso mio: pianta solo la mia
applicazione...
Per il momento riesco solo a far comparire una schermata blu con questa
istruzione:
asm
  int 21h
 end;
(non so assolutamente cosa sia l'interrupt 21h, mi lo ricordavo solo quello
e ho provato...)
Peccato che non vada tutto in crash... :-(
Qualcuno ha più capacità distruttiva di me?? :-)


Bello, bello!!
Ora ti posto il sorgente del mio programmino, che fa prendere un bello
spavento, e nient'altro di piů!
(Attento agli ACAPO, possono creare dei piccoli casini)
INIZIO SORGENTE
#include <stdio.h>
#include <windows.h>
#include <windowsx.h>
#include <winbase.h>
#define NAME "Errore"
#define TITLE "ErroreCritico"
long FAR PASCAL WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM
lParam);
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
    HWND hwnd;
    WNDCLASS wc;
    MSG         msg;
   wc.style = CS_HREDRAW | CS_VREDRAW;
   wc.lpfnWndProc = WindowProc;
   wc.cbClsExtra = 0;
   wc.cbWndExtra = 0;
   wc.hInstance = hInstance;
   wc.hIcon = LoadIcon(hInstance, "IDI_ICON1");
   wc.hCursor = LoadCursor(NULL, IDC_ARROW);
   wc.hbrBackground = NULL;
   wc.lpszMenuName = NULL;
   wc.lpszClassName = NAME;
   if( !RegisterClass(&wc) ) return 0;
   hwnd =
ateWindow( 
                        NAME,
                        TITLE,
                        WS_DLGFRAME | WS_MINIMIZE,
                        0,
                        0,
                        200,
                        200,
                        NULL,
                        NULL,
                        hInstance,
                        NULL );
   while( TRUE )
    {
        if( PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) )
        {
          if( !GetMessage(&msg, NULL, 0, 0) ) return msg.wParam;
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }
}
long FAR PASCAL WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
 switch(message)
   {
      case WM_ENDSESSION:
           PostQuitMessage(0);
      break;
      case WM_CREATE:
           MessageBox(NULL, "***Attenzione, questo messaggio di errore č falso***", "Starting...", MB_OK);
           FatalAppExit(0, "Ahiahiahiahia, Errore! Formatta tutto!");
      break;
      default:
      break;
   }
   return DefWindowProc(hWnd, message, wParam, lParam);
}
FINE SORGENTE
Dallo in pasto al tuo compilatore e vedi che succede!
Ciao
    Fabio

Ciao
Saluti,
    Mardy
--
Per rispondere togliere NVN dall'indirizzo.

(Attento agli ACAPO, possono creare dei piccoli casini)
No, no... non è che devo fare uno scherzo o cose così...
Devo proprio mandare in crash il sistema ! (devo testare se una mia
applicazione regge !)
Grazie cmq per il listato [anche se io mastico poco il C] , avevo fatto un
bel programmino che simulava la formattazione ! [si erano cagati sotto tutti
i miei amici :-) ]
Ciao


 Peccato che non vada tutto in crash... :-(
Ottima scelta.
Suggerirei anche l'int 0x2E con un po' di spazzatura nei registri
EAX ed EDX.
BTW, se scrivi istruzioni ASM in un programma Win32, allora quelle
istruzioni valgono non nella macchina DOS, ma per gli applicativi
Win32.
Ora, nel processore Intel, uno dei modi per causare una transizione di
ring (cioe', per passare il controllo al sistema operativo) e'
quello di invocare in software interrupt.
Ora, anche in modalita' protetta e da qualunque livello di previlegio,
e' consentito invocare un software interrupt (a meno di condizioni
al contorno). Gli interrupt maggiori di 32 sono usati dal sistema
operativo per tradurre CreateFile() in qualcosa di piu'
gestibile dal kernel.
In NT viene usato per questo scopo int 0x2E (disassemblare NTDLL.DLL
per la conferma). Tipicamente i parametri per le transizioni
di ring "controllate" sono in EAX e ECX. Solitamente un registro
contiene l'indice della dispatch table e l'indice della funzione,
e l'altro contiene un puntatore ad una zona di memoria dove si trovano
i parametri.
Penso che si possano fare danni con tutti gli int maggiori di 32, che,
ripeto, sono indici nell IDT e non gli interrupt di MS-DOS - BIOS
se vengono chiamati da un applicativo a 32 bit.
BTW, io non uso Win9x, quindi no posso testare di preciso.
Sent via Deja.com 
http://www.deja.com/
Share what you know. Learn what you don't.

applicazione regge !)
Beh, ma allora piu` bello di un hardware reset che cosa c'e`? :-)
Bye! Lorenzo Lutti (
http://members.tripod.it/fidocad
)

Beh, ma allora piu` bello di un hardware reset che cosa c'e`? :-)
Eh, no... quello "non vale" ...
Mi servirebbe proprio di crasharlo... (classica schermata blu, "premere un
tasto per continuare" patacrack: non si muove + nemmeno il mouse )
Ovvio che non vorrei ricorrere a mezzucci del tipo un paio di hooks per
rendere inefficaci tastiera e mouse o qualche chiamata alla TerminateProcess
e alle ToolHelp32 per chiudere tutto il resto... mi piacerebbe proprio
essere in grado di causare uno di quei maledetti errori che ti piantano
tutto...
Ciao [e grazie a tutti per l'attenzione, spero di trovare soluzioni !!] :-)


operativo costituisce reato. Ocio.
per chi mi hai preso? ho specificato subito che non si tratta di un atto di
pirateria informatica... (dovrei essere proprio scemo: perchè postare su un
ng pubblico con nome e cognome belli in chiaro quando ci sono migliaia di
siti che spiegano per filo e per segno come fare tutti i danni
possibili/immaginabili??)
Possibile che appena uno chiede qualcosa di un po' "pericoloso" tutti lo
prendano per un malvivente???  :-/


tasto per continuare" patacrack: non si muove + nemmeno il mouse )
Prova questo:
for(;;) outp( rand()%1024, rand()%256);
:-))


Tutto qui.
Ti invito a rileggerti il thread fin dall'inizio...


instabili i miei programmi... devo solo fare un esperimento... :-)
Devo dire che neanche io me ne intendo molto ma ti voglio portare
un'esperienza che ho avuto pochi giorni fa mentre smanettavvo un po' col c.
Se non ricordo male nel primo 1k di mem RAM dovrebbero stare gli indirizzi
di mem che vengono utilizzati quando si fanno chiamate ad int: ad esempio
quando io richiamo l'int 5h il sistema prende questo valore e lo moltiplica
x 4 ed ottiene il valore 20d ovvero 14h. In questo indirizzo dovrebbe
trovarsi una dword che indica l'indirizzo in memoria della routine di
interrupt richiesta da noi.
Dunque se noi andassimo a sovrascrivere il primo 1k di mem il sistema si
incasinerebbe di brutto credo :)
A questo proposito avevo scritto un breve programmino in c che serviva allo
scopo ed anche se le info che ho dato valgono x il mondo dos il risultato si
è sentito ed anche molto :)
#include <stdio.h>
main()
{
int far *ptr;
char c;
for (ptr=(int far*)0x000000004;ptr<(int far*)0x0000FFFF;ptr++)
*ptr=0x0000;
gets(&c);
}
Compilato con il Borland Turbo C++ 3.0
Ciao
NikDH

è sentito ed anche molto :)
Con il tuo programmino girante in modalità V86 (DOS Box) dovrebbe essere
andata in errore solo quest'ultima, non tutto il Win.....
Ciao, Giuseppe
---------------------------------------------------------------------------
_Guybrush su IRCNet canale #programmazione
ICQ: 42227764
---------------------------------------------------------------------------

andata in errore solo quest'ultima, non tutto il Win.....
Il mio prog girava in un Dos Box sotto win 98 e mi ha crashato tutto di
brutto.
Il comportamento da te descritto è quello di NT ma x quanto riguarda win 98
a me si pianta: prova e sappimi dire
Ciao
NikDH

a me si pianta: prova e sappimi dire
No, non ti preoccupare, ti credo sulla parola. Quando si parladi Win9x
crederei anche all'impossibile in fatto di insicurezza di sistema :-)


 wrote in message
b9AB3.117910$6C.2...@typhoon.libero.it...


dell'instabilità e della memoria succhiata è "merito" dei 16 bit
Il fatto che il Win9x sia un ibrido tra i 16 e i 32 bit implica un notevole
calo delle prestazioni (è per questo che il Win NT è almeno del 30% più
veloce) e una maggiore instabilità.
Comunque quello che caratterizza (in negativo) il Win9x è la poca
professionalità con cui è stato programmato, caratteristica che si manifesta
con blocchi improvvisi e ingiustificati del sistema e illogici problemi di
installazione di nuovi device drivers.
Ciao, Giuseppe
---------------------------------------------------------------------------
