Win3x.Org :: LudOS

Win3x.Org http://www.win3x.org/win3board/

LudOS http://www.win3x.org/win3board/viewtopic.php?f=69&t=2250	Page 27 sur 33

Auteur :	inico [ 07 juin 2007 20:59 ]
Sujet du message :

code.google.com a écrit :
# Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://ludos.googlecode.com/svn/trunk/ ludos

Ca appartient à google.
MARKMONITOR INC. est seulement le registar du ndd.
Ca ressemble a un cybersquatting regler à l'amiable.

Citation :
Domain Name: GOOGLECODE.COM
Registrar: MARKMONITOR INC.
Whois Server: whois.markmonitor.com
Referral URL: http://www.markmonitor.com
Name Server: NS1.GOOGLE.COM
Name Server: NS2.GOOGLE.COM
Name Server: NS3.GOOGLE.COM
Name Server: NS4.GOOGLE.COM
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 04-feb-2007
Creation Date: 08-mar-2005
Expiration Date: 08-mar-2008

[..]
Registrant:
Google Inc.
(DOM-1358613)
1600 Amphitheatre Parkway
Mountain View
CA
94043
US

Domain Name: googlecode.com

Registrar Name: Markmonitor.com
Registrar Whois: whois.markmonitor.com
Registrar Homepage: http://www.markmonitor.com

Administrative Contact:
DNS Admin
(NIC-14290820)
Google Inc.
1600 Amphitheatre Parkway
Mountain View
CA
94043
US
dns-admin@google.com
+1.6506234000
Fax- +1.6506188571
Technical Contact, Zone Contact:
DNS Admin
(NIC-14290820)
Google Inc.
1600 Amphitheatre Parkway
Mountain View
CA
94043
US
dns-admin@google.com
+1.6506234000
Fax- +1.6506188571

Created on..............: 2005-Mar-08.
Expires on..............: 2008-Mar-08.
Record last updated on..: 2007-Feb-04 03:47:10.

Domain servers in listed order:

NS1.GOOGLE.COM
NS2.GOOGLE.COM
NS3.GOOGLE.COM
NS4.GOOGLE.COM

Auteur :	tombcore [ 08 juin 2007 00:29 ]
Sujet du message :

Non cryptage Xor à clé complexe, c'est très rapide. Sa prend quelques ligne asm la compression / décompression. Je peut vous coller la code en C si vous voulez, c'est un pti crypter que je me suis fait pour crypter les chaines dans des exes. (pour passez les antivirus qui pensent que mon programme contient du code malicieux)

Le principe c'est on a un flux de donnée , et une chaine de caractère qui est la clef de cryptage.

résultat = Data Xor Clef[j]
C'est réversible, la même fonction crypte et décrypte si la clef reste identique. Il s'agit là de l'exemple le plus simple. On peut bien sur s'amuser a faire bouger les caractères de la clef pour compliquer, mais disons que là sans la clef, le gars n'a aucune chance de retrouver ses données. C'est extrêmement rapide, même sur un 286.

Code : Tout sélectionner

/* 
*  Decrypt encrypted shell code data
*/

void Decrypt(unsigned char *DataBuffer, DWORD DataLen, unsigned char Key[], DWORD KeyLen){

	WORD KeyCount = 0;
	DWORD i;

	KeyLen--;
	for (i = 0; i < DataLen; i++){
		DataBuffer[i] ^= Key[KeyCount];
		if (KeyCount == KeyLen)
			KeyCount = 0;
		else 
			KeyCount++;
	}
}

Auteur :	PulkoMandy [ 08 juin 2007 08:10 ]
Sujet du message :

Pour faire un TSR, il y a une interruption dos "terminate and stay resident".
Pour ce qu'il faudrait mettre dans l'int, ben... faut voir de quoi on aura le plus besoin

Je pense que les fonctions devraient pouvoir être chargées séparément, par exemple pour la lib graphique dont on a pas besoin tout le temps.

Auteur :	tr16 [ 08 juin 2007 08:13 ]
Sujet du message :

intéressant çà

m'intéresse ton crypter tombcore(une fois fait en asm donc je m'en occuperai)

Mais il faut résoudre le problème des TSR..car mon prog fait 50 octecs et il réserve...~900 octects ce qui est une perte énorme...

Sinon j'ai pensais pourquoi ne pas faire un "kernel" ludos qui se lance après MS DOS et qui chargerai tout le bazar de TSR et driver,interruption...(dont le parser) puis lancerai le programme pour se loguer ?

faudra demander à Pulkomandy son avis mais si en plus on fait en sorte que les dossiers systèmes et utilisateurs sont inaccessible sans que le 'kernel' soit lancé se serait encore mieux.

Auteur :	corwintirnanog [ 08 juin 2007 08:59 ]
Sujet du message :

Merci pour l'explication, le Web n'en finira pas de m'étonner

Auteur :	tr16 [ 08 juin 2007 09:26 ]
Sujet du message :

Toujours dans la catégorie interruption:

Le shell DOS qui tourne en boucle.

Ici il s'agit d'un détournement d'interruption(l'int 16h) du bios.
Et dès qu'on lance ce programme on constate que des multitudes de visages apparaissent. Un visage= un appel a l'int 16h détournée.

Je comprends maintenant pourquoi le ventilateur de mon processeur augmente la cadence lorsque je lance le DOS.

çà mouline....

PS: après le lancement de ce programme le DOS est INUTILISABLE,il faut redémarrer le PC.
Je ne suis pas reponsable des dégats provoqués par ce programme.

Sinon j'ai réussi un TSR, qui lance des interruptions. Puis ai lancé un autre prog qui l'appelle. En temps normal il bloque le DOS mais là....une visage est apparue donc l'int marche (bien que le contraire aurait été étonnant

)

On avance,on avance..à quand le driver clavier maison ? (on détourne l'int 9 et on fait tout péter...)

Auteur :	corwintirnanog [ 08 juin 2007 11:05 ]
Sujet du message :

tr16 a écrit :
Je comprends maintenant pourquoi le ventilateur de mon processeur augmente la cadence lorsque je lance le DOS. çà mouline....

Il faut que tu utilise APM.

Auteur :	tr16 [ 08 juin 2007 11:07 ]
Sujet du message :

ok...sinon les sources de ls.com sont sur le site du projet ainsi que la license.

----
Publié: vendredi 08 juin 2007 12:08

Merci Tombcore pour ton code je viens de finir de l'écrire en ASM.

j'ai eu quelques bugs de débordements (et il y en a sûrement encore).

mais apparemment çà marche:

chaine originale: (j'avais pas trop d'idée

)

salut toi!

clé:
23,14,13,6,2

chaine cryptée:
doasv7zbo#

j'ai décryptée et on retrouve bien la chaine de départ.
Bien sûr ici la chaine est plus petite (longueur 6) par rapport à la chaine (10)

Je garde ces sources dans un coin

pour les ajouter a une interruption.
si çà intéresse je peux les passer.

----
Publié: vendredi 08 juin 2007 19:53

Et c'est repartit!!!(enfin pas complétement).

Voilà ayant réussi récemment à implémenter des TSR, j'ai recoder ma lib en asm et ai conçu une interruption qui affiche des fenêtres, des lignes( pour le moment 80 % est fait)

Ce qui fait des exécutables n'ayant pas besoin de linker les fonctions graphiques (bref des pseudo dlls sous DOS quoi

).

Par contre je recherche des personnes sachant interfacer l'asm avec le C.
Sinon pas de lib C utilisant cette interruption...

--> dans cette version il n'y aura qu'un affichage simple de ligne et fenêtre pas encore la possibilité de mettre du texte, il faudra le faire manuellement.

Je privilégie en effet l'aspect sécurité de ma lib..beaucoup de tests (et perte de temps)...mais risque d'erreur, débordement mémoire très faible.

Pour les programmeurs asm:
vous pourrez tester tout celà d'ici une semaine tout au plus.
Pour les programmeurs asm:
heu..là çà va être plus long...je vais voir du côté de mon vieux Borland C++ ce que je peux faire..

Bref, une fosi cette (maudite) lib terminée (version 0.2.0 et oui on passe à 0.2 comme ls vu la réécriture complète de la lib..et la sortie prochaine ? de ludOS 0.2 )

PS:
Je recherche des personnes pour des tests sur des assez vieilles machines
(moins c'est puissant mieux c'est).
Pour tester la rapidité d'affichage et bugs éventuels.

Des programmeurs asm, pour s'amuser à envoyer n'importe quoi en paramètre à l'interruption pour voir si tout est bien sécurisée.

-->>>>>>> Dans la version 0.2.0 il n'y aura que le type WIN_CLASSIC (deux traits), en effet la gestion de deux catégories est pour le moment trop "lourde" à gérer (en temps d'exécution et de programmation).

Auteur :	guigui [ 12 juin 2007 17:32 ]
Sujet du message :	écriture dans la mémoire vidéo en asm

Wikipédia en a écrit :
Typically these starting segments are:

* 0xA000 for EGA/VGA graphics modes (64 KiB)
* 0xB000 for monochrome text mode (32 KiB)
* 0xB800 for color text mode and CGA-compatible graphics modes (32 KiB)

Auteur :	Dr Frankenstein [ 13 juin 2007 04:01 ]
Sujet du message :

guigui a écrit :
Wikipédia en a écrit :
Typically these starting segments are:

* 0xA000 for EGA/VGA graphics modes (64 KiB)
* 0xB000 for monochrome text mode (32 KiB)
* 0xB800 for color text mode and CGA-compatible graphics modes (32 KiB)

Élabore..... je vois pas où tu veux en venir...

Page 27 sur 33	Fuseau horaire sur UTC+02:00
Développé par phpBB® Forum Software © phpBB Limited Traduction française officielle © Qiaeru