0000054: CE 5.4.2 - Additional NOPs after conditional jump

Notes
(0000095) Dark Byte (developer) 2008-07-13 20:34	at compile time it is unknown how long the script is, so fills in the nops in case it's bigger than 128 bytes

(0000103) Csimbi (reporter) 2008-07-15 12:21 edited on: 2008-07-15 12:22	Hi Dark Byte, I am not sure what you mean by that. Could you explain it please? Thank you. PS. I am guessing that you are saying that the length of the jump is not known (and therefore, it is not known how many bytes are needed for the jump instruction itself). If this is the case, would it be possible to add a two-level compilation (in first round we compile, the second we assemble and compact the code - or, something like that)? I guess your response might be that it's not worth the effort - but in reality, good large code caves are hard to come by...

(0000104) Dark Byte (developer) 2008-07-15 13:44 edited on: 2008-07-15 13:53	It's not that easy If it's found out that the 3th jump has changed in offset because it did need a larger block of code, then the jumps in front of it have to be recalculated again in case they point after it. And that recalculation can then again cause other offsets to change. This means that the WHOLE script will then need to get recompiled for each jump it encounters (imagine how slow it'll get then) Also, you have alloc, why use codecaves ?

(0000105) Csimbi (reporter) 2008-07-15 16:54 edited on: 2008-07-15 16:56	Well, I guessed that in the first round the compiler would not create the final code - it would just compile instruction blocks (things between jumps) and calculate their lengths, and in the second round, these blocks would be compiled again however this time the jumps would be filled in according to the block sizes. Sort of how a normal compiler assembles the EXE from subroutines. But, ok, no problem - you're the expert. Probably not even worth the effort. My original concern is clear I guess, so I am happy to consider this issue closed. As for the caves - the answer is simple: because I create trainers (and these cannot allocate memory, just patch the memory with the necessary code, and done). Well, at least this is how a newbie like me does it ;-) Thanks for your patience.

(0000106) Dark Byte (developer) 2008-07-15 19:31	the auto assembler is more a single line execution script It encounters an instruction, and assembles it at that point. If it can't determine what the instruction points to (e.g the target address hasn't been defined yet) it'll pick the worst case scenario e.g: labelx: mov eax,#10000 ret startofscript: cmp [ecx+200],1 je labelx ... will pick the short jump variant but I guess I can add in a override for script writes to specifically pick a short jump or long jump (e.g "je short address") as for writing trainers: If you program them yourself: Look into VirtualAllocEx If you use the ce trainer maker: CE 5.4's trainer maker does do alloc correctly

(0000107) Csimbi (reporter) 2008-07-17 14:07	Hi Dark Byte, thank you for all the replies. I use TMK 1.51 (Trainer Maker Kit from Corsica Productions). It is a simple patcher, but supports customizing the UI any way I like it (labels, button, a whole suite of controls), sound, hotkeys, everything - it is easy to use (like c++ builder) for dummies like me (who don't know anything about win32 and can't even code their own hotkeys). The thing I don't like about the CE trainer maker (though I did not try the newest versions) is exactly the opposite of what I wrote above about TMK - but I understand asking you to re-write CE's trainer maker would be too big of a request, so I have decided not to ask it...

(0000323) Dark Byte (developer) 2009-11-06 22:46	resolved'ish' in ce 5.5 replace the "jle done1" with "jle short done1" and ce won't be adding those nops

Issue History
Date Modified	Username	Field	Change
2008-07-13 16:52	Csimbi	New Issue
2008-07-13 20:34	Dark Byte	Note Added: 0000095
2008-07-13 20:34	Dark Byte	Status	new => confirmed
2008-07-13 20:34	Dark Byte	Relationship added	related to 0000011
2008-07-15 12:21	Csimbi	Note Added: 0000103
2008-07-15 12:22	Csimbi	Note Edited: 0000103
2008-07-15 13:44	Dark Byte	Note Added: 0000104
2008-07-15 13:53	Dark Byte	Note Edited: 0000104
2008-07-15 16:54	Csimbi	Note Added: 0000105
2008-07-15 16:56	Csimbi	Note Edited: 0000105
2008-07-15 19:31	Dark Byte	Note Added: 0000106
2008-07-17 14:07	Csimbi	Note Added: 0000107
2008-09-07 17:01	Csimbi	Issue Monitored: Csimbi
2009-11-06 22:46	Dark Byte	Note Added: 0000323
2009-11-06 22:46	Dark Byte	Status	confirmed => resolved
2009-11-06 22:46	Dark Byte	Resolution	open => fixed
2009-11-06 22:46	Dark Byte	Assigned To	=> Dark Byte

Relationships