How to 'Packet Sniff'. (English and German)
How to 'Packet Sniff'. (English and German)
Credits go to:
Walter Sobchak
ENGLISH :
Packets - Sniffing & Analysis
[UPDATE] - 082408 - Added another Chapter to the Packet Analysis named "Extended Structure Analysis"
:: Content ::
1. What do I need ?
^---> Download links
2. First arrangements
^---> Setting up WPE
^---> Setting up Windows Calculator
3. Sniffing Packets
4. Analyzing Packets
^---> The Structure
^---> Extended Structure Analysis
^---> The Encryption
-----------------------------------------------------
1. What do you need ?
Well at first you need the following things :
Windows
WPE
Windows Calculator - well I guess you're using Windows
A Hex-Editor, or notepad (I'll use HexWorkshop)
-----------------------------------------------------
2. First arrangements
Start WPE and go to View -> Options
and change the settings for "Winsock 2.0" like this :
Why ? Because if the app you will sniff packets on is using Winsock 2.0
WPE will capture them. Since as for default the winsock 2.0 settings are
disabled in WPE.
Ok now you start the Windows Calculator. Either using [WINDOWS-KEY]+[R]
and entering "calc" or starting it from your Startmenu and your Programs
folder. Now when the calculator is open go to View and change to "Scientific"
so you'll be able do deal with hexadecimal stuff.
-----------------------------------------------------
3. Sniffing Packets
Lets sniff some Packets.
Start any app, I am using the Internet Explorer in my example.
Now start WPE and select the Internet Explorer Process.
Click on the "Target program" button.
And select the Internet Explorer or iexplore.exe
Now we can start the sniffing clicking this button :
Now lets navigate the Internet Explorer to "www.mpgh.net/forum".
Ok now check the Gauge-Window to see if WPE really captured some packets.
So after the page fully loaded my Gauge looked like this :
This doesn't have to be the same for all of you, it can vary.
Now we can stop the sniffing using the red Stop-Button we all know from our
VRC-times ;D
Your WPE should now look like this :
Of course it doesn't have to look exactly like this.
So this is where you can view the captured packets.
I guess this is enough with sniffing, I guess you could sniff all apps,
games or whatever you want now.
-----------------------------------------------------
4. Analyzing Packets
The Structure
Well as for my examples I will use a fictive game. Since this should be an
universal tutorial and not only for one game. Please consider that I can't
write this tutorial for all games/apps and for all packet structures there
are on earth, just try to do it yourself.
Well lets say we have a game called "JungleBob Online" (although the name is
irrelevant, i just wanted to use the name ;D).
We start the game and wait for the login screen to appear. Now we start our
WPE application and select the JungleBob.exe and start sniffing packets.
Lets try to log in with "myusername" as username and "mypassword" as password.
Ok this username does not exist in our game and is not ours but we will use it
to test the packets.
Now stop the sniffing process and look at the first packet which was sent from
the client to the server.
Our packet should look like this :
(in WPE you will see the packet in HEX-Mode on the left, and the same packet
in ASCII-Mode on the right side)
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
(i write it with spaces between every hex value so its easier to read)
So what do we know ? We used the username "myusername" and the password
"mypassword" and WPE tells us our packets size is 36.
Now lets check the bytes. When working with bytes you have to know that
theres a reversed byte order for values... means...
(I hope you know what hexadecimal is)
PS: For all the experts who want to flame me after i post this ... i
know its called Little Endian and Big Endian and has something to do with
the bit-order, but i don't want to explain it here... since this tutorial
is for "beginners".
If you have a decimal value 1 the normal hex value will be 01.
If we have a 2 byte delimiter (called WORD or 16bit integer) the value will
look like 00 01, if we have a 4 byte delimiter (called DWORD or 32bit integer)
it will look like 00 00 00 01.
So thats the normal byte order, if we have the reversed byte order everything
is ... yeah ... reversed.... so our value will look like this :
(as 2 bytes)
original : 00 01 reversed : 01 00
(as 4 bytes)
original : 00 00 00 01 reversed : 01 00 00 00
So now lets check our login-packet again.
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
As we know most values are either displayed as 2 or 4 bytes we can
start checking our login-packet.
The first 2 bytes look like a value.
22 00
reversed : 00 22
Start your calculator and change the view from Dec(standard) to Hex.
Now enter your hex value 0022 (of course without the spaces).
Now change the view to Dec again and you see our value is 34.
Lets check the packet-size again ... WPE is saying our packet is 36
bytes long. Do you see the parallels ? Our packet-size minus our 2
bytes at the beginning = 34.
So the first 2 bytes are indicating the packet length that will follow.
(It has not to be this way ... the length can be on the 4. position
or somewhere else...)
In my example the 2 bytes which are indicating the length aren't
included in the length, that's because some games which use encrypted
packets are doing it also this way, cause they do encrypt all the bytes
excepting the packet length (in most cases the first 1, 2 or 4 bytes).
But you shouldn't care about encryption now, since our packet seems to be
sent in plain text. You know that cause when you look at the ASCII-Mode
you see our username and password we used before.
Ok What we know is the first 2 bytes indicate the packet length. But
what about the rest ? Well since I'm doing this for a long time know in
most cases the next few bytes are a command or the "packet-header" (its
not a real "header" but i just call it this way). How to test this ?
Just sniff another login-packet in our game and change the username and
password you enter to something else (no matter what). The value should
not change.
Ok now we know 11 00 is our command (or "header"). You don't have to
deal with this 2 bytes in dec, its just a hexadecimal header used for
the packet protocol the developers created for the game. Like 11 00 is
the login 12 00 is the getserverlist-packet and so on, you got what I mean ?
Wow we already discovered so much now lets continue. We look at the
ASCII-Mode and it seems to be that the next value is our username
"myusername" but whats that ? There are so many 00s following our
username in the HEX-Mode.
Why's that ? Well most games have a limit for the username and password
the user can enter. In most cases its either 12, 16, 24, 28 or 32
characters of length.
So for an easier packet protocol they set the length of the buffers or
variables for the username and password static ....
Like if our buffer has a length of 5 and we write "lol" into it the buffer will look like this :
6C 6F 6C 00 00
So now we know how the login-packets structure looks like :
2B = 2 Bytes
4B = 4 Bytes
XB = X Bytes
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
<LENGTH>.2B <HEADER>.2B <USERNAME>.16B <PASSWORD>.16B
So thats the basic guide to analyze a packet. Well the thing is you
will have to deal with a lot of values...
Like you login and the server responds with some 4 byte values... just
write them onto a piece of paper and check the next packets which are sent.
So you can discover their function. Like the server responds with a 4
byte sessionID which the client next sends to the character server to
authenticate himself, and so on.
4. Analyzing Packets
Extended Structure Analysis
Ok since some people told me such a login-procedure is kinda easy I'd
like to add an extended structure analysis chapter here. In the following
example I will show (or simulate) a login-procedure with serverresponses
and finally the "worldlist selection". Well since most mmorpgs use
more than one servers or "worlds" I will try to show you here, how
most of the stuff is done basically.
Well we start right under the login-procedur we analyzed in the
chapter above. Now lets assume we sent our login packet.
So now we're waiting for the server to respond. What do we know ?
If our login is false, the server has to tell that the client
so that the client can give us an error message, else it will
give us an ok and let us through.
Now lets again assume we sent our login packet and received a
packet from the server. Wow whats with the client ?
It says wrong password, did we type something wrong?
Lets check the packet (which could look like this) :
04 00 12 00 02 00
<LENGTH>.2B <HEADER>.2B <UNKNOWN>.2B
So thats the packet the server sends us, telling the client
the password is wrong. I already colored the stuff we learned
in the above tutorials.
But whats the last 2 bytes for ? Well thats probably a flag, telling the
client whether the login was successful or not. Just do some checks and log
in with some fictive username which does not exist in the game and the
packet could look like this :
04 00 12 00 01 00
Now the client tells you "This Accountname is not available, please register first."
So now we surely know, the last 2 bytes is the login-flag.
You can again reverse it and transform it from hex to dec using your
calculator. Basically you don't have to do it since you already see
what values it'll be, but if you're still not that good in hexadecimal use
the calculator.
So thats the flags we know for now :
original : 01 00 reversed : 00 01 dec : 1
original : 02 00 reversed : 00 02 dec : 2
So thats basically a server variable transformed into a WORD ( 2 bytes ).
So when we have a successful login the flag maybe 00 00 and would tell
the client "hey the login was successful, go on". But since we still don't
know what the flag would look like when we had a successful login,
we go on and test it.
Log in with your username and password and the server
responds something like that :
08 00 12 00 00 00 C6 6F 5D A1
<LENGTH>.2B <HEADER>.2B <LOGINFLAG>.2B <UNKNOWN>.4B
So what do we know ? The first two bytes indicate the length.
Next is the header, then the flag (which seems to be 0 in dec)
and some DWORD (4 bytes) value. I already colored the stuff we know once again.
Ok what could this new value be ? We still don't know...
Lets reverse it and transform it into dec using our calc.
original : C6 6F 5D A1 reversed : A1 5D 6F C6 dec : 2707255238
Wow whats with this value ? Well we don't know it yet ... lets go
on with our packet analysis... Just write down the original 4 bytes
and look for it in the next packets. So we could be able to
analyze the function of this 4 bytes.
Get ingame and redo, or continue the sniffing.
Ok now we have the worldserver-selection screen in our game.
Lets check the new packets we captured.
Mh the client seems to send something to the server after our
above packet (12 00). Well that could be a request
to get the worldserverlist.
The packet looks like this :
02 00 13 00
Seems to be nothing great in here, just the length and
the flag. Thats the way the serverlist is requested by the client.
Next we see a packet we received from the server. As you probably can see
in the ASCII-View in WPE there are some strings in plain text,
prolly the servernames. Let's see what we got :
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
Wow thats our first long packet. WPE shows our total size 59.
And the first two bytes tell us 57.
So you remember the total size - 2 (the first two bytes) = the length of our data.
Well lets see, what do we know ?
We see the length, and the header, but what is next ?
Check the ASCII-View in WPE again. There are three names in plaintext...
The Jungle, The Beach and The Land. Thats our servernames.
So we have 3 servers. Now it seems that the 5. byte of the packet ( 03 )
tells us how many servers we got in the list.
We have 3 here so the hex for 3 is 03. So after this servercount we already
have our servername "The Jungle", but whats that ? There are those
00s again. Well that means the same we had before with our username
and password, you remember ? It seems that the maximum length of a
servername is 12 (use the ASCII-View and the HEX-View parallel in WPE to count it)
thats why the unused place is filled with 00. So what do we know, what
information does such a server list has to store ?
Well it has to tell the client the name of the server, the ip and
the port where the client should next connect right ?
Well most IPs are sent as 4 single bytes, some servers also send
them as plain text. Lets assume our server sends it using a DWORD.
What would this look like... well let's do an example.
We have the IP address 212.178.67.42.
Now you split it into 4 independent values :
212 178 67 42 (so just "remove" the dots).
Now every single value will be converted into hex using our calculator.
212 = D4
178 = B2
67 = 43
42 = 2A
So our DWORD (4 bytes) is D4 B2 43 2A.
(do not reverse this!, since its 4 single values and not ONE big value)
So basically what did we do ?
212.178.67.42
^
|-Remove the dots
v
212 178 67 42
^
|-Convert every single value to hex
v
D4 B2 43 2A
Now lets check our packet again... whats after the servername.
Well in such cases you just have to play around with the values.
Pick every byte and convert it ... either byte for byte
(to see if its an ip address) or 2 bytes at once (reversed!) or 4 bytes
at once (reversed!). So after we played around a bit we found out
that the next 4 bytes after the servername indicate the ip address.
Lets check it.
D9 D0 2C 12
^
|-Convert it to dec
v
217 208 44 18
^
|-Add the dots
v
217.208.44.18
Well that seems to be an IP-address, if you're not sure, just ping
it or something else. Well... we already got the servername,
the ip... but whats with the port ?
Check the next bytes of our packet, there are still 2 bytes
left until the next servername begins.
Well the maximum value a port can have is 65535, thats basically
the maximum value a 16bit-integer (also called short or word) can be.
Type 65535 (dec) into your calculator and convert it to hex.
What do we have here ? FF FF - Two bytes, huh ?
Well it seems we found our port value.
The 2 bytes after the ip-address seems to be our port.
Lets convert it (remember : thats a normal value again, so we have to reverse it)
original : D0 07 reversed : 07 D0 dec : 2000
The port of the first worldserver seems to be 2000.
So I guess you could do the rest of the packet on your own...
Now let's collect all data we found and build a structure
(I'll basically do it with collors in here)
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
<LENGTH>.2B <HEADER>.2B <SERVERCOUNT>.1B
{ //for every servercount :
<SERVERNAME>.12B <IP>.4B <PORT>.2B
}
So the serverinformation we can gather from this packet is :
(I'll use "--" as delimiter, no real function for that, if you wonder)
Servername -- IP -- Port
The Jungle -- 217.208.44.18 -- 2000
The Beach -- 217.208.44.19 -- 2000
The Land -- 217.208.44.20 -- 2000
Ok now lets get back to the game, choose a server and sniff the packets.
(Thats the last packet I'll discuss here lol)
Now after you've chosen the server, the client connects to this
(see ip and ports we found out above) and we get the character list.
But lets see what really happens after the client successfully
connected to the worldserver.
The client seems to send a packet to the worldserver.
06 00 15 00 C6 6F 5D A1
Oh whats this ? This is our value from above that we got from the server
after we successfully logged in, remember ?
And now the server sends it again to the worldserver ???
Well yeah, thats kinda an authentication-method most mmorpgs use.
Look... you log in using "John" as username and "12345"
(irrelevant in my example) as password. Now the server checks whether this
information is right or not. In our example ... if the information IS correct,
the server generates a DWORD ( 4 bytes ) or 32bit Integer value stores
it and sends it back to the client. Thats called sessionid
(most websites which have a login-interface also use this kind of
authentication, but of course if can vary).
Now after the client has chosen a worldserver he would like he connects
to it and sends his sessionid.
Well since the login server and the worldserver are "seperated from each other"
(or basically two different applications) the world server does need
this value to check whether someone really logged in before and got
this sessionid. Since the loginserver stored our sessionid
(in a database or whereever) the worldserver just checks whether
the sessionid is available.
Normally the sessionid is deleted when the client disconnects
from the game, the server or whatever.
Well ... now thats the part where I stop. I won't update the encryption chapter
since its basically the same for everything. If you know how to decrypt one
packet, you basically know how to decrypt every packet of one game.
4. Analyzing Packets
The Encryption
Well I won't be writing to much in here, since you can't tell just
from looking at the packets what kind of encryption it is. Well of
course you can, but not in all cases.
I will just write some hints down.
Like lets assume we capture a login-packet of a mmorpg.
(remember our login packet from above ?)
You shouldn't be able to read your username or password in
ASCII-Mode now anymore.
At first do some checks, like the one with the first 2 bytes beeing
the length and so on. Well next you can redo the sniff at the login
process and see if the bytes do change ( of course use the same
username and password as before ). Using that method you can say
whether the encryption is static or not. Next do the checks like
the one sniffing more login packets where you use fictive
usernames and password which vary in length and see if some
values change.
Well now you could do some basic analysis. Like lets assume we
have a login packet which looks like this
( we used the username and password as before "myusername" and "mypassword") :
22 00 66 77 1A 0E 02 04 12 05 19 16 1A 12 77 77 77 77 77 77 1A 0E 07 16 04 04 00 18 05 13 77 77 77 77 77 77
Now we see the first two bytes and do the length check.
Ok its works, it seems to be the packet length.
Now do the check with the other username and passwords...
You will notice that the first four bytes do not change.
That means starting from the 5. byte there is our
username and password data.
I hope you know how to use a HexEditor for the next steps
(well thats what I do, you can also use notepad).
Lets write down the packet beginning at the 5. byte
It looks like that to me, using HexWorkshop :
So we see there are some bytes beeing 77 ...
Seems to be strange huh ?
Lets write down our username and password under the exact
positions of both values
(the 77 does seem to be placeholders, since their the same everywhere right?)
My Hex-Editor looks like this :
Wow whats that ? Our username and password does exactly fit
into the encrypted packet data.
Well that could be a XOR-Encryption ( Exclusive or - Wikipedia, the free encyclopedia ).
How to test it ?
Start your calculator (the windows one ;D) and be sure "Hex" is checked.
Now type in the first byte of the value which could be your username.
In our case its 1A. So we type 1A into the calculator. Now we
look at the line under the encrypted data, and see that 6D in
hex stands for a "m" in ASCII.
Now when you already typed 1A into your calculator hit the XOR-Button...
then type in our hex value for "m" (6D) and hit enter.
Our result is 77. Strange isn't it ?
Now lets do the check.
Take the next byte of our encrypted data. In our case its 0E.
Type 0E into the calculator, press the XOR-Button, type 77 and hit enter.
You should get 79 now which is the hex value for "y".
Well it seems we have a static XOR-Encryption using the key 77 here.
So you'll be able to decrypt all the packet data of our game using
the XOR method and the key 77.
An implementation into a programming language could look like this
Code:
Well thats the end of my tutorial. I hope it's not to complicated and I
didn't mix up to much things. I hope you enjoyed it.
__________________________________________________ __________________________________________________ _____________________________
GERMAN : (Translated by psych0o)
Packets - Sniffing & Analysis
:: Inhalt ::
1. Was brauche ich ?
^---> Download links
2. Erste Einstellungen
^---> Einstellungen für WPE
^---> Einstellungen für den Windows Rechner
3. Pakte sniffen (abfangen)
4. Pakete analysieren
^---> Die Struktur
^---> Erweiterte Struktur Analyse
^---> Die Verschlüsselung
-----------------------------------------------------
1. Was brauche ich ?
Benötigt werden diese Programme:
Windows
WPE
Windows Rechner - ist bei Windows standartmäßíg installiert
Einen Hex-Editor, oder Notepad (Ich werde HexWorkshop benutzen)
-----------------------------------------------------
2. Erste Einstellungen
Starte WPE und gehe im Menü auf View -> Options
und ändere die Einstellungen für "Winsock 2.0" in diese:
Warum ? Wenn das Programm, von dem du die Pakete sniffen willst, WINSOCK 2.0 benutzt, wird WPE dadurch in der Lage sein, diese zu sniffen, da die WINSOCK 2.0 Einstellungen standartmäßig DEAKTIVIERT sind.
Nun starte den Windows Taschenrechner. Entweder über die Tastenkürzel [WINDOWS-TASTE]+[R], wo du dann "calc" eingibst, oder über das Startmenü (Start -> Alle Programme -> Zubehör -> Rechner).
Sobald der Taschenrechner geöffnet ist, klicke auf "Ansicht" und wähle dort "Wissenschaftlich", so dass man Hexdezimale Zahlen benutzen kann.
-----------------------------------------------------
3. Pakete sniffen (abfangen)
Lasst uns nun ein paar Pakete sniffen.
Für dieses Beispiel nehmen wir den Internet Explorer. Starte also diesen.
Nun startest du WPE und wählst den Internet Explorer Prozess aus.
Klicke auf den "Target Program" Button.
Und wähle den Internet Explorer (iexplore.exe) aus.
Nun können wir das Sniffen starten, in dem wir diesen Knopf drücken:
Lasst uns nun im Internet Explorer die Seite "www.mpgh.net/forum" aufrufen.
Ok nun prüf die Messgrafiken um zu sehen, ob WPE wirklich Pakete aufnimmt.
Nachdem die Seite komplett geladen wurde, sieht die Messgrafik bei mir so aus;
Dieses muss bei euch nicht genauso aussehen, es kann variieren.
Halte nun das Sniffing an, in dem du den roten Stop-Knopf drückst, den wir alle von einem Videorecorder kennen.
Nun sollte WPE in etwa so aussehen:
Natürlich muss es bei euch nicht wieder genau so aussehen.
Ihr seht dort nun die abgefangenen Paketed packets.
Ich vermute, dass wir nun genug über das Sniffing geredet haben und dass du nun in der Lage bist, alle Programme und Spiele zu sniffen.
-----------------------------------------------------
4. Pakete analysieren
Die Struktur
Ich werde hier als Beispiel ein fiktives Spiel benutzen, da das Tutorial auf andere Spiele anwendbar sein soll und nicht nur für eins.
Bitte habt verständnis dafür, dass ich dieses Tutorial nicht für jedes Spiel/Programm schreiben kann und auch nicht für jede Paketstruktur, die es auf der Welt gibt.
Probiert es einfach selber aus.
Nehmen wir nun an, wir haben ein Spiel anmens "JungleBob Online" (Der Name spielt keine Rolle, ich wollte bloß einen Namen benutzen)
Wir starten das Spiel und warten auf den Loginbildschirm. Nun starten wir WPE und wählen "JungleBob.exe" aus und starten das Sniffen.
Last uns versuchen mit dem Benutzernamen "myusername" und dem Passwort "mypassword" einzuloggen.
Ok, dieser Benutzername exestiert nicht in unserem Spiel und er gehört nicht uns. Wir verwenden das nur zum testen der Pakete.
Nun stoppen wir den Sniffing-Vorgang und schauen uns die ersten Pakete an, welche vom Client (also dem Spiel) zu dem Server geschickt wurden.
Unsere Pakete sollten in etwa so aussehen:
(in WPE werden die Pakete links als HEX-Dezimal angezeigt und rechts als ASCII Zeichen)
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
(Ich habe es mit Leerzeichen geschrieben, damit man es besser lesen kann)
Was wissen wir nun? Wir benutzten den Benutzernamen "myusername" und das Passwort "mypassword" und WPE sagt uns, dass die Paketgröße 36 Bytes ist.
Prüfen wir also mal diese Bytes. Wenn wir mit Bytes arbeiten müssen wir wissen,
dass dort eine umgekehrte Byte-Anordnung für die Werte ist.
(Ich hoffe ihr wisst, was Hexdezimal ist. Wenn nicht, lernt erst etwas über das Hexdezimal System)
P.S.: Für alle Experten hier, die mich gleich anflamen... Ich weiß, dass es "Little Endian" und "Big Endian" heisst und es was mit der Bit-Anordnung zu tun hat.
Aber ich möchte das hier nicht weiter erklären, weil dieses Tutorial sich an Anfänger richtet.
Wenn du einen Dezimalwert von 1 hast, ist sein Hexwert 01.
Wenn du einen 2-Byte Delimiter haben (WORD oder 16bit Integer genannt), sieht der Wert so aus: 00 01
Wenn wir einen 4-Byte Delimiter haben (DWORD oder 32bit Integer genannt), sieht der Wert so aus: 00 00 00 01
Also immer 2-Bytes oder 4-Bytes bis zum nächsten Wert.
Das ist die normale Byte-Anordnung.
Bei einer umgekehrten Anordnung sieht alles... umgekehrt aus.. Also sehen unsere Werte so aus:
(Als 2-bytes)
Original: 00 01 Umgekehrt: 01 00
(Als 4-bytes)
Original: 00 00 00 01 Umgekehrt: 01 00 00 00
Lasst uns nun nochmal das Login-Paket anschauen.
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
Wie wir wissen, werden die Werte entweder als 2-Byte oder 4-Byte getrennt angezeigt. Damit können wir nun unsere Loginpaket prüfen.
Die ersten 2 Bytes sehen aus wie ein Wert.
22 00
Umgekehrt : 00 22
Startet euren Windows Rechner und ändert die Ansicht von Dez(DEC) (Standart) auf Hex.
Nun gebt als Hex Wert ein: 0022 (natürlich ohne leerzeichen)
Nun ändert die Ansicht erneut auf Dec (Dezimal).
Vergleicht nun mit der Paket-Größe, die uns WPE genannt hat (36 bytes)
Siehst du die Parallele? Unsere Paketgröße minus den 2 Bytes, die wir gerade genommen haben ergibt 34.
Also werden durch die ersten 2 Bytes die restigen Anzahl an Bytes des Pakets angegeben.
(Doch es kann auch an anderen Stellen (z.B. der 4. Stelle) vorkommen)
In meinem Beispiel sind die 2-Bytes, welche die Größe angeben, nicht in die die Paketgröße mit einbezogen, weil viele Spiele verschlüsselungen für die Pakete benutzen, so dass alle Pakete, bis auf die Bytes, die die Größe angeben, verschlüsselt sind.
Die Bytes, die die Größe angeben sind meistens die ersten, zweiten oder vierten Bytes.
Aber du solltest dir jetzt noch nicht soviele Gedanken um die Verschlüsselung machen, da diese Pakete im Beispiel unverschlüsselt als Plain-Text (reiner Text) sind.
Dadurch kann man den Benutzernamen und das Passwort im ASCII-Fenster (rechts) sehen, welche wir vorher festgelegt haben.
Wir wissen nun, dass die ersten 2 Bytes die Paket-Länge angeben.
Aber was ist mit dem Rest? Nun, da ich das schon eine ganze Weile mache, weiß ich, dass die nächsten paar Bytes ein Befehl oder der "Paket-Kopf" (Header) sind.
(Ich weiß, dass es nicht der wirkliche "Paket-Header" ist, aber zur besseren veranschaulichung, definiere ich es hier so)
Wie testen wir das nun?
Sniff nun weitere Login-Pakete, in dem du einen anderen Benutzernamen und ein anderes Passwort angibst (welche ist egal).
Bis auf die Bytes, die den Benutzernamen und das Passwort enthalten, sollten sich die Werte nicht ändern.
Ok wir wissen nun, dass 11 00 unser Befehl (oder Kopf) ist. Du brauchst das nicht in Dezimal umrechnen.
Es ist einfach ein Hexdezimaler Header, den die Spieleprogrammierer als "Paket Protokoll" erstellt haben.
11 00 ist der Login, 12 00 ist das "getserverlist"-Paket (Serverliste holen) und so weiter und so weiter.
Verstanden was ich meine?
Ok wir haben viel rausgefunden. Lasst uns weiter machen.
Wir schauen auf das ASCII-Fenster und es sieht so aus, dass der nächste Wert der Benutzer (myusername) ist.
Aber was haben die ganzen 00en zu bedeuten, die nach dem Benutzernamen folgen?
Ganz einfach: Die meisten Spiele haben ein Limit für die Länge von Benutzername und Passwort.
In den meisten fällen ist es eine Länge von 12, 16, 24, 28 oder 32 Zeichen.
Damit es einfacher ist, haben die Programmierer die Länge für den Benutzernamen und das Passwort festgesetzt (static)
Wenn unser Puffer nun eine Länge von 5 hat und wir "lol" reinschreiben, dann sieht das so aus:
6C 6F 6C 00 00
Wir wissen nun also, dass die Login-Paket Struktur so aussieht:
2B = 2 Bytes
4B = 4 Bytes
XB = X Bytes
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
<LÄNGE>.2B <KOPF>.2B <USERNAME>.16B <PASSWORT>.16B
Das ist eine Grundanleitung für das Analysieren von Paketen.
Die Sache ist nur, dass du mit vielen Werten rumhantieren musst.
Wie z.B. wenn der Server auf den Login mit einem 4-Byte Wert antwortet.
Einfach auf ein stück Papier schreiben und die nächsten Pakete prüfen, welche gesendet werden.
So kannst du ihre Funktion rausfinden. Z.B. wenn der Server als Antwort eine 4-Byte lange SessionID sendet, welche der Client zum Character-Server schickt, um sich zu authentifizieren.
4. Pakete Analysieren
Erweiterte Struktur Analyse
Da viele Leute sagen, dass ein solches Login-Verfahren sehr leicht ist, möchte ich hier nun näher über die Erweiterte Struktur Analyse eingehen.
Ich werde ein Beispiel zeigen/simulieren, wie das ganze mit Server-Antworten und der "(Welten) Serverauflistung" abläuft.
Da die meisten MMORPGs mehr als nur einen Spielserver (oder "Welt) haben, werde ich versuchen hier zu zeigen, wie das ganze Zeug abläuft.
Wir starten erneut bei dem Login-Verfahren, welches wir analysiert haben im vorherigen Kapitel.
Nun lasst uns annehmen, dass wir ein Login-Paket gesendet haben.
Wir warten nun auf die Antwort des Servers. Was wissen wir?
Wenn der Login falsch ist (falsches Passwort z.B.), sagt der Server dem Client das und der Client kann uns eine Fehlermeldung anzeigen.
Andernfalls gibt er uns ein ok und lässt uns rein.
Nehmen wir also an, dass wir unser Login-Paket geschickt haben und ein Paket vom Server empfangen haben.
Was sagt der Client? Er sagt "Falsches Passwort". Haben wir was falsch eingetippt?
Lasst uns das Paket prüfen, welches ungefähr so aussehen könnte:
04 00 12 00 02 00
<LÄNGE>.2B <KOPF>.2B <UNBEKANNT>.2B
Das ist das Paket, was uns der Server geschickt hat, welches dem Client sagt, dass das Passwort falsch ist.
Ich habe die Sachen, die wir bereits gelernt haben, farblich gekennzeichnet.
Aber wofür sind die letzten 2 Bytes? Die sagen dem Client, dass der Login erfolgreich war oder nicht.
Überprüft das einfach und loggt euch mit einem fiktiven Benutzernamen ein, welcher nicht exestiert in dem Spiel.
Dann könnte das Paket so aussehen:
04 00 12 00 01 00
Nun sagt der Client uns "Der Benutzername exestiert nicht, bitte registrier dich erst"
Nun wissen wir definitiv, dass die letzten 2 Bytes das sogenannte "Login-Flag" sind.
Du kannst es natürlich wieder umdrehen und mit dem Taschenrechner in Dezimal umwandeln, doch da du schon siehst, wie die Werte lauten, brauchst du das nicht tun.
Aber wenn du noch nicht so gut im Hexdezimalen System bist, benutz den Taschenrechner.
Das sind nun die "Flags", die wir nun kennen:
Original : 01 00 Umgekehrt : 00 01 Dezimal : 1
Original : 02 00 Umgekehrt : 00 02 Dezimal : 2
Das ist einfach eine Server Variable umgekehrt in ein WORD ( 2 Bytes).
Also könnte das Flag für den erfolgreichen Login zum Beispiel 00 00 sein und würde dem Client sagen "Hey, der Login war erfolgreich, mach weiter".
Aber solange wir nicht wissen, wie das Flag aussieht, wenn der Login erfolgreich war, müssen wir das weiter Testen.
Log dich mit deinem Benutzernamen und deinem Passwort ein.
Der Server wird dann mit etwas antworten, was etwa so aussieht:
08 00 12 00 00 00 C6 6F 5D A1
<LÄNGE>.2B <KOPF>.2B <LOGINFLAG>.2B <UNBEKANNT>.4B
Was wissen wir also?
Die ersten 2 Bytes geben die Länge an.
Die nächsten 2 sind der "Kopf" oder auch der "Befehl".
Als nächstes kommt das Loginflag (welches in Dezimal 0 zu sein scheint).
und ein DWORD (4 Bytes) wert.
Was könnte der neue Wert bedeuten? Wir wissen es noch nicht...
Also kehren wir ihn um und wandeln in in DEZIMAL um mit unserem Rechner.
Original : C6 6F 5D A1 Umgekehrt : A1 5D 6F C6 Dezimal : 2707255238
Was dieser Wert bedeutet, wissen wir jetzt noch nicht. Also analysieren wir unser Paket weiter...
Schreib die 4-Bytes auf und guck, ob sie im nächsten Paket auch vorkommen.
So wären wir in der Lage zu analysieren, was diese 4-Bytes für eine Funktion haben.
Geh ins Spiel rein oder mache es nochmal oder fahre fort mit deinem Sniffing.
Ok, wir haben nun das Auswahlfenster im Bildschirm, wo wir die Spielwelt/den Spielserver auswählen können.
Lasst uns die nächsten Pakete prüfen, die wir gesnifft haben.
Es sieht so aus, dass unser Client etwas an den Server schickt, nachdem Paket von oben (12 00).
Das könnte die Anfrage für die Serverliste sein.
Das Paket schaut so z.B. aus:
02 00 13 00
Nichts besonderes. Nur die Paketlänge und das Flag. Dadurch wird die Serverliste angefragt vom Client.
Wie du nun im Ascii-Fenster sehen kannst, werden die Servernamen als Text angezeigt.
Lasst uns sehen, was wir haben:
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
Wow, dass ist unser erstes, langes Paket. WPE zeigt eine Größe von 59 Bytes an.
Und die ersten 2 Bytes sagen uns 57.
Wie du dich also erinnerst, ist die Totale Länge - 2 = die länge unserer Daten.
Also nochmal schauen, was wir nun wissen.
Wir sehen die Länge, den Header (Kopf), aber was ist das nächste?
Überprüf nochmal die ASCII-Ansich in WPE. Da sind 3 Namen in Plaintext...
The Jungle, The Beach und The Land (Anmerkung: Ich habe die Namen so gelassen)
Das sind unsere Servernamen.
Also haben wir 3 Server. Nun sieht es also so aus, als ob uns das 5te Byte des Pakets (03) uns die Anzahl der Server nennt.
Nach der Serveranzahl folgt direkt der Servername "The Jungle", aber was ist das? Da sind schon wieder diese vielen 00en.
Das bedeutet aber das selbe, wie beim Loginnamen zuvor.. Nähmlich das die Maximallänge eines Servernames 12 ist (Benutz die ASCII und HEX Ansicht parallel in WPE um es zu zählen)
Deshalb wird der ungenutze Platz mit 00 gefüllt.
Was wissen wir nun? Was für Informationen muss eine solche Serverliste speichern?
Es muss dem Client den Namen des Servers, die IP und den Port, wo der Client sich verbinden kann, nennen.
Die meisten IPs werden als 4 einfache Bytes gesendet. Manche Server senden sie auch als Plaintext.
Lasst uns annehmen, dass der Server es als DWORD (4 Bytes) sendet.
Wie würde das aussehen? Hier ein Beispiel:
Wir haben die IP Adresse 212.178.67.42.
Nun teilen wir sie in 4 unabhängige Werte auf:
212 178 67 52 (entfernt einfach die punkte).
Nun wird jeder einzelne Wert in Hex umgewandelt. Nehmt dafür den Rechner.
212 = D4
178 = B2
67 = 43
42 = 2A
Unser DWORD ist also D4 B2 43 2A.
(Dreht das nicht um, da dies 4 einzelne Werte sind und nicht EIN GROßER Wert ist!)
Was haben wir nun gemacht?
212.178.67.42
^
|-Entferne die Punkte
v
212 178 67 42
^
|-Wandel jeden einzelnen Wert in HEX um.
v
D4 B2 43 2A
Lasst uns nun unser Paket nochmal anschauen, was nach dem Servernamen kommt.
In solchen Fällen musst du einfach mit den Werten rumspielen.
Nimm jedes Byte und wandel es in DEZIMAL um. Entweder Byte für Byte (um zu sehen ob es eine IP Adresse ist) oder 2 Bytes aufeinmal (umgekehrt!) oder 4 Bytes aufeinmal (umgekehrt!)
Nachdem wir also ein wenig rumgespielt haben, haben wir rausgefunden, dass die nächsten 4 Bytes nach dem Servernamen die IP Adresse sind.
Lasst uns das prüfen.
D9 D0 2C 12
^
|-Wandel in Dezimal um
v
217 208 44 18
^
|-Füge die Punkte hinzu
v
217.208.44.18
Das scheint eine IP-Adresse zu sein. Wenn du dir nicht sicher bist, Ping die IP einfach an oder so.
Nun fehlt uns nur noch der Port.
Prüfe die nächsten Bytes unseres Paketes. Da sind immer noch 2 Bytes bis zum nächsten Servernamen.
Ein Port kann maximal die Zahl 65535 haben. Das ist das Maximum eines 16Bit Integers (auch SHORT oder WORD genannt).
Tippe 65535 (Dezimal) in deinen Rechner ein und konvertiere es in HEX.
Was haben wir hier? FF FF - 2 Bytes, oder?
Es sieht so aus, als hätten wir den Port gefunden.
Die 2 Bytes nach der IP Adresse scheinen der Port zu sein.
Lasst uns das umwandeln (Nicht vergessen, dass wir es umdrehen müssen, da es ein normaler WORD Wert ist!)
Original : D0 07 Umgekehrt : 07 D0 Dezimal : 2000
Also der Port des ersten Servers scheint 2000 zu sein.
Ich glaube, du kannst den rest des Pakets selber analysieren.
Nun sammeln wir alle Daten, die wir gefunden haben, und bilden eine Struktur.
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
<LÄNGE>.2B <KOPF>.2B <SERVERZAHL>.1B
{ //for every servercount :
<SERVERNAME>.12B <IP>.4B <PORT>.2B
}
Die gesammelten Serverinformationen aus diesem Paket sind:
(Ich benutze "--" als Trenner. Es hat keine richtige funktion, also nicht wundern)
Servername -- IP -- Port
The Jungle -- 217.208.44.18 -- 2000
The Beach -- 217.208.44.19 -- 2000
The Land -- 217.208.44.20 -- 2000
Nun lasst uns zurück zum Spiel gehen, einen Server auswählen und die Pakete sniffen.
(Das ist das letzte Paket, welches ich hier erkläre)
Nachdem du den Server ausgewählt hast, verbindet sich der Client auf diesen
(siehe IP und Port, welche wir oben gefunden haben) und wir erhalten die Character Liste.
Aber lasst uns sehen, was tatsächlich passiert, nachdem sich der Client erfolgreich auf den Spielserver verbunden hat.
Der Client scheint pakete zu an den Spielserver zu senden.
06 00 15 00 C6 6F 5D A1
Oh was ist das? Das ist unser erster Wert, welchen wir oben vom Server erhalten haben, nachdem wir uns erfolgreich eingeloggt haben. Erinnerst du dich?
Und nun schickt der Server es auch zum Spielserver???
Hm ja, dass das ist eine art Authentifizierungsmethode, welche die meisten MMORPGs benutzen.
Schau... Du loggst dich als "John" mit dem Passowrt "12345" (irrelevant in dem Beispiel) ein.
Nun prüft der Server, ob diese Daten (Username und Passwort) stimmen.
Wenn diese Informationen STIMMEN, generiert der Server ein DWORD (4 Bytes; 32bit Integer) Wert, speichert diesen und schickt ihn zum Client.
Das ist eine sogenannte "SESSIONID"
(Viele Webseiten, die ein Login haben, verwenden ebenfalls diese Art der Authentifizierung, aber das kann auch variieren)
Nachdem der Client einen Spielserver ausgewählt hat, auf den er connected, schickt er ihm diese SESSIONID.
Da der Loginserver und der Spielserver "von einander getrennt" sind (oder einfach 2 verschiedene Programme/Computer),
brauch der Spielserver diesen Wert, um zu prüfen, ob sich schon jemand davor eingeloggt hat und diese SessionID bekam.
Während der Loginserver die SessionIDs speichert (z.B. in einer Datenbank), prüft der Spielserver nur, ob diese SessionID verfügbar ist.
Normalerweise wird die SessionID gelöscht, when der Client sich vom Spiel ausloggt.
4. Pakete analysieren
Die Verschlüsselung
Nun ich werde hier nicht viel schreiben, weil du nicht einfach in die Pakete schauen kannst, um rauszufinden, welche art der Verschlüsselung es ist.
Ok, du kannst schon, aber nicht in jedem Fall.
Ich schreibe einfach ein paar Tipps hier.
Nehmen wir haben, wir haben ein Loginpaket gesnifft, von einem MMORPG.
(Erinner dich an das Login Paket von oben)
Du solltest nicht in der Lage sein, den Benutzernamen und das Passwort in ASCII-Modus zu lesen.
Zu erst führen wir ein paar Tests aus. Solche wie mit den ersten 2 Bytes, welche die Länge anzeigen, und so weiter.
Mache dies nochmal und benutze dabei den selben Benutzernamen und das selbe Passowrt.
Wenn sich die Bytes ändern, weißt du, dass es sich nicht um eine statische Verschlüsselung handelt.
Bleiben die Bytes gleich, ist sie Statisch.
Als nächstes Sniffe Pakete mit anderen Benutzernamen und Passowrt, welche in der Länge sich untershceiden und schau, ob sich Werte ändern.
Du kannst nun ein paar einfache Analysen machen.
Nehmen wir an, wir haben ein solches Paket:
(wir benutzten den Benutzernamen "myusername" und das Passwort "mypassword"):
22 00 66 77 1A 0E 02 04 12 05 19 16 1A 12 77 77 77 77 77 77 1A 0E 07 16 04 04 00 18 05 13 77 77 77 77 77 77
Nun sehen wir die ersten 2 Bytes und prüfen die Länge.
Ok es klappt, es scheint die Paketlänge zu sein.
Nun prüfe das selbe mit einem anderen Benutzernamen und Passord...
Du wirst bemerken, dass die ersten 4 Bytes sich nicht ändern.
Das bedeutet, dass unser Benutzername und unser Passwort am 5. Byte anfängt.
Ich hoffe du weißt, wie man einen HexEditor für die nächsten Schritte benutzt.
(Was ich hier mache, kannst du auch mit Notepad machen).
Lasst uns das Paket vom 5. Byte an aufschreiben.
So sieht es für mich mit HexWorkshop aus:
Wir sehen hier einige Bytes die 77 sind...
Komischer oder?
Schreib deinen Benutzernamen und dein passwort exakt unter die Positionen der beiden Werte.
(die 77 scheinen die Platzhalter zu sein, da sie überall gleich sind, richtig?)
Mein Hex-Editor schaut so aus:
Erstaunlich. Unser Benutzername und Passwort passen exakt unter die Verschlüsselten Bytes.
Das könnte eine XOR-Verschlüsselung sein ( Exclusive or - Wikipedia, the free encyclopedia ).
Wie testen wir das?
Starte den Rechner (den von Windows ;D) und stell auf HEX um.
Nun schreibst du das erste Byte des Wertes, der der Benutzername sein könnte.
In unserem Fall ist es 1A. Also schreiben wir 1A in den Rechner.
Nun schauen wir in die Zeile unter den Verschlüsselten Daten und sehen, dass 6D in HEX für "m" steht in ASCII.
Nachdem du also 1A in den Rechner eingegeben hast, drückst du den XOR-Knopf...
Dann tippe den Hexwert für "m" (6D) ein und drück die Enter Taste.
Unser Ergebnis ist 77. Komisch oder?
Nun lasst uns das Prüfen.
Nimm das nächste Byte von den verschlüsselten Daten. In unserem Fall ist es 0E.
Tippe 0E in den Rechner, drück den XOR-Knopf und tippe 77. Dann drück die Enter taste.
Du solltest 79 erhalten, was der Hexwert für "y" ist.
Es scheint also, dass es eine statische XOR-Verschlüsselung ist, die den Key 77 benutzt.
Damit bist du in der Lage, alle Pakete zu entschlüsseln, die das Game verwendet.
Einfach de XOR-Methode mit dem Wert 77 anwenden.
Eine Einbindung in eine Programmiersprache könnte so aussehen:
Code:
---------- Post added at 01:39 AM ---------- Previous post was at 01:13 AM ----------
PLease Stick it.
Walter Sobchak
ENGLISH :
Packets - Sniffing & Analysis
[UPDATE] - 082408 - Added another Chapter to the Packet Analysis named "Extended Structure Analysis"
:: Content ::
1. What do I need ?
^---> Download links
2. First arrangements
^---> Setting up WPE
^---> Setting up Windows Calculator
3. Sniffing Packets
4. Analyzing Packets
^---> The Structure
^---> Extended Structure Analysis
^---> The Encryption
-----------------------------------------------------
1. What do you need ?
Well at first you need the following things :
Windows
WPE
Windows Calculator - well I guess you're using Windows
A Hex-Editor, or notepad (I'll use HexWorkshop)
-----------------------------------------------------
2. First arrangements
Start WPE and go to View -> Options
and change the settings for "Winsock 2.0" like this :
Why ? Because if the app you will sniff packets on is using Winsock 2.0
WPE will capture them. Since as for default the winsock 2.0 settings are
disabled in WPE.
Ok now you start the Windows Calculator. Either using [WINDOWS-KEY]+[R]
and entering "calc" or starting it from your Startmenu and your Programs
folder. Now when the calculator is open go to View and change to "Scientific"
so you'll be able do deal with hexadecimal stuff.
-----------------------------------------------------
3. Sniffing Packets
Lets sniff some Packets.
Start any app, I am using the Internet Explorer in my example.
Now start WPE and select the Internet Explorer Process.
Click on the "Target program" button.
And select the Internet Explorer or iexplore.exe
Now we can start the sniffing clicking this button :
Now lets navigate the Internet Explorer to "www.mpgh.net/forum".
Ok now check the Gauge-Window to see if WPE really captured some packets.
So after the page fully loaded my Gauge looked like this :
This doesn't have to be the same for all of you, it can vary.
Now we can stop the sniffing using the red Stop-Button we all know from our
VRC-times ;D
Your WPE should now look like this :
Of course it doesn't have to look exactly like this.
So this is where you can view the captured packets.
I guess this is enough with sniffing, I guess you could sniff all apps,
games or whatever you want now.
-----------------------------------------------------
4. Analyzing Packets
The Structure
Well as for my examples I will use a fictive game. Since this should be an
universal tutorial and not only for one game. Please consider that I can't
write this tutorial for all games/apps and for all packet structures there
are on earth, just try to do it yourself.
Well lets say we have a game called "JungleBob Online" (although the name is
irrelevant, i just wanted to use the name ;D).
We start the game and wait for the login screen to appear. Now we start our
WPE application and select the JungleBob.exe and start sniffing packets.
Lets try to log in with "myusername" as username and "mypassword" as password.
Ok this username does not exist in our game and is not ours but we will use it
to test the packets.
Now stop the sniffing process and look at the first packet which was sent from
the client to the server.
Our packet should look like this :
(in WPE you will see the packet in HEX-Mode on the left, and the same packet
in ASCII-Mode on the right side)
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
(i write it with spaces between every hex value so its easier to read)
So what do we know ? We used the username "myusername" and the password
"mypassword" and WPE tells us our packets size is 36.
Now lets check the bytes. When working with bytes you have to know that
theres a reversed byte order for values... means...
(I hope you know what hexadecimal is)
PS: For all the experts who want to flame me after i post this ... i
know its called Little Endian and Big Endian and has something to do with
the bit-order, but i don't want to explain it here... since this tutorial
is for "beginners".
If you have a decimal value 1 the normal hex value will be 01.
If we have a 2 byte delimiter (called WORD or 16bit integer) the value will
look like 00 01, if we have a 4 byte delimiter (called DWORD or 32bit integer)
it will look like 00 00 00 01.
So thats the normal byte order, if we have the reversed byte order everything
is ... yeah ... reversed.... so our value will look like this :
(as 2 bytes)
original : 00 01 reversed : 01 00
(as 4 bytes)
original : 00 00 00 01 reversed : 01 00 00 00
So now lets check our login-packet again.
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
As we know most values are either displayed as 2 or 4 bytes we can
start checking our login-packet.
The first 2 bytes look like a value.
22 00
reversed : 00 22
Start your calculator and change the view from Dec(standard) to Hex.
Now enter your hex value 0022 (of course without the spaces).
Now change the view to Dec again and you see our value is 34.
Lets check the packet-size again ... WPE is saying our packet is 36
bytes long. Do you see the parallels ? Our packet-size minus our 2
bytes at the beginning = 34.
So the first 2 bytes are indicating the packet length that will follow.
(It has not to be this way ... the length can be on the 4. position
or somewhere else...)
In my example the 2 bytes which are indicating the length aren't
included in the length, that's because some games which use encrypted
packets are doing it also this way, cause they do encrypt all the bytes
excepting the packet length (in most cases the first 1, 2 or 4 bytes).
But you shouldn't care about encryption now, since our packet seems to be
sent in plain text. You know that cause when you look at the ASCII-Mode
you see our username and password we used before.
Ok What we know is the first 2 bytes indicate the packet length. But
what about the rest ? Well since I'm doing this for a long time know in
most cases the next few bytes are a command or the "packet-header" (its
not a real "header" but i just call it this way). How to test this ?
Just sniff another login-packet in our game and change the username and
password you enter to something else (no matter what). The value should
not change.
Ok now we know 11 00 is our command (or "header"). You don't have to
deal with this 2 bytes in dec, its just a hexadecimal header used for
the packet protocol the developers created for the game. Like 11 00 is
the login 12 00 is the getserverlist-packet and so on, you got what I mean ?
Wow we already discovered so much now lets continue. We look at the
ASCII-Mode and it seems to be that the next value is our username
"myusername" but whats that ? There are so many 00s following our
username in the HEX-Mode.
Why's that ? Well most games have a limit for the username and password
the user can enter. In most cases its either 12, 16, 24, 28 or 32
characters of length.
So for an easier packet protocol they set the length of the buffers or
variables for the username and password static ....
Like if our buffer has a length of 5 and we write "lol" into it the buffer will look like this :
6C 6F 6C 00 00
So now we know how the login-packets structure looks like :
2B = 2 Bytes
4B = 4 Bytes
XB = X Bytes
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
<LENGTH>.2B <HEADER>.2B <USERNAME>.16B <PASSWORD>.16B
So thats the basic guide to analyze a packet. Well the thing is you
will have to deal with a lot of values...
Like you login and the server responds with some 4 byte values... just
write them onto a piece of paper and check the next packets which are sent.
So you can discover their function. Like the server responds with a 4
byte sessionID which the client next sends to the character server to
authenticate himself, and so on.
4. Analyzing Packets
Extended Structure Analysis
Ok since some people told me such a login-procedure is kinda easy I'd
like to add an extended structure analysis chapter here. In the following
example I will show (or simulate) a login-procedure with serverresponses
and finally the "worldlist selection". Well since most mmorpgs use
more than one servers or "worlds" I will try to show you here, how
most of the stuff is done basically.
Well we start right under the login-procedur we analyzed in the
chapter above. Now lets assume we sent our login packet.
So now we're waiting for the server to respond. What do we know ?
If our login is false, the server has to tell that the client
so that the client can give us an error message, else it will
give us an ok and let us through.
Now lets again assume we sent our login packet and received a
packet from the server. Wow whats with the client ?
It says wrong password, did we type something wrong?
Lets check the packet (which could look like this) :
04 00 12 00 02 00
<LENGTH>.2B <HEADER>.2B <UNKNOWN>.2B
So thats the packet the server sends us, telling the client
the password is wrong. I already colored the stuff we learned
in the above tutorials.
But whats the last 2 bytes for ? Well thats probably a flag, telling the
client whether the login was successful or not. Just do some checks and log
in with some fictive username which does not exist in the game and the
packet could look like this :
04 00 12 00 01 00
Now the client tells you "This Accountname is not available, please register first."
So now we surely know, the last 2 bytes is the login-flag.
You can again reverse it and transform it from hex to dec using your
calculator. Basically you don't have to do it since you already see
what values it'll be, but if you're still not that good in hexadecimal use
the calculator.
So thats the flags we know for now :
original : 01 00 reversed : 00 01 dec : 1
original : 02 00 reversed : 00 02 dec : 2
So thats basically a server variable transformed into a WORD ( 2 bytes ).
So when we have a successful login the flag maybe 00 00 and would tell
the client "hey the login was successful, go on". But since we still don't
know what the flag would look like when we had a successful login,
we go on and test it.
Log in with your username and password and the server
responds something like that :
08 00 12 00 00 00 C6 6F 5D A1
<LENGTH>.2B <HEADER>.2B <LOGINFLAG>.2B <UNKNOWN>.4B
So what do we know ? The first two bytes indicate the length.
Next is the header, then the flag (which seems to be 0 in dec)
and some DWORD (4 bytes) value. I already colored the stuff we know once again.
Ok what could this new value be ? We still don't know...
Lets reverse it and transform it into dec using our calc.
original : C6 6F 5D A1 reversed : A1 5D 6F C6 dec : 2707255238
Wow whats with this value ? Well we don't know it yet ... lets go
on with our packet analysis... Just write down the original 4 bytes
and look for it in the next packets. So we could be able to
analyze the function of this 4 bytes.
Get ingame and redo, or continue the sniffing.
Ok now we have the worldserver-selection screen in our game.
Lets check the new packets we captured.
Mh the client seems to send something to the server after our
above packet (12 00). Well that could be a request
to get the worldserverlist.
The packet looks like this :
02 00 13 00
Seems to be nothing great in here, just the length and
the flag. Thats the way the serverlist is requested by the client.
Next we see a packet we received from the server. As you probably can see
in the ASCII-View in WPE there are some strings in plain text,
prolly the servernames. Let's see what we got :
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
Wow thats our first long packet. WPE shows our total size 59.
And the first two bytes tell us 57.
So you remember the total size - 2 (the first two bytes) = the length of our data.
Well lets see, what do we know ?
We see the length, and the header, but what is next ?
Check the ASCII-View in WPE again. There are three names in plaintext...
The Jungle, The Beach and The Land. Thats our servernames.
So we have 3 servers. Now it seems that the 5. byte of the packet ( 03 )
tells us how many servers we got in the list.
We have 3 here so the hex for 3 is 03. So after this servercount we already
have our servername "The Jungle", but whats that ? There are those
00s again. Well that means the same we had before with our username
and password, you remember ? It seems that the maximum length of a
servername is 12 (use the ASCII-View and the HEX-View parallel in WPE to count it)
thats why the unused place is filled with 00. So what do we know, what
information does such a server list has to store ?
Well it has to tell the client the name of the server, the ip and
the port where the client should next connect right ?
Well most IPs are sent as 4 single bytes, some servers also send
them as plain text. Lets assume our server sends it using a DWORD.
What would this look like... well let's do an example.
We have the IP address 212.178.67.42.
Now you split it into 4 independent values :
212 178 67 42 (so just "remove" the dots).
Now every single value will be converted into hex using our calculator.
212 = D4
178 = B2
67 = 43
42 = 2A
So our DWORD (4 bytes) is D4 B2 43 2A.
(do not reverse this!, since its 4 single values and not ONE big value)
So basically what did we do ?
212.178.67.42
^
|-Remove the dots
v
212 178 67 42
^
|-Convert every single value to hex
v
D4 B2 43 2A
Now lets check our packet again... whats after the servername.
Well in such cases you just have to play around with the values.
Pick every byte and convert it ... either byte for byte
(to see if its an ip address) or 2 bytes at once (reversed!) or 4 bytes
at once (reversed!). So after we played around a bit we found out
that the next 4 bytes after the servername indicate the ip address.
Lets check it.
D9 D0 2C 12
^
|-Convert it to dec
v
217 208 44 18
^
|-Add the dots
v
217.208.44.18
Well that seems to be an IP-address, if you're not sure, just ping
it or something else. Well... we already got the servername,
the ip... but whats with the port ?
Check the next bytes of our packet, there are still 2 bytes
left until the next servername begins.
Well the maximum value a port can have is 65535, thats basically
the maximum value a 16bit-integer (also called short or word) can be.
Type 65535 (dec) into your calculator and convert it to hex.
What do we have here ? FF FF - Two bytes, huh ?
Well it seems we found our port value.
The 2 bytes after the ip-address seems to be our port.
Lets convert it (remember : thats a normal value again, so we have to reverse it)
original : D0 07 reversed : 07 D0 dec : 2000
The port of the first worldserver seems to be 2000.
So I guess you could do the rest of the packet on your own...
Now let's collect all data we found and build a structure
(I'll basically do it with collors in here)
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
<LENGTH>.2B <HEADER>.2B <SERVERCOUNT>.1B
{ //for every servercount :
<SERVERNAME>.12B <IP>.4B <PORT>.2B
}
So the serverinformation we can gather from this packet is :
(I'll use "--" as delimiter, no real function for that, if you wonder)
Servername -- IP -- Port
The Jungle -- 217.208.44.18 -- 2000
The Beach -- 217.208.44.19 -- 2000
The Land -- 217.208.44.20 -- 2000
Ok now lets get back to the game, choose a server and sniff the packets.
(Thats the last packet I'll discuss here lol)
Now after you've chosen the server, the client connects to this
(see ip and ports we found out above) and we get the character list.
But lets see what really happens after the client successfully
connected to the worldserver.
The client seems to send a packet to the worldserver.
06 00 15 00 C6 6F 5D A1
Oh whats this ? This is our value from above that we got from the server
after we successfully logged in, remember ?
And now the server sends it again to the worldserver ???
Well yeah, thats kinda an authentication-method most mmorpgs use.
Look... you log in using "John" as username and "12345"
(irrelevant in my example) as password. Now the server checks whether this
information is right or not. In our example ... if the information IS correct,
the server generates a DWORD ( 4 bytes ) or 32bit Integer value stores
it and sends it back to the client. Thats called sessionid
(most websites which have a login-interface also use this kind of
authentication, but of course if can vary).
Now after the client has chosen a worldserver he would like he connects
to it and sends his sessionid.
Well since the login server and the worldserver are "seperated from each other"
(or basically two different applications) the world server does need
this value to check whether someone really logged in before and got
this sessionid. Since the loginserver stored our sessionid
(in a database or whereever) the worldserver just checks whether
the sessionid is available.
Normally the sessionid is deleted when the client disconnects
from the game, the server or whatever.
Well ... now thats the part where I stop. I won't update the encryption chapter
since its basically the same for everything. If you know how to decrypt one
packet, you basically know how to decrypt every packet of one game.
4. Analyzing Packets
The Encryption
Well I won't be writing to much in here, since you can't tell just
from looking at the packets what kind of encryption it is. Well of
course you can, but not in all cases.
I will just write some hints down.
Like lets assume we capture a login-packet of a mmorpg.
(remember our login packet from above ?)
You shouldn't be able to read your username or password in
ASCII-Mode now anymore.
At first do some checks, like the one with the first 2 bytes beeing
the length and so on. Well next you can redo the sniff at the login
process and see if the bytes do change ( of course use the same
username and password as before ). Using that method you can say
whether the encryption is static or not. Next do the checks like
the one sniffing more login packets where you use fictive
usernames and password which vary in length and see if some
values change.
Well now you could do some basic analysis. Like lets assume we
have a login packet which looks like this
( we used the username and password as before "myusername" and "mypassword") :
22 00 66 77 1A 0E 02 04 12 05 19 16 1A 12 77 77 77 77 77 77 1A 0E 07 16 04 04 00 18 05 13 77 77 77 77 77 77
Now we see the first two bytes and do the length check.
Ok its works, it seems to be the packet length.
Now do the check with the other username and passwords...
You will notice that the first four bytes do not change.
That means starting from the 5. byte there is our
username and password data.
I hope you know how to use a HexEditor for the next steps
(well thats what I do, you can also use notepad).
Lets write down the packet beginning at the 5. byte
It looks like that to me, using HexWorkshop :
So we see there are some bytes beeing 77 ...
Seems to be strange huh ?
Lets write down our username and password under the exact
positions of both values
(the 77 does seem to be placeholders, since their the same everywhere right?)
My Hex-Editor looks like this :
Wow whats that ? Our username and password does exactly fit
into the encrypted packet data.
Well that could be a XOR-Encryption ( Exclusive or - Wikipedia, the free encyclopedia ).
How to test it ?
Start your calculator (the windows one ;D) and be sure "Hex" is checked.
Now type in the first byte of the value which could be your username.
In our case its 1A. So we type 1A into the calculator. Now we
look at the line under the encrypted data, and see that 6D in
hex stands for a "m" in ASCII.
Now when you already typed 1A into your calculator hit the XOR-Button...
then type in our hex value for "m" (6D) and hit enter.
Our result is 77. Strange isn't it ?
Now lets do the check.
Take the next byte of our encrypted data. In our case its 0E.
Type 0E into the calculator, press the XOR-Button, type 77 and hit enter.
You should get 79 now which is the hex value for "y".
Well it seems we have a static XOR-Encryption using the key 77 here.
So you'll be able to decrypt all the packet data of our game using
the XOR method and the key 77.
An implementation into a programming language could look like this
Code:
Code:
// we are starting from byte 2 since the first 2 bytes are our
// packet length which is not encrypted,
for(int i = 2; i < packetLength; i++)
{
packet[i] = packet[i] ^ 0x77;
}
didn't mix up to much things. I hope you enjoyed it.
__________________________________________________ __________________________________________________ _____________________________
GERMAN : (Translated by psych0o)
Packets - Sniffing & Analysis
:: Inhalt ::
1. Was brauche ich ?
^---> Download links
2. Erste Einstellungen
^---> Einstellungen für WPE
^---> Einstellungen für den Windows Rechner
3. Pakte sniffen (abfangen)
4. Pakete analysieren
^---> Die Struktur
^---> Erweiterte Struktur Analyse
^---> Die Verschlüsselung
-----------------------------------------------------
1. Was brauche ich ?
Benötigt werden diese Programme:
Windows
WPE
Windows Rechner - ist bei Windows standartmäßíg installiert
Einen Hex-Editor, oder Notepad (Ich werde HexWorkshop benutzen)
-----------------------------------------------------
2. Erste Einstellungen
Starte WPE und gehe im Menü auf View -> Options
und ändere die Einstellungen für "Winsock 2.0" in diese:
Warum ? Wenn das Programm, von dem du die Pakete sniffen willst, WINSOCK 2.0 benutzt, wird WPE dadurch in der Lage sein, diese zu sniffen, da die WINSOCK 2.0 Einstellungen standartmäßig DEAKTIVIERT sind.
Nun starte den Windows Taschenrechner. Entweder über die Tastenkürzel [WINDOWS-TASTE]+[R], wo du dann "calc" eingibst, oder über das Startmenü (Start -> Alle Programme -> Zubehör -> Rechner).
Sobald der Taschenrechner geöffnet ist, klicke auf "Ansicht" und wähle dort "Wissenschaftlich", so dass man Hexdezimale Zahlen benutzen kann.
-----------------------------------------------------
3. Pakete sniffen (abfangen)
Lasst uns nun ein paar Pakete sniffen.
Für dieses Beispiel nehmen wir den Internet Explorer. Starte also diesen.
Nun startest du WPE und wählst den Internet Explorer Prozess aus.
Klicke auf den "Target Program" Button.
Und wähle den Internet Explorer (iexplore.exe) aus.
Nun können wir das Sniffen starten, in dem wir diesen Knopf drücken:
Lasst uns nun im Internet Explorer die Seite "www.mpgh.net/forum" aufrufen.
Ok nun prüf die Messgrafiken um zu sehen, ob WPE wirklich Pakete aufnimmt.
Nachdem die Seite komplett geladen wurde, sieht die Messgrafik bei mir so aus;
Dieses muss bei euch nicht genauso aussehen, es kann variieren.
Halte nun das Sniffing an, in dem du den roten Stop-Knopf drückst, den wir alle von einem Videorecorder kennen.
Nun sollte WPE in etwa so aussehen:
Natürlich muss es bei euch nicht wieder genau so aussehen.
Ihr seht dort nun die abgefangenen Paketed packets.
Ich vermute, dass wir nun genug über das Sniffing geredet haben und dass du nun in der Lage bist, alle Programme und Spiele zu sniffen.
-----------------------------------------------------
4. Pakete analysieren
Die Struktur
Ich werde hier als Beispiel ein fiktives Spiel benutzen, da das Tutorial auf andere Spiele anwendbar sein soll und nicht nur für eins.
Bitte habt verständnis dafür, dass ich dieses Tutorial nicht für jedes Spiel/Programm schreiben kann und auch nicht für jede Paketstruktur, die es auf der Welt gibt.
Probiert es einfach selber aus.
Nehmen wir nun an, wir haben ein Spiel anmens "JungleBob Online" (Der Name spielt keine Rolle, ich wollte bloß einen Namen benutzen)
Wir starten das Spiel und warten auf den Loginbildschirm. Nun starten wir WPE und wählen "JungleBob.exe" aus und starten das Sniffen.
Last uns versuchen mit dem Benutzernamen "myusername" und dem Passwort "mypassword" einzuloggen.
Ok, dieser Benutzername exestiert nicht in unserem Spiel und er gehört nicht uns. Wir verwenden das nur zum testen der Pakete.
Nun stoppen wir den Sniffing-Vorgang und schauen uns die ersten Pakete an, welche vom Client (also dem Spiel) zu dem Server geschickt wurden.
Unsere Pakete sollten in etwa so aussehen:
(in WPE werden die Pakete links als HEX-Dezimal angezeigt und rechts als ASCII Zeichen)
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
(Ich habe es mit Leerzeichen geschrieben, damit man es besser lesen kann)
Was wissen wir nun? Wir benutzten den Benutzernamen "myusername" und das Passwort "mypassword" und WPE sagt uns, dass die Paketgröße 36 Bytes ist.
Prüfen wir also mal diese Bytes. Wenn wir mit Bytes arbeiten müssen wir wissen,
dass dort eine umgekehrte Byte-Anordnung für die Werte ist.
(Ich hoffe ihr wisst, was Hexdezimal ist. Wenn nicht, lernt erst etwas über das Hexdezimal System)
P.S.: Für alle Experten hier, die mich gleich anflamen... Ich weiß, dass es "Little Endian" und "Big Endian" heisst und es was mit der Bit-Anordnung zu tun hat.
Aber ich möchte das hier nicht weiter erklären, weil dieses Tutorial sich an Anfänger richtet.
Wenn du einen Dezimalwert von 1 hast, ist sein Hexwert 01.
Wenn du einen 2-Byte Delimiter haben (WORD oder 16bit Integer genannt), sieht der Wert so aus: 00 01
Wenn wir einen 4-Byte Delimiter haben (DWORD oder 32bit Integer genannt), sieht der Wert so aus: 00 00 00 01
Also immer 2-Bytes oder 4-Bytes bis zum nächsten Wert.
Das ist die normale Byte-Anordnung.
Bei einer umgekehrten Anordnung sieht alles... umgekehrt aus.. Also sehen unsere Werte so aus:
(Als 2-bytes)
Original: 00 01 Umgekehrt: 01 00
(Als 4-bytes)
Original: 00 00 00 01 Umgekehrt: 01 00 00 00
Lasst uns nun nochmal das Login-Paket anschauen.
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
Wie wir wissen, werden die Werte entweder als 2-Byte oder 4-Byte getrennt angezeigt. Damit können wir nun unsere Loginpaket prüfen.
Die ersten 2 Bytes sehen aus wie ein Wert.
22 00
Umgekehrt : 00 22
Startet euren Windows Rechner und ändert die Ansicht von Dez(DEC) (Standart) auf Hex.
Nun gebt als Hex Wert ein: 0022 (natürlich ohne leerzeichen)
Nun ändert die Ansicht erneut auf Dec (Dezimal).
Vergleicht nun mit der Paket-Größe, die uns WPE genannt hat (36 bytes)
Siehst du die Parallele? Unsere Paketgröße minus den 2 Bytes, die wir gerade genommen haben ergibt 34.
Also werden durch die ersten 2 Bytes die restigen Anzahl an Bytes des Pakets angegeben.
(Doch es kann auch an anderen Stellen (z.B. der 4. Stelle) vorkommen)
In meinem Beispiel sind die 2-Bytes, welche die Größe angeben, nicht in die die Paketgröße mit einbezogen, weil viele Spiele verschlüsselungen für die Pakete benutzen, so dass alle Pakete, bis auf die Bytes, die die Größe angeben, verschlüsselt sind.
Die Bytes, die die Größe angeben sind meistens die ersten, zweiten oder vierten Bytes.
Aber du solltest dir jetzt noch nicht soviele Gedanken um die Verschlüsselung machen, da diese Pakete im Beispiel unverschlüsselt als Plain-Text (reiner Text) sind.
Dadurch kann man den Benutzernamen und das Passwort im ASCII-Fenster (rechts) sehen, welche wir vorher festgelegt haben.
Wir wissen nun, dass die ersten 2 Bytes die Paket-Länge angeben.
Aber was ist mit dem Rest? Nun, da ich das schon eine ganze Weile mache, weiß ich, dass die nächsten paar Bytes ein Befehl oder der "Paket-Kopf" (Header) sind.
(Ich weiß, dass es nicht der wirkliche "Paket-Header" ist, aber zur besseren veranschaulichung, definiere ich es hier so)
Wie testen wir das nun?
Sniff nun weitere Login-Pakete, in dem du einen anderen Benutzernamen und ein anderes Passwort angibst (welche ist egal).
Bis auf die Bytes, die den Benutzernamen und das Passwort enthalten, sollten sich die Werte nicht ändern.
Ok wir wissen nun, dass 11 00 unser Befehl (oder Kopf) ist. Du brauchst das nicht in Dezimal umrechnen.
Es ist einfach ein Hexdezimaler Header, den die Spieleprogrammierer als "Paket Protokoll" erstellt haben.
11 00 ist der Login, 12 00 ist das "getserverlist"-Paket (Serverliste holen) und so weiter und so weiter.
Verstanden was ich meine?
Ok wir haben viel rausgefunden. Lasst uns weiter machen.
Wir schauen auf das ASCII-Fenster und es sieht so aus, dass der nächste Wert der Benutzer (myusername) ist.
Aber was haben die ganzen 00en zu bedeuten, die nach dem Benutzernamen folgen?
Ganz einfach: Die meisten Spiele haben ein Limit für die Länge von Benutzername und Passwort.
In den meisten fällen ist es eine Länge von 12, 16, 24, 28 oder 32 Zeichen.
Damit es einfacher ist, haben die Programmierer die Länge für den Benutzernamen und das Passwort festgesetzt (static)
Wenn unser Puffer nun eine Länge von 5 hat und wir "lol" reinschreiben, dann sieht das so aus:
6C 6F 6C 00 00
Wir wissen nun also, dass die Login-Paket Struktur so aussieht:
2B = 2 Bytes
4B = 4 Bytes
XB = X Bytes
22 00 11 00 6D 79 75 73 65 72 6E 61 6D 65 00 00 00 00 00 00 6D 79 70 61 73 73 77 6F 72 64 00 00 00 00 00 00
<LÄNGE>.2B <KOPF>.2B <USERNAME>.16B <PASSWORT>.16B
Das ist eine Grundanleitung für das Analysieren von Paketen.
Die Sache ist nur, dass du mit vielen Werten rumhantieren musst.
Wie z.B. wenn der Server auf den Login mit einem 4-Byte Wert antwortet.
Einfach auf ein stück Papier schreiben und die nächsten Pakete prüfen, welche gesendet werden.
So kannst du ihre Funktion rausfinden. Z.B. wenn der Server als Antwort eine 4-Byte lange SessionID sendet, welche der Client zum Character-Server schickt, um sich zu authentifizieren.
4. Pakete Analysieren
Erweiterte Struktur Analyse
Da viele Leute sagen, dass ein solches Login-Verfahren sehr leicht ist, möchte ich hier nun näher über die Erweiterte Struktur Analyse eingehen.
Ich werde ein Beispiel zeigen/simulieren, wie das ganze mit Server-Antworten und der "(Welten) Serverauflistung" abläuft.
Da die meisten MMORPGs mehr als nur einen Spielserver (oder "Welt) haben, werde ich versuchen hier zu zeigen, wie das ganze Zeug abläuft.
Wir starten erneut bei dem Login-Verfahren, welches wir analysiert haben im vorherigen Kapitel.
Nun lasst uns annehmen, dass wir ein Login-Paket gesendet haben.
Wir warten nun auf die Antwort des Servers. Was wissen wir?
Wenn der Login falsch ist (falsches Passwort z.B.), sagt der Server dem Client das und der Client kann uns eine Fehlermeldung anzeigen.
Andernfalls gibt er uns ein ok und lässt uns rein.
Nehmen wir also an, dass wir unser Login-Paket geschickt haben und ein Paket vom Server empfangen haben.
Was sagt der Client? Er sagt "Falsches Passwort". Haben wir was falsch eingetippt?
Lasst uns das Paket prüfen, welches ungefähr so aussehen könnte:
04 00 12 00 02 00
<LÄNGE>.2B <KOPF>.2B <UNBEKANNT>.2B
Das ist das Paket, was uns der Server geschickt hat, welches dem Client sagt, dass das Passwort falsch ist.
Ich habe die Sachen, die wir bereits gelernt haben, farblich gekennzeichnet.
Aber wofür sind die letzten 2 Bytes? Die sagen dem Client, dass der Login erfolgreich war oder nicht.
Überprüft das einfach und loggt euch mit einem fiktiven Benutzernamen ein, welcher nicht exestiert in dem Spiel.
Dann könnte das Paket so aussehen:
04 00 12 00 01 00
Nun sagt der Client uns "Der Benutzername exestiert nicht, bitte registrier dich erst"
Nun wissen wir definitiv, dass die letzten 2 Bytes das sogenannte "Login-Flag" sind.
Du kannst es natürlich wieder umdrehen und mit dem Taschenrechner in Dezimal umwandeln, doch da du schon siehst, wie die Werte lauten, brauchst du das nicht tun.
Aber wenn du noch nicht so gut im Hexdezimalen System bist, benutz den Taschenrechner.
Das sind nun die "Flags", die wir nun kennen:
Original : 01 00 Umgekehrt : 00 01 Dezimal : 1
Original : 02 00 Umgekehrt : 00 02 Dezimal : 2
Das ist einfach eine Server Variable umgekehrt in ein WORD ( 2 Bytes).
Also könnte das Flag für den erfolgreichen Login zum Beispiel 00 00 sein und würde dem Client sagen "Hey, der Login war erfolgreich, mach weiter".
Aber solange wir nicht wissen, wie das Flag aussieht, wenn der Login erfolgreich war, müssen wir das weiter Testen.
Log dich mit deinem Benutzernamen und deinem Passwort ein.
Der Server wird dann mit etwas antworten, was etwa so aussieht:
08 00 12 00 00 00 C6 6F 5D A1
<LÄNGE>.2B <KOPF>.2B <LOGINFLAG>.2B <UNBEKANNT>.4B
Was wissen wir also?
Die ersten 2 Bytes geben die Länge an.
Die nächsten 2 sind der "Kopf" oder auch der "Befehl".
Als nächstes kommt das Loginflag (welches in Dezimal 0 zu sein scheint).
und ein DWORD (4 Bytes) wert.
Was könnte der neue Wert bedeuten? Wir wissen es noch nicht...
Also kehren wir ihn um und wandeln in in DEZIMAL um mit unserem Rechner.
Original : C6 6F 5D A1 Umgekehrt : A1 5D 6F C6 Dezimal : 2707255238
Was dieser Wert bedeutet, wissen wir jetzt noch nicht. Also analysieren wir unser Paket weiter...
Schreib die 4-Bytes auf und guck, ob sie im nächsten Paket auch vorkommen.
So wären wir in der Lage zu analysieren, was diese 4-Bytes für eine Funktion haben.
Geh ins Spiel rein oder mache es nochmal oder fahre fort mit deinem Sniffing.
Ok, wir haben nun das Auswahlfenster im Bildschirm, wo wir die Spielwelt/den Spielserver auswählen können.
Lasst uns die nächsten Pakete prüfen, die wir gesnifft haben.
Es sieht so aus, dass unser Client etwas an den Server schickt, nachdem Paket von oben (12 00).
Das könnte die Anfrage für die Serverliste sein.
Das Paket schaut so z.B. aus:
02 00 13 00
Nichts besonderes. Nur die Paketlänge und das Flag. Dadurch wird die Serverliste angefragt vom Client.
Wie du nun im Ascii-Fenster sehen kannst, werden die Servernamen als Text angezeigt.
Lasst uns sehen, was wir haben:
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
Wow, dass ist unser erstes, langes Paket. WPE zeigt eine Größe von 59 Bytes an.
Und die ersten 2 Bytes sagen uns 57.
Wie du dich also erinnerst, ist die Totale Länge - 2 = die länge unserer Daten.
Also nochmal schauen, was wir nun wissen.
Wir sehen die Länge, den Header (Kopf), aber was ist das nächste?
Überprüf nochmal die ASCII-Ansich in WPE. Da sind 3 Namen in Plaintext...
The Jungle, The Beach und The Land (Anmerkung: Ich habe die Namen so gelassen)
Das sind unsere Servernamen.
Also haben wir 3 Server. Nun sieht es also so aus, als ob uns das 5te Byte des Pakets (03) uns die Anzahl der Server nennt.
Nach der Serveranzahl folgt direkt der Servername "The Jungle", aber was ist das? Da sind schon wieder diese vielen 00en.
Das bedeutet aber das selbe, wie beim Loginnamen zuvor.. Nähmlich das die Maximallänge eines Servernames 12 ist (Benutz die ASCII und HEX Ansicht parallel in WPE um es zu zählen)
Deshalb wird der ungenutze Platz mit 00 gefüllt.
Was wissen wir nun? Was für Informationen muss eine solche Serverliste speichern?
Es muss dem Client den Namen des Servers, die IP und den Port, wo der Client sich verbinden kann, nennen.
Die meisten IPs werden als 4 einfache Bytes gesendet. Manche Server senden sie auch als Plaintext.
Lasst uns annehmen, dass der Server es als DWORD (4 Bytes) sendet.
Wie würde das aussehen? Hier ein Beispiel:
Wir haben die IP Adresse 212.178.67.42.
Nun teilen wir sie in 4 unabhängige Werte auf:
212 178 67 52 (entfernt einfach die punkte).
Nun wird jeder einzelne Wert in Hex umgewandelt. Nehmt dafür den Rechner.
212 = D4
178 = B2
67 = 43
42 = 2A
Unser DWORD ist also D4 B2 43 2A.
(Dreht das nicht um, da dies 4 einzelne Werte sind und nicht EIN GROßER Wert ist!)
Was haben wir nun gemacht?
212.178.67.42
^
|-Entferne die Punkte
v
212 178 67 42
^
|-Wandel jeden einzelnen Wert in HEX um.
v
D4 B2 43 2A
Lasst uns nun unser Paket nochmal anschauen, was nach dem Servernamen kommt.
In solchen Fällen musst du einfach mit den Werten rumspielen.
Nimm jedes Byte und wandel es in DEZIMAL um. Entweder Byte für Byte (um zu sehen ob es eine IP Adresse ist) oder 2 Bytes aufeinmal (umgekehrt!) oder 4 Bytes aufeinmal (umgekehrt!)
Nachdem wir also ein wenig rumgespielt haben, haben wir rausgefunden, dass die nächsten 4 Bytes nach dem Servernamen die IP Adresse sind.
Lasst uns das prüfen.
D9 D0 2C 12
^
|-Wandel in Dezimal um
v
217 208 44 18
^
|-Füge die Punkte hinzu
v
217.208.44.18
Das scheint eine IP-Adresse zu sein. Wenn du dir nicht sicher bist, Ping die IP einfach an oder so.
Nun fehlt uns nur noch der Port.
Prüfe die nächsten Bytes unseres Paketes. Da sind immer noch 2 Bytes bis zum nächsten Servernamen.
Ein Port kann maximal die Zahl 65535 haben. Das ist das Maximum eines 16Bit Integers (auch SHORT oder WORD genannt).
Tippe 65535 (Dezimal) in deinen Rechner ein und konvertiere es in HEX.
Was haben wir hier? FF FF - 2 Bytes, oder?
Es sieht so aus, als hätten wir den Port gefunden.
Die 2 Bytes nach der IP Adresse scheinen der Port zu sein.
Lasst uns das umwandeln (Nicht vergessen, dass wir es umdrehen müssen, da es ein normaler WORD Wert ist!)
Original : D0 07 Umgekehrt : 07 D0 Dezimal : 2000
Also der Port des ersten Servers scheint 2000 zu sein.
Ich glaube, du kannst den rest des Pakets selber analysieren.
Nun sammeln wir alle Daten, die wir gefunden haben, und bilden eine Struktur.
39 00 14 00 03 54 68 65 20 4A 75 6E 67 6C 65 00 00 D9 D0 2C 12 D0 07 54 68 65 20 42 65 61 63 68 00 00 00 D9 D0 2C 13 D0 07 54 68 65 20 4C 61 6E 64 00 00 00 00 D9 D0 2C 14 D0 07
<LÄNGE>.2B <KOPF>.2B <SERVERZAHL>.1B
{ //for every servercount :
<SERVERNAME>.12B <IP>.4B <PORT>.2B
}
Die gesammelten Serverinformationen aus diesem Paket sind:
(Ich benutze "--" als Trenner. Es hat keine richtige funktion, also nicht wundern)
Servername -- IP -- Port
The Jungle -- 217.208.44.18 -- 2000
The Beach -- 217.208.44.19 -- 2000
The Land -- 217.208.44.20 -- 2000
Nun lasst uns zurück zum Spiel gehen, einen Server auswählen und die Pakete sniffen.
(Das ist das letzte Paket, welches ich hier erkläre)
Nachdem du den Server ausgewählt hast, verbindet sich der Client auf diesen
(siehe IP und Port, welche wir oben gefunden haben) und wir erhalten die Character Liste.
Aber lasst uns sehen, was tatsächlich passiert, nachdem sich der Client erfolgreich auf den Spielserver verbunden hat.
Der Client scheint pakete zu an den Spielserver zu senden.
06 00 15 00 C6 6F 5D A1
Oh was ist das? Das ist unser erster Wert, welchen wir oben vom Server erhalten haben, nachdem wir uns erfolgreich eingeloggt haben. Erinnerst du dich?
Und nun schickt der Server es auch zum Spielserver???
Hm ja, dass das ist eine art Authentifizierungsmethode, welche die meisten MMORPGs benutzen.
Schau... Du loggst dich als "John" mit dem Passowrt "12345" (irrelevant in dem Beispiel) ein.
Nun prüft der Server, ob diese Daten (Username und Passwort) stimmen.
Wenn diese Informationen STIMMEN, generiert der Server ein DWORD (4 Bytes; 32bit Integer) Wert, speichert diesen und schickt ihn zum Client.
Das ist eine sogenannte "SESSIONID"
(Viele Webseiten, die ein Login haben, verwenden ebenfalls diese Art der Authentifizierung, aber das kann auch variieren)
Nachdem der Client einen Spielserver ausgewählt hat, auf den er connected, schickt er ihm diese SESSIONID.
Da der Loginserver und der Spielserver "von einander getrennt" sind (oder einfach 2 verschiedene Programme/Computer),
brauch der Spielserver diesen Wert, um zu prüfen, ob sich schon jemand davor eingeloggt hat und diese SessionID bekam.
Während der Loginserver die SessionIDs speichert (z.B. in einer Datenbank), prüft der Spielserver nur, ob diese SessionID verfügbar ist.
Normalerweise wird die SessionID gelöscht, when der Client sich vom Spiel ausloggt.
4. Pakete analysieren
Die Verschlüsselung
Nun ich werde hier nicht viel schreiben, weil du nicht einfach in die Pakete schauen kannst, um rauszufinden, welche art der Verschlüsselung es ist.
Ok, du kannst schon, aber nicht in jedem Fall.
Ich schreibe einfach ein paar Tipps hier.
Nehmen wir haben, wir haben ein Loginpaket gesnifft, von einem MMORPG.
(Erinner dich an das Login Paket von oben)
Du solltest nicht in der Lage sein, den Benutzernamen und das Passwort in ASCII-Modus zu lesen.
Zu erst führen wir ein paar Tests aus. Solche wie mit den ersten 2 Bytes, welche die Länge anzeigen, und so weiter.
Mache dies nochmal und benutze dabei den selben Benutzernamen und das selbe Passowrt.
Wenn sich die Bytes ändern, weißt du, dass es sich nicht um eine statische Verschlüsselung handelt.
Bleiben die Bytes gleich, ist sie Statisch.
Als nächstes Sniffe Pakete mit anderen Benutzernamen und Passowrt, welche in der Länge sich untershceiden und schau, ob sich Werte ändern.
Du kannst nun ein paar einfache Analysen machen.
Nehmen wir an, wir haben ein solches Paket:
(wir benutzten den Benutzernamen "myusername" und das Passwort "mypassword"):
22 00 66 77 1A 0E 02 04 12 05 19 16 1A 12 77 77 77 77 77 77 1A 0E 07 16 04 04 00 18 05 13 77 77 77 77 77 77
Nun sehen wir die ersten 2 Bytes und prüfen die Länge.
Ok es klappt, es scheint die Paketlänge zu sein.
Nun prüfe das selbe mit einem anderen Benutzernamen und Passord...
Du wirst bemerken, dass die ersten 4 Bytes sich nicht ändern.
Das bedeutet, dass unser Benutzername und unser Passwort am 5. Byte anfängt.
Ich hoffe du weißt, wie man einen HexEditor für die nächsten Schritte benutzt.
(Was ich hier mache, kannst du auch mit Notepad machen).
Lasst uns das Paket vom 5. Byte an aufschreiben.
So sieht es für mich mit HexWorkshop aus:
Wir sehen hier einige Bytes die 77 sind...
Komischer oder?
Schreib deinen Benutzernamen und dein passwort exakt unter die Positionen der beiden Werte.
(die 77 scheinen die Platzhalter zu sein, da sie überall gleich sind, richtig?)
Mein Hex-Editor schaut so aus:
Erstaunlich. Unser Benutzername und Passwort passen exakt unter die Verschlüsselten Bytes.
Das könnte eine XOR-Verschlüsselung sein ( Exclusive or - Wikipedia, the free encyclopedia ).
Wie testen wir das?
Starte den Rechner (den von Windows ;D) und stell auf HEX um.
Nun schreibst du das erste Byte des Wertes, der der Benutzername sein könnte.
In unserem Fall ist es 1A. Also schreiben wir 1A in den Rechner.
Nun schauen wir in die Zeile unter den Verschlüsselten Daten und sehen, dass 6D in HEX für "m" steht in ASCII.
Nachdem du also 1A in den Rechner eingegeben hast, drückst du den XOR-Knopf...
Dann tippe den Hexwert für "m" (6D) ein und drück die Enter Taste.
Unser Ergebnis ist 77. Komisch oder?
Nun lasst uns das Prüfen.
Nimm das nächste Byte von den verschlüsselten Daten. In unserem Fall ist es 0E.
Tippe 0E in den Rechner, drück den XOR-Knopf und tippe 77. Dann drück die Enter taste.
Du solltest 79 erhalten, was der Hexwert für "y" ist.
Es scheint also, dass es eine statische XOR-Verschlüsselung ist, die den Key 77 benutzt.
Damit bist du in der Lage, alle Pakete zu entschlüsseln, die das Game verwendet.
Einfach de XOR-Methode mit dem Wert 77 anwenden.
Eine Einbindung in eine Programmiersprache könnte so aussehen:
Code:
Code:
// Wir fangen bei Byte 2 an, da die ersten 2 Bytes unsere
// unverschlüsselte paket-größe sind.
for(int i = 2; i < packetLength; i++)
{
packet[i] = packet[i] ^ 0x77;
}
---------- Post added at 01:39 AM ---------- Previous post was at 01:13 AM ----------
PLease Stick it.
Similar Threads
- 2Last post
- 0Last post
- 6Last post
Originally Posted by runekri3
(sent packets to quickly change hat) in aqw
