Python 編譯生成 pyc 僅僅為了提升載入速度,並不是為了防止破解,反編譯後和原來一模一樣。pyinstaller,py2exe,只是把 pyc 打個包,同樣很弱。代碼混淆也只能增加看懂代碼的難度,但並不能防止破解。所以最為穩妥的辦法只有修改Python解釋器,對源代碼進行加密,解釋器載入源代碼時再解密,這種方法雖然可以防止破解,但給自己帶來麻煩不說,發布程序是需要打包自己修改後的解釋器,相當麻煩。
㈡ 如何防止程序員反編譯
java從誕生以來,其基因就是開放精神,也正因此,其可以得到廣泛愛好者的支持和奉獻,最終很快發展壯大,以至於有今天之風光!但隨著java的應用領域越來越廣,特別是一些功能要發布到終端用戶手中(如android開發的app),有時候,公司為了商業技術的保密考慮,不希望這裡面的一些核心代碼能夠被人破解(破解之後,甚至可以被簡單改改就發布出去,說嚴重點,就可能會擾亂公司的正常軟體的市場行為),這時候就要求這些java代碼不能夠被反編譯。
這里要先說一下反編譯的現象。因為java一直秉持著開放共享的理念,所以大家也都知道,我們一般共享一個自己寫的jar包時,同時會共享一個對應的source包。但這些依然與反編譯沒有什麼關系,但java的共享理念,不只是建議我們這樣做,而且它自己也在底層上「強迫」我們這么做!在java寫的.java文件後,使用javac編譯成class文件,在編譯的過程,不像C/C++或C#那樣編譯時進行加密或混淆,它是直接對其進行符號化、標記化的編譯處理,於是,也產生了一個逆向工程的問題:可以根據class文件反向解析成原來的java文件!這就是反編譯的由來。
但很多時候,有些公司出於如上述的原因考慮時,真的不希望自己寫的代碼被別人反編譯,尤其是那些收費的app或桌面軟體(甚至還有一些j2ee的wen項目)!這時候,防止反編譯就成了必然!但前面也說過了,因為開放理念的原因,class是可以被反編譯的,那現在有這樣的需求之後,有哪些方式可以做到防止反編譯呢?經過研究java源代碼並進行了一些技術實現(結果發現,以前都有人想到過,所以在對應章節的時候,我會貼出一些寫得比較細的文章,而我就簡單闡述一下,也算偷個懶吧),我總共整理出以下這幾種方式:
代碼混淆
這種方式的做法正如其名,是把代碼打亂,並摻入一些隨機或特殊的字元,讓代碼的可讀性大大降低,「曲線救國」似的達到所謂的加密。其實,其本質就是打亂代碼的順序、將各類符號(如類名、方法名、屬性名)進行隨機或亂命名,使其無意義,讓人讀代碼時很累,進而讓人乍一看,以為這些代碼是加過密的!
由其實現方式上可知,其實現原理只是擾亂正常的代碼可讀性,並不是真正的加密,如果一個人的耐心很好,依然可以理出整個程序在做什麼,更何況,一個應用中,其核心代碼才是人們想去了解的,所以大大縮小了代碼閱讀的范圍!
當然,這種方式的存在,而且還比較流行,其原因在於,基本能防範一些技術人員進行反編譯(比如說我,讓我破解一個混淆的代碼,我寧願自己重寫一個了)!而且其實現較為簡單,對項目的代碼又無開發上的侵入性。目前業界也有較多這類工具,有商用的,也有免費的,目前比較流行的免費的是:proguard(我現象臨時用的就是這個)。
上面說了,這種方式其實並不是真正加密代碼,其實代碼還是能夠被人反編譯(有人可能說,使用proguard中的optimize選項,可以從位元組流層面更改代碼,甚至可以讓JD這些反編譯軟體可以無法得到內容。說得有點道理,但有兩個問題:1、使用optimize對JDK及環境要求較高,容易造成混淆後的代碼無法正常運行;2、這種方式其實還是混淆,JD反編譯有點問題,可以有更強悍的工具,矛盾哲學在哪兒都是存在的^_^)。那如何能做到我的class代碼無法被人反編譯呢?那就需要我們下面的「加密class」!
加密class
在說加密class之前,我們要先了解一些java的基本概念,如:ClassLoader。做java的人已經或者以後會知道,java程序的運行,是類中的邏輯在JVM中運行,而類又是怎麼載入到JVM中的呢(JVM內幕之類的,不在本文中闡述,所以點到為止)?答案是:ClassLoader。JVM在啟動時是如何初始化整個環境的,有哪些ClassLoader及作用是什麼,大家可以自己問度娘,也不在本文中討論。
讓我們從最常見的代碼開始,揭開一下ClassLoader的一點點面紗!看下面的代碼:
Java代碼
publicclassDemo{
publicstaticvoidmain(String[]args){
System.out.println(「helloworld!」);
}
}
上面這段代碼,大家都認識。但我要問的是:如果我們使用javac對其進行編譯,然後使用java使其運行(為什麼不在Eclipse中使用Runas功能呢?因為Eclipse幫我們封閉,從而簡化了太多東西,使我們忽略了太多的底層細節,只有從原始的操作上,我們才能看到本質),那麼,它是怎麼載入到JVM中的?答案是:通過AppClassLoader載入的(相關知識點可以參考:http://hxraid.iteye.com/blog/747625)!如果不相信的話,可以輸出一下System.out.println(Thread.currentThrea().getContextLoader());看看。
那又有一個新的問題產生了:ClassLoader又是怎樣載入class的呢?其實,AppClassLoader繼承自java.lang.ClassLoader類,所以,基本操作都在這個類裡面,讓我們直接看下面這段核心代碼吧:
看到這里,已經沒有必要再往下面看了(再往下就是native方法了,這是一個重大伏筆哦),我們要做的手腳就在這里!
手腳怎麼做呢?很簡單,上面的代碼邏輯告訴我們,ClassLoader只是拿到class文件中的內容byte[],然後交給JVM初始化!於是我們的邏輯就簡單了:只要在交給JVM時是正確的class文件就行了,在這之前是什麼樣子無所謂!所以,我們的加密的整個邏輯就是:
在編譯代碼時(如使用ant或maven),使用插件將代碼進行加密(加密方式自己選),將class文件裡面的內容讀取成byte[],然後進行加密後再寫回到class文件(這時候class文件裡面的內容不是標準的class,無法被反編譯了)
在啟動項目代碼時,指定使用我們自定義的ClassLoader就行了,而自定義的部分,主要就是在這里做解密工作!
如此,搞定!以上的做法比較完整的闡述,可以仔細閱讀一下這篇文章:https://www.ddtsoft.com/#developerworks/cn/java/l-secureclass/文章中的介紹。
通過這個方法貌似可以解決代碼反編譯的問題了!錯!這里有一個巨大的坑!因為我們自定義的ClassLoader是不能加密的,要不然JVM不認識,就全歇菜了!如果我來反編譯,呵呵,我只要反編譯一下這個自定義的ClassLoader,然後把裡面解密後的內容寫到指定的文件中保存下來,再把這個加了邏輯的自定義ClassLoader放回去運行,你猜結果會怎樣?沒錯,你會想死!因為你好不容易想出來的加密演算法,結果人家根本不需要破解,直接就繞過去了!
現在,讓我們總結一下這個方法的優缺點:實現方式簡單有效,同時對代碼幾乎沒有侵入性,不影響正常開發與發布。缺點也很明顯,就是很容易被人破解!
當然啦,關於缺點問題,你也可以這么干:先對所有代碼進行混淆、再進行加密,保證:1、不容易找到我們自定義的那個ClassLoader;2、就算找到了,破解了,代碼可讀性還是很差,讓你看得吐血!(有一篇文章,我覺得寫得不錯,大家可以看一看:http://www.scjgcj.com/#blog/851544)
嗯,我覺得這個方法很好,我自己也差點被這個想法感動了,但是,作為一個嚴謹的程序員,我真的不願意留下一個隱患在這里!所以,我繼續思索!
高級加密class
前面我們說過有個伏筆來著,還記得吧?沒錯,就是那個native!native定義的方法是什麼方法?就是我們傳說中的JNI調用!前面介紹過的有一篇文章中提到過,其實jvm的真實身份並不是java,而是c++寫的jvm.dll(windows版本下),java與dll文件的調用就是通過JNI實現的!於是,我們就可以這樣想:JNI可以調用第三方語言的類庫,那麼,我們可不可以把解密與裝載使用第三方語言寫(如C++,因為它們生成的庫是不好反編譯的),這樣它可以把解密出來的class內容直接調jvm.dll的載入介面進行初始化成class,再返回給我們的ClassLoader?這樣,我們自定義的ClassLoader只要使用JNI調用這個第三方語言寫的組件,整個解密過程,都在黑盒中進行,別人就無從破解了!
嗯,這個方法真的很不錯的!但也有兩個小問題:1.使用第三方語言寫,得會第三方語言,我說的會,是指很溜!2.對於不同的操作系統,甚至同一操作系統不同的版本,都可能要有差異化的代碼生成對應環境下的組件(如window下是exe,linux是so等)!如果你不在乎這兩個問題,我覺得,這個方式真的挺不錯的。但對於我來說,我的信條是,越復雜的方式越容易出錯!我個人比較崇尚簡潔的美,所以,這個方法我不會輕易使用!
對了,如果大家覺得這個方法還算可行的話,可以推薦一個我無意中看到的東西給大家看看(我都沒有用過的):jinstall,
更改JVM
看到這個標題,我想你可能會震驚。是的,你沒看錯,做為一個程序員,是應該要具有懷疑一切、敢想敢做的信念。如果你有意留心的話,你會發現JVM版本在業界其實也有好幾個版本的,如:Sun公司的、IBM的、Apache的、Google的……
所以,不要阻礙自己的想像力,現在沒有這個能力,並不代表不可能。所以,我想到,如果我把jvm改了,在裡面對載入的類進行解密,那不就可以了嗎?我在設計構思過程中,突然發現:人老了就是容易糊塗!前面使用第三方語言實現解密的兩個問題,正好也是更改JVM要面對的兩個問題,而且還有一個更大的問題:這個JVM就得跟著這個項目到處走啊!
㈢ 如何對編譯的dll文件進行加密來防止反編譯
為防止這類反向工程的威脅,最有效的辦法是模糊。
模糊工具運用各種手段達到這一目標,但主要的途徑是讓變數名字不再具有指示其作用的能力、加密字元串和文字、插入各種欺騙指令使反編譯得到的代碼不可再編譯。
例子:
對未經模糊處理的代碼執行反向工程:
Private
Sub
CalcPayroll(ByVal
employeeGroup
As
SpecialList)
While
employeeGroup.HasMore
employee
=
employeeGroup.GetNext(True)
employee.updateSalary
DistributeCheck(employee)
End
While
End
Sub
同樣的代碼,經過模糊處理再執行反向工程:
Private
Sub
a(ByVal
b
As
a)
While
b.a
a
=
b.a(True)
a.a
a(a)
End
While
End
Sub
顯然,兩段代碼的處理邏輯相同。但是,要說清楚第二段代碼到底在做些什麼極其困難,甚至要判斷它正在訪問哪些方法、哪些變數也很困難。
這種改變變數名稱的功能是可配置的,例如,假設正在構造一個DLL,可以要求不改動API,有趣的是,這一處理過程顯然只是簡單地把大量變數的名稱簡縮成單個字元,但獲得了非常好的模糊效果。
㈣ C#怎樣防止反編譯
我使用的方法是利用加殼工具:virboxProtectorStandalone。直接進行加殼。高級混淆、虛擬化代碼、智能壓縮等加密策略。如果要授權控制,可使用許可版本的virboxProtector。
未經加殼保護的 ILspy 反編譯效果如下:
public int add(int a, int b){
return a + b;}public int div(int a, int b){
return a / b;}public int mul(int a, int b){
return a * b;}public int sub(int a, int b){
return a - b;}
解決方案:
深思自主研發了為 C# .net 語言做保護的外殼(Virbox Protector)。將C# .net 編譯成的執行程序(.exe),動態庫(.dll)直接拖入加殼工具即可完成保護操作,十分方便。並且在效果上已經完全看不到源碼中的邏輯。
加密後的效果
public int add(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16416u, 21, 16384u, 32u, 31516u, 5).Invoke(this, new object[]
{
this,
a,
b
});}
public int div(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16956u, 21, 16924u, 32u, 31516u, 2).Invoke(this, new object[]
{
this,
a,
b
});}
public int mul(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16776u, 21, 16744u, 32u, 31516u, 3).Invoke(this, new object[]
{
this,
a,
b
});}
public int sub(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16596u, 21, 16564u, 32u, 31516u, 4).Invoke(this, new object[]
{
this,
a,
b
});}
架構支持
IIS 服務架構的後台邏輯 DLL 文件
windows PC 應用程序 EXE 文件
windows PC 應用程序動態庫 DLL 文件
UG等第三方繪圖工具使用的 DLL 文件
Unity3d 編譯使用的 DLL 文件
㈤ perl如何避免反編譯
為了保護Perl源代碼,常用的有三種方法。
1.
使用Perl自帶的perlcc工具。這個工具有一個最大的弱點:它只能作用於一個perl文件。假如你和我一樣寫了十幾二十幾個perl包,主程序里倒是空空如也,估計要郁悶死。用也是可以用的,就是要把所有的源代碼到一個文件,取消所有的package定義,把原來不同package下面同名的函數改名,不同的package裡面的同名全局變數也要改名。然後
$perlcc -o hello hello.pl
得到可執行程序hello. Perlcc的原理是把perl程序轉換成C程序,然後用GNU
C編譯器編譯。它在Windows上也可以用,但需要額外安裝C編譯器,比如Intel C或者MS Microsoft Visual
C。由於perlcc把代碼先變C再變可執行程序,反編譯出來的源碼很難看懂,所以安全性很高。但是把所有的代碼寫一個文件,模塊也不能用了,這簡直是從地鐵時代回到烏蓬船時代,我想不會有人覺得舒服。何況這樣混雜後的代碼該如何維護升級和做版本控制呢,頭大。另外,perlcc有申明,不保證它編譯出來的東西能用(參見$perldoc
perlcc)。我沒遇到這個情況,而是遇到了perlcc直接就對我的程序編譯不通過,沒戲唱了。{2006.12.15更新:找到perl不能編譯我的程序的原因了:1.
只能用use 不能用require,模塊文件名的後綴都改成.pm, use後跟不帶後綴的文件名就可以。2.
所有的全局數組,必須用my, our,
或者local來定義,不可以用預設作用范圍。第二點其實應該是perlcc的一個bug了,因為關聯數組和簡單變數都沒有這個問題。}
2. perl2exe,據說很好用,但令人沮喪的是要license, 而且據說跨平台還有問題。
3. PAR(Perl Archive Toolkit)。這個命名法則是類似於JAR(Java
Archive)。下載下來以後還要從CPAN上下載一些依賴性模塊。CPAN模塊果然好裝,每個模塊都是
$perl Makefile.PL
$make
$make install
就能裝好。最後安裝PAR。裝好以後會在/usr/bin/下面添加一些工具。我不關心別的,就要用pp:
$pp -o hello hello.pl
這樣生成的hello就是可執行文件,而且把用到的perl模塊文件也全打包進來了。運行的時候它會在/tmp/par-username/下生成一個叫
cache-123456789之類的臨時文件夾,打開看看可以發現就是自己的源代碼。這樣不是沒達到我想要的隱藏源代碼的目的么?原來還需要啟動過濾器:
$pp -f Bleach -o hello hello.pl
或者
$pp -f Bytecode -o hello hello.pl
前面的Bleach過濾器是PAR自己實現的,而Bytecode這種過濾方式是Perl的標准格式(需要Perl
5.8.1以上版本支持)。過濾之後,臨時文件夾裡面的文件就不是簡單可讀了。當然是有辦法crack,
但這和恢復帶初始變數名的源代碼是兩回事。
㈥ 如何防止代碼被反編譯
針對代碼反編譯,推薦使用CBS賽博鎖,通過把安全容器內嵌到操作系統中,對容器內的應用和數據進行加鎖,程序和數據在容器內運行,實現最後一米數據安全,防止核心數據被泄露,防止伺服器終端中病毒,防止反編譯,反破解。
㈦ 如何防止代碼被反編譯
由於apk是Android虛擬機載入的,它有一定的規范,加密apk後Dalvik無法識別apk了。完全避免是不可能的,總有人能夠破解你的代碼。但是有幾種方式來提高被反編譯取代碼的難度。
1 關鍵代碼使用jni調用本地代碼,用c或者c++編寫,因此相對比較難於反編譯
2 混淆java代碼。混淆是不改變代碼邏輯的情況下,增加無用代碼,或者重命名,使反編譯後的源代碼難於看懂。 網上開源的java代碼混淆工具較多,一般是用ant的方式來編譯的。
1 . 在工程文件project.properties中加入下proguard.config=proguard.cfg , 如下所示:
target=android-8
proguard.config=proguard.cfg
Eclipse會通過此配置在工程目錄生成proguard.cfg文件
2 . 生成keystore (如已有可直接利用)
按照下面的命令行 在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下,輸入keytool -genkey -alias android.keystore -keyalg RSA -validity 100000 -keystore android.keystore
參數意義:-validity主要是證書的有效期,寫100000天;空格,退格鍵 都算密碼。
命令執行後會在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下生成 android.keystore文件。
3. 在Eclipce的操作
File -> Export -> Export Android Application -> Select project -> Using the existing keystore , and input password -> select the destination APK file
經過混淆後的源代碼,原先的類名和方法名會被類似a,b,c。。。的字元所替換,混淆的原理其實也就是類名和方法名的映射。
但4大組件並沒有混淆(所有在清單文件定義的組件不能被混淆),因為系統需要通過清單文件來查找和運行應用程序。
proguard.cfg 文件代碼解讀
-optimizationpasses 5 ->設置混淆的壓縮比率 0 ~ 7
-dontusemixedcaseclassnames -> Aa aA
- ->如果應用程序引入的有jar包,並且想混淆jar包裡面的class
-dontpreverify
-verbose ->混淆後生產映射文件 map 類名->轉化後類名的映射
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/* ->混淆採用的演算法.
-keep public class * extends android.app.Activity ->所有activity的子類不要去混淆
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService
-keepclasseswithmembernames class * {
native <methods>; -> 所有native的方法不能去混淆.
}
-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet);
-->某些構造方法不能去混淆
}
-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet, int);
}
-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}
-keepclassmembers enum * { -> 枚舉類不能去混淆.
public static **[] values();
public static ** valueOf(java.lang.String);
}
-keep class * implements android.os.Parcelable { -> aidl文件不能去混淆.
public static final android.os.Parcelable$Creator *;
}
㈧ 怎麼防止Java開發出來的程序被別人反編譯
防止Java開發出來的程序被別人反編譯有很多種方法,下面給你介紹幾種:
1、隔離Java程序
最簡單的方法就是讓用戶不能夠訪問到Java Class程序,這種方法是最根本的方法,具體實現有多種方式。例如,開發人員可以將關鍵的Java Class放在伺服器端,客戶端通過訪問伺服器的相關介面來獲得服務,而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前,通過介面提供服務的標准和協議也越來越多,例如 HTTP、Web Service、RPC等。但是有很多應用都不適合這種保護方式,例如對於單機運行的程序就無法隔離Java程序。
2、對Class文件進行加密
為了防止Class文件被直接反編譯,許多開發人員將一些關鍵的Class文件進行加密,例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前,程序首先需要對這些類進行解密,而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成,也可以使用軟體完成。
3、轉換成本地代碼
將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼,也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊,Java程序在使用這些模塊時,需要使用JNI技術進行調用。
4、代碼混淆
代碼混淆是對Class文件進行重新組織和處理,使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯,即反編譯後得出的代碼是非常難懂、晦澀的,因此反編譯人員很難得出程序的真正語義。從理論上來說,黑客如果有足夠的時間,被混淆的代碼仍然可能被破解,甚至目前有些人正在研製反混淆的工具。但是從實際情況來看,由於混淆技術的多元化發展,混淆理論的成熟,經過混淆的Java代碼還是能夠很好地防止反編譯。
不同保護技術比較希望能給大家帶來參考:
㈨ Java 源代碼怎麼防止反編譯
保護Java程序的基本方法然後對代碼混淆問題進行深入研究,最後結合一個實際的應用程序,分析如何在實踐中保護Java程序。
反編譯成為保護Java程序的最大挑戰
通常C、C++等編程語言開發的程序都被編譯成目標代碼,這些目標代碼都是本機器的二進制可 執行代碼。通常所有的源文件被編譯、鏈接成一個可執行文件。在這些可執行文件中,編譯器刪除了程序中的變數名稱、方法名稱等信息,這些信息往往是由內存地 址表示,例如如果需要使用一個變數,往往是通過這個變數的地址來訪問的。因此,反編譯這些本地的目標代碼就是非常困難的。
㈩ 如何防止JAVA程序源代碼被反編譯
我們都知道JAVA是一種解析型語言,這就決定JAVA文件編譯後不是機器碼,而是一個位元組碼文件,也就是CLASS文件。而這樣的文件是存在規律的,經過反編譯工具是可以還原回來的。例如Decafe、FrontEnd,YingJAD和Jode等等軟體。下面是《Nokia中Short數組轉換演算法》
類中Main函數的ByteCode:0 ldc #162 invokestatic #185 astore_16 return其源代碼是:short [] pixels = parseImage("/ef1s.png");
我們通過反編譯工具是可以還原出以上源代碼的。而通過簡單的分析,我們也能自己寫出源代碼的。
第一行:ldc #16
ldc為虛擬機的指令,作用是:壓入常量池的項,形式如下ldc index這個index就是上面的16,也就是在常量池中的有效索引,當我們去看常量池的時候,我們就會找到index為16的值為String_info,裡面存了/ef1s.png.
所以這行的意思就是把/ef1s.pn作為一個String存在常量池中,其有效索引為16。
第二行:2 invokestatic #18
invokestatic為虛擬機指令,作用是:調用類(static)方法,形式如下
invokestatic indexbyte1 indexbyte2
其中indexbyte1和indexbyte2必須是在常量池中的有效索引,而是指向的類型必須有Methodref標記,對類名,方法名和方法的描述符的引用。
所以當我們看常量池中索引為18的地方,我們就會得到以下信息:
Class Name : cp_info#1
Name Type : cp_info#19
1 和19都是常量池中的有效索引,值就是右邊<中的值,再往下跟蹤我就不多說了,有興趣的朋友可以去JAVA虛擬機規范。
這里我簡單介紹一下parseImage(Ljava/lang/String;)[S 的意思。
這就是parseImage這個函數的運行,我們反過來看看parseImage的原型就明白了
short [] parseImage(String)
那麼Ljava/lang/String;就是說需要傳入一個String對象,而為什麼前面要有一個L呢,這是JAVA虛擬機用來表示這是一個Object。如果是基本類型,這里就不需要有L了。然後返回為short的一維數組,也就是對應的[S。是不是很有意思,S對應著Short類型,而「[」對應一維數組,那有些朋友要問了,兩維呢,那就「[[」,呵呵,是不是很有意思。
好了,調用了函數,返回的值要保存下來吧。那麼就是第三行要做的事情了。