• Serveur xmlsocket & triche

    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 ^^

    Tags Tags : , , , ,
  • Commentaires

    1
    dj_ouf
    Mercredi 26 Avril 2006 à 16:56
    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
    Mercredi 26 Avril 2006 à 18:52
    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
    Mercredi 26 Avril 2006 à 19:10
    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
    Mercredi 26 Avril 2006 à 19:12
    Ca n'empechera pas ton gars de se logguer avec l'ancien client :)
    5
    Mercredi 26 Avril 2006 à 19:20
    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
    dj_ouf
    Jeudi 27 Avril 2006 à 09:02
    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
    Jeudi 27 Avril 2006 à 12:49
    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
    dj_ouf
    Jeudi 27 Avril 2006 à 23:52
    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
    Vendredi 28 Avril 2006 à 01:27
    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
    divarvel Profil de divarvel
    Vendredi 28 Avril 2006 à 17:47
    Rahalalah javascript sera toujours là pour nous faire ch*er !
    11
    Samedi 29 Avril 2006 à 10:32
    et par c++ c'est possible qu'il entre ? ou alors je demande encore n'inporte quoi arg ma tête ...
    12
    Samedi 29 Avril 2006 à 11:45
    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
    dj_ouf
    Samedi 29 Avril 2006 à 22:50
    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
    Dimanche 30 Avril 2006 à 01:20
    ouép c'est saoulant....
    15
    Mardi 2 Mai 2006 à 11:30
    Dur dur donc ...
    16
    divarvel Profil de divarvel
    Mercredi 3 Mai 2006 à 22:02
    Ca se sécure comment la faille par JS alors ?
    17
    Samedi 6 Mai 2006 à 15:31
    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
    Mardi 9 Mai 2006 à 22:20
    Pareil, pas moyen de vérifier la provenance des requêtes ?

    Ralalah ! Je ferai jamais de site en flash ^^ :p
    19
    Jeudi 11 Mai 2006 à 07:15
    c'ets ptete pour ça que je voit pas beaucoup de site en flash aussi
    20
    Dimanche 14 Mai 2006 à 22:37
    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
    Mercredi 17 Mai 2006 à 07:08
    ok ^^j'espere que ça passera !
    22
    bricedenice2929
    Jeudi 25 Mai 2006 à 15:31
    les hacker sur ton site sont des gros *** dsl pour ça mais bon ^^
    23
    MegAleX
    Mercredi 31 Mai 2006 à 23:19
    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
    Vendredi 2 Juin 2006 à 22:48
    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
    MegAleX
    Mardi 6 Juin 2006 à 21:53
    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
    dj_ouf
    Vendredi 22 Septembre 2006 à 13:56
    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
    Mardi 28 Novembre 2006 à 02:50
    Va jeter un oeil la dessus pour éviter déja les problèmes de décompilation avec Flash : www.amayeta.com/ :)
    28
    Jeudi 30 Novembre 2006 à 20:12
    Ouép je connais ce logiciel depuis un moment... Mais t'as vu le prix ?
    29
    CGuilweb
    Mercredi 7 Février 2007 à 12:33
    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
    Vendredi 9 Février 2007 à 18:47
    Non j'ai déjà trouvé des décompileurs qui peuvent décompiler les classes...
    Flare le fait très bien par exemple.
    Suivre le flux RSS des commentaires de cet article


    Ajouter un commentaire

    Nom / Pseudo :

    E-mail (facultatif) :

    Site Web (facultatif) :

    Commentaire :