剛用程式偵測了一下, 發現是Visual Basic寫的.
http://www.pczone.com.tw/upload/001/dpb.JPG
http://www.pczone.com.tw/upload/001/00.jpg
那個偵測程式有問題吧?
我用VC++的Tool Dependency Walker
裡面並沒有出現VB的Runtime
而是出現
MSVCRT
也就是 Microsoft Visual C++ Runtime
表示這是用VC++寫的

贊助商連結

我想它可能有用VC++包裝.
Dependency Walker 只要碰到加殼的就只能偵測出殼的資訊.

我認為它沒有加殼的理由
它不是病毒 加殼不能給他什麼好處
況且 它是以檔案大小很小的3D動畫程式出名的
加殼只會加大他的檔案大小 以此來說
他應該不會加殼
唯有的可能 就是把另一個程式壓縮存放在本身裡
然後再解壓縮出來再執行 但是....我也是覺得可能性不大

我目前知道的加殼方式 好像只有把另一個程式寫在自己程式本身裡面
加密編碼 然後要執行時再把那些部份輸出成另一個執行檔
然後執行該檔案 我沒有看過可以直接寫在程式的記意體裡
然後把執行位置的暫存器改成那個記憶體的位置 來加殼的程式
不過 很久沒玩這種東西 有沒有我也不知道

所以 我還是認為這是用VC++寫的
你可以試著把VB的Runtime砍掉在跑跑看
應該還是可以跑才對

錯, 你可以去嘗試隨便一個加殼軟體, 如UPX好了, 加殼軟體都會壓縮整個檔案(甚至有的加殼軟體就只有單純壓縮的功能就可以讓一般Debug軟體讀不出正確的組合語言), 所以檔案會變小很多, 而且這跟病毒沒關係, 加殼的功能是要讓Debug軟體讀不出正確的組合語言, 讓破解檔案的駭客更難破解出軟體的序號.
我也沒100%確定不是VC++寫的, 但是可以確定的是微軟的Dependency Walker只能簡單讀出正常檔案的Compiler, 有加殼過的資料就不正確了.

我舉別的例子好了

Heaven 7
http://www.demoscene.hu/~picard/h7/

就是這支，也算是先趨吧 ;) 2000 年就得獎的大作
透過 3d engine 重複的貼圖，音樂也不見得是 mp3
音樂的格式很多種，不見得都是 wav
與個例子來說 6k 的 midi 要播個幾分鐘也不是做不到
sdk 或是組語所寫出來的程式都可以很小，因為很多不須要的 lib 可以不放進來
再加上把編譯好的 exe 再透過壓縮執行檔的壓縮程式壓縮(這是在繞口令嗎)，就可以再變的更小

為什麼沒流傳開，我想這可能說不完，太技術性的東西不見得實用
況且程式設計師的工具越來越多，越低階的人才就越少
設備的價格不再如從前，不會是斤斤計較多了幾K的時代

他可能不是在 dos 下可執行的，或是還有另外的
年代久遠如果記錯還真是抱歉... :|||:

ethanliu所說的這支動畫檔就是用UPX包裝的, 他們因此可以將檔案變小, 而且更難知道它是用什麼製作的, 因為它是很普遍的包裝軟體, 所以可以直接顯示他的包裝軟體, 如下圖.
http://www.pczone.com.tw/upload/001/heaven7.JPG

我剛剛用新版一點的偵測軟體已經正確讀出這支動畫(64k-1.exe)的殼了, 一樣也是UPX, 只是更複雜.
http://www.pczone.com.tw/upload/001/64k.JPG

為了證明我講的是對的, 我已經將那兩個檔案都解殼了, 在下面附件中, 你會發現解殼的檔案真的變大了, 但一樣能正常執行.

Dependency Walker是用於偵測一個程式所用到的DLLs
所以稱Depend 也就是它所需要的DLLs
不過 這個軟體似乎只對於Export Table裡的DLL有用
我試過動態加載的DLL 也就是不用.lib加入的DLL
而是使用LoadLibrary的DLL並沒有用 Dependency Walker找不到它
但是用動態加載DLL的方式很麻煩 要一個一個弄
所以人們通常都用靜態加載
但是 我試另一套軟體 功能比較好 連動態也能抓到
不過 也沒見到VB的Runtime

我研究了一下 發現這UPX套加殼軟體加出來的東西還不錯
它用的是對PE的結構進行加殼和解殼的操作
可以直接在記意體內完成 不用我說的輸出成檔案再執行
速度會快很多 比起用檔案的方式 有很大的進步
相對的 如果是把執行檔解壓縮輸出成檔案再執行的加殼方式
Dependency Walker就只能偵測得到殼程式本身所需的DLLs
因為真正的程式是被殼執行的 不過只要在硬碟裡找出它解出來的檔案
就能對它分析 通常都在Temp資料夾裡

看了那個程式的PE 我大概了解他的方式
他並不是對整個程式進行壓縮
而是對於某些資料較大的部份進行壓縮
一個程式真正的程式碼產生的內容並不會太多
真正讓程式大的東西通常是夾在裡面的資料
而它UPX所壓出來的程式 就那兩個程式而言
程式碼部份是保留的 Export Table那些東西因此也存在
真正被壓縮的東西只有資料 所以Dependency Walker查到的東西應該錯不了
如果不信的話 你可以看得到D3D8.DLL 和下面有個DSOUND.DLL
又是何解?這兩樣是通常有用到3D的Game會用到
也就是DirectX的Runtime 如果不是DirectX就是OpenGL
如果說 連程式也被壓縮 那麼 Dependency Walker便無法查到這兩個DLL
故證 Dependency Walker查到的東西並沒錯
就算程式的部份也被壓縮了 換另一套抓得到動態的軟體
加多少殼也是一樣的
唯一令人有點懷疑的就是 MSVCRT可能是殼用的DLL反而不是那個程式本身

你之前那個的確程式有問題 把UPX誤判程VB
UPX令我意外的是 它壓縮的比例還蠻高的
但是 話說 如果是一般的程式 沒有大量的資料
加殼的確沒必要 如果說為了防破解 其實也只能多撐一下 防君子
你可以解開它 那就表示 網路上解開這種東西的工具多得是
加殼只是多廢苦心罷了 對於真正的強者
加再多殼也是多餘的
但是對資料量較大的執行檔 加殼如果可以減少容量
的確值得這樣做

不過每個殼所會去處理的結構不一樣, 有的真的只是簡單壓縮資料, 但是UPX他絕對可以加密組合語言的部份...
而且目前的包裝技術不是單存的接壓檔案到TEMP然後執行, 如果是醬就太簡單了...
目前的包裝技術是他會去壓縮組合語言的部份, 然後在執行的時候解壓縮然後在記憶體中重新堆疊, 不是簡單的解壓縮檔案...
舉個例好了...
我將有包裝跟沒包裝的同個檔案讀出組合語言, 你會發現兩個檔案同個記憶體位置的東西不一樣了, 左邊包裝過的讀出來幾乎是無意義的資料, 右邊可以清楚看出組合語言的每個清晰的指令, 如PUSH, CALL, MOV...
http://www.pczone.com.tw/upload/001/od.JPG

據我的經驗, VC++Compiler出來的檔案會比其他公司的大很多, 如Borland C++ Builder, GCC, bloodshed...
網路上大家的討論是, VC++包的時候也會將很多需要的dll包進去, 但我也不保證是這樣, 因為畢竟是網路上大家的討論, 微軟也不公佈包裝手法...

Windows下作業係統的執行檔格式是公開的
http://cpatch.org/siva/document/pe/PE.htm
或是你可以在搜尋引擎找到PE的相關資料
要使用DLL 不外乎兩種方法
一是使用Inport Table(之前寫Export Table是弄錯了)
一是使用LoadLibrary載入
VC++所引用DLL的方式 也不外乎這兩種
前者包函在PE結構裡 而且PE的結構是公開的 這就是為何網路上的軟體 可以輕易分析執行檔用了那些DLL
裡面哪有哪些資源等等
而就算是使用LoadLibrary載入 也只要對原來的LoadLibrary做手腳
讓它指向自己的LoadLibrary就可以知道它載了哪些DLL

只要對PE和組語有一定的了解 要寫出加殼程式不難
單單把code解到記憶體裡 然後跳到該記憶體開頭
以執行 似乎可行的樣子 但是還有些問題
記憶體的定址可能就是問題之一
原本程式設計 裡面的位置指向的目的已經不是原來的位置
就需要做修正 不過 組語不是我的專長
這只是我的推測

另外一個將面臨的問題 會是
新的CPU有防止執行在於非執行區塊的Code
因為 有無數個漏洞 都是基於緩衝區溢滿所造成的
它對於沒有檢查長度的字串 給予超過長度的字串
然而 字串後面所接的 就是一些設計好的程式碼
程式就被導向這些設計好的程式碼然後執行它們
但是新的CPU不準許執行資料區塊裡的東西
所以對於新的CPU 加殼程式可能會無法作用

PE檔案我知道...
沒錯只要一些從新運算的語法, 就可以讓原始組合語言顯示出來...
你講的也很對, 我的確發現很多程式在新的LGA775上無法執行...
舉個例, TorrentSpy

這是一個網路上的團隊.各有分工
有接到案子就一起工作.其實也沒見過面.
主要的工作就是接一些產品簡介.
以前還收集了兩張cd他們的作品集.

裡面的文字.還很搞笑的說64k還沒塞滿.繼續說了一些廢話.
呵呵~