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

隨筆-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 溪流 閱讀(8162) 評論(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://m.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 失敗)
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>
            欧美日韩高清在线播放| 99国产精品私拍| 免费成人激情视频| 久久精品伊人| 久久精品一区四区| 久久久av水蜜桃| 免费一级欧美片在线观看| 欧美黄免费看| 国产精品日韩精品欧美精品| 国产精品久久国产精麻豆99网站| 国产精品久久久久一区二区三区共| 国产精品男人爽免费视频1 | 亚洲女爱视频在线| 亚洲欧美日韩在线不卡| 午夜精品国产精品大乳美女| 亚洲人午夜精品| 久久国产视频网| 欧美在线一区二区| 久久精品在线视频| 亚洲一区二区三区高清| 国产精品入口日韩视频大尺度| 国产日韩欧美视频在线| 亚洲欧洲精品一区二区三区不卡 | 欧美精品一区二区三区一线天视频| 麻豆精品国产91久久久久久| 欧美成人中文字幕| 国产模特精品视频久久久久| 亚洲精品国产精品国自产观看| 亚洲综合好骚| 亚洲电影免费观看高清完整版在线观看 | 国产三级欧美三级| 在线观看欧美一区| 一本大道久久a久久精二百| 亚洲欧美在线看| 欧美a级理论片| 一本色道久久加勒比精品| 久久综合久久久| 国产精品入口福利| 在线精品一区| 久久精品国产91精品亚洲| 日韩性生活视频| 欧美高清视频在线观看| 一区二区三区在线不卡| 亚洲一区二区精品在线| 亚洲国产精品一区二区尤物区| 久久不见久久见免费视频1| 亚洲第一级黄色片| 欧美视频三区在线播放| 亚洲经典自拍| 欧美成人免费全部观看天天性色| 亚洲欧美视频一区| 国产精品日本精品| 亚洲欧美中文在线视频| 在线一区二区三区四区五区| 欧美精品日韩| 亚洲国产高清一区| 久久一综合视频| 欧美在线一二三| 国产伦精品一区二区三区照片91| 亚洲一区在线观看免费观看电影高清| 亚洲激情国产| 欧美激情第一页xxx| 亚洲福利久久| 亚洲国产日韩一区| 亚洲一区二区网站| 亚洲精品国精品久久99热| 欧美黄色aaaa| 久久久亚洲国产天美传媒修理工| 国产精品久久久久7777婷婷| 亚洲一区二区三区精品视频| 亚洲人成网站色ww在线 | 亚洲影视在线| 亚洲黄色在线视频| 欧美激情中文字幕乱码免费| 怡红院精品视频| 久久精品二区三区| 欧美在线观看视频| 激情欧美日韩| 欧美~级网站不卡| 欧美肥婆在线| 午夜久久一区| 久久欧美肥婆一二区| 1024成人网色www| 午夜在线视频观看日韩17c| 亚洲一区二区三区四区中文| 国产一区视频在线观看免费| 牛牛国产精品| 欧美不卡视频一区| 一本色道久久综合亚洲精品按摩| 一本色道久久综合精品竹菊| 欧美精品123区| 久久精品91久久香蕉加勒比| 久久久久久久综合色一本| 日韩视频一区二区在线观看| 欧美国产精品v| 欧美精品在线观看91| 亚洲在线观看免费视频| 亚洲欧美视频在线观看视频| 国产伦精品一区二区三区| 久久一区国产| 欧美99在线视频观看| 亚洲高清中文字幕| 亚洲精品久久久久中文字幕欢迎你 | 国产视频亚洲精品| 亚洲欧美在线看| 午夜精品一区二区三区在线播放| 国产日韩欧美成人| 麻豆成人av| 欧美日韩色综合| 久久综合久久综合九色| 国产精品爱久久久久久久| 亚洲一区二区在线播放| 欧美在线短视频| 一区二区三区四区国产精品| 亚洲大胆在线| 国产一区二区三区久久久| 亚洲国产免费| 在线成人激情视频| 亚洲视频在线观看网站| 狠狠色香婷婷久久亚洲精品| 亚洲精品视频在线播放| 亚洲大胆美女视频| 中国av一区| 亚洲午夜女主播在线直播| 欧美激情麻豆| 美女脱光内衣内裤视频久久影院| 欧美日韩另类在线| 欧美国产一区二区三区激情无套| 欧美日韩在线三区| 亚洲国产精品第一区二区 | 国产精品视频精品| 亚洲三级视频| 亚洲高清在线| 久久人人爽爽爽人久久久| 亚洲曰本av电影| 欧美成人性生活| 久久精品av麻豆的观看方式 | 国产日韩av一区二区| 亚洲精品在线看| 狠狠色噜噜狠狠色综合久| 亚洲午夜精品17c| 欧美亚洲在线| 欧美日韩综合视频网址| 日韩视频免费观看高清在线视频 | 欧美激情中文不卡| 在线观看日韩精品| 午夜精品久久久久久久男人的天堂 | 亚洲伦理在线| 亚洲国产精品久久久久久女王| 亚洲综合清纯丝袜自拍| 亚洲一区久久久| 欧美日韩一区二区三区| 亚洲日本久久| 一区二区三区免费在线观看| 欧美成人亚洲成人| 欧美在线视频一区二区三区| 国产啪精品视频| 另类图片国产| 在线免费观看欧美| 欧美不卡福利| 亚洲精品国产精品久久清纯直播 | 欧美国产日韩xxxxx| 欧美激情一区二区三区| 91久久久精品| 国产精品裸体一区二区三区| 亚洲在线免费| 欧美成人一区二区在线| 亚洲视频在线一区| 国产日韩欧美一区| 免费观看在线综合色| 亚洲欧洲视频在线| 欧美在线播放高清精品| 狠狠色2019综合网| 欧美日韩精品久久久| 亚洲综合日本| 国产最新精品精品你懂的| 久久九九免费视频| 日韩视频在线观看国产| 欧美亚州一区二区三区| 性欧美1819性猛交| 欧美福利一区| 欧美在线地址| 亚洲人在线视频| 国产视频久久| 欧美日韩高清在线播放| 久久精品国产综合| 这里只有精品丝袜| 欧美国产日本高清在线| 香蕉尹人综合在线观看| 亚洲二区免费| 国产一区二区三区无遮挡| 欧美国产在线观看| 久久偷看各类wc女厕嘘嘘偷窃| 亚洲免费精品| 亚洲狠狠丁香婷婷综合久久久| 亚洲欧美一区二区在线观看| 亚洲日本va午夜在线电影| 新67194成人永久网站| 最新高清无码专区| 亚洲精品小视频|