+- PowerBASIC Users Meeting Point (http://pump.richheimer.de)
+-- Forum: User to User Discussions (http://pump.richheimer.de/forumdisplay.php?fid=3)
+--- Forum: Programming (http://pump.richheimer.de/forumdisplay.php?fid=7)
+--- Thread: Calling opcode string discussion (/showthread.php?tid=21)
RE: Calling opcode string discussion - Charles Pegge - 02-05-2025
It's a completely open compiler. Even the full source code for OxygenBasic is included. But the binary Apps it produces are normally completely independent of o2, so you already have reasonable security, like PB. But if you want to make it Mossad and CIA proof, the opcode strings with some cryptography will help protect the critical sections. But it would be much cheaper for the hackers to raid your offices or bribe your employees for the source code
You can also do a few other things like blanking out strings before they are released. So your program does not leave a trail of telltale litter on the heap.
The API calls I use for memory allocation are VirtualAlloc VirtualProtect & VirtualFree
RE: Calling opcode string discussion - Anne Wilson - 02-05-2025
Thanks so much Charles
Quote:The API calls I use for memory allocation are VirtualAlloc VirtualProtect & VirtualFree
How do you implement these API calls inside an exe to enable the exe to run inside the
system memory? Could you please provide an example program?
RE: Calling opcode string discussion - Charles Pegge - 02-05-2025
EXE and DLL loading and preparing the binary image, and executing the program is handled entirely by Bill. For JIT purposes, o2 does some of that work directly, without making a PE file. The full compilation, assembly and linkage take place in memory. No files are used other than the source code. Those 3 functions are used in the top level of the compiler which is inc\self\main.o2bas
The VirtualAlloc functions are not needed when making a PE file. This involves making headers, tables and the binary code for Bill to read.
RE: Calling opcode string discussion - Anne Wilson - 02-05-2025
Ok Charles, I have tried out using a PowerBasic program to poke
a function inside the system memory. I'm not to sure that it can be
done, but this program works by CALL DWORD the function
which is already poke inside the system memory.
Can you please check whether this is the correct approach?
Currently I'm running this program using Admin rights and I
wonder whether I can run it without Admin rights.
Code:
' Mem allocate system.bas
' This program allocates memory, writes some code into that
' memory, changes the memory protection to allow execution,
' and then executes the code.
' VirtualAlloc is used to allocate a block of memory.
' The %MEM_COMMIT and %MEM_RESERVE flags are used
' to commit and reserve the memory, and %PAGE_READWRITE
' is used to set the memory protection to read/write.
'
#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"
%MEM_COMMIT = &H1000
%MEM_RESERVE = &H2000
%PAGE_READWRITE = &H4
%PAGE_EXECUTE_READ = &H20
' place a test function inside the system memory
' and runs it
DECLARE FUNCTION TestRetM() AS DWORD
'==============================
FUNCTION PBMAIN () AS LONG
' Machine code for a simple test function that returns 42
LOCAL Cd1 AS STRING * 6
' MOV EAX, 42; RET
Cd1 = CHR$(&HB8) + CHR$(&H2A) + CHR$(&H00) + CHR$(&H00) + CHR$(&H00) + CHR$(&HC3)
' Allocate the system memory to run the code
LOCAL InsMemSys AS DWORD
InsMemSys = VirtualAlloc(0, LEN(Cd1), %MEM_COMMIT OR _
%MEM_RESERVE, %PAGE_READWRITE)
IF InsMemSys = 0 THEN
MSGBOX "Failed to allocate memory"
EXIT FUNCTION
END IF
' Copy the code into the allocated memory
POKE$ InsMemSys, Cd1
' Change memory protection to allow execution
LOCAL oldProtect AS DWORD
IF VirtualProtect(InsMemSys, LEN(Cd1), _
%PAGE_EXECUTE_READ, oldProtect) = 0 THEN
MSGBOX "Failed to change memory protection"
VirtualFree InsMemSys, 0, %MEM_RELEASE
EXIT FUNCTION
END IF
' Execute the code --------- inside the system memory -------------
LOCAL Dresult AS DWORD
CALL DWORD InsMemSys USING TestRetM() TO Dresult
' Display the Dresult
MSGBOX "The result of the Test function : " + STR$(Dresult)
' Free the allocated memory
VirtualFree InsMemSys, 0, %MEM_RELEASE
' Exit the program
ExitProcess 0
END FUNCTIONRE: Calling opcode string discussion - Charles Pegge - 02-05-2025
I'll have to stop now, Anne. I can look at it later. Should be ok. It will GPF if you go outside the allocated memory. It's location is also unpredictable to hackers so it is harder for them to find.
RE: Calling opcode string discussion - Charles Pegge - 02-06-2025
Looks fine to me, Anne. Here are the references for the record:
VirtualAlloc
https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc
VirtualFree
https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree
VirtualProtect
https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect