Horizon Zero Dawn [Engine:Decima]

[ZippyDSMlee]

Oh nice I can start NG+ at level 10 or so, then set skill points to zero! THen I can take my time exploring, crafting and gainign skills!! YAY!!!

How to use this cheat table?

1. Install Cheat Engine
2. Double-click the .CT file in order to open it.
3. Click the PC icon in Cheat Engine in order to select the game process.
4. Keep the list.
5. Activate the trainer options by checking boxes or setting values from 0 to 1

[tscolin]

May i request an update please? Steam 1.11

[hawkins]

I would love a Update as well if possible.

[SunBeam]

I've specified several times: 1) I'm not updating this anymore for the open public; 2) how to update it. Would be nice if you actually combed the topic and figured it out yourselves rather than posting a quick "please update" post. Cheers!

[ZippyDSMlee]

I've specified several times: 1) I'm not updating this anymore for the open public; 2) how to update it. Would be nice if you actually combed the topic and figure it out yourselves rather than posting a quick "please update" post. Cheers!

Thank you for your hard work!

[shaggy_kyle]

I've specified several times: 1) I'm not updating this anymore for the open public; 2) how to update it. Would be nice if you actually combed the topic and figured it out yourselves rather than posting a quick "please update" post. Cheers!

don't know if you'll answer but is there an updated version on pateron?

[SunBeam]

There is, yes. I did explain how to update this table here though, but sure. You can subscribe anytime.

[tonka4ok]

Heya, I've been reversing and exploring this game for quite some time now, currently working on frozen wastes build.
I managed to reverse and make sense of a few things but I can't figure out some stuff, so I've been looking at SunBeam's table today and:

(Just a quick note from my end: I know you haven't been touching the game in a year maybe, and if you feel like I am asking too many questions and wasting your time, I am willing to become your Patreon if you can help me with this and further with my HZD reversing adventures)

1. How did you initially figure out the localPlayer address? (This drove me crazy)
I managed to track mine down from health and multiple pointerscans but now looking at your table - it seems I am at the wrong address even though the health values are real? You seem to be starting one level up and your "Destructibility" pointer is actually the "localPlayer"' that I was using, I guess I was in the wrong this whole time?
2. How the hell did you figure out that localPlayer +0x60 is invulnerability byte? That's really cool I really wanna know how did you find out, I implemented a lame script to make myself invulnerable when I could've done as you have!
3. How do you figure out that soldier->0x228 is AIFaction? Where did you come to the conclusion that this is a "faction"?
4. How did you find the debug functionality? That is really really cool as well, really impressive, I've been fiddling around trying to find what you did, no luck, not even close.
5. Did you need to use IDA in any part of your reversing? Did CE do the trick for you?


A funny moment: I spent 2 days looking at double coordinates and wondering why I can't modify them to move around... Looking at your table - they were floats all along at a whooole different place.

[SunBeam]

1. How did you initially figure out the localPlayer address? (This drove me crazy)
I managed to track mine down from health and multiple pointerscans but now looking at your table - it seems I am at the wrong address even though the health values are real? You seem to be starting one level up and your "Destructibility" pointer is actually the "localPlayer"' that I was using, I guess I was in the wrong this whole time?

I used string references which pointed to exported Engine functions:

2. How the hell did you figure out that localPlayer +0x60 is invulnerability byte? That's really cool I really wanna know how did you find out, I implemented a lame script to make myself invulnerable when I could've done as you have!

I usually find a structure of reference, then I browse the memory address in Hex Dump (Memory View > bottom part), select a big range of data with my mouse and activate an exception breakpoint for that page. Then do stuff in game, while lagging, like shooting, getting hit, etc. And a lot of crap shows up in the debug window. Then I test whatever I consider interesting (like BOOLs -- mov byte ptr [], cmp byte ptr []) and based on the effect, name them. Without debug symbols or the source code you won't know who they are and at what offsets in which structures. So this is just me analyzing effects.

3. How do you figure out that soldier->0x228 is AIFaction? Where did you come to the conclusion that this is a "faction"?

By RTTI name. See [ Debug ] > Get Name script. Give it structure address, get name. Also, there are a lot of string references pointing to game functions:



You just have to figure out how the functions work, which arguments to call them with, etc. Or how to relate their use to the structures you've already mapped. That's how.

With the picture above you can clearly see the names. So that function I've highlighted is Entity::GetFaction. The "exported" part refers to the fact that the function was declared as an export when the game/Engine was compiled, so it can be used externally. So with that you need first an Entity pointer (see the code first checks 'rcx'). If valid, then it reads another pointer from Entity+0x228. That's the Faction pointer/structure. Then I debugged the address I got by either running that function or checking the mapped tree in my table and figured out the faction offset (what to change and where so factions change):

4. How did you find the debug functionality? That is really really cool as well, really impressive, I've been fiddling around trying to find what you did, no luck, not even close.
5. Did you need to use IDA in any part of your reversing? Did CE do the trick for you?

By checking around the health and ammo processing. Whenever I see "cmp byte ptr []" I have to test what happens when that byte is 0 or 1 Then you go back to the base address in that cmp and try other offsets. With exception breakpoints, like I said earlier. No, no IDA used in the process. I mainly used x64dbg.

[tonka4ok]

...

Wow!

Thank you very much for all the heads up and the interesting approaches that you just introduced to me!
I really didn't expect such a detailed response, you are a lifesaver!
I am going to try x64dbg right away, haven't used it!
Just wondering one thing, you mentioned exception breakpoints, how are they actually useful in the current scenario? Aren't they triggered upon an exception occurrence? Or am I wrong?

[rambo99jose]

Thank you very much for all the heads up and the interesting approaches that you just introduced to me!
I really didn't expect such a detailed response, you are a lifesaver!
I am going to try x64dbg right away, haven't used it!
Just wondering one thing, you mentioned exception breakpoints, how are they actually useful in the current scenario? Aren't they triggered upon an exception occurrence? Or am I wrong?

They pause program execution at chosen instruction, letting you see the stack and register values

[tonka4ok]

Thank you very much for all the heads up and the interesting approaches that you just introduced to me!
I really didn't expect such a detailed response, you are a lifesaver!
I am going to try x64dbg right away, haven't used it!
Just wondering one thing, you mentioned exception breakpoints, how are they actually useful in the current scenario? Aren't they triggered upon an exception occurrence? Or am I wrong?

They pause program execution at chosen instruction, letting you see the stack and register values

Don't the hardware/software breakpoints do the same?

[rambo99jose]

ugh nvm, its not same thing
SunBeam is on another level lol

[SunBeam]

Just wondering one thing, you mentioned exception breakpoints, how are they actually useful in the current scenario? Aren't they triggered upon an exception occurrence? Or am I wrong?

When you debug some on-screen value (read/write, hardware or software breakpoint -- most people use VEH) you usually end-up with a series of instructions accessing (reading/writing from/to) your address. Then you see something like this: "cmp byte ptr [rcx+750],1". Instantly you will say "well, rcx is base, so let me see what's there". In modern games, this is a structure that has a certain layout.

The first element you will often find at "rcx" (meaning offset 0 of rcx structure; and by "rcx" I mean the ADDRESS shown in RCX register) is the member-functions or virtual functions table pointer. Simplified, there's an address at offset 0x00 that points to a table of addresses. These are addresses to functions that can be executed in the context of your "rcx" address. Why are these useful? Because if you inspect the executable code of these functions, you might find OTHER offsets of interest within our "rcx" structure.

Since most games are not shipped with debug symbols, you won't know what the layout of that structure is. Namely, what's the structure called and what are the elements called and at which offset within your structure. Sure, CE can help identify them by RTTI when possible, but it doesn't happen for a lot of games. Please be advised that we're not talking Unity Engine here, as for that Engine CE operates differently (using mono, which gives out a shit ton of information).

To find out which offsets are being used by the game on THOUGHT-OF events, you would want to use exception breakpoints. How does this work? Well, your address is part of allocated memory. If you check Memory View > View > Memory Regions you will see which region (or PAGE) your "rcx" address is a part of. Exception breakpoints would be set over a defined range in that "rcx" of yours, ergo in that page. When the game Engine code attempts to access (read/write) an address and the data in it in YOUR RANGE, it will trigger an exception. That exception will then report the "culprit" (which piece of executable code tried to use that location) in the debug window. And you get a big ass list of said instructions.

Case in point: I see my health is 100 on screen. Scan for it, find it, debug it. Get hit and I see this: "sub [rcx+250],1". Every time I get hit, 1 point is subtracted from [rcx+250]. "rcx" becomes our address. Say our RCX is 0x25F800420 (an address). What we do then is go to it in Memory View, bottom part (hex dump) and Ctrl+G > 25F800420. Then press Ctrl+Enter so you see the offsets on the left-hand side. After this, make a selection by dragging the mouse from +00000000 till an offset of your choice: +00000310. Then right-click OVER THE BYTES and pick Data Breakpoint > Exception Breakpoint.

It will look kinda like this (ignore the ?? in the picture, for you there will be valid data there):



What that will do is to set a watch-dog over the range you've selected and every time the game Engine executable code tries to access (read/write) a byte/word/dword/qword/etc. in that red range, the said executable code will show up in the debug window. Just like normal debugging. So why is this good? Cuz you will get to see which offset in your "rcx" structure is being used and what for.

DO NOT USE F5 BREAKPOINTS WHILE EXCEPTION BREAKPOINTS ARE ACTIVE. You won't be able to step through executable code. If you forgot you've switched to exception breakpoints, just Ctrl+B in Memory View, delete all breakpoints in that list (also right-click and "Show shadow breakpoints"), then right-click in hex dump and change Data Breakpoint to Hardware Breakpoint.

Long story short: your structure is part of a page. Imagine a sheet of paper with text on it. At the middle of the page there is a paragraph. That paragraph is your structure. You want to find out what accesses each of the letters in that ENTIRE paragraph. That's how exception breakpoints work.

Lastly, be advised that when you use exception breakpoints over ranges, there will be executable code that will CONSTANTLY read certain offsets. And that will make the game lag. If you don't freak out instantly "omg, my game froze" and have patience, you will see that the screen refreshes, even if after 20-30s and by 1 frame. Just have patience. Then, to find as much as possible (what's used), I recommend DOING A LOT OF ACTIONS in-game while the exception breakpoint is active. For example, if I debug my Weapon structure, I usually fire the weapon, hide/show weapon (if action is doable), reload, change weapons, throw weapon on ground, pick it back up, etc. All the actions you can think of. Then when you get back to CE you will have a big ass list of instructions in the debug window Past that it's your job to inspect them all (I usually copy-paste them to Notepad++ to inspect later on; what if the game crashes?).

Cheers,
Sun

[tonka4ok]

...

Thank you, now I understand what you mean.
My confusion with the exception breakpoints was from a "strange" developer standpoint - I imagined that the game had to throw an exception(unhandled?) in some way, and the breakpoints will hit... I wish I had asked about this sooner, this method looks very effective in some cases!
Also, thanks for the ctrl+enter

And not to forget - thank you once again for the extremely detailed response! I got a lot of value from this conversation, will go back to learning and hopefully I would contribute back some day when I reach your level!