1.pe文件基本概念
2.怎样为PE添加自己的加载e加脚本
3.修改PE系统设定的2种方法
4.win8运行在U盘上，还能装win pe吗
5.简述PE文件结构中的基地址、虚拟地址和相对虚拟地址，器源以及虚拟地址和相对虚拟地址之间的载器转换公式。
6.dlopen和System.loadLibrary的区别

pe文件基本概念

       模块标识模块 (MODULE) 在 PE 文件设计中涉及基本概念的源码回顾。术语 "MODULE" 表示一个可执行文件或 DLL 中在内存中加载的加载e加代码 (CODE)、数据 (DATA)、器源电脑图片psd源码资源 (RESOURCES)。载器除代码和数据直接由程序使用外，源码模块还包括由 Windows 用于确定代码和数据加载位置的加载e加支撑数据结构。在 位 Windows 中，器源这些支撑数据结构位于模块数据库 (由 HMODULE 指示的载器段) 中。在 Win 中，源码这些数据结构位于 PE 文件头中，加载e加这里将简要解释。器源

       关于 PE 文件最重要的载器两个因素是，磁盘上的可执行文件与它被 Windows 加载到内存后非常相似。Windows 加载器无需为从磁盘加载文件而创建进程。它使用内存映射文件机制将文件中的相似块映射到虚拟空间中。构建分析模型，PE 文件类似于预制的房屋。它本质上开始于一个空间，这个空间连接到其他空间的组件（例如，将其连接到 DLL 等）。对于 Win 的 DLL 来说，这个概念同样容易应用。async源码解读一旦模块加载，Windows 可以有效地将其与其他内存映射文件同等对待。

       与 位 Windows 不同的是， 位 NE 文件加载器读取文件的一部分并创建内存中的不同数据结构表示模块。当数据段或代码段需要加载时，加载器必须从全局堆中申请一个段，从可执行文件中读取新鲜数据，转到该位置，读取这些数据，并进行适当的修正。此外，每个 位模块都有责任记住当前使用的所有段选择器，无论该段是否已被丢弃。

       对于 Win 来说，模块使用的代码、数据、资源、导入表和其他需要的模块数据结构都在一个连续的内存块中。在这种情况下，只需知道加载器将可执行文件映射到何处即可。通过作为映像的一部分的指针，可以很容易地找到该模块的所有不同块。相对于虚拟地址另一个需要知道的概念是相对于虚拟地址 (RVA)。PE 文件中的dubbo mock 源码许多域使用术语 RVA 来指定。RVA 是项目相对于文件映射到内存的偏移。例如，加载器将文件映射到内存块的虚拟地址 0x 开始。如果映像中的实际表首址是 0x，则它的 RVA 是 0x。

       为了将 RVA 转换为有用的指针，只需将 RVA 值加到模块的基地址上即可。基地址是内存映射 EXE 和 DLL 文件的首址，在 Win 中这是一个重要的概念。方便起见，Windows NT 和 Windows9x 使用模块的基地址作为该模块的实例句柄 (HINSTANCE)。在 Win 中，术语 "实例句柄" 可能会导致混淆，因为该术语源自 位 Windows。在 位 Windows 中，程序的每个副本得到自己分开的数据段（以及关联的全局句柄）以将其与其他副本区分开来，形成了术语 "实例句柄"。在 Win 中，每个程序不必与其他程序区别开来，因为它们共享相同的地址空间。术语 INSTANCE 维持了 位 Windows 和 位 Windows 之间的连续性。在 Win 中重要的是，你可以调用 GetModuleHandle() 对任何 DLL 访问其组件！如果 dllname 为 NULL，github源码教程则得到执行体自己的模块句柄。这是非常有用的，如通常编译器生成的启动代码将取得这个句柄并将它作为参数 hInstance 传给 WinMain！

       最后，你需要理解的 PE 文件概念是 "块 (Section)"。PE 文件中的块等同于 NE 文件中的段或资源。块可以包含代码或数据。与段不同的是，块是内存中的连续空间，没有尺寸限制。当连接器和库为你建立并包含操作系统至关重要的信息的其他数据块时，这些块包含你的程序直接声明和使用的代码或数据。在一些 PE 格式描述中，块也称为对象。由于 "对象" 一词的含义如此广泛，只能将代码和数据称为 "块"。

扩展资料

       PE文件被称为可移植的执行体是Portable Execute的全称，常见的EXE、DLL、OCX、SYS、COM都是PE文件，PE文件是微软Windows操作系统上的程序文件（可能是间接被执行，如DLL）

怎样为PE添加自己的pyqt保护源码脚本

       一、使用Winpeshl.ini添加自定义脚本：

       可以使用Winpeshl.ini的文件来启动自定义的外壳应用程序。Winpeshl.exe将在启动期间处理Winpeshl.ini中的设置。使用文本编辑器(如记事本)创建具有以下文件目录结构的Winpeshl.ini文本文件。例如：

       [LaunchApp]

       AppPath = %SYSTEMDRIVE%/myshell.exe

       [LaunchApps]

       %SYSTEMDRIVE%/mydir/application1.exe, -option1 -option2

       application2.exe, -option1 -option2

       注：将AppPath项设置为外壳应用程序的路径。此路径可以是绝对路径，也可以使用环境变量(相对路径)，例如%SYSTEMROOT%/System/Myshell.exe。AppPath 项不支持命令行选项。将此文件保存到WinPE系统映像的%SYSTEMROOT%/System下。

       二、使用Startnet.cmd添加自定义脚本：

       使用Startnet.cmd可以在WinPE系统中添加自定义的命令行脚本。默认情况下，WinPE系统包括Startnet.cmd脚本，此脚本位于WinPE系统映像的 %SYSTEMROOT%/System 中。当前，主要用Startnet.cmd来启动Wpeinit.exe。用于安装即插即用 (PnP) 设备、处理 Unattend.xml 设置以及加载网络资源。编辑Startnet.cmd 以包括自定义命令。

       注意：对于PnP和网络支持，请确保在自定义Startnet.cmd脚本中包含了对wpeinit的调用。

       三、使用Unattend.xml添加自定义脚本：

       运行imagex /info d:/boot.wim，查看WinPE系统映像的信息。我们要注意这一行：

       Image Count: 2

       说明此WinPE系统映像文件中其实包含了两个映像。每个映像的详细信息在后面有详细的说明。这里要特别说明的是我们需要编辑的是第二个名称为WDS的映像，因为WDS使用此映像来引导计算机。

       使用imagex命令加参数mountrw将 *.wim 加载到pemount目录中：

       imagex /mountrw c:/winpe2/pe2.wim 2 c:/pemount

       使用peimg命令将第三方驱动添加到WinPE 2.0系统中，如需添加多个设备驱动请重复该步骤。

       peimg /inf=c:/winpe2/netdrv/xxx.inf c:/pemount/windows

       使用imagex命令加参数unmount及commit将修改写入到 *.wim 中。

       imagex /unmount c:/pemount /commit

修改PE系统设定的2种方法

       一、修改内部注册表的方法。

       1、首先将内部注册表的文件提取出来：

       WXPESYSTEMCONFIG*.*WXPESYSTEMSETUPREG.HI_(这是CAB压缩包，将它解开成SETUPREG.HIV)

       REGEDIT/sREG文件名

       2、运行注册表编辑器REGEDIT.EXE，鼠标点击HKEY_LOCAL_MACHINE，然后点“文件”-“加载配置单元”，打到提取出来的注册表文件(需要改哪个就加载哪个)，打开，提示挂载名时随便输入取一个名字如“WinPE”，展开HKEY_LOCAL_MACHINE后里面就有一项WinPE，然后就跟普通的注册表操作一样了，改好后用鼠标点一下“WinPE”项目，然后“文件”-“卸载配置单元”，这个文件就改好了。

       3、用改过的注册表文件替换原来的。

二、修改PE配置文件的方法。

       如果要修的项依赖于外置程序的目录结构(比如要在右键菜单中添加用UltraEdit打开)，就不能用上面的方法了，因为外置程序的绝对路径是不确定的(不同的机器中盘符不能确定)。

       这种情况就需要用原始的REG命令来做了(就跟毛桃在REGDOC.CMD中的做法一样)，这个命令的语法比较艰涩，且注册表键值的表示方法跟REG文件不同。在命令提示符下通过/?参数可以获得它的用法(中文的哦)，提醒一下/?参数是个以多层使用的，如REG/?得到的是基本参数的说明，如用REGADD/?则可得到ADD这个参数的用法……

       有了这个命令的基础后，我们来看看是怎么解决不定路径问题的。

       在REGDOC.CMD中有一个环境变量%TP%，代表的是REGDOC.CMD这个文件所在的路径。我们可以通过%TP%..表示它的上层目录，%TP%....表示它的上两层目录。用此方法可以索引到外置程序目录内的所有路径，而不用考虑外置程序目录本身的绝对路径。

       (还有个方法就是在WinPE.INI中用PECMD的REGI命令一行行添加，这个比系统的REG命令好理解些，同样可以用%CurDir%环境变量来索引外置程序目录内的所有路径)

       直接修改的好处是启动PE就是所需要设置，不依赖外部配置文件，PE的加载速度也比较快，但麻烦。修改配置文件则比较简单，但要依赖配置文件加载过程(直到加载到那些语句时才会生效)，启动时需要额外的时间加载，相当于给系统打补丁去修改默认设置。

       一般情况下不推荐直接修改PE注册表，麻烦，重新打包也比较花时间。但有些跟系统紧密的键必须直接修改才有效，比如屏幕分辨率，虽然在外面也可以修改有，但在登录时加载到它之前是无效的，那么在登录的过程中屏幕就会因切换分辨率而闪烁。自己修改注册表的前提是自己要知道所希望的改变要修注册表中的哪些键值。可以上网搜索，现在网上的这些资源多得是，实在找不到的话可以还可以用RegMon之类的注册表监视软件来定位。比如修改记事本的自动换行，又不知道相应的键值在哪。可以先开启RegMon，然后在记事本中改变换行的选项，看RegMon的监视结果，来定位是哪个键值。因为系统本身也在不断的更改注册表，RegMon中的显示会很多，但是通过不断的改变记事本中的设置，最终是可以找到的，这个过程需要的是耐心和和细心的。

win8运行在U盘上，还能装win pe吗

       å¯ä»¥ã€‚

       åœ¨å¯åŠ¨é¡¹ä¸­å¢žåŠ WinPe的WIM文件就行了。

       åœ¨Win8中启动后，用BCDEDIT看，如下所示：

       Windows 启动加载器

       -------------------

       æ ‡è¯†ç¬¦ { bf6f5-f7-4c-a6d9-3cce}

       device ramdisk=[D:]\Disk.wim,{ 4ead--4b6b-9fe6-f8ba4b

       f}

       path \Windows\system\boot\winload.exe

       description Boot from Wim Image

       locale zh-CN

       osdevice ramdisk=[D:]\Disk.wim,{ 4ead--4b6b-9fe6-f8ba4b

       f}

       systemroot \Windows

       detecthal Yes

       winpe Yes

       ä»¥ä¸Šæ ‡è¯†ç¬¦{ bf6f5-f7-4c-a6d9-3cce}和{ 4ead--4b6b-9fe6-f8ba4bf}根据不同的机器，内容不同。

       å¦‚用BOOTICE软件来设置会非常方便。

       è¯•è¯•å§ã€‚

简述PE文件结构中的基地址、虚拟地址和相对虚拟地址，以及虚拟地址和相对虚拟地址之间的转换公式。

       答案：当PE文件通过Windows加载器载入内存后，内存中的版本称为模块映射文件的起始内存地址称为基地址。每个程序都有自己的虚拟地址空间，这个虚拟空间的内存地址称为虚拟地址。

       虚拟地址和相对虚拟地址之间的转换公式：虚拟地址=基地址+相对虚拟地址

dlopen和System.loadLibrary的区别

       åŠ¨æ€é“¾æŽ¥åº“在 unix 下，习惯以 .so 为文件名结尾（通常还以 lib 开头）。而 Windows 下是以 .DLL 为文件后缀。Windows 在处理 dll 上还有一些细节容易被人忽略

       å¦‚果需要运行时主动加载一个动态链接库，windows 下可以使用 LoadLibrary 这个 kernel API (在 kernel.dll 中)；unix 下是用 dlopen 。Windows 下找到 dll 中导出符号的地址，可以用 GetProcAddress ，而 unix 也有对应的 api ...

       è¿™äº›ç›¸äº’对应的 api ，似乎预示着对等的功能，但事实上是有区别的。

       DLL 事实上和 EXE 文件一样，同属 PE 格式的执行文件。对于隐式的引用外部符号，需要把外部符号所在的位置写在 PE 头上。PE 加载器将从 PE 头上找到依赖的符号表，并加载依赖的其它 DLL 文件。

       ä½†æ˜¯ï¼Œunix 上并非如此，so 文件大多为 elf 执行文件格式。当它们需要的外部符号，可以不写明这些符号所在的位置。也就是说，通常 so 文件本身并不知道它依赖的那些符号在哪些 so 里面。这些符号是由调用 dlopen 的进程运行时提供的。而 unix 下的执行文件本身会暴露自己静态链接的符号，（可以是自己本身实现的，或者是从静态库 .a 文件里链入的）。dlopen 将把这些符号通报给 dlopen 加载的 .so 文件，最终完成动态链接。（事实上 dlopen 还可以指定 mode ，完成更复杂的操作）

       å› ä¸ºè¿™ä¸ªåŒºåˆ«ï¼Œunix 下的 lua 解释器可以完全静态链接所有的 lua api ；我们为 lua 扩展的库，以 so 的形式存在被运行时加载不会有任何隐患。而 Windows 下，必须生成一个 luacore 的 DLL 文件，由 lua 解释器于扩展库共享 lua api (还包括 crt 的实现) 才不会出问题。

       ä¹Ÿå› ä¸ºè¿™ä¸ªåŒºåˆ«ï¼ŒVC 下才会有让 windows 开发新手困惑不解的动态链接 CRT ，静态链接 CRT ，多线程库，单线程库，等等的选项。没点点 windows 开发功力的人，多少都要在上面栽几个跟头。

       ä»ŽåŠ¨æ€é“¾æŽ¥åº“的这个设计上来看，个人感觉Windows 弄的糟糕透顶。尤其是对开发者来说是这样。至少我们在 windows 下做一个 dll 文件给大家使用还需要携带一个 .lib 文件；而 unix 下一般只需要有相应的头文件就够了。对于编写新的 .so ，找不到的符号可以就让它在那里，直到最终执行文件来把所有需要的符号联合到一起。windows 可以存在一个 dll 对另一个 dll 的隐式依赖；而 unix 下一般不需要让 so 和 so 有隐式依赖关系。这让我们全局替换类似 CRT 的东西变的困难许多；而以我自己的编程经验来看，好处却没有多少。

       unix 下需要用 ldconfig 来管理动态库，这比 windows 下 copy DLL 到当前目录下就可以用的方式，无疑提高了系统的安全性。

操作系统的ELF,COFF,PE文件格式有什么区别

       1. ELF（Executable and Linkable Format）和COFF（Common Object File Format）是两种不同的机器语言文件格式，分别针对不同的芯片平台。例如，ARM和x架构就有各自的汇编语言格式和寄存器设置。

       2. PE（Portable Executable）文件格式是在COFF指令结构基础上发展起来的，它为Windows操作系统中的可执行文件提供了一种封装形式。PE文件包含了DOS文件头、导入表、导出表、资源表等额外信息，这些信息帮助PE载入器按照特定流程加载和执行文件。

       3. 由于PE文件格式中包含了特定于操作系统的信息，如导入表和导出表，因此在不同的操作系统中，这些文件格式可能会有所不同。例如，即使是基于x架构的Linux和Windows系统，它们的可执行文件格式也是不兼容的。Linux的加载器无法识别Windows PE文件中的特定结构，因此Windows PE文件不能在Linux上执行。

       4. 尽管x平台上的COFF以及其他类似的代码格式在底层结构上可能相似，但由于操作系统的差异，这些格式在具体实现和结构上可能会有所不同。这些差异导致了不同操作系统间的文件格式不兼容，需要在加载和执行时进行适当的转换或适配。