[Development/Frage] FlyFF C# Source Files auf den aktuellen Stand

Hallo zusammen,
mich mögen noch nicht viele kennen aber dennoch bin ich in der Server Emulator Szene tätig.

Unter anderem schreibe ich an einem Matrix Online Server Emulator in C#.
Dieser benutzt unter anderem Twofish und RSA Encryption (letzteres um diverse Daten zu signieren aber auch um den Initial Twofish Key zu verschlüsseln).

Ich hatte vor Jahren mal just4fun einen Caali pServer ausprobiert und finde immer noch Emulator Development besser als geleakte Offi Files (auch wenn diese wie der echte Server agieren). Der Grund bei FlyFF ist einfach: Koreaner sind schlechte Programmierer (Was man anhand des hohen Speicherbedarfs des Offi Worldservers feststellt - während Caali Files damals auf ne Uralt Kiste problemlos liefen :)).

Da es nun 1000 Releases von Modifizierten offiziellen Sourcen mit Custom Content gibt, steig ich nicht mehr durch wo es denn nun einen Server gibt mit dem man einfach den offiziellen DE/EN Client nutzen kann :).

Angeblich gibts basierend auf den offiziellen Sourcen auch V19 Server - aber wenn ich mir die Sourcen anschaue find ich kein CryptoPP und seit V15 wurden die Packete ja verschleiert.

Daher mal die Frage in den Raum : wäre noch jemand interessiert adishen Source upzugraden um auf den aktuellen Stand zu bringen ? :)

Da ich im Netz nichts gefunden habe : weiss jemand aus dem Stehgreif welche Verschlüsselung nun bei FlyFF genutzt werden ?
Ich hab mir ein paar Packets gesnifft...aber irgendwas passt da nicht. Entweder ist es keine richtige CBC Verschlüsselung (da die verschlüsselten Daten keine 16 Byte Blöcke groß sind) oder die nutzen ECB ohne IV.

CRC32 nutzt jeder Server da keiner ahnung von Packeten hat, zieh dir die "Verschlüsselung" wo (Angeblich) Tom94 erweitert hat und dann hast du Packet Editor, ganz einfach dass zeug.

Packet Cryption haben evtl. 10% aller Server, der Rest hat keine Ahnung, und wenn du Packete so Verschlüsselst mit Twofish oder AES hast du massiven Latenz verlusst, dazu ist RSA kein Encryption's verfahren sondern lediglich ein Key "generator".

Offi FlyFF ist scheiße gecoded? wüsstest du nur bissl was über den Source würdest du anderst denken, schau dir dass Window Interface an, dann sagst du nichts mehr, oder CAr, sieht man aber wie viel ahnung du hier in den raum wirfst.

Caali Files liefen, ja, allerdings war die Latenz letzter müll und ohne die Neuz richtig zu Emulieren ging nichts, warum nutzt jeder Offi Source? weil man dazu die Neuz hat, hätte man 1337 V19 SERVER Source ohne Client, würde man trz Offi Source nutzen allein wegen der Neuz, daher brauchst du garnicht erst dass "Project" anfangen.

Die Serverfiles sind relativ OK gecodet, lediglich der Client ist völliger Mist, weil er uralten DirectX Sourcecode benutzt (DX8 glaub ich, dazu noch schlampig modifiziert) und auf VC6 Basis geblieben ist - zusätzlich die Verwendung von statischen Libs, was damals die einzige Option war, heute ist da einiges mehr rauszuholen.

Die Serverfiles machen hingegen ihre Arbeit, der Worldserver lädt auch alles im Vorraus, der Verbrauch bleibt über die Zeit und die Anzahl der Spieler her fast gleich.

Zudem ist der Vergleich zwischen Caali Worldserver und Gala Worldserver völliger Schwachsinn - während der Offi Worldserver eine Vielzahl von Prozessen im Hintergrund laufen hat, lief Caali auf nötigster Basis - es ging ja kaum was außer Farmen, Shoppen und Einkaufen - und ab etwa 120 Spielern (wenn überhaupt) war Schluss.

Statt dich also mit der endlosen Erweiterung von Emulatoren zu beschäftigen, solltest du dir das bisschen Zeit nehmen, um den Aeonsoft Sourcecode auf aktuellen Stand zu bringen (ein "Upgrade" auf VC10 oder VC11 z.B. nimmt wenig Zeit in Anspruch), da hast du im Endeffekt viel mehr von.

Zur Verschlüsselung: Wie ich die Faulen Leute von Gala kenne, haben die locker TripleDES wiederverwertet und neben DB-PW, config.ini und list.txt Encryption auch für die Packets verwendet.

1. Crc32 ist keine Verschlüsselungsmethode. Es ist lediglich ein hash Algorithmus um eine Prüfsumme der zu verifizierenen Daten zu bilden um gegenzuprüfen ob alle Daten korrekt angekommen sind.
2.symmetrische Verschlüsselung bei Netzwerk Verkehr ist gang und gebe und gerad bei game server sehr beliebt weil diese sehr schnell sind. Soviel zum Thema Latenz :)

3 . RSA: und wozu nutz du dann RSA Keys ? Nur weil sie schön sind wohl eher nicht. Les dir mal auf ******** den Server emulator Starter guide durch. RSA kann Inhalte signieren und auch daten Verschlüsseln nur ist rsa halt langsamer.

4 . Offi source : gut das du scheinbar Ahnung hast. Welches Window Interface ? Die 10 Fenster die da offen sind weil die koreaner es nicht hingekommen Server zusammen zu fassen und einfach separate threads zu starten ? ;) wozu braucht ein Account und ein login server jeweils eine eigene exe ? Von der Performance von MSSQL ganz zu schweigen .
Aber koreaner lieben halt MSSQL , active x und IE :)

Ich mein bei dem source wundert es mich nivht mehr wo die ganzen lags und DCs herkommen bei drn offiziellen Servern.

Quote:

Originally Posted by nikon2k 4 . Offi source : gut das du scheinbar Ahnung hast. Welches Window Interface ? Die 10 Fenster die da offen sind weil die koreaner es nicht hingekommen Server zusammen zu fassen und einfach separate threads zu starten ? ;) wozu braucht ein Account und ein login server jeweils eine eigene exe ? Von der Performance von MSSQL ganz zu schweigen . Aber koreaner lieben halt MSSQL , active x und IE :) Ich mein bei dem source wundert es mich nivht mehr wo die ganzen lags und DCs herkommen bei drn offiziellen Servern.

da 1-3 nichts mit meinem Post zu tun haben, zitiere ich mal nur Punkt 4.

Zu allererst solltest du dir mal ein Bild machen, wie die Leute von Aeon/Gala das ganze geplant haben - immerhin wird Flyff von über 10 Publishern vertrieben - das in 14 Ländern.

Die Koreaner haben Anfang 2003/04 mit dem Coding angefangen - eine Zeit, wo die Südkoreaner erst mit dem großen PC Hype angefangen haben und nicht jeder Zweite sich dort einen guten Rechner leisten konnte. Dementsprechend gabs auch nicht allzuviele gute Rechner dort und die Performance wurde auf mehrere Rechner ausgelegt - zusätzlich gelöst durch mehrere Binaries.

AccountServer ist hauptsächlich für das Billing verantwortlich - grundsätzlich OK, da das Billing stets etwas seperater vom Gameserver laufen sollte. Zusätzlich ist er für die Zuweisung der Gameserver verantwortlich.

Der Cert ist für die Publisher entwickelt worden, da in einigen Ländern (Japen und Taiwan sind da z.B. zu nennen) andere Zertifizierung von Accounts gelten, oder sogar Zeitlimits. Der checkt halt ob ein Account überhaupt spielen darf.

(Natürlich könnte man Account und Cert in einem Server verpacken, aber was du da erzählst, ist Erbsenzählerei. Ob nun 3 oder 7 Fenster, wo ist da das SIGNIFIKANTE Problem bei der Sache?)

TransServer: Sämtliche DB Verwaltung
CoreServer: Gilden/Party/Teilweise Worldverwaltung
LoginServer: Antihack/Gameguard Verwaltung
CacheServer: guess what...
WorldServer: Alles, was ingame passiert - Mover, Systeme, die diese verbinden (SR, GW, GS, RR, etc...).

Die Neuz ist halt der Client, da muss man nicht viel zu sagen.
Die Tatsache, dass die OffiServer alle massig Probleme mit Ghost-DCs und co zu tun haben, dürfte unter anderem mit dem Pingpaket oder schlechter Verschlüsselung zu tun haben. Wissen tun wir es nicht, aber ein versifftes Pingpaket ist ein wahrscheinlicher Faktor.

Ich denke, auch Sicherheit wird da eine Rolle gespielt haben. Wenn ich mich an damalige Zeiten erinnere, liefen viele Binaries (ob nun direkt bei Galas Boxes, oder bei anderen Asia Publishern) seperat auf bis zu 10 Maschinen - Worldserver nehmen stets pro Channel alleine eine Box ein, Datenbanken genauso (dein SQL Performance Argument ist völliger Schwachsinn, direkte Querys wären eine VIEL größere Belastung), Account, Cert meist auf einer Box, genauso Core und Login.

Recht hast du schon, egal was die Koreaner machen, von Microsoft weichen sie nur zu ungern ab - sei es DirectX, SQL Server oder Internet Explorer, um sich P0rns, Cracked WinXP auf den Firmen-FTP zu ziehen (kein Scheiß.)

Ich bin kein Experte, was C++ angeht - ganz im Gegenteil, man darf mich zu Recht als N00b bezeichnen. Aber zu sagen, dass Caali oder adidishen Files besser als Offi sind, kann getrost nicht dein Ernst sein (ob Potential oder nicht, es geht um das JETZT).

Im Endeffekt bringt uns allen so eine Diskussion nichts, es ist in deinem Sinne, ob du den Kram selbst erweitern willst, die Community (und alle großen Server) arbeiten auf Basis des in 2010 releasten v15 Sourcecodes und haben damit eine um längen bessere Alternative als den Caalikram, der ein Hobbyprojekt war oder den unausgereiften adidishen C# Source.

Danke twilight. Das war sehr informativ und macht auch in den aussagen Sinn . Tripledes wäre denkbar. Jetzt wäre nur die frage wo der ist lol. Ich vermute der client setzt den für die Session beim ersten connect.

Ich hab btw nie gesagt das caali adishen besser sind , nur das mir Emulatoren sympathischer sind ;) zumsl ich auch nicht det cpp pro bin allerdings mehr Ahnung von c# hab ;)

Such halt nach den 3 namensgebenden Keys.
Problem ist, diese zu finden, da sie willkürlich auftauchen, wenn man sie sucht - selbst mit Diassembler ist es schwer, die ausfindig zu machen. ;) Einziger Trost: Sie tauchen nacheinander auf.

Wie gesagt, TripleDES ist eine reine Vermutung. Früher wurde es bei denen nur für die Passwörter in den Configs verwendet (an alle anderen: da kommt nicht euer plaintext SQL PW rein :facepalm:.) Mit v17 kam dann diese Verschlüsselung auch in der list.txt hinzu.
Und da wir wissen, dass die Leute da drüben SEHR faul sind, ist für mich die Wahrscheinlichkeit von TripleDES sehr hoch. :D

Dein erster Post machte für mich doch sehr den Eindruck, als seien Emulatoren deiner Meinung nach die "besseren" Files. :p
Da ist jeder ja für sich - ich mag SQL Server und die Stored Procedures und komm prima damit klar. Andere hingegen kommen null damit zurecht und sympathisieren mehr mit MySQL und direkten Queries.

Ja da geb ich dir recht. Mir ist MySQL lieber - wobei Stored Procedures ja auch bei MySQL 5 zur Verfügung stehen (nur nutzt das kaum einer).

Stored Procedures sind zum beispiel ne Sache die ich an MSSQL mag.
Naja ich bin halt ursprünglich Web Developer (inzwischen entwickel ich sehr breitgefächert) - da ist man eher an MySQL gewöhnt :D

Ich werd mir mal TripleDES genauer anschauen (da ich bisher nur mit AES, Twofish und Blowfish was zu tun hatte, kenn ich es selbst noch nicht).

Wenn die Keys alle 3 nacheinander auftauchen , könnte man ggf. eine eine "Bruteforce" suche starten nach einer 48 Byte Binäre reihenfolge.
Ähnlich haben wir auch das 2 RSA Key Pair im MxO Client finden könnten (da sind halt 1024 Byte).

Ich schau es mir die Tage mal an .

Jetzt habe ich noch ein paar Fragen: die v15 sources die draussen sind, haben diese Verschlüsselung nicht oder ? Aber wurde das mit v15 nicht eingeführt ?
Oder sind das v14 Sources mit "v15 Features" (gleiches wohl für die angeblichen v19 sources) ?
Würde mich mal interessieren .
Ich hab zum Beispiel die angeblichen v19 files aus einem YouTube Tutorial installiert (aber halt nur kurz einmal den Client gestartet und paar Mobs platt gemacht).

Ich mein man kann ja viel mit Resourcen nachrüsten aber im Client steckt ja bestimmt auch programmierte Logik mit drin für Features von v19 ..oder kann man die ebenfalls im Resource steuern ?
Sorry für die vielen Fragen ...hab die FlyFF Szene etwas aus den Augen gelassen für nen Jahr ;)

Ês ist eine vollwertige v15 Source released. Danach kam der krims krams der User.

Ist das offizielle v15 doch noch nicht mit verschlüsselten packeten gewesen ?

Ich bin mir nicht ganz sicher, denke es war ohne.

Quote:

Originally Posted by xTwiLightx Such halt nach den 3 namensgebenden Keys. Problem ist, diese zu finden, da sie willkürlich auftauchen, wenn man sie sucht - selbst mit Diassembler ist es schwer, die ausfindig zu machen. ;) Einziger Trost: Sie tauchen nacheinander auf. Wie gesagt, TripleDES ist eine reine Vermutung. Früher wurde es bei denen nur für die Passwörter in den Configs verwendet (an alle anderen: da kommt nicht euer plaintext SQL PW rein :facepalm:.) Mit v17 kam dann diese Verschlüsselung auch in der list.txt hinzu. Und da wir wissen, dass die Leute da drüben SEHR faul sind, ist für mich die Wahrscheinlichkeit von TripleDES sehr hoch. :D Dein erster Post machte für mich doch sehr den Eindruck, als seien Emulatoren deiner Meinung nach die "besseren" Files. :p Da ist jeder ja für sich - ich mag SQL Server und die Stored Procedures und komm prima damit klar. Andere hingegen kommen null damit zurecht und sympathisieren mehr mit MySQL und direkten Queries.

FlyFF nutzt seit V16 für Config, List & DB Pw (was schon länger so genutzt wird) Trible-Des (DES3) wovon der 2. Key in der Config "+JlI¯Íê!" ist, für die Packete wird kein Trible Des verwendet, würde zuviel Performance ziehen.

Um genau zu sein, ist dass hier die FlyFF Packet Cryption:

Quote:

for ( i = 0; i < nSize; ++i ) pOutput[i] = pXORTable[byKeyIndex++] ^ pInput[i];

Die XorTable brauch ich allerdings hier nicht zu Posten, mehr ist es nicht, aber hey, ihr habt sicher wieder mehr ahnung als ich, wah? :3

Die Packet Liste von FlyFF wurde seit V16 auch geändert, Snapshot Packet ist 34603192, nichtmehr 0x....

Nun zum Window Interface was du grad angesprochen hast, dir sollte klar sein dass ich dass Window Manage im Client meinte, dies sehr gut geschrieben ist.

Dazu läuft FlyFF Komplett auf DirectX9, nicht 8 @TwiLight, einzigste Fail im Client ist dass Timing System, was FlyFF auf 60 FPS bindet, würde man diese zahl freigeben heißt Offen legen dass sie auch mal 30 oder 100 haben kann, würde man dass ganze Game Design zerstören weil alle SFX etc mit dem Ablaufen. (Danke hierbei an Clemi)

Die V15 Source wo Released ist hat keine Packet Verschlüsselung, nur diesen Checksum Schrott Namens CRC32, was man aber auch weg kicken kann, die ganzen Posi Bugs von FlyFF kommen durch dass schlechte Snapshot Handling, ich mein, der Client bekommt ab und zu eine Kette an Snapshot's, heißt es wird die Snapshot Packet ID in dass Packet gepackt, der Counter und dann die ganzen Snapshot's, diese wird vom Client mittels einer Switch Case abfrage durch gengangen was dass ganze Massiv langsam macht, dazu kann der Client in der Sekunde (!) maximal 60 Packete annehmen, was nicht gerade viel ist, warum nur 60? weil dass Recv "Thread" über die FrameMove funktion läuft die 60x in der Sekunde aufgerufen wird anhand der FrameRate. :)

Daher kann man im übrigen auch nicht einfach die Grafik von FlyFF anheben.

Wenn ich mich nicht irre, waren das hier die Keys für 3DES.

Quote:

Originally Posted by Sedrika Wenn ich mich nicht irre, waren das hier die Keys für 3DES. Code: static unsigned char keys[3][8] = { { 0x1F, 0x25, 0x38, 0x41, 0x7C, 0xBF, 0x1D, 0x1D }, { 0x2B, 0x4A, 0x6C, 0x49, 0xAF, 0xCD, 0xEA, 0x21 }, { 0x15, 0x37, 0x85, 0x51, 0xC6, 0xEC, 0x5, 0x21 } };

Config Keys, völlig nutzlos. :D

Quote:

Originally Posted by Wanetrain Config Keys, völlig nutzlos. :D

Keine Ahnung :) hatte es nur unter 3des Keys gesaved