nisrom currently uses a mix of methods to find SID27 keys :
bruteforce search for two u16 halfkeys from a known keyset. Only checks for SID27 key; so far no false positives but slow, and not 100% reliable (when e.g. one halfkey such as 0x0023 is loaded with a mov #imm8, the search will fail)
two complementary strategies that analyze code looking for the encryption function, then backtrack to find which keys are loaded. The keys can be either already known or new.
The code analysis is generally superior but the results are a bit ambiguous.
The possible outcomes are thus, ranked approximately from high to low confidence :
strat 1 found a known s27 and/or s36 ( currently not checked)
strat 2 found a known s27 and/or s36 and/or s36k2; rarely more than one
strat 1 discovered a new s27/s36 - usually both
bruteforce search found a known sid27 key as two u16 literals
strat 2 discovered a new s27 and/or s36 (currently not handled; hard to distinguish between s27 and s36)
Need to look at this closer so that nisrom returns only one "buest guess" keyset, plus either a confidence value or a "source" field e.g. "STRAT2_S36K1_KNOWN", "STRAT1_BOTH_NEW", "BRUTE_S27" etc ?
nisrom currently uses a mix of methods to find SID27 keys :
bruteforce search for two u16 halfkeys from a known keyset. Only checks for SID27 key; so far no false positives but slow, and not 100% reliable (when e.g. one halfkey such as 0x0023 is loaded with a
mov #imm8, the search will fail)two complementary strategies that analyze code looking for the encryption function, then backtrack to find which keys are loaded. The keys can be either already known or new.
The code analysis is generally superior but the results are a bit ambiguous.
The possible outcomes are thus, ranked approximately from high to low confidence :
Need to look at this closer so that nisrom returns only one "buest guess" keyset, plus either a confidence value or a "source" field e.g. "STRAT2_S36K1_KNOWN", "STRAT1_BOTH_NEW", "BRUTE_S27" etc ?