如图所示，为啥左边转的结果不对呢？

冥界3大法王

如你用左边转的结果去修改*.exe肯定输出不对。



图2也和右边对不上啊。

怎么能让左边的转换器 输出一致？

archon1

待处理的在内存中的数据的字节数大于一个字节时就存在字节序，X86架构的字节序是固定的：在内存中存储时低位在前，高位在后，显示时正常显示；以前PowerPC架构在内存中存储时是高位在前，低位在后；MIPS架构（龙芯）则可以设置相应寄存器来决定在内存中存储顺序。
所以，你上面的结果没有不对，一个是显示时都是高位在前低位在后（所有架构都是这样），在内存中存储时因为是x86架构所以低位在前高位在后。
你要是粗略学习过汇编就了解了。

yes2

第一个图左右不同，是因为左边的十六进制是以unicode来展示的，一个汉字2字节，所以是4e91 7fe0 7fe0。右边相当于是把这个unicode字符串的十六进制字节按顺序展示出来，所以就是91 4e e0 7f e0 7f。
第二个图我觉得应该是把高位的0省略了没有输出。我觉得我是不适应这种自动省略的方式的，会影响我判断

_Bitter

图一是的对 你要这样 看    00004e91 汇编的语言    十六进制就是  91 4E  后面同理
图二  比如OD  DBUG里面 UNICODE码都是这么现实的，右边只是处理的而已00是无法显示在转换里面的

_Bitter

_Bitter 发表于 2024-12-22 09:35
图一是的对 你要这样 看    00004e91 汇编的语言    十六进制就是  91 4E  后面同理
图二  比如OD  DBUG里 ...

回复可能不是很专业。有专业的可以讲解下

冥界3大法王

_Bitter 发表于 2024-12-22 09:35
图一是的对 你要这样 看    00004e91 汇编的语言    十六进制就是  91 4E  后面同理
图二  比如OD  DBUG里 ...

我就纳闷 给弄个转换器，结果还（对）用不上，整个废物点心花架子啊。
工具是不少，用的最顺手的还得说是WinHEX

wgz001

结果看上去差别不大

snrtdwss

两个都是对的 只是汇编显示的顺序是要从右往左看

JackLSQ

大小端的问题

无闻无问

找找有没有设置大端模式，小端模式的地方……

52bojie

数据类型的原因。如图二，23 57 69，如果是word类型就如右图所示。如果是byte类型，那么在二进制文件中是 23 57 69

冥界3大法王

无闻无问 发表于 2024-12-22 10:50
找找有没有设置大端模式，小端模式的地方……

@无闻无问
右侧的数据不是固化好的？编码模式能改无非是否显示出汉字等字符来。
那16进制是死的吧？
左侧更没有设置的地方啊，也是死的啊。

综上所述设计的不科学，俺编的x64dbg插件就学习微软给出的世界编码遍历所有语言编码情况
只要内存中不加密的字符就能搜索出来。