I understand what you are saying but I don't function that way, when I implement a Toolset feature, it has to cover 100% of cases otherwise I just postpone it. That is why you don't see any info on active ROS on NAND for instance even though it's feasible, I am still looking for a way to get that information for NOR somehow so that feature is on standby.It is not required to hash ALL possible options. It could be most recents OFW/CFW from 4.84-4.89. It should cover at least 80% of the scenarios. Or the hash could be collected from the current users. Not to tell that a ROS has Rebug, but to tell that it has OFW 4.xx or CFW 4.xx
If someone can provide a way to md5 hash 7Mb of memory (not a string like a js library would expect) in acceptable times, then I should be able to add all the hashes that littlebalup collected.
At some point I would need to reverse engineer the cellSslCertGetMd5Fingerprint vsh export, there might be a reusable sub there that could do the job..
I am looking at the code right now I don't see anything obviously wrong with it.The picture that I posted was using MAMBA. So it looks like there's a regression.
The code calls syscall 1022 with sub code 0x7FFF in theory that should return 0x666 (right?), in which case the payload is identified as Mamba.
There's an easy way to check in the Toolset logs, check the Debug messages checkbox, you will get a ton of extra logs so I recommend to look just after loading.
If you care to look in those logs, there are 4 lines giving you the result of each test for syscall 6, syscall 8 for CFW, syscall 8 for HEN and syscall 1022.
It will look like:
"peek sc_1022 ret: 0x???"
