Server Help :: View topic - Decoding User.dat

Server Help

General Questions - Decoding User.dat

Cheese - Fri Mar 23, 2007 4:03 am
Post subject: Decoding User.dat

I have two user.dat files.

i want to bring users from one .dat to the other.

a typical entry:
Cheese! mÂ±ÃT 3 3R33 333 R3 3RR33R33 3 RRR3 R3 3RR RR33R3 3RRRR RR33 333333333 Ã® Å’ JÂ½Fâ€šÂ½FÃŽÃˆÂ¿Eh

any help?

Chambahs - Fri Mar 23, 2007 5:38 am
Post subject:

Im probably wrong, but doesnt that contain the players PW? Decrypting that would allow you to see all the players' passwords...thats not cool lol..

L.C. - Fri Mar 23, 2007 7:52 am
Post subject:

Yes. Users.dat does contain passwords. My buddy (coder) was able to decrypt the whole thing through the use of PHP. I lost the files for it though, so I would have to ask my buddy.

Basically the simple explanation to that is one of those "the first 4 bytes is the <fill in the blank>, the next 2 bytes are the <blank>," and so on. That's what I know at the moment.

The one thing that seems to be is that each and every player has a dual password. For example, I might be using "abc123" for my player password. To the biller, "abc123" AND "s7sgf87th0t34a0" would be my password (that was just random garble). For odd-numbered lengthed passwords, I think the "regenerated" form of their password is what is stored in users.dat. Even-numbered lengths should be in their natural "abc123" form. I think all users have their "abc123" password, and whether a system administrator knows it or not, they all also have a "regenerated/encrypted" password or whatever. Encrypted is probably the wrong word for this.

Cheese - Fri Mar 23, 2007 3:42 pm
Post subject:

luckily i dont care about the pws xD

i want to make a better dat viewer...

that lets you edit everything.

Cheese - Fri Mar 23, 2007 4:15 pm
Post subject:

each entry is 196 bytes long.

Code: Show/Hide

45000000677265656E737061636500000000000000000000000000000000
0000000000007C12561657EA00000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000C000000520000000100000052B5A08
7A48E166F6DDF02466DDF024688FF0100

all values are in hexadecimal.

45000000 is the userid. (decimal 69)

677265656E7370616365000000000000000000
00000000000000000000000000 is the name. (hex greenspace)

7C12561657EA00000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000 is ????????

0C000000 is squad id. (decimal 12)

52000000 is total usage in seconds. (decimal 82)

01000000 is number of logins. (decimal 1)

52B5A087 is last ip.

A48E166F is macid.

6DDF0246 is last login date/time.

6DDF0246 is creation date/time.

88FF is time zone bias.

0100 is bypass. (decimal 1)

i will fill in the blanks when i find out what they are.
btw what is bypass?

Maverick - Fri Mar 23, 2007 4:19 pm
Post subject:

Cheese, you prove that it's a good thing players are warned when they enter a zone with a custom (non-ssc) biller.

Mine GO BOOM - Fri Mar 23, 2007 4:20 pm
Post subject:

As long as you make sure when you merge the userids in, that they are unique, you should be able to just append it to the end of the other users.dat file. I have not tried it, but I don't remember seeing any special header section in the file that would need changed, just straight data. Squad information won't transfer, but usernames/passwords should this way.

Cheese - Fri Mar 23, 2007 4:27 pm
Post subject:

well, until now, the dat viewers dealt with the squad/user/score dats seperately.

it should be fairly easy to link them :\

@ mav
EZ ;D i wont even try to decode pw. No need. Nor will i help anyone to do so. Plus, thats why its encrypted xD

Cheese - Fri Mar 23, 2007 4:43 pm
Post subject:

**this post has been brutally killed by cheese**

ps. wheeeeeee it only took me 20 mins to decode all that ;D

Animate Dreams - Fri Mar 23, 2007 5:16 pm
Post subject:

Lol, Mav, there are existing billers that use no encryption on their player database(including passwords) at all. If Cheese has proven anything to you, it should be that the people who are trying to get passwords just aren't that smart. You should've caught onto the non-SSC warning thing being necessary YEARS ago.

BDwinsAlt - Sat Mar 24, 2007 1:29 am
Post subject:

Skybill showed my pass in plain text in the terminal when I entered asss. Who ever said it sent out an encoded password from the client to the biller lied. I heard that from somewhere. The password looks like it's being sent in plain text from the client to the server.

Couldn't you just edit catid's biller a little and take out the encryption part?

Dr Brain - Sat Mar 24, 2007 8:38 am
Post subject:

If you think your password on catid's biller is any more secure, then you're dead wrong.

Smong - Sat Mar 24, 2007 11:57 am
Post subject:

BDwinsAlt wrote:

Who ever said it sent out an encoded password from the client to the biller lied. I heard that from somewhere. The password looks like it's being sent in plain text from the client to the server.

Supposedly only the SSC biller makes the client send the encoded password.

BDwinsAlt - Sun Mar 25, 2007 10:30 pm
Post subject:

Isn't that reverse of what it should be. I trust SSC with plain text passwords. I don't trust another network without an encoded password.

Continuum needs a makeover then.
Maybe a Client-side MD5 hash?

Animate Dreams - Sun Mar 25, 2007 11:58 pm
Post subject:

Smong wrote:

[..]

Supposedly only the SSC biller makes the client send the encoded password.

I believe the unencoded password is only sent to the biller(in the case of SSC) on the first login, and thereafter the encoded password is used. SkyBill isn't done, I'm pretty sure Doc Flabby doesn't plan on leaving it as plain text passwords. But he has(understandably) left it as such at the moment, since it's still in development. But this should be a hint that password security amounts to absolutely nothing. In other words, NEVER use the same password on a non-ssc server.

BDwinsAlt - Mon Mar 26, 2007 12:21 am
Post subject:

Good thing I use a different alias

Smong - Mon Mar 26, 2007 6:15 am
Post subject:

BDwinsAlt wrote:

Isn't that reverse of what it should be. I trust SSC with plain text passwords. I don't trust another network without an encoded password.

It would be nice if cont always used the encoded password (excluding account creation as Animate Dreams pointed out). I suspect what happened is SSC was the only custom biller at the time it was added to cont. As such there are no documents made for other future billers to implement an encoded password.

It's not just about trusting SSC. Any zone is vulnerable to password grabbing exploits. SSC merely encodes the password so should someone manage to grab it they can't use it.

Doc Flabby - Mon Mar 26, 2007 6:37 am
Post subject:

I suggest a read of this thread.

http://forums.minegoboom.com/viewtopic.php?t=7166

The server can just as easily obtain the password as the biller. When you login to a zone you need to trust both. The encoding continuum uses to send the password to SSC servers can be cracked at the server if its the same encoding i think it is..... Which would (partly) explain why SSC is so careful about what servers it grants access too.

Cheese - Wed Mar 28, 2007 5:33 pm
Post subject:

rightfully so.

make it better, mr flabby!

Cheese - Wed Mar 28, 2007 7:37 pm
Post subject:

and also, from whats left, its looks like the pw is encrypted (maybe).
the hex does not match up with the ASCII...

hmm.

so were you saying that pw is plain text in transit?