Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


My first trainer - Works, but also breaks other stuff :(

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking
View previous topic :: View next topic  
Author Message
strideram
Newbie cheater
Reputation: 0

Joined: 03 Dec 2013
Posts: 13

PostPosted: Sat Dec 07, 2013 2:29 pm    Post subject: My first trainer - Works, but also breaks other stuff :( Reply with quote

I wrote the following trainer for the Game XCOM Enemy Within. My intention was to hack the resource called Meld. The hack I enabled has unintended side effects. I would appreciate if you could read the process I followed and point out mistakes or alternative steps.

I am aware there is an existing wonderful cheat table (/viewtopic.php?p=5506311#5506311) for this game. It doesn't work for the latest version of the game, but it should be fixed shortly. I am doing this simply to better understand the process of hacking a game.

Code:
[ENABLE]
//code from here to '[DISABLE]' will be used to enable the cheat

alloc(newmem,2048)
label(returnhere)
label(originalcode)
label(exit)
label(aob_addr)
registersymbol(aob_addr) 
aobscan(aob1,29 03 8B 1B 8B 4C 24 14)

newmem: //this is allocated memory, you have read,write,execute access
//place your code here
add [ebx],eax
//nop
mov ebx,[ebx]
mov ecx,[esp+14]

originalcode:
//sub [ebx],eax
//mov ebx,[ebx]
//mov ecx,[esp+14]

exit:
jmp returnhere

//"XComEW.exe"+386C41:
// 29 03 8b 1b 8b 4c 24 14
aob1:
aob_addr:
jmp newmem
nop
nop
nop
returnhere:

 
 
[DISABLE]
//code from here till the end of the code will be used to disable the cheat
dealloc(newmem)
//"XComEW.exe"+386C41:
aob_addr:
sub [ebx],eax
mov ebx,[ebx]
mov ecx,[esp+14]
unregistersymbol(aob_addr)



When activated, consuming the resource will not deplete its numbers, instead it will increment it. However, it seems the lines I have replaced, they get called when a LOT of stuff needs to be decremented. Thus by enabling the cheat, I have broken a lot of sliders, where decreasing the slider only increases the value!

Steps followed:


0. Completed the CE tutorial Steps 1-8. Read (very well written articles) and understood the basics of Auto Assembler scripts and AOB scanning.

1. Did multiple scans for the value of Meld till I found one address. Restarting the game would change the address.

2. Found what writes to that address.

Code:

# Meld is currently stored at 37339A90.
# Changing the value at that address changes the value in the game.

# Result of the write access search

01516C37 - FF 15 94E99D02  - call dword ptr [XComEW.exe+184E994]
01516C3D - 8B 44 24 10  - mov eax,[esp+10]
01516C41 - 29 03  - sub [ebx],eax <<
01516C43 - 8B 1B  - mov ebx,[ebx]
01516C45 - 8B 4C 24 14  - mov ecx,[esp+14]

EAX=0000000A
EBX=37339A90
ECX=0000000A
EDX=007CCAF0
ESI=007CCBB4
EDI=3756D980
ESP=007CCAE0
EBP=00000000
EIP=01516C43


3. At this stage, most tutorials ask to remember the base address and the offset and do a search for addresses that have the value as the base address. This search did not return any values. I assume this means this is not a pointer?

4. Replace the `sub` command with the `add` command. Tested it out. And yes, the meld was no longer being decremented. Hoorah!

5. Something felt wrong about this hack, this wasn't how the various articles described the process.

6. Did a search for what addresses this opcode accesses. Found a LOT of addresses. Soon realized I had broken most of the sliders in the game Sad


So, did I miss a step somewhere? Is there a tutorial that explains how to find the correct opcodes to hack?
Back to top
View user's profile Send private message
justa_dude
Grandmaster Cheater
Reputation: 23

Joined: 29 Jun 2010
Posts: 891

PostPosted: Sat Dec 07, 2013 2:41 pm    Post subject: Reply with quote

Ask CE to show you what /accesses/ the address and see if you can find some bit of code that only accesses the bit you're interested in. If not, start tracing the code and look for flags that indicate which slider is being manipulated (eg, ecx=a or whatever).
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Sat Dec 07, 2013 3:45 pm    Post subject: Reply with quote

In addition to what justa_dude said, you can also dissect data structures to find an 'ID' to compare for filtering. You will also need to learn this for completing step 9 of the CE tutorial.
Back to top
View user's profile Send private message
strideram
Newbie cheater
Reputation: 0

Joined: 03 Dec 2013
Posts: 13

PostPosted: Sat Dec 07, 2013 5:24 pm    Post subject: Reply with quote

@justa_dude, I didnt fully understand what was it you asked me to do. I did the following. Please don't mind the detailed explanations. It might seem trivially small steps, but I want to be sure I am following the right steps.
---------------

This time around the Meld value is stored at the address 34df3690.

I searched for what "accesses" the address. I found 3 entries. The 2nd and 3rd entries pop up when consuming the meld. The first gets called a lot when moving around in the games interface, opening different menus. This is the entry as reported by CE.

Code:
012C2FEF - CC - int 3
012C2FF0 - 8B 44 24 08  - mov eax,[esp+08]
012C2FF4 - 8B 08  - mov ecx,[eax] <<
012C2FF6 - 8B 54 24 04  - mov edx,[esp+04]
012C2FFA - 89 0A  - mov [edx],ecx

EAX=34DF3690
EBX=3713F474
ECX=000002CB
EDX=012C2FF0
ESI=022FB8B0
EDI=124DE0E0
ESP=006273C4
EBP=3713F280
EIP=012C2FF6


The following is the entire function,

Code:
XComEW.PIBGetInterface+200F10 - mov eax,[esp+08]
XComEW.PIBGetInterface+200F14 - mov ecx,[eax]
XComEW.PIBGetInterface+200F16 - mov edx,[esp+04]
XComEW.PIBGetInterface+200F1A - mov [edx],ecx
XComEW.PIBGetInterface+200F1C - ret 0014


This looks like code to copy a value from one address to another. I placed a breakpoint at the `ret` statement. I also had the "what accesses this address" debugger window open. It showed the access count for the line of code I was interested in. I switched to the game, opened a different menu, it hit the breakpoint. Switched back to Memory view. Noticed the count hadn't incremented. Kept hitting `F9` till the count incremented. Noted down the values of the various registers and the return address.

Code:
#Registers
eax 34df3690 - red
ebx 3713f474 - r
ecx 000002c1 - r
edx 0062b0c8 - r
esi 022fb8b0 - black
edi 124de0e0 - r
ebp 3713f280 - b
esp 0062b054 - r
eip 012c2ffc - b

#Return address - 015c172c
#Parameters - 0062b0c8, 34df3690


Quote:
SIDEBAR - As noted above, some of the registers were in red colour and some in black. Is there a significance?


At this point I stepped through to the caller, address 015c172. I checked the value for the address 0062b0c8 (ie, the address in the edx register) and found

Code:
0062B0C7 - 00 C1                 - add cl,al
0062B0C9 - 02 00                 - add al,[eax]


Huh?? I thought this was copying the Meld value to another location. I didn't proceed beyond that. Help!!!!

------------

Seems I can't "double-post" (why is that bad? anyway...)

@++METHOS,

++METHOS wrote:
In addition to what justa_dude said, you can also dissect data structures to find an 'ID' to compare for filtering. You will also need to learn this for completing step 9 of the CE tutorial.


That totally went over my head. I haven't completed Step 9. It was far too complicated for me.

I had initially thought if I read through the existing cheat table for this game, I should be able to figure stuff out. But damn that thing is huge. After knowing the basics I can understand what most of the instructions mean. But how did he find those pointers? Man, kudos to the author and all the contributors for finding all that!
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Sat Dec 07, 2013 6:17 pm    Post subject: Reply with quote

strideram wrote:
I searched for what "accesses" the address. I found 3 entries.
-Right-click on an open space in the debugger window (while it is running), and click on 'check if found opcodes also access other addresses (max 8 )'.

Return to the game and use your meld.

Return to the debugger window. If any of the opcodes are only accessing ( 1 ) address, then you are good to use that one. If not, we can look at dissecting data structures.

FYI: Another way to check if an instruction is accessing other addresses, is by right-click on it in the memory viewer and clicking on 'find out what addresses this instruction accesses'. By doing this, you can check instructions, individually, (and) you are able to see all of the addresses and their values without being limited to only ( 8 ) addresses etc.
Back to top
View user's profile Send private message
strideram
Newbie cheater
Reputation: 0

Joined: 03 Dec 2013
Posts: 13

PostPosted: Sat Dec 07, 2013 7:06 pm    Post subject: Reply with quote

++METHOS wrote:
click on 'check if found opcodes also access other addresses (max 8 )'


Wasn't aware of that. Will remember for next time.

++METHOS wrote:
in the memory viewer and clicking on 'find out what addresses this instruction accesses'.


I used this method to find out whether my "first trainer" had side effects. Unfortunately it did, and here I am posting this thread Smile

EDIT: I forgot to add - all three opcodes also access lots of other addresses.

++METHOS wrote:
If not, we can look at dissecting data structures.



Okie. I had read this article on dissecting data (ww w. szemelyesintegracio . hu/cheats/41-game-hacking-articles/230-dissect-data-structures). While it made sense in that article, how do I do it for this game? While I am in the strategy part of the game, there is only one player me. And when I am in the tactical part of the game, meld cannot be consumed.

Also, not sure if its relevant, but in the thread of the XCOM EW cheat table, the author mentioned that adding Meld to the table was very difficult as it wasnt a part of any data structure.

Irrespective of that, I would love your assistance with dissecting whatever needs dissecting Smile
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Sat Dec 07, 2013 9:13 pm    Post subject: Reply with quote

You have different options, some are better than others, depending on the game and what you're after. For example, dissecting data structures may not be the best route. Using justa_dude's back tracing method might be better if you are comfortable with it.

Sometimes, using the pointer scanner may be the best route. I definitely would not rule it out as a viable alternative.

For dissection, make sure your current meld address is in your cheat table, then right-click to see which instructions write to or access the address. Once the debugger window populates with opcodes, stop the debugger. Highlight one of the instructions and click 'Show disassembler'. Take note of the offset; for example:

mov [esi+08],edi

the offset is +08.

Now, right-click the instruction inside of memory viewer to see all of the addresses that the instruction is accessing. When results start to populate, you may notice that your meld address is one of them. What you want to do is add several addresses to your cheat table, so that you have your meld address and 4 to 5+ other addresses. Stop the debugger again.

In your cheat table, right-click on your meld address again, only this time, click on 'browse memory region'. Now, click on 'tools' from the drop-down menu of the memory viewer and select 'dissect data structures'. The meld address should already be filled in. Click Ctrl+G to add a new group. Click inside the text field of the new group so that your cursor is there. Now, click Ctrl+A to add more addresses to group 2 (add as many as you need, based on how many addresses you added to your table).

From here, you simply fill in the addresses, with meld address being in group 1 and all of the other addresses in group 2. When you are finished, you need to tack on the offset so that you can see the base of the structure. For example, if the offset was +08, you need to tack on -08.

If your meld address was 102A334F, and the instruction was mov [esi+08],edi, then you will write 102A334F-08 in the text field of group 1. You will do the same for all of the other addresses, and add -08 at the end of them.

If there is no offset, then don't worry about any of this.

Once you are finished, click on 'Structure', 'Define new structure', okay/yes/okay.

From here, you can analyze the code to see if there is a static value that can be used, that differs from all of the others so that you can filter the meld address out from the rest of the addresses. You may have to dig deep and use an address inside of a pointer tree. I typically take a screen shot of the entire structure (I use snagit because it has a scroll feature, but there may be others) so that I can compare it against a new structure once I have restarted the game (you can also use the 'lock' feature for comparison). The addresses that you add the second time do not have to be the same, as long as you include the new meld address in group 1.

If this approach doesn't work, you can try justa_dude's approach, although it is a little more advanced. The easiest method of all, however, would be to use the pointer scanner, in such a case.

Quote:
Also, not sure if its relevant, but in the thread of the XCOM EW cheat table, the author mentioned that adding Meld to the table was very difficult as it wasnt a part of any data structure.
-Can you provide the link?
Back to top
View user's profile Send private message
strideram
Newbie cheater
Reputation: 0

Joined: 03 Dec 2013
Posts: 13

PostPosted: Sat Dec 07, 2013 10:34 pm    Post subject: Reply with quote

The debugger shows the following two opcodes,

1. mov ecx,[eax] <- The function in which the code belongs only reads the value of Meld

2. sub [ebx],eax <- This is the line that decrements the Meld on consumption

Neither have an offset. Both opcodes access a lot of address, the Meld address being one of them.

I will need clarifications for the rest of your instructions.

Quote:
What you want to do is add several addresses to your cheat table, so that you have your meld address and 4 to 5+ other addresses.


Are these 4-5 address chosen at random? Are these addresses that any one opcode (say the 2nd one) accesses?

Quote:
From here, you can analyze the code to see if there is a static value that can be used, that differs from all of the others so that you can filter the meld address out from the rest of the addresses. You may have to dig deep and use an address inside of a pointer tree.


How do I recognize a "static" value? "Differs from others" meaning? I suppose once I understand how to choose the addresses, I might understand how to check for differences. "use an address inside a pointer tree" means what?


Link to the XCOM EW Cheat Table - forum.cheatengine.org /viewtopic.php?p=5506311#5506311

In that post, he has a section "Update #2". In that he mentions,

Quote:
Update #2:
Added resource script.
Money, engineer and scientists were easy once I traced the money back to its parent array. Meld took some time as it does not seem to be part of any specific structure - I had to do a lot of pointer scans to eliminate false positives. Meld is sitting with a bunch of other variables that are mostly 0 or 100. For Meld, I picked the shortest possible pointer route with the same base address as money and scientists. If, for some reason it causes a crash (or other weird stuff), please let me know what you did when it happened.
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Sat Dec 07, 2013 11:34 pm    Post subject: This post has 1 review(s) Reply with quote

strideram wrote:

Are these 4-5 address chosen at random? Are these addresses that any one opcode (say the 2nd one) accesses?
-Yes, as long as you're not adding your meld address twice or something...you obviously do not want to unknowingly compare your meld structure with your meld structure, or you will never find a unique ID for your conditional jump! Very Happy

Quote:
How do I recognize a "static" value? "Differs from others" meaning? I suppose once I understand how to choose the addresses, I might understand how to check for differences. "use an address inside a pointer tree" means what?
-A static value doesn't change. So, even if you close the game out, and start up the game again, find your meld address again, and dissect data structures again, the value at whatever particular offset you are observing in your meld structure won't change. While you play the game, you can actually create two groups...one with meld structure that is locked, and another with meld structure that is not locked...that way, you can see which values change and which one's do not (or use screenshots for comparing). The reason you need to find a value that doesn't change, is because when you perform your compare in your script, to filter out the bad addresses, you need to compare to something that never changes so that your script will always work.

Differs from others - meaning, when you have two or more structures that you are dissecting, you can see that at some offsets, the values will be the same. If the value at offset +08 for your meld structure is 00000001 and the value at offset +08 for another structure is also 00000001, then, obviously, you can not use that offset for your compare, because both addresses have the same value...and you can not properly filter out all of the non-meld addresses if they have the same value. That being the case, you need to find an offset in your meld structure that has a value that is different from all of the other structures at that offset. It can take a long time, and you still may never find one.

Pointer tree - you will see, when you dissect data structures, that some offsets may be interpreted as pointer addresses (sometimes they are wrong, but you can check them by changing the element type). When you find one, you will notice that you can expand/collapse it. All of these 'sub-offsets' can also be used for finding a proper ID for comparing/filtering in your script.


Quote:
Link to the XCOM EW Cheat Table - forum.cheatengine.org /viewtopic.php?p=5506311#5506311

In that post, he has a section "Update #2". In that he mentions,

Quote:
Update #2:
Added resource script.
Money, engineer and scientists were easy once I traced the money back to its parent array. Meld took some time as it does not seem to be part of any specific structure - I had to do a lot of pointer scans to eliminate false positives. Meld is sitting with a bunch of other variables that are mostly 0 or 100. For Meld, I picked the shortest possible pointer route with the same base address as money and scientists. If, for some reason it causes a crash (or other weird stuff), please let me know what you did when it happened.
-From my understanding, he used the money structure (and possibly the money instruction) to manipulate the meld address.

For example, if you find the money address, and check which instructions access it, you may find an instruction that ONLY accesses the money address. If the meld address is always the same offset/distance away from the money address, then the money instruction can be used to manipulate both, the money (and) the meld address.

You can check this by find the money address, then finding meld address. Subtract the meld address from the money address (or vice versa, depending) to get the offset (distance/difference). Close the game and do it again. If the value for the offset is the same, you can use the money structure/instruction (may even be part of the same structure) to inject your code.

At least, this is my understanding based on what he explains. Perhaps he was not able to find a viable instruction, but was able to utilize the money structure to find a viable offset for his conditional jump/compare, then just use one of the money instructions to alter both offsets (money and meld).
Back to top
View user's profile Send private message
strideram
Newbie cheater
Reputation: 0

Joined: 03 Dec 2013
Posts: 13

PostPosted: Sun Dec 08, 2013 1:12 pm    Post subject: Reply with quote

Damn!! I almost had this!!

TLDR - I managed to get a filter in place that only operated on the meld address. However the game would crash when trying to start a research. I couldnt figure out if some other address was also passing the filter as the game would crash before showing another address in the "What addresses does this instruction access window".

Long story -

Dissecting multiple randomly selected addresses was absolutely no help. Instead I went with locking the meld address and comparing it with values after reloading the save. I was able to find a pattern.


Code:
0000 - 4 Bytes           36678E90 : 965                3C07F690 : 1000               
0004 - 4 Bytes           36678E94 : 0                  3C07F694 : 0                 
0008 - 4 Bytes           36678E98 : 0                  3C07F698 : 0                 
000C - 4 Bytes           36678E9C : 1                  3C07F69C : 1                 
0010 - 4 Bytes           36678EA0 : 51                 3C07F6A0 : 51                 
0014 - 4 Bytes           36678EA4 : 2                  3C07F6A4 : 2                 
0018 - 4 Bytes           36678EA8 : 1                  3C07F6A8 : 1                 
001C - 4 Bytes           36678EAC : 0                  3C07F6AC : 0                 
0020 - 4 Bytes           36678EB0 : 0                  3C07F6B0 : 0                 
0024 - 4 Bytes           36678EB4 : 0                  3C07F6B4 : 0                 


The meld value is at offset 0. I found the "1 51 2 1" values to always be present whenever I play the game irrespective of how much meld I gain/consume. With that in mind, I modified my script to the following

Code:
alloc(newmem,2048)
label(returnhere)
label(cleanup)
label(originalcode)
label(exit)
label(aob_addr)
registersymbol(aob_addr) 
registersymbol(pMeld)
alloc(pMeld,8)
aobscan(aob1,29 03 8B 1B 8B 4C 24 14)

newmem:
push eax
mov eax, [ebx+0c]
cmp eax, 1
jne cleanup
mov eax, [ebx+10]
cmp eax, 33
jne cleanup
mov eax, [ebx+14]
cmp eax, 2
jne cleanup
mov eax, [ebx+18]
cmp eax, 1
jne cleanup
mov [pMeld],ebx
pop eax
add [ebx],eax
mov ebx,[ebx]
mov ecx,[esp+14]
jmp exit

cleanup:
pop eax

originalcode:
sub [ebx],eax
mov ebx,[ebx]
mov ecx,[esp+14]

exit:
jmp returnhere

//"XComEW.exe"+386C41:
// 29 03 8b 1b 8b 4c 24 14
aob1:
aob_addr:
jmp newmem
nop
nop
nop
returnhere:

 
 
[DISABLE]
//"XComEW.exe"+386C41:
// 29 03 8b 1b 8b 4c 24 14
aob_addr:
sub [ebx],eax
mov ebx,[ebx]
mov ecx,[esp+14]

dealloc(newmem)
unregistersymbol(pMeld)
unregistersymbol(aob_addr)



The code between `push eax` and `pop eax` checks whether the expected pattern is present. I am hoping there is a more elegant way to it. Please point it out if possible. The `pMeld` is present so I can manually add it as a pointer address and quickly find the address at which the meld is stored.

Any ideas on how do I find the cause of the crash?
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Sun Dec 08, 2013 2:07 pm    Post subject: Reply with quote

strideram wrote:
Dissecting multiple randomly selected addresses was absolutely no help.
-I'd start with this. Why was it no help?

The reason I say that comparing random addresses against the meld address is okay (and actually better), is because the probability of checking the meld structure against other, differing structures becomes more likely. The reason that is good, is, there may be a structure that you are not seeing, that shares the same values as the meld address for the offsets that you are using to compare. If that happens, you could be altering both, the meld address (and) other non-meld addresses without even knowing - which could lead to a crash.

FYI: no need to push/pop eax:
Code:
push eax
mov eax, [ebx+0c]
cmp eax, 1
jne cleanup
mov eax, [ebx+10]
cmp eax, 33
jne cleanup
mov eax, [ebx+14]
cmp eax, 2
jne cleanup
mov eax, [ebx+18]
cmp eax, 1
jne cleanup
mov [pMeld],ebx
pop eax


This can be written like:
Code:
cmp [ebx+0c],1
jne cleanup
cmp [ebx+10],33
jne cleanup
cmp [ebx+14],2
jne cleanup
cmp [ebx+18],1
jne cleanup
mov [pMeld],ebx


Both should work, nonetheless. Nothing stands out to me at first glance as looking problematic with your script. I would investigate the offset a little more.

Tip: Some games have a cap on certain values (score, item quantity etc.), and when that cap is exceeded, the game may crash. Keep this in mind when you write a script that continually 'adds' to a given value.
Back to top
View user's profile Send private message
strideram
Newbie cheater
Reputation: 0

Joined: 03 Dec 2013
Posts: 13

PostPosted: Mon Dec 09, 2013 5:51 am    Post subject: Reply with quote

Quote:
SIDEBAR - I had read that we can't do opcodes like `mov [eax], [ebx]`. I read that to mean we can't use two values in the same statement. Hence I moving one value `[ebx+0c]` to a register before comparing it with another value, `1`. I understand now that `cmp [eax], 1` is valid while `cmp [eax], [ebx]` is not. Thanks for clearing up that misunderstanding!


------------

Wrt to the dissection, let me explain. I did a search for all addresses the `subtraction` opcode accesses. While the search was running I messed around with the interface of the game. Clicked lots of buttons. I got a lot of addresses, one of them being the meld address. I added meld to group 1. 5 other addresses I selected at random to group 2. I couldn't find anything in common in the structures of all six addresses. I believed I was supposed to find patterns in the Meld structure that don't occur in other structures. I saved the values of all 6 structures (meld + 5 random).

I then locked the Meld structure, restarted the save, found the new Meld address, added it to the dissect tool. I didn't try and find valid replacements for the 5 other structures because I immediately noticed the pattern between the locked Meld and the current Meld. I checked the saved values for the other structures and noticed the pattern was not present. This is how I finalized the pattern.

Now while collecting the accessed addresses, it never struck me to "research an item", one of the many actions I can perform in the game. So I don't know if that action resulted in the subtraction opcode accessing any new addresses.

I made my script and it worked in areas where the original script had failed. I got only one accessed address. Then I went on to research an item and GAME CRASHED. I can't access the game, for now, to further test this. Maybe at night.

My point is, how am I supposed to collect and analyze enough addresses to ensure that pattern filters it down to one. What more should I have done during the dissecting process?

Now consider that the game XCOM EW has two parts. The strategy part which is played out in the XCOM base and the tactical part which is played out on the field. All these meld hacking related stuff I am doing during the strategy part. How can I be sure that the subtraction opcode is not called during any action in tactical part? Should I play through an entire level with the debugger attached collecting addresses? For how long should the address collection run?
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Mon Dec 09, 2013 2:04 pm    Post subject: Reply with quote

strideram wrote:
My point is, how am I supposed to collect and analyze enough addresses to ensure that pattern filters it down to one. What more should I have done during the dissecting process?
-There's really no definitive answer here. Each game will vary. Some games/codes are easy, some are not. It all boils down to a lot of work/time/trial and error etc. That being said, if you are insistent on using data structures to find your fix, I would recommend adding as many addresses to your structure as possible (all of them, if you can). Use a program like Snagit to take a massive screenshot so that you can compare your data with your next dissection. Checking your meld structure against all other structures is the only sure-fire way of finding a reliable offset without extensive testing. To be honest, though, addresses may populate later on that you weren't aware of, so there is really no way around the testing phase. There are other things that can be done, such as checking inside pointer trees, and adjusting your offset to see beyond the base of your structure (doesn't always work). For example, since your offset is 0, you could, instead, try -100 and checking to see if anything can be used that occurs before your structure (be sure to double check these values after you close and restart the game). For that matter, you could increase the default structure size when you are creating your structure and looking for code there.

Other than that, you can do as the author for the game table has done, use the pointer scanner or set a breakpoint and compare register values etc. You do have options.

Quote:
Now consider that the game XCOM EW has two parts. The strategy part which is played out in the XCOM base and the tactical part which is played out on the field. All these meld hacking related stuff I am doing during the strategy part. How can I be sure that the subtraction opcode is not called during any action in tactical part? Should I play through an entire level with the debugger attached collecting addresses? For how long should the address collection run?
-Set a breakpoint on the opcode and play through the tactical part. Do anything you can to try to trigger it.

TIP1: You can use Cheat Engine's speed hack to speed up the game, if needed.

TIP2: You could try changing the update interval in settings to get a better feel for which offsets are changing in real time.
Back to top
View user's profile Send private message
strideram
Newbie cheater
Reputation: 0

Joined: 03 Dec 2013
Posts: 13

PostPosted: Sun Dec 15, 2013 6:25 am    Post subject: Reply with quote

I don't get much time during the weekdays to play the game and try hacking it. Resumed my attempts today.

The crash caused by starting a research was unrelated to my hack. I reloaded a save, enabled the hack, researched - all worked good. I had found a pattern that resulted in only the meld address passing through.

The bad news was the "static" values (the pattern) I found, they changed once I completed a tactical mission. The changed values remain constant irrespective of what actions I take in the strategy part of the game. But if I start a tactical mission and complete it, on returning to the strategy part of the game, the values are changed again. I tried dissecting starting from [meld-100] addresses. Couldn't really find a pattern that survives completing a mission.

I will try with the "pointer scanner and register values" thingy. Though I might have to read up on how to get the pointer scanner to work. The last time I tried, I couldn't reduce the number of results found to below 50,000.

Towards the start of this thread, justa_dude mentioned,

Quote:
.. start tracing the code and look for flags that indicate which slider is being manipulated (eg, ecx=a or whatever).


Any tips/pointers on what "tracing the code" means and how do I go about doing that?
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Sun Dec 15, 2013 12:46 pm    Post subject: Reply with quote

strideram wrote:
The last time I tried, I couldn't reduce the number of results found to below 50,000.
-Nothing wrong with that, as long as the pointer continues to work.

strideram wrote:
Towards the start of this thread, justa_dude mentioned,

Quote:
.. start tracing the code and look for flags that indicate which slider is being manipulated (eg, ecx=a or whatever).
-I will let justa_dude elaborate on that. Regarding register values, I would think that Csimbi would have checked those to look for any filtering possibilities - but it's possible that he didn't. To check register values against meld, simply put a breakpoint on the instruction that is manipulating your meld value. If your instruction reads:

sub [ebx],eax

Then the meld address is at ebx, so when you breakpoint and run to cycle through the addresses, you will see your meld address being stored in the ebx register (that's how you can differentiate your meld address from the others). Simply cycle through the different values to see if your meld address carries any unique register values (besides base address). I would be surprised if it does, at this point. However, you never know.

Similar steps can be used to test workable offsets...

Simply write a script that will filter out everything except your target address/value, based on the offset values that you have chosen to compare with, and have everything else jmp originalcode. Then, after you enable the script, follow it from your instruction to the code cave, and this time, set a breakpoint on your newly assembled code that only handles your targeted address (since everything else is being filtered around it). By doing this, the game should break only when your targeted address gets accessed...if it doesn't, then you know that your offsets are bad. Anyway, it's a good way to test.

You can also try the structure spider to compare it with the health base address, since Csimbi seems to have found a relation between the two.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites