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

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

突然想到個問題,EXE可否像DLL一樣導出函數呢?于是就起來做試驗——

 

靜態鏈接調用

嗯,先建立一個EXE,內容很簡單:

 

#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函數是等下用來測試的。其中ExeLibrary.h 中模仿系統生成的DLL頭文件進行了宏定義:

 

#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;

}

 

然后運行:

clip_image001

 

能跑,運行結果也正確,說明函數被正確執行。

 

查了下進程列表,木有ExeLibrary.exe。

再查調試環境的模塊列表:

clip_image002

ExeLibrary赫然在目。

 

整個運行過程中,WinMain 函數木有進入。嘗試

 

動態加載調用

先為剛才的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;

}

 

運行結果:

 

clip_image003

 

同剛才一樣,一切正常。

 

結論

可以像DLL一樣,在EXE里導出函數。調用時可以靜態鏈接也可以動態加載。EXE只作為一個進程內的模塊被加載,不會新起一個進程。加載過程中EXE中的WinMain函數不會被調用。

 

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

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

評論:
# re: EXE導出函數 2012-12-01 13:15 | OwnWaterloo
exe和dll還是有很多區別的。
首先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產生的指令里會有error_code的地址。
如果是dll,加載時指令中的地址會被正確地重定位。
而exe不行,即使保留重定位信息也不行。

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

鏈接產生這個dll/exe的時候,是很難確切地知道加載后該dll/exe的地址。同樣也很難確切知道error_code的地址,因為它和dll/exe被加載后的基地址之間的偏移是鏈接后就固定了的。

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

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

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

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

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

1. test files

module.c 導出1個變量與3個函數

__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 輸出變量地址、函數地址以及函數包含的指令

#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)

查看反匯編與重定項
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條)指令的操作數(地址在10001001)是 10003000
1000100A 處(set的第2條)指令的操作數(地址在1000100B)也是 10003000
注意"File Type: DLL",這是根據PE的域來的。

編譯并運行得到的輸出是
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 恰好加載在首選基地址,所以沒有發生重定項。
要演示重定項發生的情況, 可以將 module.dll 復制一份, 然后用 LoadLibrary 加載。
或者直接首選基地址為一個會沖突的, exe的默認基地址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 的輸出,可以發現指令中的操作數有相應的修改,以正確的使用00393000上的變量error_code。


4. dll fixed

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

產生的dll里就沒有重定項信息
dumpbin /relocations module.dll

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

main.exe


5. exe export

默認exe是不會包含重定項信息的
cl /O1 module.c && dumpbin /relocations module.exe

File Type: EXECUTABLE IMAGE

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

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

但是讓 main.c 鏈接到 module.exe 可以運行成功(之前dll fixed的情況是加載 main.exe 失?。?br>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。
如果真的調用了get和set,也只是讀寫了其他的地址,而不是error_code。
bug已經產生了。 沒崩只是運氣, 那個地址恰好有讀寫權限。
而且實驗代碼一般都比較短,跑完馬上就退出了,這種意外的寫入產生的影響也不一定能發現。

6. exe export with relocation information

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

dumpbin /relocations module.exe 會產生很多輸出,因為它還引用了libc。

而讓 main.c 鏈接到 module.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
  回復  更多評論
  
# re: EXE導出函數 2012-12-05 00:11 | 溪流
@OwnWaterloo
呀,信息量好大,學習了~!本想到周末研究一番的~  回復  更多評論
  
# re: EXE導出函數 2012-12-05 09:44 | zuhd
@OwnWaterloo
可以這樣理解嗎?
1,用lib的方式加載exe的導出函數,
#pragma comment(linker,"/FIXED:NO") ,
這樣exe就和dll一樣,均不會有問題。
2,用loadlibrary的方式加載exe的到處函數,
即使是重定向,在操作全局變量,也不會定向到全局變量的正確地址。
如:
而讓 main.c 鏈接到 module.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  回復  更多評論
  
# re: EXE導出函數 2012-12-05 14:28 | OwnWaterloo
@zuhd
我記得是只與文件類型(PE中的那個域)有關,與加載方式(隱式加載/顯式加載)無關。

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

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

但前面為了偷懶。。。 就沒有用這個方法,而是用/base:0x400000 —— 這個是exe文件默認的基地址 —— 讓dll無法加載到首選基地址。
  回復  更多評論
  
# re: EXE導出函數 2012-12-06 09:24 | zuhd
多謝OwnWaterloo
如果可以的話 希望能在cppblog單開一主題,探其究竟。  回復  更多評論
  
# re: EXE導出函數 2012-12-06 22:41 | OwnWaterloo
@zuhd
cppblog的排版功能太弱了。。。 寫東西很費勁。。。  回復  更多評論
  
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            国产日韩综合| 久久久久久久国产| 亚洲免费在线电影| 欧美色图一区二区三区| 美女国内精品自产拍在线播放| 欧美网站在线观看| 日韩一级大片| 亚洲精品黄色| 欧美.www| 99国产精品99久久久久久| 亚洲成人自拍视频| 欧美激情中文字幕一区二区| 亚洲精品乱码久久久久久日本蜜臀 | 亚洲专区在线视频| 国产精品扒开腿做爽爽爽软件| 一区二区三区偷拍| 一区二区三区精品视频| 亚洲欧美激情在线视频| 亚洲欧美日韩综合aⅴ视频| 久久资源av| 日韩视频不卡中文| 亚洲国产欧美一区二区三区丁香婷| 久久精品九九| 亚洲国产天堂久久国产91| 一区二区欧美在线| 99视频日韩| 欧美国产欧美亚洲国产日韩mv天天看完整 | 亚洲国产精品一区在线观看不卡| 久久久亚洲国产天美传媒修理工 | 在线免费观看日韩欧美| 欧美一区二区三区在线看| 欧美一级二区| 亚洲经典自拍| 亚洲国产高清aⅴ视频| 欧美日韩国产黄| 久久国产精品高清| 欧美日韩另类国产亚洲欧美一级| 久久久午夜精品| 国产精品国产自产拍高清av| 亚洲国产第一页| 狠狠干狠狠久久| 亚洲一区二区三区中文字幕| 亚洲精品乱码| 狼人天天伊人久久| 久久久国产亚洲精品| 国产精品成人观看视频国产奇米| 亚洲电影天堂av| 亚洲第一中文字幕| 久久爱www.| 久久国产直播| 国产欧美日韩亚州综合| 日韩视频一区二区在线观看| 老**午夜毛片一区二区三区| 久久精品91久久久久久再现| 国产精品日韩在线一区| 日韩视频专区| 一区二区三欧美| 欧美精品在线观看| 亚洲国产精品一区二区www| 欲色影视综合吧| 久久久久青草大香线综合精品| 久久久91精品国产| 国内精品嫩模av私拍在线观看 | 久久精品一区二区三区不卡| 久久精品亚洲乱码伦伦中文 | 欧美激情网站在线观看| 亚洲福利一区| 日韩视频免费观看| 欧美久久久久久久久| 日韩视频久久| 亚洲综合日韩在线| 国产欧美日韩精品a在线观看| 亚洲一区在线免费| 久久久亚洲欧洲日产国码αv| 韩国av一区| 免费亚洲电影在线观看| 91久久综合| 亚洲伊人第一页| 国产欧美一区二区三区在线老狼| 午夜日韩电影| 欧美电影电视剧在线观看| 亚洲三级电影全部在线观看高清| 欧美黑人一区二区三区| 在线视频欧美一区| 久久久午夜精品| 日韩视频一区二区三区在线播放免费观看 | 久久久久国色av免费观看性色| 激情婷婷久久| 欧美精品久久久久久| 中文一区字幕| 久久综合伊人77777| 亚洲理论在线| 国产日韩欧美精品一区| 麻豆九一精品爱看视频在线观看免费| 亚洲欧洲午夜| 久久精品成人欧美大片古装| 亚洲国产三级网| 国产精品久久网| 久久天堂av综合合色| 亚洲精品一区在线| 久久久综合网| 亚洲一区视频| 亚洲国产成人av| 国产精品不卡在线| 米奇777超碰欧美日韩亚洲| 99在线精品视频| 欧美成人精品三级在线观看| 亚洲综合精品自拍| 亚洲开发第一视频在线播放| 国产日产精品一区二区三区四区的观看方式 | 亚洲一区二区三区色| 亚洲电影免费观看高清完整版在线| 亚洲午夜在线观看| 亚洲激情视频在线| 国产日韩欧美亚洲| 免费观看在线综合| 香蕉久久精品日日躁夜夜躁| 亚洲精品国产精品乱码不99| 久色婷婷小香蕉久久| 欧美一区二区视频在线观看2020 | 亚洲日本成人网| 韩日欧美一区二区| 国产精品久久久亚洲一区 | 亚洲欧美电影院| 一区二区三区精品在线| 欧美国产三区| 美女精品网站| 久久一区二区三区四区| 欧美自拍偷拍午夜视频| 亚洲欧美另类在线观看| 一区二区三区四区五区在线| 亚洲靠逼com| 亚洲免费电影在线观看| 亚洲精品一区在线观看| 亚洲国产毛片完整版 | 欧美日韩四区| 欧美日韩日本视频| 欧美伦理91| 欧美激情视频在线播放 | 欧美日韩精品是欧美日韩精品| 毛片一区二区三区| 美日韩丰满少妇在线观看| 久久久另类综合| 久久深夜福利| 女人天堂亚洲aⅴ在线观看| 久久嫩草精品久久久精品| 久久久亚洲欧洲日产国码αv| 久久国产精品久久精品国产| 欧美一区视频| 久久综合伊人77777| 欧美成人一二三| 欧美深夜福利| 国产欧美日韩一区二区三区| 国产精品揄拍500视频| 国产亚洲人成网站在线观看| 国产一区在线免费观看| 亚洲福利在线看| 日韩亚洲欧美高清| 午夜精品视频在线观看一区二区| 午夜精品亚洲| 狼狼综合久久久久综合网| 欧美激情亚洲另类| 日韩视频不卡| 性欧美精品高清| 裸体女人亚洲精品一区| 欧美日本一区二区高清播放视频| 久久久7777| 日韩视频第一页| 欧美日韩不卡视频| 午夜精品理论片| 亚洲国产一区二区三区a毛片| 亚洲日本黄色| 欧美一站二站| 欧美xx视频| 亚洲视频一二三| 老司机精品导航| 国产精品久久国产愉拍| 久久国产精品第一页| 欧美日韩一区二区三| 国产一区二区三区网站| 99人久久精品视频最新地址| 欧美一级视频| 亚洲精品黄色| 久久久水蜜桃| 国产麻豆精品视频| 日韩手机在线导航| 另类成人小视频在线| 99视频一区二区三区| 久热这里只精品99re8久| 国产老女人精品毛片久久| 亚洲精品国产精品国自产在线| 亚洲欧美国产精品桃花| 亚洲丁香婷深爱综合| 久久国产精品久久精品国产| 欧美视频日韩视频在线观看| 一区二区在线观看视频在线观看| 亚洲香蕉在线观看| 亚洲人成网站影音先锋播放| 久久久国产91| 国产亚洲毛片在线|