Man merkt, dass Du Dich NULL mit der Materie beschäftigst, denn a) gibts Security Seeds schon ewige Zeiten und b) wenn ein Update nötig wäre, würde man das merken, denn schliesslich gäbe es neben einer neuen sro_client.exe ggf. sogar noch ein Patch für die PK2s und in beiden Fällen würden a) alle User DC bekommen, die keine Updates haben, insofern wären dann b) die Bothersteller schon lange am Updaten.Es wäre mehr als einfach von heute auf morgen nach nem Update alle Bots auszusperren. Man müsste in bestimmte Packets einfach nur bestimmte Sicherheitscodes einbauen welche dann auch vom geupdateteten Client geschickt werden. Vom Bot natürlich nicht. Funktionieren würde der Bot trotzdem, aber JM könnte von heute auf morgen genaue Daten sammeln: X bottet, Y nicht.
Zitat von »Daddi«
P.S:
Ich hätte mal gerne ein paar mehr Infos über deine angesprochenen "Security Seeds" welche JM wohl auch schon einsetzt?
Dein Gefühl ist schlecht. Unter anderem arbeite ich an einem Clientless Tradebot (c++) mit (zu 95% fertig), habe genug diverse Tools geschrieben (ai3,c++) und mich mit der ganzen Materie tief genug beschäftigt. Es gibt sicher den ein oder anderen hier im Forum, der mich kennt und der bestätigen kann, dass dies nicht nur Wannabe Gelaber ist. (EDIT: Fast selfown3d ^^)a) könnte man diese "Seeds" aber erweitern oder verändern
und dann? dazu muss der client upgedatet werden, upgedateter client ist schon mal komisch -> Check von z.B. bot369
b) es kommen ständig Updates bei denen nur irgendwelche Bugs gefixt werden, da könnte man das locker mit einarbeiten.
Wieso würden die Leute "DCs" bekommen? Klar, wie jeden Dienstag und?
Selbst wenns am Dienstag passiert, neuer Client, alter Bot -> Inkompatibel, bot369 muss arbeiten
Und jetzt der Clou:
Das System könnte man so aufbauen, dass regelmässig, generiert aus z.b. dem aktuellen Timestamp und einer bestimmten Code-Folge, ähnlich dem Salt-Verfahren bei Hashs, neue Sicherheitscodes genutzt werden.
Egal von welcher Seite aus soetwas generiert wird, die Gegenseite muss logischerweise für einen Gegencheck ebenfalls eine Berechnung bzw. Checkberechnung durchführen können, je nachdem obs eine Einwegverschlüsselung ist, oder ob es wieder entschlüsselt werden soll/kann/whatever. Somit muss es wiederum im Client stehen -> Debuggen, Spass haben, Nutzlos
Man könnte das Update sogar so ausarbeiten, dass man erstmal *überhaupt* nichts davon merkt, weil es noch "inaktiv" geschaltet ist und sich irgendwann durch ein bestimmtes Package, welches JM dann von den Servern neu "verbreiten" lässt, "aktiviert" und dann erst die Sicherheits-Codes mit versendet werden. Die Bothersteller bekämen überhaupt nichts davon mit, weil es wie ne Zeitbombe im Quellcode tickt und nur darauf wartet alle Bots hochgehen zu lassen.
Ähm nein? Zumindestens nicht bei Clientbasierten Bots. SBot (im Nicht CL Mode), TBot, iSRO Bot (inkl. SM als Crack für iSRO) und agBot als Beispiel reichen ggf. Packets einfach an den Client weiter, der verarbeitet sie (schliesslich ist es in die sro_client.exe implementiert) und schickt die Antwort zurück. CLBots wie SBot im CL Mode, edxCL, iSRO CL hätten ggf. ein Problem, sofern dies nicht schon vorher bekannt werden würde. Ansonsten würde es erst einmal ggf. in einem DC enden, Leute beklagen sich und dann wirds checken angefangen.
Ständig ändernde Sicherheitscodes nach einem bestimmten System würden auch die besten Bot-Hersteller nach kurzer Zeit verzweifeln lassen. Vor allem weil das Spielen bzw das Botten überhaupt nicht verhindert wird, sondern man still und heimlich einfach die Daten sammelt. Solange ein Bot läuft ohne zu murren, würden wohl mehr als 50% der Botuser nicht auf die Idee kommen ein Update dafür zu installieren. Und schon säßen sie in der Falle, denn die Bot-Liste bei JM würde immer und immer grösser werden.
Wo wir wieder beim Thema sind, ändert sich was, muss es der Client für eine Antwort auch wissen -> Code ist im Client implementiert usw usw, siehe oben. Wenn eine fehlende Antwort oder falsche Antwort jedoch nicht in einem DC enden, ist das herausfinden dieses Packets nicht unmöglich. Ich habe jeden Tag mit Packets zu tun, es würde zwangsläufig in der Frage enden "Hey, da ist ein unbekanntes Packet, was macht'n das?" und schon siehe notfalls wieder 1. Satz.
P.S:
Ich hätte mal gerne ein paar mehr Infos über deine angesprochenen "Security Seeds" welche JM wohl auch schon einsetzt?
Ob Du es Seeds oder Bytes oder sonst etwas nennst, spielt keine Rolle, Antwort hattest ja schon in Form der PDF.
Ich kann dazu nichts finden und hab das Gefühl du willst hier einfach nur ein paar schlaue Begriffe einwerfen um als "Insider" zu gelten. Aber da das ja nicht so ist, kannst du mir ja bestimmt Infos und Quellen auf anderen Seiten geben die erklären was es damit aufsich hat![]()
und dann? dazu muss der client upgedatet werden, upgedateter client ist schon mal komisch -> Check von z.B. bot369
Selbst wenns am Dienstag passiert, neuer Client, alter Bot -> Inkompatibel, bot369 muss arbeiten
Somit muss es wiederum im Client stehen -> Debuggen, Spass haben, Nutzlos
Ansonsten würde es erst einmal ggf. in einem DC enden, Leute beklagen sich und dann wirds checken angefangen.
"Hey, da ist ein unbekanntes Packet, was macht'n das?" und schon siehe notfalls wieder 1. Satz.
Die Bedürfnisse werden somit auch gedeckt,doch wer denkt noch an die kleine Randgruppe Legits?
Auf die wird ja schon seit längerer Zeit mit dem Finger gezeigt.
Könnt ihr mit euerm Wissen nicht lieber irgendwelche Dinge bauen,die die Programme Negativ beeinflussen?
Wäre es Möglich,den ein oder anderen Bot von aussen zu crashen?
Wenn die Frage "Was kann Joymax tun ?" nicht mehr zieht sollte sich wohl mal langsam die Frage "Was kann die "Community" tun?" breitmachenSehr interessanter Schlagabtausch hier.
Nur was ist im Endeffekt die Moral von der Geschicht?
Das Technisch einiges Möglich ist um die Botter des "Feldes" zu verweisen,ist schön länger klar.
Die Frage ist,lohnt es sich überhaupt darüber den Kopf zu zerbrechen?
Solange JM nicht mal ansatzweise darüber nachdenkt Anti Cheat Programme einzusetzen,ist solche Diskussionen nur Kompetenzgerangel,mehr nicht.Was jeder einzelne auf dem Kasten hat,ist hier eher Sekundär wichtig da andere Menschen diesen Hebel betätigen bzw. ihn nicht netätigen.
Hier scheint es ja eher der Fall zu sein,das sr972 eher "Tools" baut die Negative auswirkungen aufs Spiel haben.Cheat Engine hat SRO mehr als genug.
Andererseits interessieren sich die Silkroadianer ja fast nur noch für genau diese Art von Programmen.
Die Bedürfnisse werden somit auch gedeckt,doch wer denkt noch an die kleine Randgruppe Legits?
Auf die wird ja schon seit längerer Zeit mit dem Finger gezeigt.
Könnt ihr mit euerm Wissen nicht lieber irgendwelche Dinge bauen,die die Programme Negativ beeinflussen?
Wäre es Möglich,den ein oder anderen Bot von aussen zu crashen?
Naja die scheisse is die lassen Isro inner Ecke gammeln und ihr Ziel is eigentlich Ksro.
Wenn in Isro alle Botter weg währen würden wieder alle kommen und neu anfangen,aber sowas wirds nei geben =/
egits. Wenn ich das schon höre. Ich spiele auf Venus, da streiten sich sogar Legits mit Legits wer mehr legit ist, weil die einen in der Confed sind, die anderen nicht. Und Botter wie ich (ja und ich steh dazu), kriegen deren Scheiss dann zu spüren. Anstelle, die Goldbots ohne Ende mit Bottraps zu zuspammen (Ich hasse Goldbots übrigens auch wie die Sau), werden "normale" Playerbots PK15/15 gemacht. Die Goldbots in Jangan werden auf Venus natürlich NICHT bekämpft. Schliesslich hält Avalon, die Oberoberoberlegits, das Fortress und profitiert durch 20% Tax daran. Sorry, Legits wie diese, haben bei mir einfach nur verschissen
und haben im Hintergrund nen Download vonna Transporter 3 Raubkopie am laufen
Ich kann mir 1000 Filme runterladen, davon bist du *überhaupt* nicht betroffen