Hacking PS4 Cheater Returns No Results While Debug Watcher Does When Searching Nioh

  • Thread starter Thread starter Giga Knight
  • Start date Start date
  • Views Views 3,613
  • Replies Replies 10

Giga Knight

Active Member
Newcomer
Joined
Jul 4, 2016
Messages
32
Reaction score
17
Trophies
1
XP
331
Country
United States
Greetings. First, I would like to apologize if the creation of this thread is in violation of forum rules--I originally used someone else's thread to ask a question, and only got answers and guidance (for which I am grateful) regarding related questions and problems. The topic is about something else that's also related, but not quite what I seek. I figured that asking a question in my own thread, with a relevant thread title, and waiting for someone to respond to it, would be more effective toward solving this problem. If this thread is indeed in violation of the rules, I fully accept any decisions/actions the mods accordingly make/take.

With that said, the problem.

For a while now, I've been trying to alter amrita and gold values in Nioh 1.21 on my 6.72 PS4. Searching the Internet for instructions, I've found that others have edited saves and even memory to these ends; and upon finding out, recently, that 6.72 has long been exploited, I decided to do the same--or attempt to. Upon finding PS4 Cheater (at the same time I found out about 6.72), I resolved to start with that. When I used it to search memory (of eboot.bin, in its entirety) for 4-byte values, however, it returned nothing. Today, I used another program to search for the same called Debug Watcher. I didn't expect much more than PS4 Cheater, so I was shocked to find that it found the values for both amrita and gold--not in hex, but as integer values. It showed an address for each (0x11E212F8 for amrita, 0x62021300 for gold), but didn't elaborate on what part of eboot.bin those addresses were found aside from the addresses themselves. Furthermore, with the program being unstable, it was incapable of more than one search--after that, the program would require a restart for anything else.

I took these values back to PS4 Cheater, and found that there were no memory ranges that seemed to fit those two addresses, so I decided to wing it and go with whatever they'd fall between (though this would be redundant, as I'd already searched the entirety of eboot.bin). Started with the first value to receive--as expected--no values. Same result for the second. These were the case, though Debug Watcher found the values with no problem.

So we're at the present moment, with me at a complete loss as to how to proceed, aside from asking for help. Am I doing something wrong? I would greatly appreciate any help: this is something others have done before, I am confident that I can do it too, if only I can receive some clarity regarding the path forward.
 
That is an address if I'm understanding you right. Type in each one in goto in HxD. You'll have to change the layout first if it's not in hex. Goto might list them when you search, but I can't remember. If it's hex to look up, search for it.
 
It is an address, but one in memory. Did you mean I should search the save file for it? The save file's address offsets don't go that far, only up to 001F2C40.
 
Last edited by Giga Knight,
it could be an actual location or a hex address, don't know which. usually if it's a hex address, it will have what to change it to. I'm afraid I can't really help much with this as I've never used ps4 cheater.
 
To be clear, the hex values I got above were what I got from Debug Watcher after a memory scan. The values for amrita and gold were integer values, and thus were decimal values. The hex values, I'm certain, were memory addresses.

Unless there's some sort of difference between the "actual location" and "hex address" you spoke of that I'm unaware of.
 
I see. Well, if we're talking offsets of the save file, then it's as I said. I'm not sure what the difference between that and "hex sequence" is, since both are in hex.

I sense, though, that we have reached an impasse. I still appreciate your input, however--"two heads are better than one".
 
it doesn't go to offset: 11E212F8? the 0x means the rest of the numbers are 0s in front of the first 1. that's normally how offsets are written. that's kinda of a high number, which leads me to thinking it might be referring to the eboot.
 
I've always understood 0x to merely be a prefix describing the following numbers as being in hexadecimal notation. That said, the address is indeed in the eboot.bin.
 

Site & Scene News

Popular threads in this forum