青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

隨筆-90  評論-947  文章-0  trackbacks-0

突然想到個問題,EXE可否像DLL一樣導(dǎo)出函數(shù)呢?于是就起來做試驗(yàn)——

 

靜態(tài)鏈接調(diào)用

嗯,先建立一個EXE,內(nèi)容很簡單:

 

#include "stdafx.h"

#define EXE_LIBRARY

#include "ExeLibrary.h"

 

EXE_LIBRARY_API int Sum(int a, int b)

{

    return a + b;

}

 

int APIENTRY _tWinMain(_In_ HINSTANCE     hInstance,

                       _In_opt_ HINSTANCE hPrevInstance,

                       _In_ LPTSTR        lpCmdLine,

                       _In_ int           nCmdShow)

{

    return 0;

}

 

Sum函數(shù)是等下用來測試的。其中ExeLibrary.h 中模仿系統(tǒng)生成的DLL頭文件進(jìn)行了宏定義:

 

#ifdef EXE_LIBRARY

#define EXE_LIBRARY_API __declspec(dllexport)

#else

#define EXE_LIBRARY_API __declspec(dllimport)

#endif

 

EXE_LIBRARY_API int Sum(int a, int b);

 

 

然后建立另一個EXE

 

#include "../ExeLibrary/ExeLibrary.h"

#pragma comment(lib, "ExeLibrary.lib")

 

int main()

{

    int s = Sum(1, 2);

 

    return s;

}

 

然后運(yùn)行:

clip_image001

 

能跑,運(yùn)行結(jié)果也正確,說明函數(shù)被正確執(zhí)行。

 

查了下進(jìn)程列表,木有ExeLibrary.exe

再查調(diào)試環(huán)境的模塊列表:

clip_image002

ExeLibrary赫然在目。

 

整個運(yùn)行過程中,WinMain 函數(shù)木有進(jìn)入。嘗試

 

動態(tài)加載調(diào)用

先為剛才的ExeLibrary添加一個def文件:

 

LIBRARY

 

EXPORTS

    Sum

 

然后新建另一個EXE

 

#include <Windows.h>

#include <tchar.h>

 

int main()

{

    HMODULE hModule = LoadLibrary(_T("ExeLibrary.exe"));

 

    if (hModule == nullptr)

    {

        return 0;

    }

 

    typedef int (*FnSum)(int a, int b);

    FnSum Sum = (FnSum)GetProcAddress(hModule, "Sum");

 

    int s = 0;

 

    if (Sum != nullptr)

    {

        s = Sum(1, 2);

    }

 

    FreeLibrary(hModule);

 

    return s;

}

 

運(yùn)行結(jié)果:

 

clip_image003

 

同剛才一樣,一切正常。

 

結(jié)論

可以像DLL一樣,在EXE里導(dǎo)出函數(shù)。調(diào)用時可以靜態(tài)鏈接也可以動態(tài)加載。EXE只作為一個進(jìn)程內(nèi)的模塊被加載,不會新起一個進(jìn)程。加載過程中EXE中的WinMain函數(shù)不會被調(diào)用。

 

例程下載:http://pan.baidu.com/s/1mgqTYBI

posted on 2012-12-01 11:41 溪流 閱讀(8169) 評論(15)  編輯 收藏 引用 所屬分類: Windows

評論:
# re: EXE導(dǎo)出函數(shù) 2012-12-01 13:15 | OwnWaterloo
exe和dll還是有很多區(qū)別的。
首先entrypoint肯定就被忽略了。
其次重定位和依賴加載好像也會有問題。

比如試試這個?
int error_code;
__declspec(dllexport) int get_error(void) { return error_code; }
__declspec(dllimport) void set_error(int x) { error_code = x; }

get和set產(chǎn)生的指令里會有error_code的地址。
如果是dll,加載時指令中的地址會被正確地重定位。
而exe不行,即使保留重定位信息也不行。

exe可以被加載應(yīng)該是為了里面的資源而不是代碼。
  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-02 12:09 | 溪流
@OwnWaterloo
不懂,為啥例子中一個是export一個是import?  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-02 16:36 | OwnWaterloo
@溪流
手誤。。。我的錯。。。  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-02 16:48 | OwnWaterloo
@溪流
兩個都是dllexport。兩個函數(shù)產(chǎn)生的代碼都會用上error_code的地址。

鏈接產(chǎn)生這個dll/exe的時候,是很難確切地知道加載后該dll/exe的地址。同樣也很難確切知道error_code的地址,因?yàn)樗蚫ll/exe被加載后的基地址之間的偏移是鏈接后就固定了的。

于是鏈接器只能先假設(shè)dll/exe會被加載到某個位置(首選基地址),然后根據(jù)它產(chǎn)生代碼。

比如一種極端情況,將dll/exe復(fù)制一份本地文件(首選基地址相同),然后loadlibrary它倆。
那么,至少有一個dll/exe是無法被加載到首選基地址的,也就是set/get的指令中使用的地址是不正確的。

如果是dll,沒有被加載到首選基地址的話,就會發(fā)生重定項(xiàng)。set/get的指令會相應(yīng)的修改。
而exe,我記得loader就不會做這個工作,于是就。。。
  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-02 16:50 | OwnWaterloo
@溪流
另外,load是不會根據(jù)dll/exe后綴名來判斷是否是dll還是exe。
它是根據(jù)pe格式中的一個域來判斷的。具體位置我忘了。。。不過dumpbin好像能顯示出來。

也就是說。。。很多那些后綴是exe(甚至是ocx什么的),而且加載后也能成功調(diào)用里面函數(shù)的文件,其實(shí)按pe格式來說都是dll文件,只是后綴名沒有用dll而已。
  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-02 16:58 | 溪流
@OwnWaterloo
懂了~就是說EXE當(dāng)DLL用,不會被重定向咯?改天試下哈  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-02 23:47 | 朱峰everettjf
當(dāng)時我也做了個類似的研究,
http://www.shnenglu.com/everett/archive/2012/05/25/176073.aspx
交流交流  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-04 10:58 | zuhd
@OwnWaterloo
我做了個實(shí)驗(yàn),exe的導(dǎo)出函數(shù)中調(diào)用全局變量也是沒問題的,沒出現(xiàn)樓上所說的崩潰現(xiàn)象,如果按照pe格式來理解的話,即使是exe應(yīng)該也會被重定向吧?  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-04 11:00 | zuhd
樓主的例子我沒下載成功,用的是朱峰everettjf提供看雪里的例子,我新增加了兩個函數(shù),調(diào)用全局變量。如果需要提供現(xiàn)場的話,留個郵箱。  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-04 15:12 | OwnWaterloo
@zuhd
沒有崩潰=沒有問題=程序正確?

*(int*)隨便寫個什么地址 = 12; // 只要運(yùn)氣好,同樣不會立即崩潰。  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-04 16:13 | OwnWaterloo
本來應(yīng)該用高級評論將重點(diǎn)高亮的,但不知道cppblog出了什么問題用不了。只能眼睛尖點(diǎn)了。。。

1. test files

module.c 導(dǎo)出1個變量與3個函數(shù)

__declspec(dllexport) int error_code;
__declspec(dllexport) int get(void) { return error_code; }
__declspec(dllexport) void set(int x) { error_code = x; }
int main(void) { return 0; }

main.c 輸出變量地址、函數(shù)地址以及函數(shù)包含的指令

#include <stdio.h>

__declspec(dllimport) int error_code;
__declspec(dllimport) int get(void);
__declspec(dllimport) void set(int x);

int main(void)
{
int i;
unsigned char const* p;

printf("%p\n", (void*)&error_code);

p = (unsigned char*)get;
printf("%p:", p);
for (i=0; i<12; ++i) printf(" %02X", p[i]);
printf("\n");

p = (unsigned char*)set;
printf("%p:", p);
for (i=0; i<12; ++i) printf(" %02X", p[i]);
printf("\n");

return 0;
}


2. dll

編譯
cl /LD /O1 module.c /link /noentry

查看首選基地址
dumpbin /all module.dll | find /i "image base"
10000000 image base (10000000 to 10004FFF)

查看反匯編與重定項(xiàng)
dumpbin /disasm /relocations module.dll

File Type: DLL

10001000: A1 00 30 00 10 mov eax,dword ptr ds:[10003000h]
10001005: C3 ret
10001006: 8B 44 24 04 mov eax,dword ptr [esp+4]
1000100A: A3 00 30 00 10 mov dword ptr ds:[10003000h],eax
1000100F: C3 ret

BASE RELOCATIONS #4
1000 RVA, C SizeOfBlock
1 HIGHLOW 10003000
B HIGHLOW 10003000

10001000 處(get的第1條)指令的操作數(shù)(地址在10001001)是 10003000
1000100A 處(set的第2條)指令的操作數(shù)(地址在1000100B)也是 10003000
注意"File Type: DLL",這是根據(jù)PE的域來的。

編譯并運(yùn)行得到的輸出是
cl main.c module.lib && main.exe
10003000
10001000: A1 00 30 00 10 C3 8B 44 24 04 A3 00
10001006: 8B 44 24 04 A3 00 30 00 10 C3 00 00

error_code的地址和指令中使用的地址是相同的。


3. dll relocation

上面 module.dll 恰好加載在首選基地址,所以沒有發(fā)生重定項(xiàng)。
要演示重定項(xiàng)發(fā)生的情況, 可以將 module.dll 復(fù)制一份, 然后用 LoadLibrary 加載。
或者直接首選基地址為一個會沖突的, exe的默認(rèn)基地址0x400000。

cl /LD /O1 module.c /link /noentry /base:0x400000

dumpbin /all module.dll | find /i "image base"
400000 image base (00400000 to 00404FFF)

dumpbin /disasm /relocations module.dll
00401000: A1 00 30 40 00 mov eax,dword ptr ds:[00403000h]
00401005: C3 ret
00401006: 8B 44 24 04 mov eax,dword ptr [esp+4]
0040100A: A3 00 30 40 00 mov dword ptr ds:[00403000h],eax
0040100F: C3 ret

BASE RELOCATIONS #4
1000 RVA, C SizeOfBlock
1 HIGHLOW 00403000
B HIGHLOW 00403000

cl main.c module.lib && main.exe
00393000
00391000: A1 00 30 39 00 C3 8B 44 24 04 A3 00
00391006: 8B 44 24 04 A3 00 30 39 00 C3 00 00

對比 dumpbin 得到的反匯編與 main.exe 的輸出,可以發(fā)現(xiàn)指令中的操作數(shù)有相應(yīng)的修改,以正確的使用00393000上的變量error_code。


4. dll fixed

如果鏈接時選擇基地址固定
cl /LD /O1 module.c /link /noentry /base:0x400000 /fixed

產(chǎn)生的dll里就沒有重定項(xiàng)信息
dumpbin /relocations module.dll

并且選擇的是一個肯定會沖突的基地址,所以加載main.exe就會失敗。

main.exe


5. exe export

默認(rèn)exe是不會包含重定項(xiàng)信息的
cl /O1 module.c && dumpbin /relocations module.exe

File Type: EXECUTABLE IMAGE

注意"File Type: EXECUTABLE IMAGE",這是根據(jù)PE的域來的。

并且首選基地址也是沖突的。
dumpbin /all module.exe | find /i "image base"
400000 image base (00400000 to 0040BFFF)

但是讓 main.c 鏈接到 module.exe 可以運(yùn)行成功(之前dll fixed的情況是加載 main.exe 失敗)
cl main.c module.lib & main.exe
0039B700
00391000: A1 00 B7 40 00 C3 8B 44 24 04 A3 00
00391006: 8B 44 24 04 A3 00 B7 40 00 C3 33 C0

注意指令里的操作碼,并沒有修改為error_code的地址:0039B700。
如果真的調(diào)用了get和set,也只是讀寫了其他的地址,而不是error_code。
bug已經(jīng)產(chǎn)生了。 沒崩只是運(yùn)氣, 那個地址恰好有讀寫權(quán)限。
而且實(shí)驗(yàn)代碼一般都比較短,跑完馬上就退出了,這種意外的寫入產(chǎn)生的影響也不一定能發(fā)現(xiàn)。

6. exe export with relocation information

可以用 /fixed:no 附帶上重定項(xiàng)信息
cl /O1 module.c /link /fixed:no

dumpbin /relocations module.exe 會產(chǎn)生很多輸出,因?yàn)樗€引用了libc。

而讓 main.c 鏈接到 module.exe 并運(yùn)行的同樣不會發(fā)生重定項(xiàng)
cl main.c module.lib & main.exe
0039B700
00391000: A1 00 B7 40 00 C3 8B 44 24 04 A3 00
00391006: 8B 44 24 04 A3 00 B7 40 00 C3 33 C0
  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-05 00:11 | 溪流
@OwnWaterloo
呀,信息量好大,學(xué)習(xí)了~!本想到周末研究一番的~  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-05 09:44 | zuhd
@OwnWaterloo
可以這樣理解嗎?
1,用lib的方式加載exe的導(dǎo)出函數(shù),
#pragma comment(linker,"/FIXED:NO") ,
這樣exe就和dll一樣,均不會有問題。
2,用loadlibrary的方式加載exe的到處函數(shù),
即使是重定向,在操作全局變量,也不會定向到全局變量的正確地址。
如:
而讓 main.c 鏈接到 module.exe 并運(yùn)行的同樣不會發(fā)生重定項(xiàng)
cl main.c module.lib & main.exe
0039B700
00391000: A1 00 B7 40 00 C3 8B 44 24 04 A3 00
00391006: 8B 44 24 04 A3 00 B7 40 00 C3 33 C0  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-05 14:28 | OwnWaterloo
@zuhd
我記得是只與文件類型(PE中的那個域)有關(guān),與加載方式(隱式加載/顯式加載)無關(guān)。

只要文件類型是exe,加載器就不會去處理重定項(xiàng)。
如果exe沒有加載到首選基地址,里面的指令操作的就不是預(yù)想中的地址。

前面說loadlibrary的意思是:這是一種讓dll/exe無法加載到首選基地址的方法。
如果將dll/exe文件復(fù)制一份(文件各種信息都是相同的),然后用loadlibrary加載這兩者,那兩者之一肯定之多有一個是被加載到首選基地址。于是就可以觀察另一個的情況了。

但前面為了偷懶。。。 就沒有用這個方法,而是用/base:0x400000 —— 這個是exe文件默認(rèn)的基地址 —— 讓dll無法加載到首選基地址。
  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-06 09:24 | zuhd
多謝OwnWaterloo
如果可以的話 希望能在cppblog單開一主題,探其究竟。  回復(fù)  更多評論
  
# re: EXE導(dǎo)出函數(shù) 2012-12-06 22:41 | OwnWaterloo
@zuhd
cppblog的排版功能太弱了。。。 寫東西很費(fèi)勁。。。  回復(fù)  更多評論
  
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            午夜一区在线| 久久久亚洲一区| 亚洲精选91| 欧美第一黄色网| 99国产精品久久久久久久| 亚洲日本理论电影| 欧美3dxxxxhd| 亚洲性线免费观看视频成熟| 亚洲图片欧美一区| 国产啪精品视频| 麻豆国产精品一区二区三区 | 欧美亚洲午夜视频在线观看| 亚洲综合首页| 亚洲黄一区二区| 亚洲精品免费网站| 国产精品一区久久久久| 久热国产精品| 欧美福利一区二区| 亚洲尤物精选| 国产亚洲aⅴaaaaaa毛片| 欧美精品免费播放| 午夜久久资源| 老司机一区二区三区| 亚洲午夜高清视频| 久久精品国产99精品国产亚洲性色| 在线观看亚洲一区| 亚洲性视频网站| 亚洲国产日韩在线一区模特| 99国产精品久久久| 精品1区2区3区4区| 9l国产精品久久久久麻豆| 国产亚洲视频在线观看| 亚洲黄色精品| 国产一区观看| 亚洲精品中文字| 国内精品美女在线观看| 99精品国产福利在线观看免费| 国产一区二区三区在线播放免费观看| 亚洲国产cao| 一色屋精品视频免费看| 在线亚洲精品| 亚洲精品日韩精品| 久久国产黑丝| 亚洲自拍都市欧美小说| 欧美高清视频| 久久久久久夜精品精品免费| 国产精品va| 亚洲国内在线| 噜噜噜噜噜久久久久久91| 亚洲欧美国产精品桃花| 一区二区三区黄色| 欧美高清成人| 欧美岛国在线观看| 狠狠色狠狠色综合系列| 午夜一区二区三区在线观看| 亚洲无毛电影| 欧美日韩国产专区| 亚洲国产精品一区二区久| 国内免费精品永久在线视频| 亚洲综合视频1区| 亚洲免费一级电影| 欧美日韩精品中文字幕| 亚洲激情六月丁香| 日韩亚洲欧美综合| 99在线|亚洲一区二区| 国产精品久久久久久久久免费桃花| 免费亚洲电影在线观看| 国内精品亚洲| 久久久福利视频| 久久性天堂网| 激情自拍一区| 久久久噜噜噜久久中文字幕色伊伊 | 欧美高清hd18日本| 国产一区二区三区在线免费观看| 亚洲一区精品在线| 久久激情五月激情| 国产视频精品免费播放| 久久精品噜噜噜成人av农村| 久久婷婷一区| 日韩视频在线免费观看| 久久久久久一区二区三区| 免费亚洲一区| 亚洲精品视频在线观看免费| 欧美成人精品1314www| 亚洲国产欧美日韩| 一区二区三区精品在线| 欧美三区美女| 欧美在线播放一区二区| 欧美在线观看一区二区三区| 欧美三级网址| 香蕉成人伊视频在线观看| 另类综合日韩欧美亚洲| 日韩一二三区视频| 国产精品嫩草99a| 久久精品免费观看| 亚洲国产另类精品专区| 亚洲一区尤物| 在线免费观看成人网| 欧美日韩精品欧美日韩精品 | 亚洲激情在线播放| 欧美区国产区| 亚洲天堂久久| 亚洲国产精品热久久| 亚洲高清视频一区二区| 欧美精品日韩一本| 午夜在线a亚洲v天堂网2018| 欧美大片专区| 欧美一区二区精品| 亚洲精品1234| 亚洲二区三区四区| 欧美日韩一区国产| 亚洲欧美综合另类中字| 免费观看一级特黄欧美大片| 亚洲午夜成aⅴ人片| 尹人成人综合网| 国产精品免费小视频| 美女免费视频一区| 亚洲欧美日韩国产| 99精品欧美一区二区三区| 久久国产日本精品| 一区二区欧美视频| 亚洲日韩欧美视频| 国产日韩精品一区| 欧美顶级少妇做爰| 欧美波霸影院| 亚洲伦伦在线| 国产欧美婷婷中文| 欧美亚洲成人免费| 欧美日韩国产成人在线观看| 久久婷婷激情| 久久久精品国产一区二区三区 | 午夜亚洲视频| 久久成人精品一区二区三区| 亚洲国产一区二区视频| 免费成年人欧美视频| 久久久久国色av免费观看性色| 99riav1国产精品视频| 亚洲第一区在线| 国外成人在线| 国内久久婷婷综合| 国产亚洲精品bt天堂精选| 国产伦精品免费视频| 国产精品一区二区欧美| 欧美三级欧美一级| 欧美日韩综合一区| 欧美日韩国产欧美日美国产精品| 美女主播视频一区| 久久在线免费观看| 米奇777在线欧美播放| 久久久久成人精品免费播放动漫| 欧美一区二区三区日韩| 午夜精品久久久久久久白皮肤| 亚洲一区二区成人| 先锋影院在线亚洲| 久久精品一区二区国产| 久久人人爽国产| 欧美成人激情视频| 欧美日韩一卡二卡| 国产精品久久久一区二区三区| 老司机67194精品线观看| 激情五月婷婷综合| 精品999在线播放| 亚洲缚视频在线观看| 亚洲精品韩国| 一本色道久久综合亚洲精品小说| 亚洲精品无人区| 亚洲无线视频| 久久久久.com| 久久综合影视| 小黄鸭精品密入口导航| 久久精品伊人| 亚洲电影免费在线观看| 亚洲毛片一区二区| 中文精品一区二区三区| 午夜在线一区二区| 久久综合网色—综合色88| 欧美人成在线| 国产综合色精品一区二区三区| 亚洲午夜av| 久久国产精品久久久久久| 国内激情久久| 国外成人在线| 日韩亚洲欧美成人一区| 亚洲欧美在线看| 久久国产主播| 亚洲女同精品视频| 久久久久免费| 欧美日韩一区二区免费在线观看| 欧美日韩亚洲系列| 黄色亚洲大片免费在线观看| 亚洲人成网在线播放| 午夜精品一区二区三区电影天堂| 久久久99精品免费观看不卡| 亚洲国产精品美女| 午夜亚洲性色福利视频| 欧美区在线播放| 在线观看国产精品网站| 午夜欧美精品久久久久久久| 欧美激情一区在线观看| 欧美一区二区三区在|