Top Posters
Top Uploaders
Users Online
Stats
Password Corruption
[POST #1] ---------------------------------------------------------------
Original topic:
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=5369
Apparently, if you have someone on your ignore list, and they are online, and you try to log on the game, the mud for some reason will check their password against what you entered. This seems like a major problem. Here's the log:
Log: Zeno: loadup derius Comm: Loading player data for: Derius (6K) Player Derius loaded from room 2500. Done.
Log: Zeno: force Derius ignore Alexander
(Alexander is now on his ignore list)
[Forced him to save and quit]
[Alexander is currently online]
[His password is currently admin1]
Enter your hero's name, or type new: Derius Password: admin1 Wrong password. Monitor: Derius; arg: admin1, encryp-arg: De00dAfYFRDsU encryp-pass: AlcdLtbYc.CCo Comm: Derius@24.194.57.197 wrong password. Comm: Closing link to Derius.
[zeno@boralis player]$ grep AlcdLtbYc.CCo */* a/Alexander:Password AlcdLtbYc.CCo~
(That would be Alexander's password)
[loaded up Derius]
Log: Zeno: force Derius ignore Alexander
(Alexander is taken off ignore list)
[Forced Derius to save and quit]
Name: Derius Password: admin1 Last connected from: (Link-Dead)
There may be other factors to this.
Alexander was the 3rd ignored person on Derius's list. Derius in a clan.
I haven't changed anything with passwords or ignore. I can reproduce this every time, even with 1 ignore. As long as the ignored player is on.
[POST #2] ---------------------------------------------------------------
Have you tried applying the MD5 password fix that was last posted in the bugfix threads? This may fix the issue you're having.
Edit: Oh. Bah. This happens under original passwords? Very odd. I never noticed any kind of problem with it before. I guess I should be glad we've been using MD5 for a long time now :P
Really not sure what might be causing that one actually.
[POST #3] ---------------------------------------------------------------
Yeah, I'll switch to MD5 today, after brunch and stuff. Wasn't planning to switch until beta.
[POST #4] ---------------------------------------------------------------
Alright I switched to md5, and I still have the problem. Here's my ignore read/write:
/* If ch is ignoring players then store those players */
{
IGNORE_DATA *temp;
for(temp = ch->pcdata->first_ignored; temp; temp = temp->next)
{
fprintf(fp,"Ignored %s~
", temp->name);
}
}
if(!strcmp(word, "Ignored"))
{
char *temp;
char fname[1024];
struct stat fst;
int ign;
IGNORE_DATA *inode;
/* Get the name */
temp = fread_string(fp);
sprintf(fname, "%s%c/%s", PLAYER_DIR,
tolower(temp[0]), capitalize(temp));
/* If there isn't a pfile for the name */
/* then don't add it to the list */
if(stat(fname, &fst) == -1)
{
if( temp )
STRFREE( temp );
fMatch = TRUE;
break;
}
/* Count the number of names already ignored */
for(ign = 0, inode = ch->pcdata->first_ignored; inode;
inode = inode->next)
{
ign++;
}
/* Add the name unless the limit has been reached */
if(ign >= MAX_IGN)
{
bug("fread_char: too many ignored names");
}
else
{
/* Add the name to the list */
CREATE(inode, IGNORE_DATA, 1);
inode->name = STRALLOC(temp);
inode->next = NULL;
inode->prev = NULL;
LINK(inode, ch->pcdata->first_ignored,
ch->pcdata->last_ignored, next,
prev);
}
if( temp )
STRFREE( temp );
fMatch = TRUE;
break;
}
Password read/write:
fprintf( fp, "Password %s~ ", ch->pcdata->pwd );
KEY( "Password", ch->pcdata->pwd, fread_string_nohash( fp ) );
This is a pretty big problem, so I'm looking for almost anyway to fix it. I'll run valgrind now.
[EDIT] From ignoring a person, saving, quitting, logging on, entering password, and being denied because of wrong password, there was nothing from valgrind.
[POST #5] ---------------------------------------------------------------
Nothing new came up. Still the same problem. Since ch->name is fine, but ch->pcdata->password is not, could that mean that ch->pcdata is corrupt/switched? I'm not sure how to compare/find out if it is. Sure I could use gdb to print it, but wouldn't be able to tell.
[POST #6] ---------------------------------------------------------------
Sorry. Really have no idea what to tell you. The old PW will probably remain borked since it hasn't been converted yet. If this is just happening to one person, use the formpass command to generate them a new password. Save it in their pfile, raise the version by 1. Problem solved. Move on.
If it's affecting all of your pfiles.... well.... dunno. I've been over the ignore code with a fine tooth comb and can't see anything that should have affected this.
[POST #7] ---------------------------------------------------------------
It's a mud wide problem, which is why I can tell this is no where near a simple problem.
I'm trying out for help on TMC and TMS too, but I have a feeling nothing will get done unless I let someone my investigate first hand.
[POST #8] ---------------------------------------------------------------
From what I can see with the posted information, it sounds like the pointer is just getting corrupted, but with a fairly regular basis. You could always to to make a variable somewhere not associated with the player file just for testing and check on a regular interval to see when/if it changes.
Also, is the actual value of the his password pointing to someone else, or is that when its being compared its referencing the wrong value?
[POST #9] ---------------------------------------------------------------
I'm really not sure what you mean. Could you provide a direct example?
[POST #10] ---------------------------------------------------------------
Well, for example, in the code that checks on the password, is the value simply corrupt, or has the actual pointer value changed? If you print the memory adress that the pointer points to when they log on, and then again compared to when password is being checked, has the pointer changed, the value of the characters password, or is it perhaps something else altogether, like the value of the password is copied into a local variable and that variable becomes corrupt rather than the original value.
Just print out the value and the memory adress(log or gdb, gdb is probably easied) upon loadup of the pfile thats returned from stralloc. If, when they log on, and its being compared to the generated value, is the value changed or the pointer changed.
Sorry, I'm a little sick and have just taken alot of nyquil, so any actual code I produced may infact cause the world to impode.
[POST #11] ---------------------------------------------------------------
Looks like it's just the password field becoming corrupt.
Monitor: Xio; arg: hobs, md5-arg: ÃîyÊŠºñ&Q?÷Š›kö md5-pass: ¹À?½˜Š°°ô{XjÑnì [Xio]
The name in brackets [Xio] at the end is ch->pcdata->filename. So the pcdata pointer is not corrupt, right? It's just password.
[POST #12] ---------------------------------------------------------------
Yeah, just your password pointer. When the other person quits, does it happen to revert? Also, if the person saves, does the new(corrupt) password save to the pfile?
[POST #13] ---------------------------------------------------------------
If the other person quits, the person who couldn't log on can get on. So yes, the password pointer reverts/becomes normal if the ignored person is not on.
Er? Which person? The one can't log on so they can't save. The other has no problems.
[POST #14] ----------------------------------------------------------------
hmmm, true. Can they, say, suicide if they are on someones ignore list?
Actually, I don't even know if smaug has another function that checks someones password.
Either way, I guess the question becomes is the actual value that is saved into their ch->pcdata->pwd corrupt, as in whats being read in is not valid, or whats returned from stralloc is corrupt, or is it that its fine during loading the character, but only becomes corrupt when it tries to compare passwords?
[POST #15] ----------------------------------------------------------------
Yes. I (Zeno) ignored my alt (Xio). Xio was then able to delete as normal.
The only thing I can think of that uses passwords is the password command, and delete. I'm glad that pcdata wasn't corrupt, only pwd.
[POST #16] ----------------------------------------------------------------
So is stralloc return a corrupted string, or is the value being provided to it corrupt, or is it something that happens after reading the character in?
[POST #17] ----------------------------------------------------------------
Er, I'm not sure how to find that out. The actual string isn't "corrupted" since it's another players password. Although I'm probably just not understanding what you mean.
[POST #18] ----------------------------------------------------------------
Ah, I've gotten somewhere thanks to someoneone TMC and watch points:
(gdb) watch ch->pcdata->pwd
Hardware watchpoint 3: ch->pcdata->pwd
(gdb) c
Continuing.
Hardware watchpoint 3: ch->pcdata->pwd
Old value = 0x9f78d60 ""
New value = 0x0
0x080b3cfb in check_reconnect (d=0xa077748, name=0x81c9aa0 "Xael", fConn=0 '') at comm.c:3152
3152 DISPOSE( d->character->pcdata->pwd );
(gdb) list
3147 }
3148 return BERR;
3149 }
3150 if ( fConn == FALSE )
3151 {
3152 DISPOSE( d->character->pcdata->pwd );
3153 d->character->pcdata->pwd = str_dup( ch->pcdata->pwd );
3154 }
3155 else
3156 {
Hardware watchpoint 3: ch->pcdata->pwd
Old value = 0x0
New value = 0x9f78d60 "èûÃð5
[POST #19] ----------------------------------------------------------------
Question. Have you tested this against an unmodified FUSS? Against an unmodified original Smaug? If you have and I just missed it, ignore me :P
One would think that if this were a bug that affected multiple muds that someone would have screamed about it long before now so I'm leaning toward thinking you've got some kind of modification it didn't like. Have you considered adding the new STRFREE and DISPOSE macros in the general forum to see if you get anything flagged by that?
[POST #20] ----------------------------------------------------------------
Hmm I guess I posted it somewhere else. Yeah, if you haven't realized it yet, this pertains only to my code. I did a test on SmaugFUSS before and its fine. Either I forgot to say that, or it's just somewhere else (Gammon, TMC, etc).
I'll go ahead and try adding those macros as soon as I figure out why my mud proc does not want to be killed. >.>
[POST #21] ----------------------------------------------------------------
Your new macros are wonderful, I'm sure they will help me out. Although the password issue didn't have any bugs with that. Going to gdb with watchpoints again, this time I've commented out those SegVio/crashover functions. Sorry about that, heh.
[POST #22] ----------------------------------------------------------------
Uhh, it turns out this line (the commented one) caused all this:
argument[0] = UPPER(argument[0]);
//argument = capitalize(argument);
Wasn't the best idea to do, it was temp, but I never expected it to cause this. Anyone know why?
[POST #23] ----------------------------------------------------------------
Where exactly is that code block located?
The UPPER macro isn't quite as intrusive as capitalize. capitalize doesn't just uppercase the first letter, it also lowercases all of the other letters in the string. Depending on what you used this on it might explain some things.
[POST #24] ----------------------------------------------------------------
default:
bug( "Nanny: bad d->connected %d.", d->connected );
close_socket( d, TRUE );
return;
case CON_GET_NAME:
if ( argument[0] == '' )
{
close_socket( d, FALSE );
return;
}
argument[0] = UPPER(argument[0]);
//argument = capitalize(argument);
/* Old players can keep their characters. -- Alty */
if ( !check_parse_name( argument, (d->newstate != 0) ) )
{
write_to_buffer( d, "Illegal name, try another.\n\rName: ", 0 );
return;
}
The capitalize was not stock. It was the part causing this problem.
[POST #25] ----------------------------------------------------------------
Strange. I don't see any reason it should, but hey, if that's all it was.... :)
It's a bit like another bug we had in our AFKMud C++ conversion. Missed one lousy boolean reset. Caused a hideous infinite loop because of it.
[POST #26] ----------------------------------------------------------------
Yeah, it's really odd. I seem to attract horrible bugs. Arrrgh.
At least this bug was fixed. Phew.