Godefroy de Compreignac

Java
Serveur xmlsocket & triche

par Skreo, le 23 Avril 2006 à 23:03 (modifié le 02/07/2007 à 12:37)

J'ai un gros problème avec mon serveur xmlsocket pour Murties.
Quelqu'un a réussi a décompiler le client flash, comprendre son code, et recréer un client. Il peut ainsi se connecter au serveur pour envoyer les informations qu'il souhaite et modifier son compte à loisir.... Il a aussi fait planter le serveur plusieurs fois en envoyant des milliers de requêtes d'un coup.
Impossible de faire passer un identifiant au serveur, qu'il vienne d'un fichier php, de la flash elle-même ou de quoi que ce soit c'est toujours possible de le récupérer.
Et impossible aussi de savoir l'hôte du client...
Un autre moyen aussi serait de contrôler toutes les requêtes entrantes, et de bannir l'ip des utilisateurs qui envoient trop de messages, ou ceux dont les stats augmentent très vite. Mais c'est vraiment galère et il y a des risques de bannir des gens pour rien.
Alors je suis ouvert à toute proposition ^^

Laisser un commentaire

Tags : serveur, xmlsocket, client, bannir, requetes
Suivre le flux RSS des commentaires de cet article
Revenir à la liste des articles
Haut de page
Commentaires
#1
26 Avril 2006 à 16:56dj_ouf
salut!! beau boulot ton jeu!

Comment un client flash recrée a partir du tiens pourrais t-il se connecté à ton server puisqu'il ne peux pas le placer sur celui çi???

Il a besoin des fichiers php contenant les identifiants de ta BDD pour communiquer ac ton serveur!!! 8-O
#2
26 Avril 2006 à 18:52Rob
Oui.. facile avec un bout de code il envoi un tas de requetes et ça fait planter... Bon 3 solutions :

- Tu met un firewall sur ton server qui limite les requetes. (la meilleure solution)

- Tu banni l'ip, mais tu risque de bannir plein de monde...

- Tu recode le client de murties qui fait que le server n'accepte que le client qui à tel code, comme ça le server accepte qu'un seul type de client se log au server. C'est assez facile à faire je pense :)

Voila :)

#3
26 Avril 2006 à 19:10Skreo
un firewall... c'est galère à installer sous linux ^^'''
Recoder le client c'est faisable sauf que beaucoup de monde a le client en cache sur leur pc, et il ne pourront donc plus se connecter...
La solution que j'ai trouvée et programmée : Compter le nombre de requêtes envoyées par chaque utilisateur et par 30 secondes.
Si un utilisateur envoie plus de 150 requêtes en moins de 30 secondes, ça bannit son ip ^^
Ca a l'air de bien marcher, j'ai testé en faisant un petit client qui envoyait plein de requêtes, et ça m'a bien banni ^^
#4
26 Avril 2006 à 19:12Rob
Ca n'empechera pas ton gars de se logguer avec l'ancien client :)
#5
26 Avril 2006 à 19:20Skreo
Ya pas d'ancien client. J'ai pas changé le client ^^
J'ai juste mis une protection contre le flood.
Par contre contre la triche j'ai toujours pas de solution :S
Je pense que le seul moyen serait de réussir à faire passer un identifiant au serveur par je ne sais quoi. Mais il ne faut pas que le hackeur puisse intercepter cet identifiant pour se connecter avec son client...
#6
27 Avril 2006 à 09:02dj_ouf
Bien joué pour le compteur de requètes!
Il a possibilité de tricher par javascript aussi...je sais que c'est que qu'ils font sur chimboz! Il arrive a récuperer les différentes variables et les modifier en les passant dans l'url par l'intermédiaire d'une commande javascript..

A part ça je ne comprends toujours pas comment le client crée du gars arrive à communiquer avec ton server!!
#7
27 Avril 2006 à 12:49Skreo
Par javascript c'est pas possible avec Murties, tout simplement parce que Murties est pas en javascript ^^
Pour le client, en fait j'imagine que le hackeur a simplement créé une application flash (ou C++ ou Java) qui se connecte au serveur sur le bon port et qui lui envoie des requête.
Par exemple en flash si on veut envoyer 100 requètes d'un coup à un serveur www.site.com sur le port 1234 :

var socket:XMLSocket = new XMLSocket();
socket.connect("www.site.com", 1234);
socket.onConnect=function(success:Boolean):Void {
if(success){
for(var i:Number=0;i<100;i++){
socket.send("requete bidon");
}
}
}
#8
27 Avril 2006 à 23:52dj_ouf
ok...ca veut dire qu'on peut flinguer n'importe quel server si on en connait le port pour s'y connecter??

Ca craint ça!!

Sinon pour le javascript on peut faire passer des variables à flash grace à l'objet embed. voiçi un exemple:

javascript:void(document.body.getElementsByTagName("embed")[0].SetVariable("_level1.cabine.avatar_design","a00800400l"));

Après j'ai pas tester mais bon... :-)
#9
28 Avril 2006 à 01:27Skreo
Ah oué zut j'avais pas prévu ça... merci
En effet je viens de vérifier on peut tricher comme ça...
ralala quand est-ce que Flash deviendra secure ??...
#10
28 Avril 2006 à 17:47divarvel
Rahalalah javascript sera toujours là pour nous faire ch*er !
#11
29 Avril 2006 à 10:32bricedenice2929
et par c++ c'est possible qu'il entre ? ou alors je demande encore n'inporte quoi arg ma tête ...
#12
29 Avril 2006 à 11:45Skreo
Ben oué je l'ai dit plus haut, on peut très bien créer un client en C++ qui se connecte à mon serveur. Mais c'est beaucoup plus simple de le faire en flash ^^
#13
29 Avril 2006 à 22:50dj_ouf
De rien ;-) Une faille de résolue en +, une!
Perso je connais pas comment sécuriser un flash contre des commandes javascript.. En déscativement le javascript de ta page html ca marche?

C'est vrai que flash est très vulnérable! C'est lourd! Il faut se creuser la tête pour contourner toutes les failles possiblent!
#14
30 Avril 2006 à 01:20Skreo
ouép c'est saoulant....
#15
2 Mai 2006 à 11:30bricedenice2929
Dur dur donc ...
#16
3 Mai 2006 à 22:02divarvel
Ca se sécure comment la faille par JS alors ?
#17
6 Mai 2006 à 15:31Skreo
Ben justement on peut pas...
Enfin heureusement les fonctions JS pour ça sont pas très évoluées, donc c'est difficile de bien tricher, vu que la structure des variables utilisateur est assez compliquée sur Murties v2 (pas comme sur la v1...)
#18
9 Mai 2006 à 22:20divarvel
Pareil, pas moyen de vérifier la provenance des requêtes ?

Ralalah ! Je ferai jamais de site en flash ^^ :p
#19
11 Mai 2006 à 07:15bricedenice2929
c'ets ptete pour ça que je voit pas beaucoup de site en flash aussi
#20
14 Mai 2006 à 22:37divarvel
Nan, je pense pas que ce soit ça la cause...
La flash c'est considéré comme bon pour les anims et les ptits jeux.
C'est pas dans les moeurs internet de faire tt un site avec... C vu comme du design le plus souvent
#21
17 Mai 2006 à 07:08bricedenice2929
ok ^^j'espere que ça passera !
#22
25 Mai 2006 à 15:31bricedenice2929
les hacker sur ton site sont des gros *** dsl pour ça mais bon ^^
#23
31 Mai 2006 à 23:19MegAleX
Bonne chance pour sécuriser ^^
Sur la V1, un ptit script PHP et hop ! =) (grillé rapidement, pas revenu depuis)
Merci pour l'infos sur le JS dj_ouf :p

Une bonne 1ere solution serait d'empecher la décompilation du flash, puis de modifier les noms des scripts/variables/le port..
Si possible ..
#24
2 Juin 2006 à 22:48Skreo
Ah c'est toi MegAleX qui avait fait le script de triche pour la v1 ? ça m'avait bien fait chier... J'avais juste bannis l'ip du site sur lequel était le script pour la connexion à un compte :p
J'ai trouvé que ASO comme logiciel gratuit pour sécuriser les flash en modifiant le nom des variables et des fonctions. Mais c'est pas top car ça vérifie pas si le mot à remplacer est dans ue chaîne de caractères... Donc ça fait des gros bugs
#25
6 Juin 2006 à 21:53MegAleX
Ouaip, d'ailleurs j'avais changé le script de serveur et hop ^^ (pas longtemps)
J'avais découvert ton site grâce a SmilM et son site^^
Je voulais revenir pour la V2 aussi, mais euh pas trop le temps ..
Ya pas des infos sur le net sinon pour bloquer les décompilateurs ? (de toute façon, le flash doit etre lisible par le flash player, et donc par les décompilateurs :/)
Bonne chance ;)
#26
22 Septembre 2006 à 13:56dj_ouf
re (après plusieurs mois! ^^)

on ne peut pas empêcher la décompilation des swf...
Toutes les meilleures sécurisation pour le flash sont des astuces imaginées par le créateur. Il faut obfusquer un maximum le nom des variables et orienter un maximum de tests et requètes côté serveur...C'est la seule solution..en gros il faut décourager le hacker avec plusieurs procédures à effectuer avant de récuperer des infos ;-)
#27
28 Novembre 2006 à 02:50CladTheKiller
Va jeter un oeil la dessus pour éviter déja les problèmes de décompilation avec Flash : www.amayeta.com/ :)
#28
30 Novembre 2006 à 20:12Skreo
Ouép je connais ce logiciel depuis un moment... Mais t'as vu le prix ?
#29
7 Février 2007 à 12:33CGuilweb
Je sais pas comment est développé ton client, mais je pense que tu as mis ton code dans les images de séquence. Dans ce cas, c'est facilement décompilable.

Essayes de refaire ton client en utilisant les Classes AS. Car tous les prog de décompil flash que j'ai pu tester sont incapables de recup le code des classes... à voir.
Tes variables et surtout ton protocole de communication seraient protégés, mais ça t'oblige à recompiler ton client...
#30
9 Février 2007 à 18:47Skreo
Non j'ai déjà trouvé des décompileurs qui peuvent décompiler les classes...
Flare le fait très bien par exemple.
#31
25 Avril 2007 à 17:52Chris
;-( Murties un super jeu se fait pirateur alala
#32
3 Septembre 2007 à 02:52Naruto
Pirater ti frére xD
Mes de toute façon c'est pas un probléme si il triche de toute façon si il passe premier trop vite il ce fera reperer et sinon si c'est pas pour sa a quoi sa sert xD

Ajouter un commentaire
Nom ou pseudo :

E-mail (facultatif) :

Site Web (facultatif) :

Commentaire :

Recopiez le code inscrit sur l'image :

Ce code est un code de sécurité pour empêcher le spam en vérifiant que la personne qui poste est bien un humain et non un robot.

Haut de page

Blog de Skreo :: Webdev && Hi-Tech

Java

Serveur xmlsocket & triche

Commentaires