|
|
10-05-2010, 12:42 PM
Hello, I have a 471 deob and I want to make a server for it, so I'm attempting to retrieve the update keys from the cache, according to information here on the forums they are the bytes in the .idx255 reference table.
So:
first reading the actual header(3 bytes):
unsigned byte cacheid
unsigned short fileid
then reading the container header(5 bytes):
unsigned byte compressiontype
int containersize(some say this is tribyte, I've tried both, I still don't get the right ukeys)
then I just read a byte[containersize]
Then I heard diffrent versions of what to do:
-some say just read all the bytes 1 by 1 which will give the ukeys
-others say first the cacheid byte then the fileid byte shifted to the left by 8 and then the fileid byte and then all the bytes are the rest of the ukeys.
I'm testing this with a revision of which I allready have the ukeys to compare, but I'm having no luck.. I've noticed all the update keys in all the revisions start with 0xff 0x00 0xff and then a couple of more 0x00 before the actual thing seems to start and they all end with a couple of 0x00's
However my output does not start with these things and in the end of my output there's LOTS of 0x00's, not a couple but ALOT and it says my containersize is 65k+ bytes..
Does anyone know the problem or just have the 471 update keys or can tell me where in the client the update keys are being compared as my attempts of tracing that method have been unsuccessful.
Thanks in advance!
bump..
Also I heard I need to only look in file 255 of cache 255 so i ripped the methods from the client however that get method contains
if (idxFile.getCacheFileLen() < (long) (6 + id * 6)){
and basicly my filelength is always too low so it won't run.. the .idx255 file is 96 bytes but ofc id 255 * 6 + 6 is way higher, does this mean my cache is not complete? however I swear it is..:/
I've seen that thread before, but at this point I don't think it can help me further:/
I think I got em now by just isolating myself with the client
the first 8 ukeys are always 0xff 0x00 0xff 0x00 INT
int is 4 bytes so far every revision i've seen it's 0x00 0x00 0x00 SOMEBYTE, I took the same as in 474(0x80) and it kinda worked..
Then the next ukeys are 4 bytes for crc value and another 4 bytes for FIT revision, so that's 8 bytes for every cacheidx in that revision
The last 8 ukeys don't really come into play (I think), if I change them on other revisions it still works perfectly, so I took the same ones as in 474: 0xb8 0xf2 0x4d 0x21 0x00 0x00 0x00 0x00
However I'm not 100% sure it is correct, but for now I'm blaming it on incomplete 471 cache, if anyone has anymore information about this or a 471 cache that you're sure of is complete please respond. (I think the cache is incomplete because I keep getting stuck either at sound engine or loading fonts..)
Code:public static int UNKNOWN = 0x80;//change public static void makeIt(int i, int[] keys, int pos){ keys[pos] = i >> 24; keys[pos+1] = i >> 16; keys[pos+2] = i >> 8; keys[pos+3] = i; } public static int[] crcVals = {595519776, 525774820, -2012082158, -615227200, 789053345, -1973169980, 2071664368, -965120839, 907761831, 405724540, 785097901, -1293052677, -1573563692, 126773822, -1551042924, -1192080095};//16 ints need to be i think public static int[] fitVals = {0, 0, 186, 92, 15, 57, 0, 96, 19, 0, 0, 0, 74, 1, 1, 0};//16 ints public static int[] getUKEYS(){ int[] ukeys = new int[8+crcVals.length*8*2+8]; ukeys[0] = -1; ukeys[1] = 0; ukeys[2] = -1; ukeys[3] = 0; ukeys[4] = 0; ukeys[5] = 0; ukeys[6] = 0; ukeys[7] = UNKNOWN; for(int i = 0; i < crcVals.length; i++){ makeIt(crcVals[i], ukeys, 8+i*8); makeIt(fitVals[i], ukeys, 12+i*8); } int pos = (crcVals.length - 1)*8+12+4; ukeys[pos] = 0xb8; ukeys[pos+1] = 0xf2; ukeys[pos+2] = 0x4d; ukeys[pos+3] = 0x21; ukeys[pos+4] = 0; ukeys[pos+5] = 0; ukeys[pos+6] = 0; ukeys[pos+7] = 0; return ukeys; }
| « 40$ for stuff to be done. | how to fix a error? » |
| Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |
