Results 1 to 12 of 12

Thread: 64-bit process remote hook technology and some changes in the 64 module export table

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Jan 2020
    Posts
    1,563

    64-bit process remote hook technology and some changes in the 64 module export table

    Talking about the 64-bit process remote hook technology and some changes in the 64 module export table


    I have used Yi Language for more than 10 years, and what I have left is only some nostalgia and plot. I still remember that the last time I posted on this forum was 10 years ago, and during that time I only visited the forum sporadically. Normal use is also purely a hobby, not from a professional class. If some insights are wrong, forget it.
    We know that the Yi language currently supports 32-bit compilation, and it is estimated that it will not be improved in the future. This seems to have become a failed product that has been abandoned. In this case, facing the popularity of 64-bit systems nowadays, Yi language enthusiasts are somewhat helpless and sad when faced with the operating level of 64-bit programs. Fortunately, there are some persistent fans who donít want to give up, and are still encouraging to solve these problems. For example, an open source module WOW64Ext in this forum provides some basic packages for the 64-bit module process of easy language operation. I also encapsulate it on this basis. Several functions have been added, as a further expansion, friends who may be able to continue to improve.
    One: Talking about the remote hook technology of 64-bit process
    On the topic of HOOK, there is nothing new on the Internet, so I will not talk about the boring topics of HOOK here. This article mainly explains some of the main differences between remote HOOK under 64-bit and 32-bit.
    First, let's take a look at the order in which a remote HOOK is to be implemented:
    1: Apply for memory space in the target process to store our truncated interspersed code and HOOK original code
    2: The instruction to modify the HOOK target position is to jump to the memory space requested by 1
    3: In the interspersed code, the registers we need or other communication means are communicated to the callback interface of our program. In this process, if you only need to get the value, you do not need to wait for the interspersed code. If you need to modify the code to take effect, you need to wait for the interspersed code. Call back the return of the interface, and write back the modified content.
    4: The interspersed code finally jumps back to the next jump instruction of the length of the HOOK position, or the specified position.
    5: Complete the entire HOOK process
    It seems to be very simple to understand the whole process. It is not difficult to achieve this process, but there are many situations to be considered in order to be relatively perfect.
    For example, the choice of jump use: The shorter the HOOK jump code is, the better. For example, a 32-bit JMP jump only needs 5 bytes, but the situation is completely different in a 64-bit process. The 32-bit process addressing capability is 4 bytes, while the 64-bit process addressing capability becomes 8 bytes. However, all jump direct addressing in 64-bit assembly only supports 4 bytes, which of course is not in 32-bit What's the problem, because the 32-bit maximum addressing will never exceed 4 bytes, there is no saying that it exceeds the limit:
    However, if you want to achieve a long transfer in 64-bit, you must borrow a register or an address offset, so the jump code of HOOK in 64-bit generally uses the following method FFFFFFFFFFFFFFFF as the jump target address without affecting the register:
    In order not to affect the register, a register must be pressed in advance
    --------------------------
    Push rax
    Mov rax, FFFFFFFFFFFFFFFFJMP rax or call rax
    To retrieve rax internally, pay attention to the difference between JMP and call, and finally flat the stack
    --------------------------
    Push rax
    Mov rax,FFFFFFFFFFFFFFFF
    Push rax
    Ret
    Retrieve rax internally, and finally flatten the stack

    Some friends see this and want to ask. I canít directly JMP FFFFFFFFFFFFFFFF or push FFFFFFFFFFFFFFFF. If you want to ask, I really donít know how to answer you, saying that you are speechless. You should just go ahead and play with the source code.

    I will not give examples of other similar Liezi. The summary is similar. The above Liezi occupies a total of 13 bytes in length. This is still the stack in the internal level. Otherwise, it will be +1 byte in length. If one of the registers is discarded It can be -1 byte in length, so generally the existing 64-bit hooks on the Internet are generally more than 12 bytes, but a useful hook takes up 13 bytes, which is undoubtedly unbearable for me. Is it true? Is there no other way? To protect the register and support long transfer, is there another way? In fact, there is a way, that is, through JMP [rip] The machine code form is FF 25 00 00 00 00. This code occupies 6 words Section, then what does this mean? FF 25 = jmp, 00 00 00 00 is the offset length to a byte transfer length that supports 2G, JMP [rip] can be interpreted as jmp qword ptr ds: [0x address in the debugger ], by the way, that is, read the 8-byte value in this offset position as the jump address and transfer it, if the offset is 00 00 00 00, then it represents the 8-byte data at the next instruction of JMP [rip] . When you think of this, you may ask. Does this mean JMP [rip] 6 bytes + 8 bytes length? Yes, if it is connected, it is true, but we can give him an offset, can't we separate it, We only need to search for consecutive 8-byte useless code locations such as 00 or CC in other locations of the same module, and write the jump address into it, then JMP [rip] can read the jump address by offset. We can also achieve a 6-byte HOOK. The highlight of this method is that the rewrite length is small, and it does not affect the register and rsp stack pointer, which can be regarded as the purpose of saving the country by curve.

    For example, for the problem of data transfer in interleaved code: we need to obtain each value of 16 general-purpose registers RAX-R15, how do we pass these values ​​in the past. Generally, remote HOOK data transfer uses message or remote thread, because these two methods have a smaller amount of assembly rewriting and are relatively easy to implement. We will not discuss remote thread here. Letís take a look at message transfer. Generally, the two functions are the choice of SendMessageA and SendMessageA and PostMessageA, the first one will wait for the message to return, the second one will not wait, because our interspersed code needs to write back the value of the register, so we must wait for the easy language callback interface to execute the code and return before assigning a value to each register, otherwise It cannot achieve the purpose of modification. It seems that SendMessageA is more suitable because it will wait, but it is not the case. If you donít give up, you will know if you try it. If the code in the first callback interface is being processed, there is a second callback coming in. , Then when the first callback returns and the second callback is still being processed, so if the first callback returns, then the sender of SendMessageA will return no matter how many waits, that is to say, if SendMessageA gives birth to Zhang San Li Siliang This son, Zhang San and Li Si are all out. When Zhang San goes home, SendMessageA will only think that both children are home. If my understanding is wrong, please correct me, at least my test results are as above. If this is the case, SendMessageA is not suitable for us, and using SendMessageA to use delay delay in callbacks will cause certain problems. So now we donít need to use SendMessageA, and instead use PostMessageA without waiting, and we donít have to construct a loop in the interspersed code by ourselves. What to loop, loop a return flag, when the callback interface is processed, it is in memory Write a return mark. When PostMessageA is sent to play, the code loops to check this return mark to determine the processing of the callback interface. When a return mark that can be continued is obtained, the code continues down.

    Then how to transfer the value of each register? At first, I thought that Yi Language should apply for memory in the target process to store each register, but after thinking about it carefully, this is a very stupid way. It seems that this is what I have passed through a large number of HOOK points. It is easy to confuse the register value. So what about applying for memory in interspersed code? So each pass has a separate register storage space? Thinking carefully about this is a last resort and a dumb one. If you are good at using a debugger, can you think of what is most convenient for you? By the way, that is the stack space. Each passing stack space also exists independently, which is convenient, easy to write and stable. There should be no over-limit situations, and we don't use much.
    At this time, the problem comes again. PostMessageA has four parameters in total.
    Window handle
    Message number
    Message value 1
    Message value 2

    In the 64 process, the 4 parameters of the PostMessageA function are also integer 4 bytes, including the value it sends out is also an integer 4 bytes. Then the 64 process stack pointer is an 8-byte long integer, that is to say we need to split the stack pointer 8 bytes into two 4 bytes, and pass this stack pointer through the message value 1 and message value 2. In our program Combine it to get the complete stack pointer. It looks like this might be fine, but I like perfection. I also want PostMessageA to pass the handle value of a HOOK process, so that we can directly use this handle for other operations in the easy language program, and the handle corresponds to the stack address. Perfect, all the values ​​that need to be passed will not go wrong. Itís a pity that there is no more position for this handle. After repeated experiments, I found parameter two. Message number. This parameter is a bit more special.


    We can see that the message number value obtained by normal binding is PostMessageA with a range of values. The value range of parameter 2 is between C000-FFFF. Then this gives me the hope of gas. Can I add 65535 through the process handle? If it is greater than 65535 after Yilangu gets it, 65535 will be subtracted from the data we sent, and then the actual process handle value will be obtained. The message number sent by the test message can be customized to the decimal 131071= Hexadecimal 1FFFF, it can't be received in large. That is to say, according to my idea, the handle value cannot be greater than 1FFFF-FFFF=10000=decimal 65535. Although the handle value is generally not large, 65535 still finds it not feasible. Fortunately, there is no way for people to go through the continuous opening process. After the handle test, it is found that the handle value in the system increases sequentially, and increases by 4 once you open it. That is to say, if your system has never opened the handle at all, then the first handle value should be 4, and the second should be 8. Increasing sequentially. I'm just a metaphor, the system itself still has a lot of occupancy, and the system also has a limit on the maximum number of handles. Let's calculate how many handles can be opened by 65535, 65535/4=16383 times, which is completely enough. The last second parameter=process handle\4+65535, when receiving (the second parameter -65535)*4= Process handle, this accomplishes what we want.

    The following is an assembly prototype with interspersed code. It is relatively simple. In 64 assembly, the unified stacking protection of registers is canceled and can only be pressed one by one. There is no comment in this prototype. If you understand it, you will understand it naturally. If you donít understand the explanation, I canít understand it. Itís probably the case. Write the registers that need to be protected to the stack in turn to protect them -> Lift the stack -> Call APIPostMessageA -> Flat the stack -> Loop to judge the return mark -> Write back to the register -> From the stack Get the jump back address and write it -> judge whether to execute the original code -> HOOK original code -> JMP[rip].
    Itís a bit long to divide the two pictures

    This is a comparison table of the offset of each value in the stack pointer
    0000000100401392 Here is the display result after installing the rewrite jump instruction at the HOOK location

    The general situation of the module


    Here again, it is emphasized that this module is some functions added on the basis of the WOW64Ext open source module. Please keep the copyright information. If it is used for other purposes, all disputes and consequences will be borne by you.
    Originally I wanted to write about the changes to the 64-bit module export table. In view of the length, I will give it up for the time being. I will talk about it later. The source code is also included. Let's see for yourself. At the same time, the module 64_ fetch function entry () and some other commonly used subroutines are constructed.
    I would like to thank my friend Xiaoye for his help. He also spent a lot of thought to complete this function. The two discussed repeatedly and after many modifications, we finally completed a finished source code that we are quite satisfied with:
    Remote hook64 instruction_install()
    Support minimum 6 bytes, maximum 127 bytes, hook uses JMP transfer, and long transfer (not 2G short transfer), and supports minimum 6 bytes
    Support hook arbitrary instructions, support access to 16 general-purpose registers + a rip register, read and modify
    The return value of the callback interface supports whether to execute the original instruction dropped by Hook (0=execute,>0 not execute)
    Support any stack operation, through rsp
    Support arbitrary rip transfer (support longer than 2G transfer), through rip
    Support one easy language program to control multiple 64-bit target processes at the same time
    Support multiple hook points to call back into one callback interface at the same time
    And all callbacks are independent of each other, regardless of the complexity of the hook position, the callback data will not be affected
    Each time the hook passes, it will wait until the callback returns. If the callback interface does not return, the hook at the time is in the pending state.

    Flexible and changeable free control, which can meet almost all requirements
    Last edited by Shaggy Hiker; Apr 26th, 2021 at 09:39 AM. Reason: Removed link that appears to be semi-topical spam.

  2. #2
    PowerPoster Arnoutdv's Avatar
    Join Date
    Oct 2013
    Posts
    4,676

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    What is your VB6 related question?

  3. #3
    Fanatic Member TTn's Avatar
    Join Date
    Jul 2004
    Posts
    658

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    Quote Originally Posted by xiaoyao View Post
    Talking about the 64-bit process remote hook technology and some changes in the 64 module export table


    I have used Yi Language for more than 10 years, and what I have left is only some nostalgia and plot. I still remember that the last time I posted on this forum was 10 years ago, and during that time I only visited the forum sporadically. Normal use is also purely a hobby, not from a professional class. If some insights are wrong, forget it.
    We know that the Yi language currently supports 32-bit compilation, and it is estimated that it will not be improved in the future. This seems to have become a failed product that has been abandoned. In this case, facing the popularity of 64-bit systems nowadays, Yi language enthusiasts are somewhat helpless and sad when faced with the operating level of 64-bit programs. Fortunately, there are some persistent fans who donít want to give up, and are still encouraging to solve these problems. For example, an open source module WOW64Ext in this forum provides some basic packages for the 64-bit module process of easy language operation. I also encapsulate it on this basis. Several functions have been added, as a further expansion, friends who may be able to continue to improve.
    One: Talking about the remote hook technology of 64-bit process
    On the topic of HOOK, there is nothing new on the Internet, so I will not talk about the boring topics of HOOK here. This article mainly explains some of the main differences between remote HOOK under 64-bit and 32-bit.
    First, let's take a look at the order in which a remote HOOK is to be implemented:
    1: Apply for memory space in the target process to store our truncated interspersed code and HOOK original code
    2: The instruction to modify the HOOK target position is to jump to the memory space requested by 1
    3: In the interspersed code, the registers we need or other communication means are communicated to the callback interface of our program. In this process, if you only need to get the value, you do not need to wait for the interspersed code. If you need to modify the code to take effect, you need to wait for the interspersed code. Call back the return of the interface, and write back the modified content.
    4: The interspersed code finally jumps back to the next jump instruction of the length of the HOOK position, or the specified position.
    5: Complete the entire HOOK process
    It seems to be very simple to understand the whole process. It is not difficult to achieve this process, but there are many situations to be considered in order to be relatively perfect.
    For example, the choice of jump use: The shorter the HOOK jump code is, the better. For example, a 32-bit JMP jump only needs 5 bytes, but the situation is completely different in a 64-bit process. The 32-bit process addressing capability is 4 bytes, while the 64-bit process addressing capability becomes 8 bytes. However, all jump direct addressing in 64-bit assembly only supports 4 bytes, which of course is not in 32-bit What's the problem, because the 32-bit maximum addressing will never exceed 4 bytes, there is no saying that it exceeds the limit:
    However, if you want to achieve a long transfer in 64-bit, you must borrow a register or an address offset, so the jump code of HOOK in 64-bit generally uses the following method FFFFFFFFFFFFFFFF as the jump target address without affecting the register:
    In order not to affect the register, a register must be pressed in advance
    --------------------------
    Push rax
    Mov rax, FFFFFFFFFFFFFFFFJMP rax or call rax
    To retrieve rax internally, pay attention to the difference between JMP and call, and finally flat the stack
    --------------------------
    Push rax
    Mov rax,FFFFFFFFFFFFFFFF
    Push rax
    Ret
    Retrieve rax internally, and finally flatten the stack

    Some friends see this and want to ask. I canít directly JMP FFFFFFFFFFFFFFFF or push FFFFFFFFFFFFFFFF. If you want to ask, I really donít know how to answer you, saying that you are speechless. You should just go ahead and play with the source code.

    I will not give examples of other similar Liezi. The summary is similar. The above Liezi occupies a total of 13 bytes in length. This is still the stack in the internal level. Otherwise, it will be +1 byte in length. If one of the registers is discarded It can be -1 byte in length, so generally the existing 64-bit hooks on the Internet are generally more than 12 bytes, but a useful hook takes up 13 bytes, which is undoubtedly unbearable for me. Is it true? Is there no other way? To protect the register and support long transfer, is there another way? In fact, there is a way, that is, through JMP [rip] The machine code form is FF 25 00 00 00 00. This code occupies 6 words Section, then what does this mean? FF 25 = jmp, 00 00 00 00 is the offset length to a byte transfer length that supports 2G, JMP [rip] can be interpreted as jmp qword ptr ds: [0x address in the debugger ], by the way, that is, read the 8-byte value in this offset position as the jump address and transfer it, if the offset is 00 00 00 00, then it represents the 8-byte data at the next instruction of JMP [rip] . When you think of this, you may ask. Does this mean JMP [rip] 6 bytes + 8 bytes length? Yes, if it is connected, it is true, but we can give him an offset, can't we separate it, We only need to search for consecutive 8-byte useless code locations such as 00 or CC in other locations of the same module, and write the jump address into it, then JMP [rip] can read the jump address by offset. We can also achieve a 6-byte HOOK. The highlight of this method is that the rewrite length is small, and it does not affect the register and rsp stack pointer, which can be regarded as the purpose of saving the country by curve.

    For example, for the problem of data transfer in interleaved code: we need to obtain each value of 16 general-purpose registers RAX-R15, how do we pass these values ​​in the past. Generally, remote HOOK data transfer uses message or remote thread, because these two methods have a smaller amount of assembly rewriting and are relatively easy to implement. We will not discuss remote thread here. Letís take a look at message transfer. Generally, the two functions are the choice of SendMessageA and SendMessageA and PostMessageA, the first one will wait for the message to return, the second one will not wait, because our interspersed code needs to write back the value of the register, so we must wait for the easy language callback interface to execute the code and return before assigning a value to each register, otherwise It cannot achieve the purpose of modification. It seems that SendMessageA is more suitable because it will wait, but it is not the case. If you donít give up, you will know if you try it. If the code in the first callback interface is being processed, there is a second callback coming in. , Then when the first callback returns and the second callback is still being processed, so if the first callback returns, then the sender of SendMessageA will return no matter how many waits, that is to say, if SendMessageA gives birth to Zhang San Li Siliang This son, Zhang San and Li Si are all out. When Zhang San goes home, SendMessageA will only think that both children are home. If my understanding is wrong, please correct me, at least my test results are as above. If this is the case, SendMessageA is not suitable for us, and using SendMessageA to use delay delay in callbacks will cause certain problems. So now we donít need to use SendMessageA, and instead use PostMessageA without waiting, and we donít have to construct a loop in the interspersed code by ourselves. What to loop, loop a return flag, when the callback interface is processed, it is in memory Write a return mark. When PostMessageA is sent to play, the code loops to check this return mark to determine the processing of the callback interface. When a return mark that can be continued is obtained, the code continues down.

    Then how to transfer the value of each register? At first, I thought that Yi Language should apply for memory in the target process to store each register, but after thinking about it carefully, this is a very stupid way. It seems that this is what I have passed through a large number of HOOK points. It is easy to confuse the register value. So what about applying for memory in interspersed code? So each pass has a separate register storage space? Thinking carefully about this is a last resort and a dumb one. If you are good at using a debugger, can you think of what is most convenient for you? By the way, that is the stack space. Each passing stack space also exists independently, which is convenient, easy to write and stable. There should be no over-limit situations, and we don't use much.
    At this time, the problem comes again. PostMessageA has four parameters in total.
    Window handle
    Message number
    Message value 1
    Message value 2

    In the 64 process, the 4 parameters of the PostMessageA function are also integer 4 bytes, including the value it sends out is also an integer 4 bytes. Then the 64 process stack pointer is an 8-byte long integer, that is to say we need to split the stack pointer 8 bytes into two 4 bytes, and pass this stack pointer through the message value 1 and message value 2. In our program Combine it to get the complete stack pointer. It looks like this might be fine, but I like perfection. I also want PostMessageA to pass the handle value of a HOOK process, so that we can directly use this handle for other operations in the easy language program, and the handle corresponds to the stack address. Perfect, all the values ​​that need to be passed will not go wrong. Itís a pity that there is no more position for this handle. After repeated experiments, I found parameter two. Message number. This parameter is a bit more special.


    We can see that the message number value obtained by normal binding is PostMessageA with a range of values. The value range of parameter 2 is between C000-FFFF. Then this gives me the hope of gas. Can I add 65535 through the process handle? If it is greater than 65535 after Yilangu gets it, 65535 will be subtracted from the data we sent, and then the actual process handle value will be obtained. The message number sent by the test message can be customized to the decimal 131071= Hexadecimal 1FFFF, it can't be received in large. That is to say, according to my idea, the handle value cannot be greater than 1FFFF-FFFF=10000=decimal 65535. Although the handle value is generally not large, 65535 still finds it not feasible. Fortunately, there is no way for people to go through the continuous opening process. After the handle test, it is found that the handle value in the system increases sequentially, and increases by 4 once you open it. That is to say, if your system has never opened the handle at all, then the first handle value should be 4, and the second should be 8. Increasing sequentially. I'm just a metaphor, the system itself still has a lot of occupancy, and the system also has a limit on the maximum number of handles. Let's calculate how many handles can be opened by 65535, 65535/4=16383 times, which is completely enough. The last second parameter=process handle\4+65535, when receiving (the second parameter -65535)*4= Process handle, this accomplishes what we want.

    The following is an assembly prototype with interspersed code. It is relatively simple. In 64 assembly, the unified stacking protection of registers is canceled and can only be pressed one by one. There is no comment in this prototype. If you understand it, you will understand it naturally. If you donít understand the explanation, I canít understand it. Itís probably the case. Write the registers that need to be protected to the stack in turn to protect them -> Lift the stack -> Call APIPostMessageA -> Flat the stack -> Loop to judge the return mark -> Write back to the register -> From the stack Get the jump back address and write it -> judge whether to execute the original code -> HOOK original code -> JMP[rip].
    Itís a bit long to divide the two pictures

    This is a comparison table of the offset of each value in the stack pointer
    0000000100401392 Here is the display result after installing the rewrite jump instruction at the HOOK location

    The general situation of the module


    Here again, it is emphasized that this module is some functions added on the basis of the WOW64Ext open source module. Please keep the copyright information. If it is used for other purposes, all disputes and consequences will be borne by you.
    Originally I wanted to write about the changes to the 64-bit module export table. In view of the length, I will give it up for the time being. I will talk about it later. The source code is also included. Let's see for yourself. At the same time, the module 64_ fetch function entry () and some other commonly used subroutines are constructed.
    I would like to thank my friend Xiaoye for his help. He also spent a lot of thought to complete this function. The two discussed repeatedly and after many modifications, we finally completed a finished source code that we are quite satisfied with:
    Remote hook64 instruction_install()
    Support minimum 6 bytes, maximum 127 bytes, hook uses JMP transfer, and long transfer (not 2G short transfer), and supports minimum 6 bytes
    Support hook arbitrary instructions, support access to 16 general-purpose registers + a rip register, read and modify
    The return value of the callback interface supports whether to execute the original instruction dropped by Hook (0=execute,>0 not execute)
    Support any stack operation, through rsp
    Support arbitrary rip transfer (support longer than 2G transfer), through rip
    Support one easy language program to control multiple 64-bit target processes at the same time
    Support multiple hook points to call back into one callback interface at the same time
    And all callbacks are independent of each other, regardless of the complexity of the hook position, the callback data will not be affected
    Each time the hook passes, it will wait until the callback returns. If the callback interface does not return, the hook at the time is in the pending state.

    Flexible and changeable free control, which can meet almost all requirements
    Thank you for the insight. Interesting.

  4. #4
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    36,454

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    That link appeared to have nothing to do with the post. Once translated...it looked like spam...after a fashion, so I removed the links. As for the post, it isn't related to VB aside from being potentially related to moving to a 64-bit variation, and it certainly isn't a question. This appears to be a better place for it.
    My usual boring signature: Nothing

  5. #5
    Frenzied Member
    Join Date
    Nov 2017
    Posts
    1,657

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    Quote Originally Posted by Shaggy Hiker View Post
    That link appeared to have nothing to do with the post. Once translated...it looked like spam...after a fashion, so I removed the links. As for the post, it isn't related to VB aside from being potentially related to moving to a 64-bit variation, and it certainly isn't a question. This appears to be a better place for it.
    Maybe set up a special page for this user's posts?

    Like www.xiaoyaothoughts.gov.www\xiaoyaothoughts?

  6. #6

    Thread Starter
    Frenzied Member
    Join Date
    Jan 2020
    Posts
    1,563

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    Quote Originally Posted by Shaggy Hiker View Post
    That link appeared to have nothing to do with the post. Once translated...it looked like spam...after a fashion, so I removed the links. As for the post, it isn't related to VB aside from being potentially related to moving to a 64-bit variation, and it certainly isn't a question. This appears to be a better place for it.
    In fact, that link is very important, because it has source code inside. It's just that he's Chinese.I mainly hope to throw a brick to attract jade, if some people can also make a VB6 operation of the sixty-four process procedures.

  7. #7

    Thread Starter
    Frenzied Member
    Join Date
    Jan 2020
    Posts
    1,563

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    I hope to return it to the VB6 plate.Because it is mainly about the principle of a method that a 32-bit program calls a 64-bit process, many of the techniques are very advanced.Because I can not achieve their own, but others see it may be able to write a complete code.Because it involves not only ordinary VB6 code, programming and assembly code.

    vfb,visual freebasic,His goal is to replace VB6, but your administrator said that as long as he is not vb6 banned release, equivalent to being killed by you, too sad.

    Your practice is to prevent advanced technology from replacing VB6 or supplementing it forever.

  8. #8

    Thread Starter
    Frenzied Member
    Join Date
    Jan 2020
    Posts
    1,563

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    Quote Originally Posted by TTn View Post
    Thank you for the insight. Interesting.
    Admin comrades, did you see this reply?As long as it can help one person, that's where this post succeeds.If you continue to maintain the VB6 forum channel, there may be ten hundred people to see, and eventually there may be a few people who really use VB6 code to achieve it.

    In fact, the VFB programming language can write a 64-bit DLL directly into the target process. It just makes sense to do it in VB6.

    The big complaint about this forum administrator is that they are clearly wrong, but they will never listen to the voice of the masses.

    Sometimes our presentation is actually to raise a question or forward an interesting and meaningful article, so that everyone can learn together.

    Some ideas are like patented inventions.No one else had ever thought of it.But for those who need it, it may be worth hundreds or thousands of dollars.

    We just hope to have more creative ideas to learn and share with you.

  9. #9
    Frenzied Member
    Join Date
    Nov 2017
    Posts
    1,657

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    If you have a beef with the forum admins here, you can always start your own VB6 focused web forum. No one is forcing you to continue to post here.

    The masses want discussion that is on topic to the thread. The way I see it, you can discuss VFB all you want in a thread where that discussion is relevant.

  10. #10
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    36,454

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    If you can come up with a question, ask that.

    I see that the link could have had source code, but it sure doesn't look like a good site. Once translated, it looked like some kind of combination between a sales site and a blogging site, both with kind of unfortunate layout. Do you have the means to move the source code somewhere else?
    My usual boring signature: Nothing

  11. #11

    Thread Starter
    Frenzied Member
    Join Date
    Jan 2020
    Posts
    1,563

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    Quote Originally Posted by Shaggy Hiker View Post
    If you can come up with a question, ask that.

    I see that the link could have had source code, but it sure doesn't look like a good site. Once translated, it looked like some kind of combination between a sales site and a blogging site, both with kind of unfortunate layout. Do you have the means to move the source code somewhere else?
    That website has nothing to do with this article. It's just that he published an article, mainly to explain that there is a very interesting technique. People wrote thousands of words. If you know how to read a few paragraphs, you will understand that it is really superb. Technology. People who donít understand will not look.
    I just reposted a better technology, in fact, more than 95% of people can't understand it and don't use it. Maybe someone will realize it in the future. Since you can't understand it, and you don't want me to post it, then you still allow me to commit suicide.

    Please delete my reprinted article.

  12. #12
    Frenzied Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    1,085

    Re: 64-bit process remote hook technology and some changes in the 64 module export ta

    xiaoyiao, your content is interesting but we find it very hard to understand some of what you suggest.

    Can you try to converse perhaps in a Western manner that would be easier for us to comprehend. Summarise your thoughts at the beginning and then give detail afterwards.

    I think you are saying that you have examples of a language where they have successfully attempted the use of 64bit hooks in an older 32 bit language.

    Suggestion: use paragraphs and bullet points and be succinct to get your point across more clearly.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width