DoubleX

I never thought even I could make some music, but I don't know if mine would be too unpleasant to hear, so it takes me some courage to share them here DoubleX - Everyone Turning Against You

Purpose Lets you directly edit various built-in global formulae Video Games using this plugin None so far Parameters Script Calls Plugin Command Prerequisites Terms Of Use Contributors Changelog Download Link Demo Link

Note This plugin works for both RMMV and RMMZ Purpose Lets you extract texts in events/common events/battle events to txt file Video Games using this plugin None so far Parameters Prerequisites Terms Of Use Contributors Changelog Download Link Demo Link

This topic aims to share the basic knowledge on what the default RMMZ TPBS battle flow implementations do in general, but you're still assumed to have at least: 1. Some plugin development proficiency(having written several easy, simple and small battle-related plugins up to 1k LoC scale) 2. Basic knowledge on what the default RMMZ turn based battle flow implementations do in general 3. Basic knowledge on what the default RMMZ TPBS battle flow does in general on the user level(At least you need to know what's going on on the surface when playing it as a player) Simplified Flowchart Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience Battle Start Input Action Slots Thinking In Frames Frame Start Start Phase Turn Phase Action Phase Turn End Phase Battle End Phase Update TPB Input Summary That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ TPBS battle flow implementations, feel free to correct me if there's anything wrong For those wanting to have a solid understanding to the default RMMZ TPBS battle flow implementations, I might open a more advanced topic for that later

This topic aims to share the basic knowledge on what the default RMMZ turn based battle flow implementations do in general, but you're still assumed to have at least: 1. Little javascript coding proficiency(barely okay with writing rudimentary Javascript codes up to 300 LoC scale) 2. Basic knowledge on what the default RMMZ turn based battle flow does on the user level(At least you need to know what's going on on the surface when playing it as a player) Simplified Flowchart Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience Start Battle Input Actions Process Turns Execute Actions Summary That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ turn based battle flow implementations, feel free to correct me if there's anything wrong For those wanting to have a solid understanding to the default RMMZ turn based battle flow implementations, I might open a more advanced topic for that later

Updates * { codebase: "1.1.1", plugin: "v1.02a" }(2021 Feb 7 GMT 1300): * 1. Added skillItemCooldownGaugeColor1 and skillItemCooldownGaugeColor2 * to let you show the TPB battler cooldown bar inside battles with * configurable colors * 2. Added cancelBattlerCooldownHotkeys and * cancelSkillItemCooldownHotkeys to let you set some hotkeys to * cancel the battler/skill item cooldown of the corresponding actors * respectively * 3. Added the following parameters: * - canCancelBattlerCooldown * - canCancelSkillItemCooldown * - cancelBattlerCooldownFail * - cancelSkillItemCooldownFail * - cancelBattlerCooldownSuc * - cancelSkillItemCooldownSuc * - canCancelBattlerCooldownNotetagDataTypePriorities * - canCancelSkillItemCooldownNotetagDataTypePriorities * - cancelBattlerCooldownFailNotetagDataTypePriorities * - cancelSkillItemCooldownFailNotetagDataTypePriorities * - cancelBattlerCooldownSucNotetagDataTypePriorities * - cancelSkillItemCooldownSucNotetagDataTypePriorities * 4. Added the following plugin commands: * - canCancelBattlerCooldown * - canCancelSkillItemCooldown * - cancelBattlerCooldown * - cancelSkillItemCooldown * 5. Added the following notetags: * - canCancelBattler * - canCancelSkillItem * - cancelBattlerFail * - cancelSkillItemFail * - cancelBattlerSuc * - cancelSkillItemSuc Video

I just received an email like this: Title: Notification Case #(Some random numbers) Sender: (Non-Paypal logo)service@paypal.com.(My PayPal account location) <(Non-PayPal email used by the real scammers)> Recipients: (My email), (The email of an innocent straw man used by the real scammers) Contents(With UI styles copying those in real PayPal emails) : Someone has logged into your account We noticed a new login with your PayPal account associated with (The email of an innocent straw man used by the real scammers) from a device we don't recognize. Because of that we've temporarily limited your account until you renew and verify your identity. Please click the button below to login into your account for verify your account. (Login button copying that in real Paypal emails) If this was you, please disregard this email. (Footers copying those in real PayPal emails) I admit that I'm incredibly stupid, because I almost believed that it's a real PayPal email, and I only realized that it's a scam right after I've clicked the login button, because it links to a URL that's completely different from the login page of the real PayPal(so fortunately I didn't input anything there). While I've faced many old-schooled phishing emails and can figure them all out right from the start, I've never seen phishing emails like this, and what makes me feel even more dumb is that I already have 2FA applied to my PayPal account before receiving this scam email, meaning that my phone would've a PayPal verification SMS out of nowhere if there was really an unauthorized login to my account. Of course, that straw man email owner is completely innocent, and I believe that owner already received the same scam email with me being the straw man, so that owner might think that I really performed unauthorized login into his/her PayPal account, if he/she didn't realize that the whole email's just a scam. Before I realized that it's just a scam, I thought he/she really done what the email claims as well, so I just focused on logging into my PayPal accounts to assess the damages done and evaluate countermeasures to be taken, and if I didn't realize that it's just a scam, I'd already have given the password of my PayPal account to the scammers in their fake PayPal login page. I suspect that many more PayPal users might have already received/are going to receive such scam emails, and I think this way of phishing can work for many other online payment gateways as well, so I think I can do some good by sharing my case, to hope that only I'll be this dumb(even though I didn't give the scammers my Paypal password at the end).

The complete microsoft word file can be downloaded here(as a raw file) Summary The whole password setup/change process is as follows: 1. The client inputs the user ID and its password in plaintext 2. A salt for hashing the password in plaintexts will be randomly generated 3. The password will be combined with a fixed pepper in the client software source code and the aforementioned salt, to be hashed in the client terminal by SHA3-512 afterwards 4. The hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants 5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed pepper in the client software source code 6. The same attachment process will be repeated, except that this time it’s determined by a randomly generated salt in the client terminal 7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512 8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal 9. The encoded version will be encrypted by RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key 10. The server decrypts the encrypted polynomial equation from the client with its RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation, which will finally be stored there 11. The 2 aforementioned different salts will be encrypted by 2 different AES-256 keys in the client software source code, and their encrypted versions will be sent to the server to be stored there 12. The time complexity of the whole process, except the SHA3-512, RSA-4096 and AES-256, should be controlled to quadratic time The whole login process is as follows: 1. The client inputs the user ID and its password in plaintext 2. The client terminal will send the user ID to the server, which will send its corresponding salts for hashing the password in plaintexts and forming distinct roots respectively, already encrypted in AES-256 back to the client terminal, assuming that the user ID from the client does exist in the server(otherwise the login fails and nothing will be sent back from the server) 3. The password will be combined with a fixed pepper in the client software source code, and the aforementioned salt that is decrypted in the client terminal using the AES-256 key in the client software source code, to be hashed in the client terminal by SHA3-512 afterwards 4. The hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants 5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed pepper in the client software source code 6. The same attachment process will be repeated, except that this time it’s determined by the corresponding salt sent from the server that is decrypted in the client terminal using a different AES-256 key in the client software source code 7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512 8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal 9. The encoded version will be encrypted by RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key 10. The server decrypts the encrypted polynomial equation from the client with its RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation 11. Whether the login will succeed depends on if the literal expression of the polynomial equation from the client exactly matches the expected counterpart already stored in the server 12. The time complexity of the whole process, except the SHA3-512, RSA-4096 and AES-256, should be controlled to quadratic time For an attacker trying to get the raw password in plaintext: 1. If the attacker can only sniff the transmission from the client to the server to get the encoded then encrypted version(which is then encrypted by RSA-4096) of the polynomial equation, the salt of its roots, and the counterpart for the password in plaintext, the attacker first have to break RSA-4096, then the attacker has to figure out the highly secret and obfuscated algorithm to decode those numbers and number separators into the resultant polynomial equation and the way its roots are attached by existing numeric literals and named constants 2. If the attacker has the resultant polynomial equation of degree 512, its roots must be found, but there’s no direct formula to do so analytically due to Abel-Ruffini theorem, and factoring such a polynomial with 156 different named constants efficiently is very, very complicated and convoluted 3. If the attacker has direct access to the server, the expected polynomial equation can be retrieved, but the attacker still has to solve that polynomial equation of degree 512 to find all its roots with the right ordering among them and all their correct literal expressions 4. If the attacker has direct access to the client software source codes, the pepper for hashing the password in plaintext, the pepper used on the polynomial equation roots, and the highly secret and obfuscated algorithm for using them with the salt counterparts can be retrieved, but it’s still far from being able to find all the roots of the expected polynomial equation of degree 512 5. If the attacker has all those roots, the right ordering among them and all their correct literal expressions still have to be figured out, and the salts and peppers for those roots has to be properly removed as well 6. If the attacker has all those roots with the right ordering among them, all their correct literal expressions, and salts and peppers on them removed, the attacker has effectively recovered the hashed password, which is mixed with salts and peppers in plaintext 7. The attacker then has to figure out the password in plaintext even with the hashing function, salt, pepper, and the highly secret and obfuscated algorithm that combines them known 8. Unless there are really efficient algorithms for every step involved, the time complexity of the whole process can be as high as factorial time 9. As users are still inputting passwords in plaintexts, dictionary attacks still work to some extent, but if the users are careless with their password strengths, then no amount of cryptography will be safe enough 10. Using numerical methods to find all the roots won’t work in most cases, because such methods are unlikely to find those roots analytically, let alone with the right ordering among them and all their right literal expressions, which are needed to produce the resultant polynomial equation with literal expressions exactly matching the expected one 11. Using rainbow tables won’t work well either, because such table would be way too large to be used in practice, due to the number of polynomial equations with degree 512 being unlimited in theory 12. Strictly speaking, the whole password encryption scheme isn’t a one-way function, but the time complexity needed for encryption compared to that for decryption is so trivial that this scheme can act like such a function Areas demanding further researches: 1. The time complexity for factoring a polynomial of degree n with named constants into n factors analytically 2. Possibilities of collisions from the ordering among all roots and all their different literal expressions 3. Existence of efficient algorithms on finding the right ordering among all roots and all their right literal expressions 4. Strategies on setting up the fixed peppers and generating random salts to form roots with maximum encryption strength Essentially, the whole approach on using polynomial equations for encryptions is to exploit equations that are easily formed by their analytical solution sets but very hard to solve analytically, especially when exact literal matches, rather than just mathematical identity, are needed to match the expected equations. So it’s not strictly restricted to polynomial equations with a very high degree, but maybe very high order partial differential equations with many variables, complex coefficients and functions accepting complex numbers can also work, because there are no known analytical algorithm on solving such equations yet, but analytical solutions are demanded to reproduce the same partial differential equations with exact literal matches, as long as performing partial differentiations analytically can be efficient enough.

Updates * { codebase: "1.1.1", plugin: "v1.01a" }(2020 Dec 26 GMT 1300): * 1. Added the following notetag types: * subjectMiss * subjectEva * subjectCnt * subjectMrf * subjectCri * subjectNorm * subjectSubstitute * 2. Added the following parameters: * subjectMissNotetagDataTypePriorities * subjectEvaNotetagDataTypePriorities * subjectCntNotetagDataTypePriorities * subjectMrfNotetagDataTypePriorities * subjectCriNotetagDataTypePriorities * subjectNormNotetagDataTypePriorities * subjectSubstituteNotetagDataTypePriorities * 3. Fixed the eventEntry of all notetags not correctly accepting all * intended suffixes and rejecting the unintended ones Video The latest version of DoubleX RMMZ Enhanced Codebase is needed as well

Updates * { codebase: "1.1.1", plugin: "v1.01a" }(2020 Dec 25 GMT 1100): * 1. Added tpbChargeGaugeColor1 and tpbChargeGaugeColor2 to let you * configure the TPB charging bar colors inside battles * 2. Added tpbIdleGaugeColor1 and tpbIdleGaugeColor2 to let you show the * TPB idling bar inside battles with configurable colors * 3. Added tpbCastGaugeColor1 and tpbCastGaugeColor2 to let you show the * TPB casting bar inside battles with configurable colors * 4. Added tpbReadyGaugeColor1 and tpbCastGaugeColor2 to let you show * the TPB cast ready bar inside battles with configurable colors * 5. Added isTpbTimeActive to let you set the TPBS wait conditions more * precisely Video