Feature request: "User Custom Section" to resolve many different issues... #28
Comments
|
Thank you for providing the implementation of "User Custom Section." I have referred to your approach and added an automatic detection mechanism for hidden sections in version 0.9.9.7-beta. Instead of using custom section start and end, I have utilized the "LastHiddenSectionLengthHex" option. It will automatically add a new section after the last known section in the system, with a default length of 0x40000000. Furthermore, because hidden sections, as you mentioned, can be located not only at the end but at any address, the detection mechanism checks if each known section is continuous. When it detects a break in continuity, it automatically adds a new section. |
|
I love your idea of automatic detection of hidden sections and almost works, but It has issues with the no man land or with the ghost section (choose the name that you like it). Below the screenshot (ss from now on) of 0.9.9.7: I don’t know if there is a way to fix it, maybe there is, but in case that you cannot find a way, then following your idea a propose to create a new scan option in Neo. See the below SS:
Instead of enable the hidden section using the new setting “Section View Detect…” put a new scan option like “Scan for Hidden Sections”, and when the user click in “First Scan Button” maybe Warning to the user that it is going to take some time and do the same process that with the setting “Section View Detect…” but then check the hidden sections one by one reading from the Start to the end maybe in blocks of 0x1000 and check the status returned by the ps4debug so is not possible that the status can be ok, when you are reading data on the ghost section. 1º We found a block of real address than reading 0x1000 bytes is returning the status ok, but the previous block of 0x1000 size where status bad. Start: Real Section address found 2º You are processed a full hidden section from his start to the end but all the blocks are bad. Then, remove this ghost section because is not a real hidden section. I think that my proposal is not a bad idea and it can be great solution to fix this issue. The only think that we don’t know is how many time it could take to process the whole memory map checking if all the hidden sections found are real or not. Note: I proposed a initial size of 0x1000 bytes when reading blocks, but it can be maybe 0x10000 for better performance... Maybe if you like this idea and decide to implement, put a setting to tests different sizes to check and find out the better performance.. |
|
Thank you, JeymyAV, for conducting such detailed testing on hidden section detection. I'm curious, which game did you use for your testing? Regarding what HexEditor does when switching pages, it's quite straightforward. It reads the specified PS4 memory starting address and the length of each page (8M), then displays it. I'm not sure why ghost data consisting entirely of zeros would appear... byte[] dst = PS4Tool.ReadMemory(mainForm.ProcessPid, section.Start + (ulong)page * PageSize, (int)memSize); section.Start + (ulong)page * PageSize = FFF804001 (page44) |
|
The game that I used for the testing is Rebel Galaxy and his CUSA is CUSA02586. I have good and bad news… The good news is nothing is wrong on your code when it switch the pages. I repeat the test with the new version PS4CheaterNeo-0.9.9.8 and below the result: We know that the real Hidden Section address start at: 0x1000000000: As I have explain in my previous post the solution is to create a new SCAN for Hidden Sections option, and the logic will something like this by steps: 1º Internally create all hidden sections and select all them and for each of this candidate to hidden section do: 2º Read all data of each candidate section (maybe by pages like now) and if all data of a section/page is 0, then this section is a ghost section and you can remove it from the final list because we don’t need it. 3º If a candidate hidden section in one of his page has data, then we know that we have found a real hidden section but we don’t have it yet the real start address of this section, because the previous page has ghost data like you can see in the page 12 of my last test. 4º We have to take at the start address the first address on page 13, so you have to read the start address of page 13 - 0x100. A) You will get more data, so we are going well and from the new address we to repeat again the same, take the new address and minus 0x100 again and read the new page/block and repeat until we have got the result of option b) B) You have got a buffer result where all data is 0. That means that between the candidate start address and minus 0x100 we have the real start address. C) Finally, when reading address with -0x10 we have got again the step B) repeat again the steps A) and B) but this time subtracting -1, byte a byte. 5º Doing the logic of point 4 you have to find out exactly the begin of the hidden section that is 0x1000000000. 6º To find out the real end of the hidden section you can apply the same logic, but instead of using the first page of the section that contains data at the staring point, you have to use the last page that contains data, and increase the address by 0x100, an follow the same logic that 4º but increasing the address. I know that all this will take a lot of time, about 1 hour, but after that the user will have the real hidden section(s) with the real start and the real end of this sections. |
|
Thank you, JeymyAV, for providing further detailed information and explanations. I'm not sure if it's due to differences in the environment or game progress, but I tested Rebel Galaxy (CUSA02586) and did not encounter the issue of ghost sections or missing 0x4000 data. However, it's worth noting that I tested the game at the very beginning, right after entering the game... |
|
OMG, can you tell me the exact version of PS4DEBUG that you have used? |
|
My FW is 6.72, and I'm using ps4debug by Ctn v1.0.15. |
|
OK. I was tested using Ctn 1.1.15 but I repeat the test with your same version v.1.0.15 and the result is the same... Clearly some is different on the memory map. See my SS: So in my case something weird happen with the FW9... I will re-test it when I have the opportunity to get a Ps4 with FW5 from a friend to check if the issue happens or it works well in FW5. Anyway, probably the issue is happening because the FW version.. But just I see this parameter, are you using the same value?:
|
|
My settings are the same because this parameter value is the default. Apart from the FW, what is your game version? I have installed Update 1.03, and in the game, I see the version as 1.08b. |
|
I have installed the same update 1.03. it Is not the game, and sure 100% that the issue is with FW9.0 and PS4Debug version for it... |
|
I noticed, JeymyAV, that your initial custom version was working. The main decisive difference between your modified version and mine is whether the ending digit of the HiddenSection's starting address is 0. In version 0.9.9.9-beta, I changed the ending digit of the HiddenSection's starting address to 0. I'm not sure if this helps, so please test it and let me know. Thank you.
|
|
No, it is no going to work... Seems that you don't have understood me... Nothing you can do by code on PS4CheaterNeo to fix this issue that I have named "Ghost Data" that seems that ONLY happen on FW 9.0 (anyway, I like more with the new setting than before cause is more easy follow the address...) I did a new test to confirm what happen using Frame lib when I tried to access to a ghost address and frame works correctly... Surprise, frame has the correct behavior. SS: In Summary (what we know) using different tools:
As the issue is ONLY with FW 9.0, on my opinion, I wouldn't spend more time. You can let as you have it, but, then, if you decided to let as it now, please, for everyone, we need my initial solution, a new setting to use custom sections (enable on/off) to give the user the option to put manually the real start/end of the detected hidden section. We need this option (Manual Customs Sections) because a whole scan to detect which one is the real hidden sections (in RG we have 525 suspected hidden sections, and only one is the real hidden section, all the others are ghost sections) can take 1-2 hours. So we need a way to store the begin and the end of the hidden sections when we found this to reuse another time without spend 1-2hrs searching for it again. Another variant of this proposal solution, could be create a new popup menu option that when we select a hidden section from the list, allow to the user to change and update manually the start and the end of the hidden section (should be nice to automatically save or ask to the user to save it when the query editor is closed) to use in another moment in the future.. I hope is clear now. |
|
Thank you, JeymyAV, for testing and providing a detailed explanation once again. I believe I understand the issue you're describing. Let me confirm if my current understanding is correct: In FW9, when reading data from hidden sections with incorrect addresses, even if there is actual data inside, it becomes empty. For example:
|
|
That's totally correct, and only happen on FW9. |
|
If possible, I wonder if JeymyAV could perform another test. It involves modifying the testing of the Below is the ReadMemory function in PS4Tool, where the catch part specifies handling of SocketException errors and attempts to reconnect. public static byte[] ReadMemory(int processID, ulong address, int length)
{
int current = CurrentIdx1();
try
{
mutexs[current].WaitOne();
ConnectedCheck(current);
byte[] buf = ps4s[current].ReadMemory(processID, address, length);
return buf;
}
catch (SocketException ex)
{
if (tickerMajor.Elapsed.TotalSeconds >= 1.5)
{
reTrySocket = tickerMajor.Elapsed.TotalSeconds < 10 ? reTrySocket + 1 : 0;
tickerMajor = System.Diagnostics.Stopwatch.StartNew();
if ((ex.ErrorCode == 10054 || ex.ErrorCode == 10060) && reTrySocket > 5) throw;
Connect(Properties.Settings.Default.PS4IP.Value, out string msg, 1000, true);
}
}
finally { try { mutexs[current].ReleaseMutex(); } catch (Exception) { } }
return new byte[length];
}Originally, I thought SocketException would only occur in case of a connection issue, so the error wouldn't be thrown. The test involves completely commenting out the catch part and then executing the Hex Editor to access the 12th page at address FFF804000. Please check if this results in any error messages in the program. Thank you. public static byte[] ReadMemory(int processID, ulong address, int length)
{
int current = CurrentIdx1();
try
{
mutexs[current].WaitOne();
ConnectedCheck(current);
byte[] buf = ps4s[current].ReadMemory(processID, address, length);
return buf;
}
//catch (SocketException ex)
//{
// if (tickerMajor.Elapsed.TotalSeconds >= 1.5)
// {
// reTrySocket = tickerMajor.Elapsed.TotalSeconds < 10 ? reTrySocket + 1 : 0;
// tickerMajor = System.Diagnostics.Stopwatch.StartNew();
// if ((ex.ErrorCode == 10054 || ex.ErrorCode == 10060) && reTrySocket > 5) throw;
// Connect(Properties.Settings.Default.PS4IP.Value, out string msg, 1000, true);
// }
//}
finally { try { mutexs[current].ReleaseMutex(); } catch (Exception) { } }
return new byte[length];
}If any errors occur after testing, my guess is that the reason the entire 12th page turns into zeros is that ReadMemory simply returns a new byte[length]. |
|
Ok, I did the test and same result. But it was expected because as I said before, the issue IS NOT on your code... Nothing that you can change on your code that could fix it because if your code is working well on FW 6.72, then that means that nothing is wrong on your code about this issue (I'm 99,99% sure). Maybe, the only thing that you could do is to implement a complex algorithm of double buffer to workaround this issue (as I have explained on others post). But is too much effort (I wouldn't do it if I were you.) It more easy and quick to implement the workaround solution of manual customs sections Anyway, happy to help with it. |
|
Thank you for helping with the testing. I understand that the issue is not with ReadMemory, and after a series of tests, it's clear that there's no way to fix it in my code. I will consider the improvement method you mentioned and incorporate it into the program. |
|
The " Please note that this feature requires obtaining the PS4's GAME_ID, so the initial Query window may take longer to start as it waits for this information to be read.
|
|
Tested version 0.9.9.11-Beta and finally it works... See sc: I love your solution cause you improve my initial idea... In this way works for all ps4 fw and on fw 9.0, editing the conf file you can manually fix the wrong address section.. There is only one small cosmetic detail, using the same idea to change status of the hidden section from True to false, I would have changed the default name of the all sections that remains a true with the name of "executable" and reflesh in this way in the query editor. See the sc:
This is because the hidden sections always will be created by the executable process game (a standard ps4 process never will create a hidden section using some dirty trick). But as I said, this is only a cosmetic tip, for me the issue is fixed, so closing... |
Recently have been discovered that some games are using hidden sections or they are creating invisible sections like this example>
Bug fix: List hidden/unlisted section/s
#27
That means that all the PS4 tools that are based on the use of sections to work with the ps4 memory address like PS4CheaterNeo are not able to access the real data of the game because they are allocated and hide in this invisible section.
Actually there is not a good solution so is not an easy way to resolve this anti-cheat measure because the root of the issue is that the ps4debug payload cannot detected it, and probably it will never do.
But there is an easy workaround that you can enhanced the PS4CheaterNeo to overpass this anti-cheat measure and already I did it and tested before telling you to be sure that I am right.
I have amended the Ps4NeoCheater 0.9.8.6 adding 2 settings and a small strip code. See the screen-shoots below:
1º First, 2 parameters options to allow the user to put manually the start address of the custom section and the end address of the custom section:
Of course, by default the values will be 0x0 in both parameters, and that will indicate to ps4NeoC. No use custom section.
2º I have did 2 small changes on the code ps4NeoC:
First change is to pass the name of the process selected for ps4NeoC to many methods as needed because we only want this custom section by applied when the user select the standard game process “eboot.bin”
Second change is this code at the end of the method GetProcessMaps(int processID) at the file PS4Tools.cs (please, you can saw my range changes very easy with the words: “BEGIN” and “END”:
Adding this code you should be see the new custom section at the last of others and now this section can be selected like any other section and do the corresponding scan on it:
Using this simple workaround I was able to find all the values that I was searching and that before was impossible to find on the others sections because they weren't there.
Finally, enhanced a bit the idea of Custom Section you can resolve the two new request made by Pharaoh2k:
1º Feature request: independnt range scan:
2º Feature request: Independent Hex Editor
You only need to add a new setting on the query editor like:
Use Only the User Custom Section (by default no selected)
If the user click on this option, the tool for the eboot process only should be show up one section, the custom section introduced by the user instead the list of sections returned by the ps4debug process..
In this way, the 1º Feature request: independnt range scan: is resolve because the user should put any range scan that he wish to try…
The other 2º Feature request: Independent Hex Editor is resolved too because instead of have 1000 of sections like happens in some games, the user only will have one section, a he could edit very quickly the values of this section using the hex editor.
Even more, another quick enhancement to this is add a new setting like this:
“Default address on the Hex Editor” and by default should be empty .
So if the user put any Hex address in this parameter, when the user click in the menu option “HexView” it should be see in the inputbox the default address save in the settings:
I hope that you like my ideas and I wish you will implement as soon as you can in this amazing tool that you are developing...
The text was updated successfully, but these errors were encountered: