Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versions 2.4 and 2.5 freeze on XMB #19

Closed
aldostools opened this issue May 9, 2022 · 10 comments
Closed

Versions 2.4 and 2.5 freeze on XMB #19

aldostools opened this issue May 9, 2022 · 10 comments

Comments

@aldostools
Copy link

aldostools commented May 9, 2022

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
Copy link
Owner

TheRouletteBoi commented May 9, 2022

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
Copy link
Author

aldostools commented May 9, 2022

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.

@aldostools aldostools reopened this May 9, 2022
@TheRouletteBoi
Copy link
Owner

TheRouletteBoi commented May 10, 2022

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
Copy link

PliskinDev commented May 10, 2022

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
Copy link
Author

aldostools commented May 10, 2022

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
Copy link
Owner

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
Copy link
Owner

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

@aldostools
Copy link
Author

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
Copy link
Owner

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

@aldostools
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants