TheRouletteBoi / RouLetteVshMenu

Playstation 3 VSH Menu, SPRX Loader, Mod Menu Loader, Payload injector, RPC Calls, CEX/DEX/HEN
MIT License
42 stars 10 forks source link

Versions 2.4 and 2.5 freeze on XMB #19

Closed aldostools closed 2 years ago

aldostools commented 2 years ago

It seems that the current scanning method is buggy. It takes too long and sometimes the value is not found. But the big issue is that it seems to be the cause of freeze on XMB. I tested versions 2.4 and 2.5, both freeze the console. So I had to revert the plugin to 2.2.

It would be great if it can be optional. Or cache the found value and show it unless a change is detected in lv0 on flash storage.

TheRouletteBoi commented 2 years ago

do you think the scanner is allocating too much memory which is causing the console to crash? The offset is cached but not the clock speed value.

aldostools commented 2 years ago

Unless you're allocating more than 64KB, the amount of memory allocated shouldn't be an issue. I think it could be related to accessing protected memory address in LV1.

Wben I mean cache the offsets, I mean between sessions. These values rarely change, unless the user reinstall the CFW or patch LV0.

If I enable socat (I'm using cobra 8.3 debug edition) I observed a large amount of peeks, and sometimes they repeated if the offset was not found. This cause an intensive CPU usage for minutes.

A possible alternative is find the value in flash storage (may decrypting lv0 to find lv1.self, then decrypt it to find the values in lv1.elf). That may be more work, but the value is more accurate & always found in a static offset.

Maybe looking for lv0 in flash storage and doing a hash checking you could create a table. But it would require to install multiple CFW to get all combinations.

TheRouletteBoi commented 2 years ago

After some test it looks like the debug version of cobra the GPU speeds take about 8 to 10 minutes for the offsets to be found.

As for going the lv0 route I don't like that idea since it is too much hassle, and plus using the pattern scanner works for all firmwares.

Edit: the reason for repeated offsets is because I do 3 offset scans. 1 CPU clock speed & 2 GPU clock speeds

PliskinDev commented 2 years ago

depends on the process size. also, don't scan the entire process if you don't need to, limit to a something. the pattern your using is good, it could be optimized a little bit.

aldostools commented 2 years ago

Edit: the reason for repeated offsets is because I do 3 offset scans. 1 CPU clock speed & 2 GPU clock speeds

Aren't the 3 offsets relative to each other? I mean if you find one, the other isn't close or a fixed position relative to the other?

Or maybe scan the 3 offsets at the same time. In other words, something like this pseudo code:


data_size = 256KB; data = allocate(data_size);
if(!data) {data_size = 128KB; data = allocate(data_size);}
if(!data) {data_size =  64KB; data = allocate(data_size);}

cpu_clock = gpu_clock1 = gpu_clock2 = count = 0;
for(address = start;  address < end; address += data_size - pattern_len)
{
  read_buffer(address, data, data_size);
  if(!cpu_clock) count += do_pattern_search1(address, end, data, data_size , &cpu_clock); // returns 1 if found, 0 if not
  if(!gpu_clock1) count += do_pattern_search2(address, end, data, data_size, &gpu_clock1);  // returns 1 if found, 0 if not
  if(!gpu_clock2) count += do_pattern_search3(address, end, data, data_size, &gpu_clock2);  // returns 1 if found, 0 if not
  if(count == 3) break;
}
TheRouletteBoi commented 2 years ago

Edit: the reason for repeated offsets is because I do 3 offset scans. 1 CPU clock speed & 2 GPU clock speeds

Aren't the 3 offsets relative to each other? I mean if you find one, the other isn't close or a fixed position relative to the other?

Or maybe scan the 3 offsets at the same time. In other words, something like this pseudo code:

data_size = 256KB; data = allocate(data_size);
if(!data) {data_size = 128KB; data = allocate(data_size);}
if(!data) {data_size =  64KB; data = allocate(data_size);}

cpu_clock = gpu_clock1 = gpu_clock2 = count = 0;
for(address = start;  address < end; address += data_size - pattern_len)
{
  read_buffer(address, data, data_size);
  if(!cpu_clock) count += do_pattern_search1(address, end, data, data_size , &cpu_clock); // returns 1 if found, 0 if not
  if(!gpu_clock1) count += do_pattern_search2(address, end, data, data_size, &gpu_clock1);  // returns 1 if found, 0 if not
  if(!gpu_clock2) count += do_pattern_search3(address, end, data, data_size, &gpu_clock2);  // returns 1 if found, 0 if not
  if(count == 3) break;
}

now that's a viable solution worth trying

TheRouletteBoi commented 2 years ago

is it possible that the debug version of cobra is causing you to freeze in XMB?

aldostools commented 2 years ago

It could be... the plugin wasn't freezing so often before I switched to cobra debug.

I will confirm it after work in a few hours.

TheRouletteBoi commented 2 years ago

Finding all patterns have reduced scan time from 14 seconds to 7 seconds

aldostools commented 2 years ago

Finding all patterns have reduced scan time from 14 seconds to 7 seconds

Very nice!!

BTW It looks like the freeze issues that I been experiencing with version 2.5 are due Cobra debug payload. I have restored version 2.5 in webMAN MOD. If Cobra debug is detected, the version 2.2 is loaded instead of 2.5.