Ben Byer wrote:
On Fri, 07 Jul 2006 16:23:31 -0700, "John Hurliman" <[EMAIL PROTECTED]>
said:
The UpdateInventoryItem packet contains a CRC that, according to
Phoenix Linden is "made up of a couple of the other fields". Through
trial and error we've discovered it is affected by at least some of
the UUIDs and permission masks, but not the name or description. Our
best guess is that this is a CRC-32, but we've found no evidence to
support this guess, it could just as easily be a homebrewed CRC
algorithm. Code or pseudocode to generate this one field nets $150
through PayPal.
For the big bucks:
General idea: add together a bunch of 32-bit little-endian numbers (with
one exception) and there you go
pseudo-Cish code: (assuming all of the non-UUID values are already
correctly stored in the correct-endian format, of course)
unsigned int LLUUID_crc(byte uuid[16]) {
unsigned int retval=0;
retval+= (uuid[3]<<24+uuid[2]<<16+uuid[1]<<8+uuid[0]);
retval+= (uuid[7]<<24+uuid[6]<<16+uuid[5]<<8+uuid[4]);
retval+= (uuid[11]<<24+uuid[10]<<16+uuid[9]<<8+uuid[8]);
retval+= (uuid[15]<<24+uuid[14]<<16+uuid[13]<<8+uuid[12]);
return retval;
}
unsigned int CRC=0; // 32 bits!
/* IDs */
CRC += LLUUID_crc(AssetID);
CRC += LLUUID_crc(FolderID);
CRC += LLUUID_crc(ItemID);
/* Permission stuff */
CRC += LLUUID_crc(CreatorID);
CRC += LLUUID_crc(OwnerID);
CRC += LLUUID_crc(GroupID);
/* CRC += another 4 words which always seem to be zero -- unclear if
this
is a LLUUID or what */
CRC += owner_mask; /* Either owner_mask or next_owner_mask
may need to be */
CRC += next_owner_mask; /* switched with base_mask -- 2 values go
here and in my */
CRC += everyone_mask; /* study item, the three were identical.
*/
CRC += group_mask;
/* other, uh, stuff */
CRC += flags;
CRC += (unsigned int)inv_type;
CRC += (unsigned int)type; // watch out for sign extension
here --
CRC += (unsigned int)creation_date; // all of these values are
internally stored
CRC += (unsigned int)sale_price; // as 32-bit numbers
CRC += (unsigned int)(sale_type* 0x07073096); /* this looks like some
sort of attempt at
an actual CRC32 -- it
comes from the table
but the first 4 bits
are zero -- odd */
So, to be clear here, the "CRC" is calculated by simple addition, with
only one value being multiplied.
As a double-check, let's match this up against the packet:
Low 00321 - UpdateInventoryItem - Untrusted - Unencoded
0065 InventoryData (Variable)
0047 GroupOwned (BOOL / 1) (unused)
0149 CRC (U32 / 1) (n/a)
0159 CreationDate (S32 / 1) (used, as unsigned -- may not
matter)
0345 SaleType (U8 / 1) (used, but multiplied by
0x07073096)
0395 BaseMask (U32 / 1) (may be used? see above)
0506 Name (Variable / 1) (not used.)
0562 InvType (S8 / 1) (used, but as a U32)
0630 Type (S8 / 1) (used, but as a U32)
0680 AssetID (LLUUID / 1) (broken up into U32s and added)
0699 GroupID (LLUUID / 1) (ditto)
0716 SalePrice (S32 / 1) (used as a U32)
0719 OwnerID (LLUUID / 1) (as above)
0736 CreatorID (LLUUID / 1) (as above)
0968 ItemID (LLUUID / 1) (as above)
1025 FolderID (LLUUID / 1) (as above)
1084 EveryoneMask (U32 / 1) (used)
1101 Description (Variable / 1) (not used)
1189 Flags (U32 / 1) (used)
1348 NextOwnerMask (U32 / 1) (used)
1452 GroupMask (U32 / 1) (used)
1505 OwnerMask (U32 / 1) (used)
Either BaseMask, GroupMask or OwnerMask is thrown away -- not clear from
above. I didn't see GroupOwned being used, but it could be in the zero
bytes I mentioned.
Ben
This works perfectly for the test cases I have available, great stuff.
I'll commit an UpdateInventoryItem packet helper to svn after I get some
sleep, e-mail me directly with the PayPal e-mail address to route the
money to. Quick question, how would you go about creating a non-zero
SaleType for something in the client? That seems like the most bizarre
part of the algorithm and all my test cases have a zero value. An 8-bit
value is multiplied by a 32-bit value and added to the CRC... maybe the
developers meant to add the SaleType then multiply the final CRC by the
32-bit value, and it's a mistake in the code? Doesn't concern me as long
as it works I suppose. Automated notecard generation here we come.
John
_______________________________________________
libsecondlife-dev mailing list
[email protected]
https://mail.gna.org/listinfo/libsecondlife-dev
