It's kind of annoying to get muted for typing, so I looked through the files to see if I could remove the filters but I didn't find anything. Does anyone know where that stuff is stored or if I can disable it entirely?
It's kind of annoying to get muted for typing, so I looked through the files to see if I could remove the filters but I didn't find anything. Does anyone know where that stuff is stored or if I can disable it entirely?
There is a file called chat.bin in the paks. It's the filter that contains a lot of bad words.Originally Posted by Patchouli
The chat.bin is a zip archive file. Inside there is a "content.dat" file. Edit it with an Hex editor and if you don't want any filter, just write FF FF FF FF in the content.dat then rezip it and rename to chat.bin again.
To finish, put it in a pak file
Ahhh, that's why I didn't see it. I only did a quick search on chat.bin for swear words, didn't think it was a zip file as well. I should have known from the PK header. Thanks!
Last edited by Patchouli; 19-03-11 at 04:40 AM.
Hello Bubbastic (or anyone who can solves my problem)
I'v found the chat.bin and the content.dat there's inside. Had open the final file with a Hex Editor (UltraEdit). But there isn't any recognizable bad word to mess with and create a custom chat filter!
All I'v found was a lot of ASCII "ÿ"s (FF hexa-codes) and, regularly, some "random" characters - what I mind are the bad words, or at least the starting byte-codes mark of!
I'v tried to insert my desired-to-block words over this strings - then packed it and throw over the client files as an additional update, of course - but didn't worked. Otherwise, turning all the file on null HexaType data (FF, as pointed by Bubbastic) worked to dismiss the manner filter.
I'm currently installing the Windows Thai LIP language files, hoping this will enable to show correctly the words but on this idiom. But doesn't believes it will help so much...
Can anyone point me the right direction?
PS: Trying right now to edit the USA's chat.bin/content.dat files... It structure is very similar to the Thai file but the strings are whole different!
And, about the W7 interface language, it hadn't worked to show the "right" characters as fine I'v expected...
Last edited by Xereta; 23-03-12 at 03:02 AM.
You need to subtract the original byte value from 256/XOR it (for every byte, of course) to encrypt/decrypt the list, otherwise - as you noted - you won't see any proper text. And yes, the file format is identical across all Pangya versions.Hello Bubbastic (or anyone who can solves my problem)
I'v found the chat.bin and the content.dat there's inside. Had open the final file with a Hex Editor (UltraEdit). But there isn't any recognizable bad word to mess with and create a custom chat filter!
All I'v found was a lot of ASCII "ÿ"s (FF hexa-codes) and, regularly, some "random" characters - what I mind are the bad words, or at least the starting byte-codes mark of!
I'v tried to insert my desired-to-block words over this strings - then packed it and throw over the client files as an additional update, of course - but didn't worked. Otherwise, turning all the file on null HexaType data (FF, as pointed by Bubbastic) worked to dismiss the manner filter.
I'm currently installing the Windows Thai LIP language files, hoping this will enable to show correctly the words but on this idiom. But doesn't believes it will help so much...
Can anyone point me the right direction?
PS: Trying right now to edit the USA's chat.bin/content.dat files... It structure is very similar to the Thai file but the strings are whole different!
And, about the W7 interface language, it hadn't worked to show the "right" characters as fine I'v expected...
Sorry, but I'm not so experienced on encrypting/decrypting data - so I'm kinda "reading greek" from you...
Can you explain this a bit to get the point? AFAIK, almost all encrypting needs a key to work. Is that key the very first byte at both files (AD at Thai version, 52 at USA version)? And how can I handle those calcles? What is the formula needed?
I sincerely fells asking above those I can, but I'm really annoyed about this filter issue!
EDIT:
NVM! I believes got the point already: was using ASCII HexaCode to decimal and subtracting it from 256, and didnt worked fine (but comes near to bad words). Now I'v tried to subtract from 255 and looks like worked!
I'v forgotten that "0" IS ALREADY a value on programming (and a not-null value, from where all counting starts)!
Now, to the next step, just to take things clear:
Is it advisable to obey the string starting point on the used file, alright? And, as far can I see comparing both files, I just need to add a new array of bytes with the same length from all before if the file becomes smaller than needed...
Double edit:
Just to inform, I did it! Already added my very first bad word to the filtering! But an alert...
I'v tried, first, using USA's file. Didn't worked - only a single char has been blocked on the whole word. Apparently USA's file structure differs a bit from Thai one: that bad words starts on one earlier bytecode slot than Thai. Also the very first bytecode of the file differs. Using Thai files worked for fine.
Tried to edit adding this info yesterday, but the forums had gone to maintenance while editing the post.
Last edited by Xereta; 23-03-12 at 04:46 PM.
When I said the file structure is identical, I did mean it.
I recommend you count the number of entries in each file and compare it with the int16 value at the beginning of the file...
So is that first byte a entry control checking value? Need I mess with if expanding (or reducing) the file size/number of entries?
Just replacing the existent entries was quite sufficient for me till now, and I'm right busy with some other threads ATM. But will check this later.
Ty for the tip! ^^
PS: I'll try both, but minds the first byte doesn't needs to be decrypted (does not makes much sense). Fine?
It's a counter (starting at 1) for the number of entries in the file. Modifying the number of entries (i.e. adding or deleting) will require you to adjust it.
Keep in mind that entries in the file always have a fixed length (30 bytes).
Correct, the counter is not encrypted. Doesn't really make any sense to XOR the values either (since it's pretty obvious what they did there...), so I guess this is a genuine case of ntreev logic - trying to confuse the ignorant masses with fog and flashing lights. :)
