Excellent detective work as always!
![Thumbup :thumbup:](./images/smilies/icon_thumbup.gif)
Excellent detective work as always!
I noticed 1 more strange thing as well: within MCode initializer function we call VirtualProtect and declare the size of memory required to cram our mcode into it, we give that memory area PAGE_EXECUTE_READWRITE abilities, thats not right by itself - the code has to be just PAGE_EXECUTE or PAGE_EXECUTE_READ (to store some strings and other constants right inside .text code). With the current setting we can do whatever we want including storing our data (dynamically changing variables) right inside it or even dynamically change the whole mcode placeholder's content, replace it with another mcode.
Code: Select all
int test(void) {
static int i = 0;
return ++i;
}
thats the issue. 1000 lines of code for COFF format. And we would have to add even more by including ELF support. Its a bit complicated for my case cuz I do know if I start mcoding some C algorithm I would end up optimizing it in assembly language. For size and performance. And as long as we have Execute+Write+Read memory page options for our mcode chunk, any badly designed c code with lots of relocations can actually be manually changed to be flat and relative (no fixups table) by placing everything in 1 segment and changing absolute addresses to be loaded with lea [relative offset]. And properly designed mcode would have no relocation troubles at all.
Code: Select all
int test(void){
static int i = 0;
return ++i;
}
Code: Select all
use64
lea rcx,[i]
mov rax, [rcx]
inc rax
mov [rcx], rax
ret
i dq 0
Code: Select all
f:=FileOpen("otest.bin", "r")
VarSetCapacity(b,f.length)
n:=f.RawRead(b, f.length)
p:=DllCall("GlobalAlloc", 'uint',0, 'ptr',n, "PTR")
Loop(n//8) ;write program data to memory in 8 byte chunks
i:=A_Index-1, NumPut(NumGet(b,i*8, "uint64"), p,i*8, "uint64")
DllCall("VirtualProtect", "ptr",p, "uint",n, "uint",0x40, "uintp",op)
msgbox(DllCall(p))
msgbox(DllCall(p))
msgbox(DllCall(p))
Code: Select all
VarSetCapacity(b,f.length)
n:=f.RawRead(b, f.length)
DllCall("VirtualProtect", "ptr",&b, "uint",n, "uint",0x40, "uintp",op)
msgbox(DllCall(&b))
good link.
I was about to proceed with json.Get optimizations using fixed (hardcoded) mcode chunks. and u say "marginal". whats the point of DLL storing mcode chunks that have no use for other applications except the function they were written for?
Ive done that many times back to 1990ss..2000ss. No compiler can create machine code that cannot be further optimized manually. A few years ago I had an idea of optimizing AHK's SearchImage with SSE4 or AVX1 instructions but give it up due to lack of time
I meant that for json.Get it will be a fixed-function logic mcoded. Unusable for other tasks. there is no point to put it in DLL for further use and make us use a satellite file with the script. Script portability suffers. Thats the reason why small scripts base64 resources like icons to store all them in 1 file. Makes sense
Empty DLL is about 3k redundant data. I managed to create 1k empty DLL but its rather a hack with zeroed sections that overlap each other.
with such logic we have overbloated stuff all over the place. We start using mcoding to optimize at first place
BTW, I would make a simple analyzing AHK function that shows number of relocated placeholders and imported DLL calls for compiled c/cpp/whatever code designed to be used as mcode. Just to let ppl check how good/bad their design of mcode.
I like that idea!vvhitevvizard wrote: ↑18 Dec 2018, 15:15BTW, I would make a simple analyzing AHK function that shows number of relocated placeholders and imported DLL calls for compiled c/cpp/whatever code designed to be used as mcode. Just to let ppl check how good/bad their design of mcode.![]()
otest.bin (compiled asm. not the file from the compiled c code)!
Users browsing this forum: No registered users and 57 guests