2017-09-23 00:53 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000134Cheat Enginepublic2009-08-04 17:20
ReporterCsimbi 
Assigned ToDark Byte 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
Summary0000134: CE 5.5 captures too short byte code on auto-assemble
DescriptionHere is the code:
00519F44 - 74 07 - je 00519f4d
00519F46 - 66 8b 10 - mov dx,[eax] <- this is what I have highlighted
00519F49 - 66 89 50 02 - mov [eax+02],edx
00519F4D - d9 46 40 - fld dword ptr [esi+40]

I click Tools -> Auto-assemble.
I click Templates -> Cheat Table framework code
I click Templates -> Code injection
I click Ok on the address.
This is the template the CE gives me:

--- clip --- clip --- clip --- clip --- clip ---
[ENABLE]
//code from here to '[DISABLE]' will be used to enable the cheat
alloc(newmem,2048) //2kb should be enough
label(returnhere)
label(originalcode)
label(exit)

00519F46:
jmp newmem
nop
nop
returnhere:

newmem: //this is allocated memory, you have read,write,execute access
//place your code here


originalcode:
mov dx,[eax]
mov [eax+02],edx

exit:
jmp returnhere

 
 
[DISABLE]
//code from here till the end of the code will be used to disable the cheat
dealloc(newmem)
00519F46:
mov dx,[eax]
mov [eax+02],edx
//Alt: db 66 8B 10 66 89
--- clip --- clip --- clip --- clip --- clip ---

Now, take a look at the jump:
00519F46:
jmp newmem
nop
nop

and the original code:
00519F46:
mov dx,[eax]
mov [eax+02],edx
//Alt: db 66 8B 10 66 89

The byte code following //Alt: db ... is missing the last two bytes that have been NOPed out. Maybe the additional NOPs are not counted (only the length of the jump itself) when the byte code is copied, so it is shorter?
Additional InformationI noticed this because CE assembles one byte shorter code and I need the byte code.
Let me know if you need more info.
Thank you for fixing.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000268

Dark Byte (developer)

Last edited: 2009-08-04 17:14

yes, it's a bug
also, there's a second bug here.
The disassembler should have shown it as
mov [eax+02],dx
instead of
mov [eax+02],edx

(and using mov [eax+02],dx instead of bytecode would solve your problem as well)

~0000269

Dark Byte (developer)

2nd bug (wrong disassembler) was already fixed in the svn

~0000270

Dark Byte (developer)

Fixed in svn
+Notes

-Issue History
Date Modified Username Field Change
2009-08-02 02:56 Csimbi New Issue
2009-08-04 17:14 Dark Byte Note Added: 0000268
2009-08-04 17:14 Dark Byte Status new => confirmed
2009-08-04 17:14 Dark Byte Note Edited: 0000268
2009-08-04 17:17 Dark Byte Note Added: 0000269
2009-08-04 17:20 Dark Byte Note Added: 0000270
2009-08-04 17:20 Dark Byte Status confirmed => resolved
2009-08-04 17:20 Dark Byte Resolution open => fixed
2009-08-04 17:20 Dark Byte Assigned To => Dark Byte
+Issue History