I don't know whether this is already released or not, but here are some fixes concerning the guildbank.
For both fixes you have to edit the DPSrvr.cpp.
Ich wüsste nicht warum es sicherer wäre, zuerst den 32-Bit Integer zu prüfen und dann in einen 16-Bit Integer zu casten o.O
Wieso überhaupt casten? Verstehe den Sinn dahinter nicht. Ich weis nicht wo du deine Programmierkünste aufgefasst hast, aber in meinen Büchern wird solch ein Cast moglichst vermieden. Außer er ist unumgänglich.
Wieso sollte man überhaupt vom Client ein "DWORD" senden lassen? Wenn das Maximum eh bei 9999 liegt? Erklär mal.
Wieso überhaupt casten? Verstehe den Sinn dahinter nicht. Ich weis nicht wo du deine Programmierkünste aufgefasst hast, aber in meinen Büchern wird solch ein Cast moglichst vermieden. Außer er ist unumgänglich.
Wieso sollte man überhaupt vom Client ein "DWORD" senden lassen? Wenn das Maximum eh bei 9999 liegt? Erklär mal.
Wenn du danach gehst, müsstest du deinen ganzen Source umschreiben.
Mir persönlich ist es wayne, ob ich 2 oder 4 Byte sende und diese dann caste, auch wenn deine Bücher dagegen sprechen. Deine Bücher sprechen wahrscheinlich gegen jede 2. Zeile im Flyff Sourcecode, kannst ihn ja mal Zeile für Zeile durchgehen und überprüfen, ob was in deinen Büchern dagegen spricht.
Am sinnvollsten wäre es, den Client auch ein short schicken zu lassen, aber dann müsstest du auch wieder casten, wo dein Büchlein ja vehement gegen ist, also musst du quasi sämtliche Item Strukturen im Source umschreiben, damit dein Büchlein nicht mehr meckert.
Der Cast macht Sinn, weil, wenn du mal einen genaueren Blick auf die Zeile wirfst
und dir nochmal den Link, den du voller Stolz gepostet hast, anguckst, siehst auch du, dass ein 32-Bit Integer ebenfalls zu einem Overflow führen kann. Wie schade, dass das ganze unsigniert ist und wie schade, dass uns am Ende einfach mal 16 Bit fehlen.
Wenn du danach gehst, müsstest du deinen ganzen Source umschreiben.
Mir persönlich ist es wayne, ob ich 2 oder 4 Byte sende und diese dann caste, auch wenn deine Bücher dagegen sprechen. Deine Bücher sprechen wahrscheinlich gegen jede 2. Zeile im Flyff Sourcecode, kannst ihn ja mal Zeile für Zeile durchgehen und überprüfen, ob was in deinen Büchern dagegen spricht.
Am sinnvollsten wäre es, den Client auch ein short schicken zu lassen, aber dann müsstest du auch wieder casten, wo dein Büchlein ja vehement gegen ist, also musst du quasi sämtliche Item Strukturen im Source umschreiben, damit dein Büchlein nicht mehr meckert.
Der Cast macht Sinn, weil, wenn du mal einen genaueren Blick auf die Zeile wirfst
und dir nochmal den Link, den du voller Stolz gepostet hast, anguckst, siehst auch du, dass ein 32-Bit Integer ebenfalls zu einem Overflow führen kann. Wie schade, dass das ganze unsigniert ist und wie schade, dass uns am Ende einfach mal 16 Bit fehlen.
Mann muss bedenken das der FlyFF Source im Jahre 2000-2003~ programmiert wurde, zwischen drin updates hatte jedoch die Base jetzt schon älter als 10 fast 15 Jahre ist.
Ich verstehe nicht, was genau du casten möchtest, wenn du bereits einen short sendest. Der FlyFF Source ist wie mann bereits aus deinem Code-Schnipsel entnehmen kann auf einem short aufgebaut was die Item Anzahl angeht. Jetzt erkläre mir doch bitte noch einmal was man hier dran casten muss:
DPClient.h
PHP Code:
void SendPutItemGuildBank( BYTE nId, short ItemNum, BYTE p_Mode );
DPClient.cpp
PHP Code:
void CDPClient::SendPutItemGuildBank( BYTE nId, short ItemNum, BYTE p_Mode ) { BEFORESENDSOLE( ar, PACKETTYPE_PUTITEMGUILDBANK, DPID_UNKNOWN ); ar << nId << ItemNum << p_Mode; SEND( ar, this, DPID_SERVERPLAYER ); }
Mann muss bedenken das der FlyFF Source im Jahre 2000-2003~ programmiert wurde, zwischen drin updates hatte jedoch die Base jetzt schon älter als 10 fast 15 Jahre ist.
Ich verstehe nicht, was genau du casten möchtest, wenn du bereits einen short sendest. Der FlyFF Source ist wie mann bereits aus deinem Code-Schnipsel entnehmen kann auf einem short aufgebaut was die Item Anzahl angeht. Jetzt erkläre mir doch bitte noch einmal was man hier dran casten muss:
DPClient.h
PHP Code:
void SendPutItemGuildBank( BYTE nId, short ItemNum, BYTE p_Mode );
DPClient.cpp
PHP Code:
void CDPClient::SendPutItemGuildBank( BYTE nId, short ItemNum, BYTE p_Mode )
{
BEFORESENDSOLE( ar, PACKETTYPE_PUTITEMGUILDBANK, DPID_UNKNOWN );
ar << nId << ItemNum << p_Mode;
SEND( ar, this, DPID_SERVERPLAYER );
}
Und zum Thema Cast und deinem Buch, ist mir eben noch eingefallen, steht in deinem Buch auch, wie man Polymorphie und späte Bindung ohne Upcast realisieren kann?
Aber wir wollen das Thema jetzt auch nicht auseinanderdiskutieren wie blöde, ich halte beide Lösungen für valide und für beide werden Casts benötigt, es sei denn du änderst die Item Struktur oder lässt es als Int stehen.
Jedoch muss ich sagen, dass mit Lethals Version auch besser gefällt, da es im Endeffekt nach der Abfrage egal ist, ob nun int in short gecastet wurde oder ob bereits mit short überprüft wurde.
Und die Gschichte mit dem Flyff Source, ja, es stimmt, Objective C und C++ sind ein riesen Unterschied, aber es lohnt sich einfach nicht, neue Systeme in validem C++ zu implementieren. Das würde dem Source sämtliche gebliebene Struktur nehmen. In valid bzw native C++ wird nämlich eigentlich nicht mit etwaigen char Arrays gearbeitet wie im Source, aber lassen wir diese Diskussionen, letztendlich kommt es für mich auf die Funktionalität an.
Und zum Thema Cast und deinem Buch, ist mir eben noch eingefallen, steht in deinem Buch auch, wie man Polymorphie und späte Bindung ohne Upcast realisieren kann?
Aber wir wollen das Thema jetzt auch nicht auseinanderdiskutieren wie blöde, ich halte beide Lösungen für valide und für beide werden Casts benötigt, es sei denn du änderst die Item Struktur oder lässt es als Int stehen.
Jedoch muss ich sagen, dass mit Lethals Version auch besser gefällt, da es im Endeffekt nach der Abfrage egal ist, ob nun int in short gecastet wurde oder ob bereits mit short überprüft wurde.
Und die Gschichte mit dem Flyff Source, ja, es stimmt, Objective C und C++ sind ein riesen Unterschied, aber es lohnt sich einfach nicht, neue Systeme in validem C++ zu implementieren. Das würde dem Source sämtliche gebliebene Struktur nehmen. In valid bzw native C++ wird nämlich eigentlich nicht mit etwaigen char Arrays gearbeitet wie im Source, aber lassen wir diese Diskussionen, letztendlich kommt es für mich auf die Funktionalität an.
Müsste ich nachschauen, hatte das Buch nur erwähnt weil ich dort mal was nachgeschlagen hatte.
Jedoch handelt es sich es hier eh nur um kleinere Unterschiede.
Wobei ich das mit dem im Client casten bevorzugen würde. Da würde z.b nie ein Dupe entstehen und darum geht es ja hier.
Aber dein Fix sollte es auch beheben nur dachte ich anfangs du machst den gleichen Fehler wie die Flyff Dev und prüfst den nicht "gecasteten" Wert. Das wäre halt wieder ne Dupe Möglichkeit.
Aber ansonsten sollte es eigentlich alles so passen.
Crash, arena and honor dupe exploit, gold and emblems dupe and more for Monster etc. 04/09/2013 - WoW PServer Exploits, Hacks & Tools - 0 Replies Wrong thread, I'm sorry, delete this.
Already posted here:
http://www.elitepvpers.com/forum/wow-pserver-expl oits-hacks-tools/2530347-crash-arena-honor-dupe-ex ploit-gold-emblems-dupe-more-monster-etc.html#post 22132114
Hack Fixes(Including Dupe Hack) 08/01/2012 - Flyff PServer Guides & Releases - 0 Replies Some guy from AscensionFlyff thought he would go around trying to start server wars or something. Used a dupe exploit in the Flyff source(wasn't too hard to find). Here's the fix for it since he lied to me about the exploit being in my code.
Dupe Fix:
I'll update this if he uses any more exploits on my server.
Update - Dupe explanation I posted on another forum: