Xenox3 (16.01.10)
Hey
Ich kenne mich inzwischen gut mit detours,hooken, speicheradressen, lua in c++ und so manche andren tollen sachen aus, die ich mit c++ programmiere.
Da ich wie immer langeweile hab wollte ich an einem kleinen Automaton rumbasteln ich bekomm die Pakete 0 probleme. ich kann sie absenden auch kein Problem.
Mein Problem ist nur wie kann ich ein packet so erstellen das es z.B. Eine Message in den Chat schreibt.Ich schon ein bisschen was von Packeten gehört aber kenn mich gar nicht so recht mit ihnen aus. Es gibt bei Flyff eine Packet strukture die hab ich mir angeschaut aber die hilft mir da leider auch nicht arg viel weiter :D
mfg Xenox3
Ne frage kann man sich mit packeten Lg´s und so cheaten?
Nein, kann man nicht!
Sorry für OT
Nein, man kann sich keine LGs durch packets cheaten
Zu deiner Frage Xenox3, einfach mal sniffen.
Erstell dir 4-5 Chars, logg dich ein, sniff die packets während du einen Text spammst (Die packets die gleich sind, benutzt du)
Dann machste das selbe mit einem anderen Char (Selber text), dann suchst du die Unbterschiede in den Packets.
Dadurch findest du den Namen/MoverID etc raus.
Probieren macht immernoch am meisten Spaß ;)
PS : Ich hab mich nie mit GameHackin / FlyFF Hacking beschäftigt, sondern nur ab und zu mal
bisschen an Sachen rumgespielt aber nie ernsthaft drangesetzt...
Geändert von Vendetta (07.01.10 um 18:08 Uhr)
jo das werd ich ma machen aber da gibts doch ihrgendwie so ne session id oder sowaS ?!
hat jemand davon ne ahnung
generelle Packetstruktur:
Code:[header] [data length checksum] [data length] [data checksum] [data] header: konstante die immer 0x5e beträgt data length checksum: ( CRC32-IEEE_802.3( data length ) xor 0xffffffff ) xor SessionID data length: Anzahl der bytes der data data checksum: ( CRC32-IEEE_802.3( data ) xor 0xffffffff ) xor SessionID data: enthält essentielle informationen für den server (Jede Data eines packetes, welches zum WorldServer gesendet wird, beginnt mit einem opcode, der dem server den Packet Typen mitteilt ( attack packet, drop packet, ... )) Die sessionID ist die erste Information, die der Client vom Server empfängt. Dies geschieht beim Verbindungsaufbau SessionID packet structur: 5e 08 00 00 00 00 00 00 00 [INT:SessionID]
Geändert von x0rain (16.01.10 um 22:15 Uhr)
Xenox3 (16.01.10)
omg TY :D genau das war mein problem wie ich die id raus bekomme
Anfang ????? Länge ?????? Kp ist immer so LängeData ????? Data
[5e] [2b 8a 32 93] [0f 00 00 00] [04 e6 68 ce] [ff ff ff ff 00 00 ff 00] [03] [00 00 00] [68 69 31]
[5e] [4e ed 8e 2b] [0e 00 00 00] [20 25 23 e7] [ff ff ff ff 00 00 ff 00] [02] [00 00 00] [68 69]
[5e] [b5 5a 2a 14] [14 00 00 00] [8e a5 71 4e] [ff ff ff ff 00 00 ff 00] [08] [00 00 00] [2f 73 20 68 69 31 32 33]
[5e] [ab 6c 65 28] [0e 00 00 00] [c5 a4 c8 e4] [ff ff ff ff 00 00 ff 00] [02] [00 00 00] [68 69]
wie man die 2 hashs raus bekommt ist das einzige problem die ändern sich andauernd-.-
Wir splitten eins deiner packete mal komplett auf:
Data Length Checksum (HASH NR1): Wir inverten ( xor 0xffffffff ) den CRC-32-IEEE_802.3 Hash der Data Länge ( die in diesem fall 15 beträgt ( siehe Data Length ) ) und xorn diesen mit der SessionID ( welche dem Client mittels des ersten Packets mitgeteilt wird. Sie setzt sich dort aus den bytes 10 - 13 zusammen )Code:[5e] --> Header [2b 8a 32 93] --> Data Length Checksum [0f 00 00 00] --> Data Length [04 e6 68 ce] --> Data Checksum [ff ff ff ff 00 00 ff 00 03 00 00 00 68 69 31] --> Data
Data Length: Little endian der byte anzahl der data ( ff ff ff ff 00 00 ff 00 03 00 00 00 68 69 31 )
Data Checksum (HASH NR2): siehe Data Length Checksum. Replace jedoch die Data Länge mit der Data ( ff ff ff ff 00 00 ff 00 03 00 00 00 68 69 31 )
Edit:
Vielleicht helfen dir einer dieser beiden source codes den zusammenhang zu verstehen ( leider kann ich nicht so gut c++):
Code:#Python Code ( CREDITS TO NFORCE ): from struct import pack, unpack from binascii import crc32 key = unpack ( '<L', '\x48\x6e\xa3\x19' ) [ 0 ] #SessionID data = '\xff\xff\xff\xff\x00\x00\xff\x00\x03\x00\x00\x00\x6d\x75\x68' result = pack ( '<BLLL', 0x5e, # Protocol byte ~crc32 ( pack ( '<L', len ( data ) ) ) ^ key, # Checksum of length len ( data ), # Length ~crc32 ( data ) ^ key # Checksum of data ) + data for x in result: print '%02x' % ord ( x ), print
Geändert von x0rain (16.02.10 um 15:26 Uhr)
Sehr schön erklärt.
Ah ich verstehe :D jetzt muss ich das nur ihrgendwie in c++ rein bekommen :D
wiso muss sowas auch immer so kompliziert sein :D
Hallo,
Ich hab dazu mal ne Frage,
Als ich mich eingeloggt hab hat der Flyff-Server mir folgendes Paket geschickt:
ich hab angenommen dass [d1 c5 d7 19] also die Session ID ist (oder?).Code:[5e] [08 00 00 00] [00 00 00 00] [d1 c5 d7 19]
Dann hat mein Client dem Flyffserver meine Zugangsdaten geschickt.
Darauf hat der Flyffserver mir wieder die Infos wie z.B. Chardaten und Realmdaten(also die versch Server z.b. Augu + ip und so) geschickt.Danach
schickt er mit ein Paket
Es sieht folgend aus:
Wo liegt hier der Fehler ? Ist die ID-Falsch ?Code:[5e] [65 72 0e 48] [04 00 00 00] [fa 25 17 18] [14 00 00 00] [5e] --> Header [65 72 0e 48] --> checksum data length [04 00 00 00] --> data length (hier 4 byte) [fa 25 17 18] --> checksum data [14 00 00 00] --> data (ka was des bedeutet) Jetzt wir [04 00 00 00] (eig [00 00 00 04]) invertiert (xor mit [FF FF FF FF]) -> [FB FF FF FF] ([FF FF FF FB]). Wenn wir des mit der SESSION-ID xor-en kommt folgendes Raus: [2A 3A 28 E6] ([E6 28 3A 2A]) des hat aber leider nichts mit der data length checksum zu tun. Ich hab des noch mal anders rum gemacht d.h. checksum genommen und invertierte data length um den "Schlüssel" heraus zu bekommen. Der ist hier: [9a 8d f1 b7].
Hoffe auf Hilfe.
MFG Funjoker^^
Geändert von funjoker (17.01.10 um 11:28 Uhr)
berrechnung der sessionid:
[d1 c5 d7 19] ---[reverse]---> [19 d7 c5 d1] ---[dec]---> 433571281
Berechnung der Data Length Checksum:
( CRC32-IEEE-802.3 ( BitConverter.GetBytes(4) ) xor 0xffffffff ) xor 433571281
Das Ergebnis noch in Hex umwandeln und dann reversen ([01 02 03 04] -> [04 03 02 01])
(Bei mir gibt die crc32 funktion eine dezimal Zahl wieder anstatt einer hexadecimal Zahl)
Dein fehler: Du darfst nicht die länge mit 0xffffffff xor'n sondern musst diese erst mit der crc32 funktion hashen. Der errechnete Hash wird anschließend mit 0xffffffff (= -1) gexor'd
Geändert von x0rain (17.01.10 um 13:21 Uhr)
I don't get it
also nochmal langsam:
Ich habe ( CRC32-IEEE-802.3 ( 4 ) xor 0xffffffff ) xor 433571281 d.h. also erstes CRC32-IEEE-802.3 ( 4 ) xor 0xffffffff des ist 0x00000004 xor 0xffffffff = 0xfffffffb (oder?) und jetzt 433571281 mit 0xfffffffb (oder?). Deshab ich immer über Bits gemacht (geht des anders? ich progge eigg in java und da mach ich des Bitweise (also mach die beide zu Binärzahlen und dann ganz einfach xor pro bit)) und habs nochmal mit dem Calculator [Um Links zu sehen registriere dich bitte. Klicke hier.] gemacht. da kommt bei mir [16 28 3a 2a] raus des jetzt noch reversen [2a 3a 28 16]. Des passt immernoch nicht^^
Ich bin viel zu doof xD
mfg funjoker^^
CRC32 ( BitConverter.GetBytes(4) ) --> 1373222836
1373222836 Xor 433571281 --> 1208906341
1208906341 ---[Hex]---> 480e7265 ---[reverse]---> 65720e48
Welche CRC32 Funktion benutzt du? (ich hab hier mal das xor 0xffffffff weggelassen das dies schon in meiner crc32 funktion getan wird.
Edit: Sorry ich hatte die Funktion BitConverter.GetBytes() vergessen einzubauen aber eigentlich muss bei deiner CRC32 funktion dabei stehen wie man die benutzt ( Das ist auf die bezogen die ich benutzte .. siehe source code ). BitConverter.GetBytes(4) --> {4 & 255, 4 >> 8 & 255, 4 >> 16 & 255, 4 >> 24 & 255}
Geändert von x0rain (16.02.10 um 15:25 Uhr)
Lesezeichen