PureBasic Forums - English

If you copy code into another process you have to be very carefull what you copy anyway.
If you copy code that calls other procedures in you program it will crash the target process. Most PB commands are compiled as calls into libs. So most of them will just crash the target process. If it uses global variables, it will crash the process. If it uses API's not importet by the target process it will crash it.

But you can avoit all this by just injecting a dll into the target process. Use the board search and search for "dll injection". This is the standart way to get additional code into another process. And it's the most stable way.

I also thought about the starting adress of the next procedure...
but is it guaranteed that the sequency of procedures in the exe is the same as in the code?

<offtopic>
bazaar = unmotivated expensive?
... you did not mean 'bizarre', I think ...?
</offtopic>

Kaeru Gaman wrote:I also thought about the starting adress of the next procedure...
but is it guaranteed that the sequency of procedures in the exe is the same as in the code?

<offtopic>
bazaar = unmotivated expensive?
... you did not mean 'bizarre', I think ...?
</offtopic>

@Kaeru: regarding sequence of procedures, I don't think it is pre-determined. For instance, it may depend on the order in which they are called.

Regarding definition of 'bazaar', I believe srod meant 'bazarre' which means unusual or exotic.

Kaeru Gaman wrote:I also thought about the starting adress of the next procedure...
but is it guaranteed that the sequency of procedures in the exe is the same as in the code?

<offtopic>
bazaar = unmotivated expensive?
... you did not mean 'bizarre', I think ...?
</offtopic>

For each procedure referenced, the generated ASM seemes to invoke the macros in alphabetical order so providing the 'dummy' procedure immediately follows the one of interest in alphabetic order you should be fine.

Demivec wrote:

srod wrote:I think that @zum1() - @test1() in the example above should give a result which is certainly no smaller than the required result. Quite why I am getting some bazaar results escapes me at the moment? Alignment perhaps?

@srod: regarding the possible reasons for your bazaar results, your examples include the debugger code woven around your desired code. Your example shows 85 bytes for me (with Win XP) with debugger but only 17 without debugger (using MessageRequester() ).

Doh!!! That was it! Thanks Demivec.

Demivec wrote:Regarding definition of 'bazaar', I believe srod meant 'bazarre' which means unusual or exotic.

that is written "bizarre", I mentioned this vocable...

I did indeed mean bizarre!

Something like this might be of use, though I struggled to convert it to Blitz or PB, and it's only relevant to x86:

http://www.devmaster.net/forums/showthread.php?t=2311

The idea is that you detect the byte-level x86 instructions by reading from the start of the function in memory until the byte signifying the end of the function.

I couldn't get it to work, but there are many nested C-style If {...} loops that I probably screwed up on!

Yes that is always another option; but in the case of PB code you will probably need to look for a RET command. This means interpreting all previous bytes to account for variable length x86 instructions etc. A bit too much work in my opinion.

Thorium wrote:If you copy code into another process you have to be very carefull what you copy anyway.
If you copy code that calls other procedures in you program it will crash the target process. Most PB commands are compiled as calls into libs. So most of them will just crash the target process. If it uses global variables, it will crash the process. If it uses API's not importet by the target process it will crash it.

But you can avoit all this by just injecting a dll into the target process. Use the board search and search for "dll injection". This is the standart way to get additional code into another process. And it's the most stable way.

Of course ,I've mentioned what you had said in my code comments,any PB command or string can't be used in the remote thread function,but my code should work because my thread function is "pure" enough,and it did work,sometimes it's handy to inject a thread in that way rather than use a dll.

It appears using a second procedure below the target procedure is NOT RELIABLE for detecting target procedure size. And the ?Label2-?Label1 example provided earlier in this thread doesn't compile because you can't directly reference labels in procedures from PB code outside the procedure ... but you can with !direct asm

Example:

Another way, sort of, if it's not possible or desirable to modify the target procedure by adding the two labels.

http://www.purebasic.fr/english/viewtop ... 77#p483177

also this should catch the code before and after the main procedure body (if that's something you want, to get the whole procedure size).

the problem with your method is that, apart from requiring a full disassembler, is that the disassembler itself that PB uses (Udis86) is old and poor from results its given me and ive seen it trip up on some very simple opcodes, so it's not really useful for anything that isn't in-house i don't think i think the Udis86 libs that come with PB havent been updated in a while so it might be better now (it was updated 2014 and supports SSE 4.2, AVX etc)

and yes you're right the problem with my method is it misses the small parts before and after the main body, I shouldve clarified that! You can see here for example: Becomes (/commented) ... Compiles to ... Although we can still get the very START by simply refering to @Procedure() instead of the first label (?Test_Begin) that just leaves the trailer part missing then

What would be a viable use case for this? Reading a procedure as memory and writing it to a remote process for execution? Without either carefully inspecting the compiled code before injection or writing the ASM yourself, I can't even begin to imagine the potential for corruption and illegal access this would cause.

The only safe way to do this would be DLL injection or to write the ASM yourself to ensure that the function doesn't try to access an address from the wrong memory space.

What would be a viable use case for this? Reading a procedure as memory and writing it to a remote process for execution? Without either carefully inspecting the compiled code before injection or writing the ASM yourself, I can't even begin to imagine the potential for corruption and illegal access this would cause.

Whoa, how presumptive! ... When in doubt presume the programmer is writing malware!?!?!?

I can't speak for the others in this thread but I'm simply doing a checksum of my routine to detect modification such as a cracker. (The checksum has to be done after the image is loaded due to address relocations - i just do it at app startup, but any modifications made thereafter such as a breakpoint are easily detected). No memory writing or injection or remote processes (or other nasty things going through your mind!) involved.

Keya wrote:Whoa, how presumptive! ... When in doubt presume the programmer is writing malware!?!?!?

I didn't say anything about malware and presumed nothing.

Performing a checksum on the size of a procedure wouldn't work as you can't inject additional ASM into a compiled image without offsetting hard-coded pointers. Generally these types of changes are either NOPs or replacing ASM with something else but without changing the effective size.

You would have to checksum the instructions themselves to detect something like this.

I rarely work with ASM but I don't believe randomized relocation affects the ASM as hard-coded pointers are generally relative offsets. The actual pointer being resolved may be different but the ASM itself wouldn't be.