A Gray Box for Visualizing Instruction Sequence Based on Improved Suffix Tree

Gray box is a kind of device in which the working process of a program or system is locally recognized. Gray box testing, also known as gray box analysis, is a software debugging method based on the limited cognition of the internal details of the program. Testers may know how system components interact with each other, but they lack a detailed understanding of internal program functions and operation. So the construction of gray box is particularly important. The most original gray boxes are static debugger and dynamic debugger. And then reflexion model, which reduces the manual work greatly, is developed and applied. The latest gray boxes are focus on regarding instructions as a natural language using the mature mathematical model to mine their internal value. Adhering to the idea of latest researches, our paper improves the original suffix tree and use the improved suffix tree as a mathematical models to analyse and visualize the internal logic of instructions. Our gray box aims at solving three problems in practical application. In addition, we explain the complexity of instruction sequence and put forward a prediction formula for the building part. By experiment, we prove the time complexity of each part and the correctness of the prediction formula, and show the effect of visualizing part.


I. INTRODUCTION
Gray box testing [1] is between white box testing and black box testing [2], which not only pays attention to the correctness of output and input, but also focuses on the internal situation of the program. Gray box testing is not as detailed and complete as white box testing, but it pays more attention to the internal logic of the program than black box testing. Nowadays, the program size is bigger and bigger, and the encryption method is more and more complex. Therefore, there are few opportunities to use white box testing in practice, and the effect of black box testing is often not up to standard. The improvement of gray box testing technology will greatly improve the security quality of programs before officially released.
Although gray box testing is very advanced, there are three problems in practical application.
The associate editor coordinating the review of this manuscript and approving it for publication was Tu Ngoc Nguyen . 1) How to collect the source instructions when facing the compression encryption? The compression encryption [3] is different from obfuscated code [4] essentially. The obfuscated code blocks the normal understanding by disturbing instructions' logic [5], however, we still can get the encrypted source code whether by static analysis or dynamic analysis. But when facing the compression encryption such as UPX [6], the static analysis loses effect immediately, and the dynamic analysis can be stopped by anti debug techniques such as timeout detection [7] or attached detection [8]. So it is necessary to innovate a new method to collect the source instruction effectively. 2) How to compress the source instructions into a suitable volume for the chosen model? For example, if a researcher wants to use N-grams model to analyse the instructions, he has to map the instructions into the form of vector domain description [9]. But if the chosen model need O(n 2 ) or more time complexity to build or traverse such as suffix tree [10], mere mapping will be not enough for the high-volume instructions, because the process will cost too much time. So it is necessary to compress the source instructions into suitable volume without losing the key information. 3) How to reuse the built model quickly and mine the hierarchical inclusion relationship? For example, a researcher can use DFS or BFS to traverse one built suffix tree many times for different aims [11]. That does reuse the model but costs too much time, because each DFS or BFS needs O(n 2 ) time complexity. And such traverse results are lack of hierarchical inclusion relationship [12], because how many times traversing are needed and where once traversing finishes in are both unknown until the traversing does finish. In other words, if we want to get the hierarchical inclusion relationship among two or more parts of instructions like the red-bordered ones in figure 1 and figure 2, by the traditional suffix tree, we have to do n times O(n 2 )time-complexityed traversing, that is, the total process for hierarchical inclusion relationship needs O(n 3 ) time complexity. So it is necessary to find a suitable model and invent a low-time-complexityed traversing algorithm.  There have been lots of related works aiming to solve these three problems. And by comparing with the related works, we explain the innovative points and the corresponding improvement effect of our paper: 1) For collecting the source instruction when facing the compression encryption. The most traditional way, which is still used currently, uses static analysis or dynamic analysis to crake the compression encryption [13], although it consumes a lot of human labor. The latest way can be summed as ''ignoring the encryption completely, using dynamic analysis or dump [14] to record the running instructions simply, mining the instruction's inner logic by mathematical way after all the recording is finished''. The latest way reduces human labor greatly and makes the whole process finish within predictable time.
Our research inherits the idea of the latest way, but makes innovations in setting breakpoints. Most of the existing researches are attaching and recording the instructions from OEP [15], which records lots of irrelevant contents. In order to make the recorded instructions closer to the theme, we propose a method which searches the aim information's memory addresses, sets Dr0 register (8 bits) [16] into the first-searched address's value, and sets Dr7 into 0 × 30101. When the first STATUS_SINGLE_STEP exception is triggered, repeat to set the TF flag [16] into 1 and record the instructions like what the dynamic analysis does. Compared with the latest way which records instruction from OEP, our debugger can record instruction more purposefully and avoid timeout detection [7] effectively. 2) For compressing the source instructions into a suitable volume for the chosen model. Basicly, the instruction compression here must satisfy that the compression result can be analysed by the corresponding model without decompression. So it is different from the common compression algorithm [17], [18] used in our daily life. And we can find many related works satisfying this point [19], [20]. The innovation of our research is that we compress not only the instructions but also their corresponding running addresses. Only both-the-samed recordings can be compressed into thesame-coloured structure object like figure 3 showing. And we use three kinds of pointers to save different relationships between each recording. Compared with the related works, our algorithm transforms the basic unit from ''char'' to ''sentence'' by compressing. Concretely speaking, we compress 100 chars into a structure object which contains all the key values of the corresponding sentence. This compression will make ten thousand times speed improvement for the latter building process of suffix tree. For example, in our experiment, our algorithm can finish building process of 290809 instructions in 213000 ticks (nearly 213 seconds). If we use the ''char'' as the basic unit, it will cost about 591 hours (24 days), so the speed improvement caused by compressing is obvious. 3) For reusing the built model quickly and mine the hierarchical inclusion relationship. The current works surely have noticed the large potential value of this research. For example, Rainer Koschke's research demonstrates how suffix tree can be used to obtain a scalable comparison in a faster way [21]. And Kai Huang's team develops an intelligent instruction sequence based malware categorization system (ISMCS) using a novel weighted subspace clustering method [22]. The most obvious feature of current works is reusing and mining through mathematical calculation, which do improve model utilization effectively and calculate out some hierarchical indexes for the instructions, but the calculation results are not able to be expanded any more. In other words, the researches still have to do lots of redundant calculations for getting the hierarchical inclusion relationship like figure 2 shown. The innovation of our research is that we put forward an ''improved suffix tree'' on the base of traditional suffix tree [10]. By the improved suffix tree, we can expand the hierarchical inclusion relationship among different parts of instructions by traversing the built tree not by mathematical calculation. And we can visualize the traversing result like the figure 1 and figure 2 showing. Compared with the traditional suffix tree, the improved suffix tree can finish traversing the visualizing both in the linear time complexity strictly. Our gray box is composed of collecting part, compressing part, improved suffix tree and visualizing part.The relationship among each part is like figure 4 shown: This paper is organized as follows. Section I introduces the background, existing problems, related works, our innovation points and corresponding improvement effects. Section II illustrates how our gray box collects the source instructions when facing the compression encryption. Section III illustrates how our gray box compresses the source instructions into a suitable volume. Section IV illustrates the similarities and differences between improved suffix tree and traditional suffix tree, discuss the constructing time consume for suffix tree, and give out a fast prediction formula for constructing time consume. Section V illustrates how gray box reuses the improved suffix tree quickly in order to mine the hierarchical inclusion relationship of the source instructions. Section VI summarizes the conclusions of this paper. Finally, the future works are on Section VII.

II. COLLECTING
This section aims at collecting the source instructions. By setting breakpoints innovatively, we realize a dynamic debugger which can record the target-specific assembly instructions and format them into a txt file. Three types of breakpoint called MBP, DRX and TF are used in this section.

A. DEFINITION
The definitions of related variables in collecting part are like table 1 shown: The pseudo code of collecting part is described in Algorithm 1:

1.Why must MBP be set before DRX?
The decision is based on practise. If we set DRX immediately after attaching, the debugged application may reset them by safeguard function before triggering, so that we can not accept exception at all. Compared with DRX, MBP can be hardly used in safeguard function, because determining every instruction in a memory-paged range costs too much time. That is also the reason why we do not just use ''MBP+TF''.
2.How many times is MBP set and triggered? Only the TIA[0] is set as MBP once time, and it is also just triggered once in loop 1, in which we set DRX at the same time. The triggering position between MBP and DRX can not be over one memory-paged rage, so the DRX can be hardly reset.
3.Why does collecting() just have two loops for three types of breakpoint?
Loop 1 is for MBP obviously. Because DRX and TF trigger the same exception, the loop 2 triggers once DRX first and sets 9-th flag bit into 1 at the same time. Except the first DRX, the rest of loop 2 triggers TF (WB-1) times simply or shuts down with the crash of debugged program. VOLUME 8, 2020 We chose a large-scale online game to test whether collecting() can effectively obtain the instruction set. The game program consists of two parts: the starting end (1.09 MB) and the client end (1.05 GB). When the game starts, the starting end decompresses the client end. We set the ASCII code of the game currency as TI. Then we attach our gray box to the game. When we do currency related operations in the game, our gray box can record the currency related instruction set directly. We set WB as one millon. When we do the different currency related operations, we can record TEXTs of different length from 2292 to 1000000.
The example of TEXT is like figure 5 shown:

D. COMPARISON
If we use the traditional way like IDA [23] to debug the game, just for the starting end (1.09 MB), 1863 functions can be resolved. To explore call relations among 1863 functions is like looking for a needle in a haystack. For the client end which is compressed into some unpublished format, IDA is unable to load the file into workspace. Compared with the latest way which dumps [14] or records the instructions from OEP [15], [24], our gray box can record instruction more purposefully and avoid timeout detection [7] effectively. If our gray box runs the game from OEP, before we do currency related operations, the game can detect itself is being debugged and kill itself. As a result we can't record currency related instruction set at all.

III. COMPRESSING
This section aims at reading TEXT into memory and mapping these context into a 3D LIST. The reason why the result is called 3D list is that every node in the list has 3 direction pointers: PRIGHT, PDOWN and PNEXT. The PRIGHT represents the first-lined, right adjacent and different kind relationship. The PDOWN represents the same column, down adjacent and the same kind relationship. The PNEXT represents the order adjacent relationship. And we denote the basic node structure of 3D LIST as NOOD.
The innovation of this block is rather than the traditional way of using a single character as the basic analysis unit, we compress and map the sentence into structure node as basic unit. Actually we formulate 100 characters as a sentence and map it into a node. There will be a great execution speed benefit facing the ''bad situation'', even promote ten thousand times.  By compressing the TEXT into 3D LIST, we not only realize the compression of memory space, but also realize the conversion of basic unit from ''char'' to ''sentence''. Lai Huoyao's team improved the UKK suffix tree and proposed the SBA suffix tree [25]. In their experiment, the basic unit is ''char'', and the capacity of experiment is 600000 characters. The time consume of their construction algorithm is like figure 7 shown: According to the figure 7, facing 600000 bytes, the time consume of SBA or UKK is between 11.700s-15.722s. When the basic unit is transformed into sentence through our gray box, the constructing time consume (building tick) of improved suffix tree is like table 3 shown: By the 10th data in table 3, we can see that 33133 × 100 bytes, which is nearly five times as much as Lai Huoyao's sample, only takes about 1.4s. The sample size is increased by 5 times and the time consume is reduced to one-tenth. And the constructing processes of UKK, SBA and our improved suffix tree have no structural change in nature. In other words, by compressing part transforms the basic unit from ''char'' to VOLUME 8, 2020 ''sentence'', we get a nearly 50 times acceleration facing 3M TEXT. As the sample size becomes bigger, the acceleration will be more obvious.

IV. IMPROVED SUFFIX TREE
In this section, we first introduce the two main differences between our improved suffix tree and the traditional UKK suffix tree [10]. Then discuss the constructing time consume of suffix tree. Finally, give out a fast prediction formula for constructing time consume.

A. DIFFERENCE
The algorithm architectures of UKK [10] and our improved suffix tree are nearly the same. The differences can be summed up into two points: first, we change the UKK's suffix link (pointer) into SUFFIX LINK (structure list). Second, our improved suffix tree keeps the necessary reverse relationships among each kind of structure.

1) SUFFIX LINK
In Ukkonen's paper [10], the illustration of string ''cacao'' is like figure 8 shown: Because of the suffix link, the constructing process UKK looks complicated. We replace suffix link (pointer) with SUF-FIX LINK (structure list), and save SUFFIX LINK till the end of gray box testing. We denote the SUFFIX structure as S(p,n,f,o,l). The p represents the pointer which precisely locals the compared position on the improved suffix tree. The n represents the pointer which makes SUFFIXs into a link. The f represents the flag which represents the state of S. The o represents the order of corresponding NODE in the 3D LIST. The l represents the length of corresponding common prefix.
By replacing suffix link with SUFFIX LINK, the illustration of string ''cacao'' shown by the improved suffix tree is like figure 9 shown: The replacement not only makes the algorithm clear, but also provides the foundation for the next section to reuse the improved suffix tree.

2) REVERSE RELATIONSHIP
Because the Ukkonen's suffix tree [10] is an one-way tree, it just can be traversed from root (top) to the leaves (bottom). There is no doubt that the UKK suffix tree has achieved remarkable success in substring inclusion relationship search [26] and palindrome detection [27], which just need linear time to finish traversing. But if we want to use the UKK suffix tree to get the hierarchical inclusion relationship like figure 2 shown, we at least need to do DFS or BFS, which exactly need quadratic time.
For getting the hierarchical inclusion relationship in linear time, we add two reverse relationship pointer. We denote the node of improved suffix tree as N(n,e,o). The n represents the pointer which points to N's parent node. The e represents the pointer which points to N's incoming edge. The o represents the information which has been defined in UKK suffix tree.

B. CONSTRUCTING TIME CONSUME
In the abstract of paper On-line construction of suffix trees [10], Ukkonen said ''Regardless of its quadratic worst case this latter algorithm can be a good practical method when the string is not too long''. Besides Ukkonen's paper, nearly all the researches related with suffix tree emphasize that they can finish constructing process by linear time in specific background [25]. But what is the constructing time consume for general situation? The constructing process using suffix link or SUFFIX LINK is the same essentially. So in the following paragraphs, the improved suffix tree's constructing time consume can be considered the same as traditional UKK suffix tree's.
we have denoted the basic unit of improved suffix tree's source data as NODE in section III. In Ukkonen's paper, the NODE saves the information of ''char''. For our gray box, the NODE saves the information of ''sentence''. And we define the new-keyworded NODEs as debut NODE, such as the '1:c', '2:a' and '5:o' in the string of ''cacao''. We define the NODEs which make more SUFFIXs' p point to the leaf of improved suffix tree as acceleration NODE, such as the '1:c', '2:a' and '5:o' in the string of ''cacao'' shown by figure 9.
Three conclusions are emphasized as following: Conclusion 1, debut NODE must be acceleration NODE, and debut NODE must make all the SUFFIX's p point to leaves at that time.
Conclusion 2, acceleration NODE can not be debut NODE, such as the '6:a'in the string of ''abcabax''. The a has been appear in '1:a' and '4:a' repeatedly, but when the '6:a' is added into improved suffix tree, the end position of the suffix which begin from '4:a' and '5:b' are linked to the leaf at that time. And the acceleration NODE doesn't ensure to make all the SUFFIXs' p point to leaves except the SUFFIX of itself, such as the '8:x' in the string of ''abcbxabxy''. When '8:x' is added, the suffix ''abx'' has never appeared before, but the suffix ''bx'' has appeared from '4:b'. So the suffix ''abx'' link to leaf, the suffix ''bx'' is still on the edge of improved suffix tree.
Conclusion 3, the SUFFIXs whose p have pointed to leaves must be added into the SUFFIX LINK earlier. Like figure 9 shown, the yellow SUFFIXs must be at the left side of the green ones.
Till now, we can divide the NODE link (source data) by the acceleration NODEs. Such as the string ''cacao'' can be divided into ''c a cao'', the string ''abcbxabxy'' can be divided into ''a b c bx abx y''. And we define some variables like table 4 shown:  We suppose that all the acceleration NODEs can make all the SUFFIXs points to leaves. Now the i-th group's total comparing time can be represented by (2).
So the total comparing time of constructing process can be calculated out by (3).
We use t to represent the total node number of NODE link and get (4) as the result.
Lower boundary: The n-dimensional Cauchy-inequality can be represented by (5).
When all a i are set to t i , and all b i are set to 1, we can get (6).
Then we plus t and divide by 2 at both sides of (7) and get (8): So the lower boundary of the constructing time consume is when n=t. In other words, all the NODEs' types are different from each other, such as the string of ''ABCDEF12345HIGK''. At that time, the lower boundary is t (or n).
Upper boundary: Because t is a constant value, so the upper boundary of (4) is depended on the (9)'s upper boundary.
Then we plus t and divide by 2 at both sides of (11) to get (12).
In reality situation, the value of t i (t j ) can be 0. And the most extreme situation (worst case) is that the NODE link only has two acceleration NODEs at the begin and end, such as ''AAAAAAAAAB''. The '1:A' and '10:B' are acceleration NODEs. And the most extreme situation can be generally regarded as: The t-lengthed NODE link is divided into 2 (n=2) parts, the first part's length t 1 is 1, and the second part's length t 2 is t-1. Put t 1 and t 2 into (12), we can get the upper boundary as (13).
Sum up: The constructing time consume can be represented by (4) approximately. The exact constructing time consume is more complex and bigger than (4). Because the acceleration NODE doesn't ensure to make all the SUFFIXs' p point to leaves except the SUFFIX of itself, such as the '8:x' in the string of ''abcbxabxy''. When '8:x' is added, the suffix ''abx'' link to leaf, the suffix ''bx'' is still on the edge of improved suffix tree,but the (4) regards ''bx'' links to leaf at the same time. So when the '9:y' is added, the (4) will miss to calculate ''bxy'', which makes the exact constructing time consume bigger than the (4).
The (4) is an n-dimensional problem, which is not suitable for human to understand. So we use the knowledge of inequality to reduce the n-dimensional problem into an one-dimensional problem. And finally the scale result is like (14) showing: According to table 3, we can draw the line chart between length and building tick as figure 10: The figure 10 illustrates that the constructing time consume is in a growth trend between O(n) and O(n 2 ).
And we can draw the line chart between length and building index as figure 11: The figure 11 illustrates that the constructing time consume of each basic unit is in a growth trend between O(n) and O(n 2 ) too. And in Prakash's paper [28], they got the similar line chart like figure 12 shown: In conclusion, the time complexity of the improved suffix tree's constructing process can not strictly maintain at O(n) level. It depends on the distribution of the acceleration NODEs mainly. And the final range is between O(n) and O(n 2 ).

C. FAST PREDICTION FORMULA
We have proved that the constructing time consume of the improved suffix tree is between O(n) and O(n 2 ), actually,  it is more closer to the O(n 2 ). By the previous experiment data in table 3, we know that 290809 sentences (28.0 MB) need 213048ms (nearly 3.5 minutes). As the source data becomes bigger, it is necessary to predict the time consume before constructing. If the prediction time is far beyond the time limit, we can stop constructing in time.
The prediction formula is on the basis of the (4) and like (15) shown: Let's explain the (15) in detail. First, we use debut NODE (T i ) to replace acceleration NODE (t i ) in (4). Because we can get all the positions of debut NODEs before constructing in a very short time.
Second, for compensating the error caused by the above replacing, we divide (4) by M which represents the ratio of exact construction time consume to the prediction value calculated by debut NODE. We can explain M more vividly with the help of figure 13: In figure 13, the red area represents the value calculated by debut NODE. The green area and blue area represent the value calculated by acceleration NODE. And the green, blue and yellow ares represent the exact constructing time consume. So the M can be regarded as the area ratio of red area to the sum of green, blue and yellow ares. Third, when calculate the (4), we regard each explicit situation and implicit situation as the same time unit as Ukkonen's paper [10] did. In fact, the average time use of once explicit situation is longer than that of implicit. And the average time use of once comparing is related with the hardware condition. So we use D to represent the two differences between exact constructing time consume and (4).
In experiment, the T represents the actual number of comparing. We can get D by dividing building tick with T. And we can get M by divide (4) with T. The actual measured values are like table 4 shown: According to table 5, we can see when the length is over 100000, the value of D is basically fixed near 3 × 10 −5 . And the maximum of M is just 4.203176136. Compared with 100000-lengthed source data, we can regard the value of D M as a constant represented by C. So the (15) can be transformed into (16).
According to our experiment situation, When we set C as 10 −5 , the relationship between prediction constructing time consume and actually recorded time consume is like figure 14 shown: According to figure 14, we can see that the difference between the predicted value and the accurate value is not more than twice. We can finish the prediction of 290809lengthed source data in 47959 ms just after compressing, which is far less than 213048 ms. Because the compressing process is linear time complexity and the constructing process is quadratic time complexity, when the source data becomes bigger, the effect of saving time will be more obvious.

V. REUSING AND VISUALIZING A. REUSING (TRAVELING)
In the IV.A, we illustrate two differences between improved suffix tree and traditional UKK suffix tree. Those two differences don't reduce constructing time consume, but change the traveling (reusing) time consume form quadratic time to linear time essentially.
For getting the hierarchical inclusion relationship like figure 2 shown, we need to finish three steps.
Step 1, find all the end position of suffixes on the improved suffix tree. such as for the string of ''cacao'', if we want to get all 5 suffixes end position on UKK suffix tree, once DFS or BFS is necessary, whose time complexity is O(n 2 ). In contrast, by improved suffix tree, we just need to do once linear-timed traversing on the SUFFIX LINK.
Step 2, find common prefixes for all suffixes. For UKK suffix tree, the DPS or BFS in the Step 1 can achieve this aim at the same time, whose time complexity is O(n 2 ). For improved suffix tree, on the basis of SUFFIX LINK and reverse relationship, we can get all the end position and length of common prefixes in O(n) time complexity totally like figure 16 shown: Step 3, combine the common prefixes to get COMBINE LINK. The common prefixes whose begin positions are continuous and end positions are the same can be combined into COMBINE structure. We denote the COMBINE structure as C(b,e,n,i,l). The b and e represent the begin and end positions of the substring respectively. The n represents the pointer to the neighbouring COMBINE structure. The i represents  identification of COMBINE which depends on the length and end position of the according substring. The l represents the length of the longest prefix.
To get COMBINE LINK, the UKK suffix need to do once DPS or BFS at least whose time complexity is O(n 2 ). For improved suffix tree, by traversing the SUFFIX LINK, we can ensure that the begin positions of common prefixes are continuous. After combine the SUFFIXs into COMBINEs, through a simple bubble sort, we can the COMBINEs whose l are the same into the same i. The process to get the COM-BINE LINK (blue part) of ''cacao'' is like figure 17 shown: We denote the variables of traversing as table 6: The general traversing process can be abstracted into algorithm 3: When we start to traverse an improved suffix tree, L is equal to 1, the PSB points to the next position of SUFFIX HEAD, PSE points to the end position of SUFFIX LINK. After traversing, we get sorted COMBINE LINK. At this moment, we can chose any COMBINE whose i appears in the COMBINE LINK more than once to expand its hierarchical relationship further. Now L is equal to 2, the PSB points to the chosen COMBINE's b, PSE points to the chosen COMBINE's e. We can do the above operations iteratively to  The 11th-15th data's traversing tick is 0 ms, the reason is that the traversing process is so fast and highest recordable accuracy is millisecond. And we make a chart line about length and traversing tick like figure 18 shown: According to figure 8, it is obvious that as the length becomes bigger, the traversing tick increases at the same time by a linear type. And in Huisheng Zhu's paper [29], they traversed the suffix tree by DFS, the relationship between length average running time is like figure 19 shown: It's obvious that the chart line in the figure 19 shows a trend of nonlinear growth. In contrast, on the basis of IV.A, our improved suffix tree can finish traversing by linear time.

B. VISUALIZING
In this subsection, we visualize the COMBINE LINK into 2D defrag picture like figure 1 shown, which then can be combined into 3D hierarchical inclusion relationship like figure 2 shown. The pseudo code of visualizing is like Algorithm 4 shown. The core idea of visualization is representing the i-equaled COMBINEs into same-coloured squares. And the diagonal direction represents the execution process of source code. The 3D hierarchical inclusion relationship is as the final result of our gray box to show the inner logic of source code.
We make an example for visualizing 290809 instruction into 3 lawyers.
When L=1, the PSB must points to the next node of COM-BINE HEAD, and the PSE must points to the last node of COMBINE LINK. The 2D defrag picture shows the 1-29089 instructions inner logic. The same-coloured squares in the 2D defrag picture represent the identical sub-instructions.
The 2D defrag picture of 1-290809 instructions is like figure 20 shown: By figure 20, we can immediately realize that the most obvious code block of 1-29089 instructions is like the purple square shown, and this code block executes twice continuously. The lower purple square represents the 45014-154164 instructions, and the upper purple square represents the 154402-263553 instructions.
Then we expand the 45014-154164 instructions. Now L=2, PSB points to the 45014th node on the SUFFIX LINK, PSE points to the 154164th node on the SUFFIX LINK. After traversing, we can get new COMBINE LIST, and visualize the COMBINE LIST by the 2D defrag picture like figure 21 shown: The 2D defrag picture of 45014-154164 instructions is like figure 21 shown: We can iterate the results of figure 21 to expand the lower blue block. Now L=3, PSB points to the 45014th node on the SUFFIX LINK, PSE points to the 78145th node on the SUFFIX LINK. The 3th-lawyered 2D defrag picture like figure 22 shown: Finally, we combine the figure 19, figure 20 and figure 21 into a 3D space. The final hierarchical inclusion relationship is like figure 23 shown: By the hierarchical inclusion relationship, our gray box can show the inner logic of source instructions vividly.
There have been lots of similar visualizing researches. In Fontana's paper [29], they developed a debugger to show   And the visualizing origin of Fontana's paper is like figure 25 shown: Fontana's research did visualize the JAVA program excellently, but like figure 25 shown, its visualization origin is based on advanced language code and call stack, which is suitable for white-box not gray-box. In contrast, our gray-box can get the similar visualizing effect just by assembly instructions.

VI. CONCLUSION
Through collecting, compressing, constructing (improved suffix tree), traversing (reusing) and visualizing, our gray box finally realizes to show the inner logic of on line game's currency-related instructions. And the gray-box can be used to visualize the 32-bit PE structure program in a short time generally.
The detailed conclusions of each part can be summarized as the following four points: 1.By II, we prove that the collecting part can record aimed instructions without the jam of compression encryption.
2.By III, we prove that the compressing part can bring obvious acceleration to the later constructing part.
3.By IV, with inequality technique, we prove the time consume range of construction process, and propose a fast prediction formula.
4.By V, we prove that the improved suffix tree can finish traversing (reusing) in linear time and achieve similar effect with white-box testing.

VII. FUTURE WORK
In the future, we plan to simulate the human brain activity by improved suffix tree, it will be Epoch-making.
What's the source of human brain's logic? The answer is human memory. We can imagine as the memorable things are saved into a suffix tree and the trifles are abandoned. In other words, the memory is interrupted but can be reformed into linear type. And suffix tree can transform the data from left to right in real time. So we can use suffix tree to record human memory.
The thing that traditional suffix tree can't reach is that the traversing of any data needs O(n 2 ) time complexity, as the amount of data becomes bigger and bigger with time going, The O(n 2 ) time complexity is absolutely unacceptable. In other words, the simulated human brain will be an idiot as the time goes by.
But with the help of Algorithm 3, we can get all-layered memory logic in a linear time, which make the simulated human brain can react quickly and human likely. That is what we will do in the future.