是啊,不看不知道,一究吓一跳.
原来JMP NEAR PTR 可以在以改指令的地址－32768或者+32767(就是一个'段')内顺意跳啊.原因大概是JMP NEAR PTR 转译成机器码时会转化成相对位移量,而这个位移量只给2个字节的空间,而且还是有符号的(要表示是向上跳还是向下跳)...
看看助记符,再看看机器码,感觉光看汇编不行啊,还要再深入啊!
看来技术没极限啊...

不光是学电路呢，恐怕钢铁冶炼和材料学都是要学的呢，呵呵

      其实JMP NEAR PTR还是在“假定”最大代码段 CS:0~CS:0FFFFH（也就是CS:0~CS:65535）的范围内跳来跳去找程序里标号处的地址。。。但因为标号又必须是明文写在代码部分里的，所以段其实就是代码段，段内其实就是指代码段内。。。不要误解以IP位移以“－32768～32767”为范围就有可能跳到CS:0上面或CS:0FFFFH下面的内存空间。。。IP累加位移后还是赋值于IP本身的，而IP本身应该是作为无符号数处理，所以没可能在以 CS:IP 所指向指令JMP NEAR PTR的上下内存空间随便跳的。。。段还是代码段，段内还是指代码段内，我写的第2点只是希望能深究一下这个代码段的由来，要是在‘段’的问题上误导了别人，可就罪过了。。。
     

    另外，我非常赞同技术没极限的说法，我觉得，技术没有最底层，也没有最边际，有的只是不断地超越现有的。。。

    对技术追求的极致真是不知道会是个什么样子。。。世界太大了。。。可惜每个人的时间都是有限的。。。

    对了，还有为技术而技术的心态也不是经常有的，甚至很少有或者没有，社会是功利的，人是有私心的，技术很多情况下都不是被当作目标而是被当作达成目标的工具而被对待着。。。不过能在百忙功利之中抽出一点时间来纯粹技术陶醉一下一定也是一种享受吧。。。

是啊!要不怎么有些书上就把JMP NEAR PTR 直接就说成为:"段内直接近转移"呢.不就他只改变IP吗.IP再改还不是在CS的64K或者4G范围内.否则就要用JMP FAR  PTR 了......

^_^。。。是呀。。。

躺在床上，反反复复还是想着自己在主贴对 JMP NEAR PTR 指令第2点体会上的文字表达上的不达意以及第3点体会上对‘－32768～32767’理解的不到位。。。
   
   

    对于第2点，也就是 JMP NEAR PTR 的跳转范围问题，结合上在4楼的回帖就应该算是完全表达了自己对这个问题的理解了。。。
   
   

    但是对于第3点，我想来想去的结果是还有一种可能：也许为什么位移是‘－32768～32767’而不是‘0～65535’的问题有点想偏了。。。把‘－32768～32767’和 JMP NEAR PTR 联想得那么“紧密”以致于非要求证出‘－32768～32767’对 JMP NEAR PTR 这条指令究竟有什么更深层次的联系根本就是一个原则性的错误。。。‘－32768～32767’的说法应该是内含了两层不同意义上的含义：
     1、为什么非要把位移看成有符号数？强调编译程序在处理位移单元参与IP地址修改时的灵活性。编译程序对于最后决定IP地址转移的位移起到了判别类型和最终确定的重要作用，所以能够“向上”转移（即位移可以为负）的说法实际上暗示了在对程序的编译处理层面上编译器因为要最优处理位移值所起到的重要判别作用。是编译器先选择确定好的IP位移值，然后程序运行执行到转移指令时，IP位移值才进入CPU数据处理环节，此时所进行的运算并没有区别于其他运算的更深层次的含义。所以对“IP位移值为什么是有符号数”问题探究的关键不应放在‘－32768～32767’与 JMP NEAR PTR 这条具体指令有什么特殊联系的问题上。关键应该在于汇编编译器是怎么样判别、处理IP位移值，又是根据什么最优化的依据来确定IP位移值的问题。。。
     2、为什么要在有符号数的角度说明转移位移的范围？仅仅是因为在上面1的理由后，继续站在在有符号数角度说明了 JMP NEAR PTR 对IP位移修改的范围。。。重点在于强调出这个范围的大小，而不是范围的起点和终点。。。
    总之一句话吧，我认为对于为什么是‘－32768～32767’而不是‘0～65535’的问题的讨论更多地不是放在CPU或者CPU指令的架构层面上，而是应该在放在汇编编译器对程序的处理层面上。。。

     
    总算说完了。。。只是自己的一点想法。。。^_^。。。

刚才又注意看了一下汇编书里面对MASM对JMP类指令的处理介绍，大致支持了之前考虑的方向。

     但是介绍MASM编译过程中的具体行为之处，特别是对于 JMP NEAR PTR 对除正常IP位移量之外的数据的处理模式，却没有看到一个明显支持“－32768～32767”的说法。

     所以对于为什么一定要强调“－32768～32767”的问题进一步保留。。。而且由此可以引发联想的一件事情就是：假如我以后有足够的反编译知识和能力，一定考虑把MASM给逆向了，到时候好好看看它的代码，看看这家伙本身的编译流程对 JMP NEAR PTR 的处理到底是个什么样子？为什么书上会反复强调“－32768～32767”？

      强烈预感：“－32768～32767”并不是MASM对于 JMP NEAR PTR 指令处理过程中的必须表达，“－32768～32767”只是因为契合补码运算原理所展示出来的虽然真实但是比较容易误导我这样的读者对MASM运行机理理解的一个JOKE。“－32768～32767”作为描述实际数据处理的CASE肯定是没有错的，但是“－32768～32767”一定可以换一种面目以一种更接近真实运算架构的面目展示出来。。。

      感慨：为什么好多技术领域都强调采集第一手资料？也许是因为经过转述的信息可能会帮助我们更快地理解，但也有可能会成为牵制我们理解的障碍。。。

谢谢分享 LZ我给你弄个邀请码吧 发你邮箱吗？

1,一直以为楼主对这个问题已实践,看了你上面的才知道你没实践.(不要不高兴!)楼住应该知道JMP SHORT 的机器码占几个字节,2个,除掉一个是指令码,另一个放位移量,如果放偏移地址一个字节是放不小的,那么JMP NEAR PTR也用位移量应该好理解点了...

2,"强烈预感：“－32768～32767”并不是MASM对于 JMP NEAR PTR 指令处理过程中的必须表达，“－32768～32767”只是因为契合补码运算原理所展示出来的虽然真实但是比较容易误导我这样的读者对MASM运行机理理解的一个JOKE。"
－32768～32767是毫无疑问的,请想:如果你在CS:FFF0处段内直接近跳到CS:0010处会怎么办?位移量是-65504(上跳)?反之如果你在CS:0010处段内直接近跳到CS:FFF0处会怎么办?位移量是+65504(下跳)?都超过了“－32768～32767”范围呀?
其实在CS:FFF0处段内直接近跳到CS:0010处不是用加(FFE0H-0003H)而是采用减(0020H+0003H)的方式.段超界原理(其实也就是0000-FFFF循环),

贴个实践给你看下:(这代码可以编译,但不要运行啊,运行他就不只跑那去了,只是用来在DEBUG下来理解jmp near PTR 的,先说明下啊)

注意那个  jmp near PTR [START-0100h]  那

上传的附件：

• 看雪01.JPG （25.59kb，138次下载）
• 看雪02.JPG （20.12kb，136次下载）

      

     1、首先非常高兴看到这样针对主题本身的回复，这说明你对我提出的问题非常关注，并且更难得的是参与到了问题本身的讨论中来（其实一开始有点担心发帖讨论这种初级的汇编命令会被人BS）。
   至于我本人的心情：一开始看到这个回复的时候确实有点担心，担心最多的地方在于我不懂编译器的原理，也没有能力反汇编MASM,另外对转介MASM对JMP指令处理的文章现在有点抵触，不知道怎么回事对经过别人解释的编译器运行原理总是有点怀疑。而至于实践的问题，我想既然我们不能直接从MASM的源码找答案的话，那唯一剩下的可能就是通过分析经过MASM编译以后的程序段来推测MASM可能的处理源程序的方式了。

    2、对于我提出的问题，也就是“－32768～32767”到底能从哪里找到可靠的依据来证明它是对JMP NEAR PTR指令处理过程中必须或者说不可替代的表达，讨论这个问题的实践基础只有可能来自两个方面：
    一、MASM编译器本身的源程序。
    二、经过MASM编译过的程序。
    对于第一个方面，根据编译器本身的源代码到底是怎么计算IP偏移数据来说明问题肯定是最直接也是最有说服力的。可惜我没有足够的能力看懂MASM编译器的源代码，所以只能考虑第二个方面，也就是通过分析经过MASM编译过的程序来推测MASM编译器的编译原理。但在分析了一些简单的小程序后，我突然意识到一个问题：也就是CPU处理类似“IP=IP+位移量”的过程中，CPU本身也许根本不会去区分所计算的位移量到底是有符号数还是无符号数，也就是说CPU更加不会去分辨IP位移量是正数还是负数。也就是说，假如我们看到一条指令是 “JMP FF00”，那么不仅CPU不知道，就是我们也根本无法仅仅根据“FF00”就去反推MASM编译器是怎么把它计算出来的，不知道它到底是代表“＋65280”还是“－256”。这就是说，利用编译器编译后的程序来推测编译器本身的运行原理是远远不够的。。。这也就是，“－32768～32767”到底是不是必须的不可替代的对IP位移范围的说明是没有办法在编译过后的程序里找到确凿的答案的。。。这也就是说，只有MASM编译器本身的源程序才能对这个问题给出实例证明。

    3、在无法直接找到对“－32768～32767”不可替代性的实例证明的情况下，我们不妨在回头看看课本中到底是怎么引出“－32768～32767”的说法的，可以以此作为一种辅助材料重新地不在实例上而是在逻辑上继续进行我们的推测。事实上，我能在汇编书里找到的是，对MASM如何计算JMP NEAR PTR指令IP位移量的说明仅仅是有向前和向后转移的这种表述，但并没有说编译处理过程中向后转移的位移就不能超过“32767”，向前转移的位移就不能超过“－32768”。“－32768”和“32767”从来没有被独立地列出，而只是作为一个范围“－32768～32767”列出过，这个范围仅仅是从有符号数角度确定IP位移所占字节数而使用的。另外，书上对MASM编译器怎么计算IP位移的公式明显更不支持“－32768～32767”的说法。所以我才推测：“－32768～32767”只是从某一个特定的角度来告诉我们IP位移的范围，但作为更加深入地理解或者说推测JMP NEAR PTR 指令的编译过程，我们更应该从MASM编译器对IP位移的原始计算过程和数据表达的具体含义的角度来理解这个问题。

    4、觉得自己用了很多文字去表达本来就不一定确定的推测肯定会让讨论的方向变得更加模糊希望自己以后足够强，能够直接用代码或者用有源代码支持的理论来和大家交流。。。

    如果可以的话，谢谢了。

    这样我可以早一点在CRACKME下几个新鲜的例子来现场感受一下别人讨论技术的氛围了。。。当然要是自己想实际完成一个哪怕是最简单的CRACKME可能都不知道是什么时候的事了。。。水平还在JMP指令这转悠呢。。。汗。。。

钻死胡同了啊。看下DEBUG对应机器码不就明朗了。。。。。。

很惭愧
说自己实践了,还搞不明白.
!贴了代码和相应机器码都不看一下...CPU不是按机器码执行吗?!
空头理论质疑有什么意义!
无语!

文风倒还不错.....

学习中！！！！！

学习了，呵呵，从没涉足这个领域，不知道以后有没有机会，
发现这个很有意思，哈哈

楼主不妨用JMP或者JMP SHORT指令来测试位移玲是否是有符号数，JMP NEAR PTR用2个字节来放，而16位的偏移也正好2个字节来放，因为是采取补码形式，只从JMP NEAR PTR看机器码也确实难以去疑，尤其是在已怀疑的情况下（已有先入为主的倾向性意见），建议：   上跳和下跳近点和参考  JMP 或JMP SHORT的对应的机器码来看，应该能确定是有无符号数。

^_^。。。看了楼上诸位仁兄的回复，我怀疑自己现在已经在自己思维的牛角尖里了。。。或者自己作茧自缚了？。。。我已经对问题的讨论方向完全晕菜。。。。。。

^_^。。。惭愧！

邀请码 我发你邮箱了 加油 不管怎么样思考是不错的事

谢谢。不过看来我确实需要赶快把汇编基础书看完一遍再好好理解，现在看了一半。。。^_^。。。

       诚如所说，测试了JMP SHORT，发现CPU对字节型的偏移地址运算的确是当作有符号数对待的（因为只有直接在该字节型数据的更高两位补FF然后参与IP运算才有可能得到正确的结果）。但对于MASM直接给出的字型的偏移地址（也就是大多数 jmp near ptr 指令所涉及的），CPU是直接进行运算，已经不会去判断数值本身所代表的是什么类型的数。我们也不能简单地推测MASM对 JMP NEAR PTR 的处理也应该和 JMP SHORT 一样，是把IP位移量当作有符号数而给出的。实际上，我认为，在针对部分程序的时候，把这个位移量理解成有别于“－32768～32767”范围的数也许更符合这个IP位移量的来由，更能够帮助我们理解MASM计算IP位移值的机理。

     我们都应该已经意识到，在“IP=IP+字型位移数据”的模式下，在MASM计算IP位移值的编译过程中（不是程序运行过程中），这个字型位移数据在“当最高位为1”的情况下可以被看作两个含有截然不同意义的数值：1、当作有符号数看待。此时最高位代表符号位，此数被当作负数，表示向前转移。2、当作无符号数看待。此时最高位不代表符号位，相当于被当作正数处理，表示向后转移。
    因为我们现在的讨论是在编译器处理源程序的过程中，所以此处向前或者向后转移的说法具有很强的指向性，以致于不能混淆。因为MASM编译器就是根据先扫出的到底是JMP NEAR PTR 指令还是其指令所对应的标号的顺序利用编译器内部的地址计数器记录它们各自的地址，并最终按照“as-aj”公式(as记录的是编译器为标号所分配的地址，aj记录的是编译器为对应的JMP指令所分配的地址)计算得到IP位移量。
    经过MASM编译器这么计算出来的IP位移量，如果单单限定在字型数据并且从有符号数的角度来考虑这个数值的范围，那么毫无疑问地是在“－32768～32767”。但是如果我们结合这个IP位移量是通过“as-aj”这个原始的导出公式并结合某些具体程序的CASE，“－32768～32767”这个范围就不一定针对所有类型的程序都能完全地直观地合理地说明IP位移量产生的来由。
    举一个例子，某ASM源程序如下：
    assume cs:code
      code segment
      start:
      
      mov ax,0
      jmp near ptr s
      db 0ff00H dup (0)
      s:
      mov ax,0

     mov ax,4c00H
     int 21H
     code ends
     end start     
     
     MASM汇编器在处理它的时候，编译器顺序扫描并由内部的地址计数器得到 jmp near ptr 指令处的地址aj(扫描过程涉及一开始对jmp near ptr的SHORT处理，但没有关系，因为扫描完成后会回归的正确数值)以及标号s处的地址as，然后根据IP位移量的计算公式“as-aj”计算出从 jmp near ptr 到s标号处的IP偏移地址0FF00H。那么针对这个源程序和编译的过程，我们再看一下到底是“－256”（向前转移256个字节）还是“＋65280”（向后转移65280个字节）更能合理地说明这个IP位移值的由来？“＋65280”作为能够直接说明编译器对 jmp near ptr 这条指令涉及的IP位移量的编译原理性阐述显然并不在“－32768～32767”这种仅仅站在狭义的有符号数角度去说明位移范围的范围内。虽然作为限制成字型数据的纯数字来讲，“＋65280”＝＝0FF00H＝＝“－256”的确成立，但是作为理解真实的IP位移值的由来来说，我们人为地仅仅根据数据的表象就建立起某些“等号”而不深入探讨“等号”外延的行为是要为之付出代价的。。。特别对于新入门的象我这样有时候爱钻牛角尖的PEOPLES。。。

    作为书本引入的“－32768～32767”在说明IP位移值范围上并没有错，但我们在针对某一些程序的时候也许应该再试图去联想一下数据到底是由什么经过什么样的处理以后产生的。。。去掉“壳”看看它的“CORE”。。。这也正是我千方百计想从某些角度在一定程度上跳出“－32768～32767”的原因。。。

    多谢各位前辈的指点。。。我写的肯定有很多不成熟的地方。。。特别是本人目前对汇编并没有一个相对整体的认识，甚至连汇编基础书都还没啃完，有时候又爱死钻牛角尖^_^。。。见谅。。。

呃……得知道汇编指令仅仅是助记符而已，汇编器在把汇编语言翻译成机器语言的时候是直译的，不像编译器还得分析各种语法做各种优化什么的（虽然masm已经不是单纯的汇编器了），所以真想弄懂指令在干什么要去学习机器码。比如EB+字节是一个short跳转，E9+字是一个16位near跳转，E9+双字是一个32位near跳转，EA+3字是一个段间far跳转且只在32位cpu下使用……

顺便数字电路电磁场量子力学什么的都在我们的课程表里面……不过那种东西学再多对你实践应用也没什么帮助。

      
      谢谢分享。
      虽然我现在没有足够的能力去追电磁场这样的基础课程，但是这种比较接近底层的知识也许一直会是心里的一个结。。。