PenUltima Online

I have been trying to learn Ruby so I decided to write a small client for UO in it. I probably sent a lot of very strange packets that scared the POL server. I've mostly only been playing with the login packet (0x80). My program is suposed to report back when login was successful but it wasn't working. I thought it was my poor ruby skills (for a least an hour) then I found I couldn't even login with the client. I can't login with any account at all. After I send my IP and 0x80 packet, the server does not respond at all, so it gets hung up at "Verifying Account..."

I noticed there were TWO admin accounts in my accounts.txt for some odd reason. I took one of them out but I am still unable to login. Everything is configured correctly.

So my problems are unable to login despite not having changed ANY configuration files (only sent strange packets), and duplicate admin accounts.




[edit]
After closing and reopening my account again, for some reason, this time it worked and I can login. But the question still remains as to why POL will suddenly not like me anymore once I start sending it strange data.
[/edit]

Wild guess here, but it may have to do with how I incorrectly padded the account name.

Normally username and password are sent with the null padding AFTER, but I was adding it before on accident. So maybe POL saw the difference between sent as "admin" and THEN as many nulls as it would take fill 30 bytes.

Maybe it saw the difference between:
61646d696e00000000000000000000000000000000000000000000000000 (correct "admin")

And:
0000000000000000000000000000000000000000000000000061646d696e (incorrect "admin")

And saw it wasn't an account that existed, then removed nulls and created it.


[edit]
It also seems that after about 8 login attempts, successful or not, POL lock that account so you can't login. I'm not sure if this is per-IP since I don't have another computer from which to test. It would be nice if this were a configurable option in pol.cfg.
[/edit]

first question is which auto account creater do u use? ...it's not a part of the core! but pol shouldn't create duplicate accounts - you're right.

pol doesn't block your account by core after x times of failed logon. maybe the client blocks it.

Shinigami

The auto account creator must be part of the distro, though the auto creator I looked at didn't seem like it was responsible. That's what I get for just glancing over the code. The problem of duplicate accounts is somewhere in there, then.


Using a script I made to simulate the login of the client, I tried to connect to my server 8 times and each time I got an 0xA8 (login successful) packet back, but on the 9th time there was no response. I could not even login with the client, so it is server side. I tested with a server on the internet and it did the same thing. After 8 or so logins the account would lock out, but other accounts could login still.

[edit]
Try with just the client. Login, then back out, login again, backout, repeat this a few times and then you'll eventually get stuck at the Validating screen. Restarting the client does not help.
[/edit]

Sounds to me like it's allowing invalid characters/zero fill at the beginning of the account name, so it's not technically creating dupes (to itself it's not anyway), but once fully parsed and recorded, it's cleaned up and turns into one??

Hrm. Interesting. Correct, tis a bug that it is allowed. If I get time I will check into it also, see if I can find the part causing it (don't hold your breath though, got 3 kids sick right now, so limited time, hehehe). Unless Shini beats me to it

I hope they get well! Plenty of rest and liquids, you know. I don't know how you find the time, man!

Do you have any idea as to why POL would just start ignoring me after a few 0x80 packets? If it's not just my bad luck that it happens (it happened with the distro techdemo server as well), it could be used as an annoying denial of service attack.

It would also be neat if POL logged if an IP failed to login after a number of times to the console, or automatically ban IPs after so many connections in a short amount of time (a few minutes).

Run UOLog to see if the client continues to send the login packets (including the one it freezes on and stops talking with pol!!!). It could be in the client, that it is not sending it at all after that.


Otherwise, then yes, it would be a fail-safe device in POL that would cause it to start ignoring it after so many consecutive.

Btw mate, why Ruby?

Anyway, check for redundancy in the packet hook, that will fix issues like this. Convert to CasZ and so forth, like the oldschool script fixes for stealing admin rights. Should fix the problem easily enough.

What possessed you to start working on your own client? Does sound interesting though, might want to look at it sometime myself

I read a lot about how easy and intuitive Ruby is and I wanted to try it out. I must say I'm impressed. I wrote this "client" in a few hours and most of it was figuring out how to format the data to send to the server. I haven't worked with sockets in Ages. I also wanted to see if I could make a decent socket application in OOP.

The packets are being sent but they're not being responded to. It's probably a failsafe, as you suggest. It would be nice if it were configurable in pol.cfg. Maybe with an option to ban that IP for a short amount of time instead of just locking the account until ???/server restart.

I wanted the foundation for a UO client so I could play with odd concepts like UO bots, password retrieval, finding bugs with the server, etc... There have just been too many times I'd have a weird idea in the bathroom and wish I had a UO client that I could play with. And, calling it a client is quite a stretch because I really only wanted to implement a few packets for now. Maybe in the future have more.


[edit]
Apparently the problem of being "locked out" isn't in the core. It's in a packet hook I didn't know existed that prevents people from doing an invalid login too many times. I think it may be locking you out of you have a valid login as well, which I'm checking now...
[/edit]

Well I found that onLogin.src in the accounts package was not properly removing trailing null values from the username and password, so I fixed RemoveSpaces() in strings.inc to remove nulls and now it works fine.

It was failing the login check every time because the username and password would have 30 - Len(username) characters of null at the end. Now, if someone fails too many times, it only hangs on them if they get an invalid password. I'll commit this to the SVN now.

How long will you be at work? Might have something for you to test something on.

aka, the result of "char" in packet hooks before character selection.

Another 2 hours or so. I can stay longer and just clock out and play on the computers.

lol ok.

Will port this over to 097 and send you a compiled version to your email

Check your email

And fire up AIM, so we can just talk there

Working on a more rebust function in string.inc to help.

Should packet.GetString return the string padded by null values?? Is that a bug in the core?

Depends on your length and offset for the starting point. With it involving packets, it would not be a bug, but rather a script issue. It gets what you pass, but if what you pass is not correct for the packet, it's on you

If a packet is malformed, like this case, the issue in GetString is a user error by not reading the packet correctly (but in fact, the packet itself was incorrect, so it worked correctly). Thus, the result would be as expected.

However, is Account creation somehow using those whitespace characters also?

The packet was correctly formed. I don't think GetString() returning null values was expected. I thought it might be intentional but I was just asking to be sure.

When it would try to find the account 'admin ', it wouldn't find it and would tell the core to create it, and the core created the account and possibly somewhere along the way stripped the nulls. I should have checked the accounts.txt file to see if there were nulls next to the name. Maybe the core should have stripped the nulls in the beginning and checked if that account existed and returned an error if it did.

Yes, and no.

GetString returns a literal of the offset and length, which is intended. have you tried the oldschool method of putting the result through CasZ() to see if that corrects it? Used to be used to fix exploits from web account creation.

I did that and got an array full of 0s. I just remove the nulls from the username and password using a shared function in strings.inc. I asked about the possibility of a trim command in the core and it got locked without so much as a "shut up tekproxy, that's stupid!" I only asked because I thought it would be really easy and small. I'm all for keeping the core tiny and doing most of the work with scripts.

Yeah, while all the basic commands like trim, find, sort, etc would be really nice, you have to think about it. eScript uses a frontend of it's own language, to interface with the core, so even adding something like trim(), means doing a lot more than simply added 4 or so lines.

I do agree, keeping it as simple as possible. It's a balancing act. Simple vs wide spread use to justify. It's all about "how much is this going to be used, and also be helpful". Some stuff put in, is far from it, some was only because it was felt to be more than simply helpful.

Thank you for explaining that. I understand things more clearly now.


...


So how about those outgoing aux connections I asked for last year? Just kidding.

Make a normal one...........

Set up a cron or scheduled task on the remote..........

bam

Yeah. I do that already. AuxServices rock.

Gotta love it