zoukankan      html  css  js  c++  java
  • <转> strcpy当初没有考虑到的地方

    最开始考虑strcpy的性能的时候,只考虑了要4bytes一起拷贝。但是忽略了一个关键问题,就是如何判断字符串的结束。由于字符串可以从4bytes中任意一个byte结束,所以需要判断是否有任何一个byte为0。
    如果对一个4bytes拆分成4个byte分别判断,那4bytes一起拷贝节省下拉性能立刻浪费掉了。今天看到Newer2k的回复,才重新开始考虑这个问题。
    拿到C++的strcpy函数一看,源代码如下:

    mov     edi,[esp+8]         ; edi points to dest string
     
    copy_start::
           mov     ecx,[esp+0ch]       ; ecx -> sorc string
           test    ecx,3               ; test if string is aligned on 32 bits
           je      short main_loop_entrance
    src_misaligned:                     ; simple byte loop until string is aligned
           mov     dl,byte ptr [ecx]
           add     ecx,1
           test    dl,dl
           je      short byte_0
           mov     [edi],dl
           add     edi,1
           test    ecx,3
           jne     short src_misaligned
           jmp     short main_loop_entrance
    main_loop:                          ; edx contains first dword of sorc string
           mov     [edi],edx           ; store one more dword
           add     edi,4               ; kick dest pointer
    main_loop_entrance:
           mov     edx,7efefeffh
           mov     eax,dword ptr [ecx] ; read 4 bytes
           add     edx,eax                                  
           xor     eax,-1
           xor     eax,edx
           mov     edx,[ecx]           ; it's in cache now
           add     ecx,4               ; kick dest pointer
           test    eax,81010100h
           je      short main_loop
           ; found zero byte in the loop
    ; main_loop_end:
           test    dl,dl               ; is it byte 0
           je      short byte_0
           test    dh,dh               ; is it byte 1
           je      short byte_1
           test    edx,00ff0000h       ; is it byte 2
           je      short byte_2
           test    edx,0ff000000h      ; is it byte 3
           je      short byte_3
           jmp     short main_loop     ; taken if bits 24-30 are clear and bit
                                       ; 31 is set
    byte_3:
           mov     [edi],edx
           mov     eax,[esp+8]         ; return in eax pointer to dest string
           pop     edi
           ret
    byte_2:
           mov     [edi],dx
           mov     eax,[esp+8]         ; return in eax pointer to dest string
           mov     byte ptr [edi+2],0
           pop     edi
           ret
    byte_1:
           mov     [edi],dx
           mov     eax,[esp+8]         ; return in eax pointer to dest string
           pop     edi
           ret
    byte_0:
           mov     [edi],dl
           mov     eax,[esp+8]         ; return in eax pointer to dest string
           pop     edi
           ret
     
    这里对一个DWORD (EAX)的判断方法是:
     
    1. 对EAX+0x7efefeff
    2. 对EAX取反
    3. 把1和2的结果作XOR,然后跟0x81010100h作test运算
     
    研究了好久,理解如下:
     
    问题的关键点在于,当且仅当EAX四个byte都不为0的时候,运算结果会是下面的pattern:

    0??? ???0 ???? ???0 ???? ???0 ???? ????
     
    分别解释如下:
     
    如果第一个byte为0, 考虑第二个byte的最后一个bit。不管这个bit是0还是1,计算公式是:
    (x+0) XOR (!x) =x xor !x=0

    如果第一个byte不为0,肯定产生进位,考虑第二个byte的最后一个bit。不管这个bit是0还是1,计算公式是:
    (x+1)XOR(!x)=!x xor !x=1
     
    这就是上面0??? ???0 ???? ???0 ???? ???0 ???? ????第二个byte的第一个bit是0的来历
     
    同理,第二,三,四个byte中的的第一个bit的0也是在前面所有的byte都不为0的时候才会出现,否则就会出现至少一个1
     
    最后再来看最一个byte的最高位。根据前面的分析,我们已经可以确保前面三个byte为0的pattern。所以我们只需要考虑前面三个byte都不是0,然后检测最后一个byte是否为0的情况。这里分成三种情况来考虑最高一个bit的情况:
     
    1) 最高byte为0
    由于前面三个byte都不是0,所以相加后最高byte肯定拿到一个进位,所以最高byte的加法变成了跟7f相加。所以公式:
    (0+0) XOR (!0) =1
     
    2) 最高byte不为0,最高bit为0。这种情况下跟7f相加,相加结果最高bit肯定会变成1:
    1 XOR (!0) =0
     
    3) 最高byte不为0,最高bit为1。这种情况下跟7f相加,不管相加后最高为是0还是1,都有:
    1 XOR (!1) =0
    0 XOR (!1) =0
     
    所以,如果EAX最高byte为0,结果的最高bit为1. 如果EAX最高byte不为0,结果最高的bit为0
     
    综上,如果所有四个byte都不为0,最后得到的pattern是:
    0??? ???0 ???? ???0 ???? ???0 ???? ????
     
    于是我们可以拿结果跟0x81010100 作TEST运算,当且仅当四个byte都不为0的时候,ZR寄存器的值为0。
     
    大家注意看,我上面的分析有一个错误!
     
    1 XOR (!1) =0
     
    错了,这里应该是1
     
    换句话说,上面的代码无法区分最高一个byte最高bit为0,其他bit为1的情况。这是这种算法的一个死穴。当出现比如0x80112233这样的DWORD的时候,test    eax,81010100h 计算的结果跟0x00112233一样。当然最后的结果不会有问题,因为byte_3 -- byte_0里面会再次作判断。所以,如果用一连串的0x80112233作为字符串内容,strcpy的效率会大大下降
     
    谢谢newer2k帮我找到我分析中的错误!
     
     

     
    本人新博客网址为:http://www.hizds.com
    本博客注有“转”字样的为转载文章,其余为本人原创文章,转载请务必注明出处或保存此段。c++/lua/windows逆向交流群:69148232
  • 相关阅读:
    C# 字典 Dictionary 转 JSON 格式遍历
    jquery-easyui-tree异步树
    android 开发环境搭建
    解决android sdk 无法更新
    043——VUE中组件之使用.sync修饰符与computed计算属性实现购物车原理
    laravel中数据库迁移的使用:
    002PHP文件处理——文件处理 is_dir mkdir getcwd chdir rmdir
    001PHP文件处理——文件处理disk_total_space disk_free_space basename dirname file_exists filetype
    042——VUE中组件之子组件使用$on与$emit事件触发父组件实现购物车功能
    041——VUE中组件之pros数据的多种验证机制实例详解
  • 原文地址:https://www.cnblogs.com/zhangdongsheng/p/2541124.html
Copyright © 2011-2022 走看看