This hardly merits the name of encyption, but merely obfuscation.encrypted with CB v1 encryption
This is of course a form of encryption, or as I called it "encrypted storage mode".encrypted with CB v7 encryption (Beefcode...)
And this is just 'raw storage mode'unencrypted aka raw
I regard all of these simply as different ways of storing the same type of data, the pure form of which is the 'raw' cheat code form.
I have zero interest in myself using cheat encryption as it serves no positive purpose.You can learn more about the encryption schemes and how to toggle them here:
The only purpose it does serve is to make it harder to export cheats to unrelated cheat engines,
and for all users that is a negative purpose.
But it could serve a GREAT purpose if implemented like I suggested, so as to allow everyone to get rid of unwanted encryption, which we have no other very practical means to do. The current implementation can only do it by repeated extraction, with and without decryption, and with the user manually identifying and separating properly raw sections from the unwanted ones in each of those output files.I totally agree that the -d switch isn't that useful when your code database has mixed content, i.e. encrypted and decrypted codes. The feature only makes sense when you extract the codes from a freshly installed CB, which contains encrypted codes only.
Yes, for a single-game case that obviously makes sense.Actually, the -d option was inherited from the "cbc" command. CBC files only store a single game and you can easily tell if the codes are raw or not.
But for many users today CBC files are not an available option anyway, since CodeBreaker is unable to use USB drives on all modern consoles. We need to maintain our cheats using only the "cheats" file on MC.
That obviously depends on exactly how the codes are stored in the "cheats" file, which I have not studied in any detail. But since the cheat engine has no trouble keeping them apart, the same should also be possible for other tools.While cb2util can decrypt all CB codes, it is not easy to detect which codes to decrypt and which codes are already in raw format.
----- snip ----- re: example cheat list in text format
Not really. If there was a real problem here, then the cheat engine itself would also be hindered by it, which is not the case.See the problem?
You definitely could do something of the kind, since the cheat engine can do it.I guess I could detect the encryption scheme with some heuristics...
I think it's really quite simple, and can be done by applying a brief test sequence to the master code (only) of each game section.
1: Identify v7 encryption:
-- Check for the encrypted beefcode sequence.
-- If found treat this game section as encrypted, and skip the other tests below
2: Identify v1 encryption:
-- Check code lines of this master code where the first word holds an address in the 28 low bits, to see if that address has bit #25 set (true for all v1 encrypted codes I think, but impossible for real RAM)
-- If found treat this game section as v1 encrypted, and skip the raw case below
3: Raw case:
-- If we even get here, just treat the current game section as raw.
That's all it should take...
Yes, but isn't convenience the main purpose of most utilities ?But to be fair I have to add that it's not really the job of cb2util to handle such cases. The -d option merely exists for convenience.
I disagree. I have no reason whatever to use an encryption tool, since I am against the use of encrypted cheats of any kind.You should use a good text editor and CB2crypt to maintain your code database,
Even so, for me it makes much better sense to use cb2util to transform the "cheats" into a text file, to which I simply append any new cheats or edit any old ones I wish to modify, after which I again use cb2util to transform that text file back into the proper "cheats" form and put it back on the MC. For me this is a much better way of handling things.and only fire up cb2util to import existing codes (in your case w/o -d) or compile new ones.
But I think you are missing my main point here, which is that for the vast majority of users, their existing code database is based on one that came built into the cheat engine originally (possibly purged of irrelevant games), to which they have then gradually added a lot of games over the years. That is exactly my own situation and one reason why I have such a jumble of differently coded cheats, though all the ones I added myself are in the raw form. (Because the original CB cheat database was in itself chaotic.)
At this point what I (and others) need is a way to transform this mixed-form database into a uniform one, with all cheats in the raw fom. And that was the purpose of my suggestion.
Trying to achieve that with the current version would require many hours of hard work. Using two separately extracted cheat text files, and separating the properly 'raw' cheat sections from each of them, and recombining them into a third file.
Multiply those hours of hard work by the number of users needing such cheat unification, and it adds up to quite a lot. In my opinion sufficient to motivate the modification, though I understand that you may disagree on that.
Whatever you decide to do, I'm still grateful for the program you've made, as it does allow me to do some of the maintenance that I need, even without the ability to conveniently get rid of all the unwanted encryption in my "cheats" database.
Best regards: dlanor