FreeER Grandmaster Cheater Supreme Reputation: 53
Joined: 09 Aug 2013 Posts: 1091
|
Posted: Wed Jan 24, 2018 1:24 am Post subject: |
|
|
You could create the aa scripts at run time eg.
Code: | function theFunctionToEncode()
local al = getAdressList()
local mr = al.createMemoryRecord()
mr.Type = vtAutoAssembler
mr.Script = [[
your AA script code here
]]
-- hotkey examples, for existing VK codes see defines.lua and others see
-- https://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx
local function getHotkeyValueForCharacter(character) return character:upper():byte(1) end
mr.createHotkey({VK_F3}, mrhActivate) -- activate on F3
mr.createHotkey({getHotkeyValueForCharacter('l')}, mrhDeactivate) -- deactivate on l (L)
mr.createHotkey({getHotkeyValueForCharacter('3'), getHotkeyValueForCharacter('P')}, mrhToggleActivation) -- toggle on 3+p
end |
make sure you use enableDRM() though since all this does is prevent someone from dumping the table from the exe/cetrainer/ct file (assuming that's possible), even if you used autoAssemble you'd still have to pass it as plaintext and at that point anything that can read CE's memory can see the AA code. enableDRM() will prevent basic things from reading CE's memory but it certainly isn't foolproof. there are ways around it. To avoid that you'd have to do it in lua via allocateMemory, writeBytes etc. to setup the assembly code rather than having a string of AA code that could be scanned for (eg. scaning for a series of 10+ bytes that are in the ASCII range, so don't think it's impossible to scan for if you don't already know the string, beyond that there are some things that could be scanned for reliably like "[enable]"/"[disable]" and "aobscan")
the only thing I can think of is that perhaps if you used autoAssemble and had the AA code string encoded/encrypted then maybe you could decode it, pass it to autoAssemble, let the decoded string go out of scope, and then call the garbage collector a lot to try and get the decoded string freed from memory so that there's a relatively short window of opportunity for someone to access it.
But honestly I don't think even that'd actually be useful since someone could simply attach to the same process and see what changes when your script is toggled...they'd see exactly what code you're writing that way since no matter how you hide, obfuscate, and encode how you ask cheat engine to change the memory, it still has to change the memory in the process itself to actually have an effect lol
The only exception to this I can think of is if you could implement the hack by setting a hardware breakpoint on the code (via lua), and using pure lua code (readInteger, writeBytes, etc.) to do what you want when that breakpoint is hit. As such, they'd see no new code being added (no allocs), no code being modified (you aren't changing the original code to jump to new memory and hardware breakpoints don't change the instruction in memory). All they'd see is the actual values you write to memory eg. health changing to 1337, and if the hack is essentially just a nop to avoid anything being written (implemented in lua by changing EIP/RIP to skip the instructions) then they'd literally see nothing at all...
However lua breakpoints are slow. So you wouldn't be able to use that method effectively for anything that is ran multiple times a second.
Also you only have 4 hardware breakpoints. You could still do it with software breakpoints, but that would change the first byte of the original instruction so they'd be able to find where you're setting the breakpoint at least.
Of course, it also requires you to understand how to use pure lua code to implement your hack....
|
|