CN112257054A

Movatterモバイル変換

Info

Publication number: CN112257054A
Application number: CN202011140562.8A
Authority: CN
Inventors: 涂腾飞; 陈淼; 张华�; 王华伟; 李文敏; 高飞; 秦素娟; 温巧燕; 秦佳伟; 崔栋; 王森淼; 时亿杰; 赵春辉; 曾星宇
Original assignee: Beijing University of Posts and Telecommunications
Current assignee: Beijing University of Posts and Telecommunications
Priority date: 2020-10-22
Filing date: 2020-10-22
Publication date: 2021-01-22
Anticipated expiration: 2040-10-22
Also published as: CN112257054B

Abstract

Translated fromChinese

本说明书一个或多个实施例提供一种软件应用越权风险检测方法、电子设备及存储介质，能够对越权行为类的逻辑漏洞进行全面准确检测。所述方法包括：获取待检测软件程序的源代码并对其进行解析，确定权限验证相关代码与作用范围，生成权限‑范围映射表；根据所述权限‑范围映射表，对所述源代码进行权限验证逻辑插桩，生成插桩中间表示代码确定相应信息流图；利用所述信息流图进行越权风险路径检测，确定越权风险路径。所述电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行以实现所述越权风险检测方法的计算机程序。所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行所述软件应用越权风险检测方法。

One or more embodiments of the present specification provide a method, an electronic device, and a storage medium for detecting an unauthorized risk of a software application, which can comprehensively and accurately detect a logic vulnerability of an unauthorized behavior. The method includes: obtaining the source code of the software program to be detected and analyzing it, determining the authority verification related code and the scope of action, and generating a authority-scope mapping table; The authority verification logic is instrumented, and the instrumentation intermediate representation code is generated to determine the corresponding information flow diagram; the unauthorized risk path is detected by using the information flow diagram, and the unauthorized risk path is determined. The electronic device includes a memory, a processor, and a computer program stored on the memory and executable on the processor to implement the unauthorized risk detection method. The non-transitory computer-readable storage medium stores computer instructions for causing the computer to execute the software application unauthorized risk detection method.

Description

Software application unauthorized risk detection method, electronic equipment and storage medium

Technical Field

One or more embodiments of the present disclosure relate to the field of computer software security technologies, and in particular, to a software application unauthorized risk detection method, an electronic device, and a storage medium.

Background

With the continuous development of information systems and internet technologies, the functions of application programs are increased, the sizes of program source codes are larger and larger, and security holes which are easy to be utilized, code backdoors and logic errors in the codes are not limited to the past forms any more, so that the detection of the security holes in the source codes by using a traditional software testing method is very difficult, and the information security and the software security face unprecedented huge challenges.

The static analysis technology is one of the common source code defect detection technologies at present, and the method is mainly characterized in that program codes do not need to be actually operated when code bugs and logic errors are detected, manual intervention is not needed in the detection process, and potential software defects and security bugs can be found only by scanning all or part of the source codes of a project to be detected by a detection program. Compared with a dynamic analysis technology, the static analysis technology has the advantages of higher coverage rate, lower rate of missing report and the like.

The existing static analysis tool for the program source code has larger dependence on known bugs, focuses more on conventional code defects, such as bugs of information data leakage, dangerous API (application program interface) interfaces, password management and the like, and cannot well detect logic bugs of unauthorized behaviors; the program source code with a large scale often uses a third-party open source framework to realize certain business functions, a section-oriented programming (AOP) mode is adopted when the frameworks are used, and the existing static analysis method cannot effectively find the code switched into the business logic in the business logic, so that the logic loopholes existing in the corresponding codes cannot be found in time or the detection result has a high false negative rate.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure are directed to a method, an electronic device, and a storage medium for detecting an unauthorized risk of a software application, which can comprehensively and accurately detect a logic vulnerability of an unauthorized behavior class possibly existing in a software application.

In view of the above, one or more embodiments of the present specification provide a software application unauthorized risk detection method, including:

acquiring a source code of a software program to be detected, analyzing the source code, determining a permission verification related code and an action range, and correspondingly generating a permission-range mapping table;

performing authority verification logic instrumentation on the source code according to the authority-range mapping table to generate an instrumentation intermediate representation code;

determining an information flow diagram of the source code according to the instrumentation intermediate representation code;

and selecting a sensitive behavior node in the information flow graph, and performing unauthorized risk path detection by taking the sensitive behavior node as a starting point to determine an unauthorized risk path.

Optionally, the analyzing the source code, determining the authority verification-related code and the action range, and correspondingly generating the authority-range mapping table includes:

determining a security framework used by the source code;

according to the semantic rule of the safety framework, an analyzer is used for analyzing the configuration file and annotation information of the source code;

acquiring the authority verification related code and the corresponding action range according to the analysis result, wherein the authority verification related code comprises a package name, a class name, a method function name, a parameter list and a return value type where the authority verification code is located, and the action range refers to a specific package, a specific class, a specific method function and a specific statement corresponding to the authority verification related code;

and generating the authority-range mapping table according to the authority verification related code and the action range.

Optionally, the performing authority verification logic instrumentation on the source code according to the authority-range mapping table to generate an instrumentation intermediate representation code includes:

reading the authority-range mapping table, and determining a corresponding code position in the source code and carrying out code calibration according to the action range corresponding to the range field in the authority-range mapping table;

determining a permission field corresponding to the range field according to the permission-range mapping table, and determining a corresponding permission verification code according to the permission field;

and performing authority verification logic code instrumentation at the calibrated code position according to the authority verification code to generate the instrumented intermediate representation code.

Optionally, the determining a corresponding code position in the source code for code calibration includes:

searching a matched code object in the source code according to the action range;

if the code object is a specific package, calibrating a first statement in a method body of each method of each class in the package;

if the code object is a specific method function, calibrating a first statement of the method weight of the method function;

and if the code object is a specific statement, calibrating the statement.

Optionally, performing authority verification logic code instrumentation at the calibrated code position according to the authority verification code to generate the instrumented intermediate representation code, including:

determining a corresponding authority verification logic code according to the authority verification code;

traversing all calibration code positions in the source code, taking the action range corresponding to the calibration code positions as a key and taking the authority verification logic code corresponding to the calibration code positions as a value, and constructing a Map object;

and in the process of converting the source code into the intermediate code, inserting the authority verification logic code into the intermediate code according to the Map object to generate the instrumented intermediate representation code.

Optionally, the information flow graph includes a function call relationship graph, a control flow graph, and a data flow graph.

Optionally, the selecting a sensitive behavior node from the information flow graph, and performing unauthorized risk path detection with the sensitive behavior node as a starting point includes:

acquiring an unauthorized sensitive operation list, wherein the unauthorized sensitive operation list comprises a to-be-verified authority and unauthorized sensitive operations related to the to-be-verified authority;

comparing the sensitive operation with the information flow graph, and screening out a function or a statement corresponding to the sensitive operation from the information flow graph for node marking;

in the information flow graph, reverse traversal is carried out from a marking node, and whether an authority verification logic code exists in a reverse traversal path or not is judged;

if the authority verification logic code is not detected until the end point, an override risk exists in the reverse traversal path;

if the authority verification logic code exists, judging whether the authority verification logic code is matched with the authority to be verified corresponding to the marking node, if not, an override risk exists in a reverse traversal path from the marking node to the authority verification logic code.

Optionally, the determining an unauthorized risk path includes:

extracting the reverse traversal path with the unauthorized risk, and determining a risk intermediate code path according to the corresponding relation between the information flow graph and the instrumentation intermediate representation code;

and restoring and converting the risk intermediate code path into a corresponding path in the source code to obtain the unauthorized risk path, and outputting the unauthorized risk path.

In view of the above, one or more embodiments of the present specification provide an electronic device for software application unauthorized risk detection, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the following method:

In view of the above, one or more embodiments of the present specification provide a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform a method of software application override risk detection, the method comprising:

As can be seen from the foregoing, in one or more embodiments of the present disclosure, a software application unauthorized risk detection method, an electronic device, and a storage medium are provided, which take into account a security framework related to a software application, determine an authority verification related code and an action range thereof by analyzing a source code of the software application, and generate a corresponding authority-range mapping table; according to the authority-range mapping table, when the source code is analyzed to generate an intermediate representation form, authority verification logic instrumentation is carried out in the service logic of the source code, and the intermediate representation form is generated after the instrumentation; acquiring a related information flow diagram on the basis of the intermediate representation form; combining the information flow graph represented in the middle with an override behavior detection strategy to detect the override behavior of the system code logic; and acquiring a high-risk path of the unauthorized behavior and a detection result. The method avoids the false negative report of some potential unauthorized behaviors when the third-party framework is used, and simultaneously adopts a method of combining the authority verification logic and the business logic in a way of inserting piles based on intermediate codes, thereby realizing the detection of the unauthorized behavior risk on the basis of not damaging the original source codes, further ensuring the safety of application software and an information system at the source and fundamentally and realizing the comprehensive and accurate detection of the logic loopholes of the unauthorized behaviors which possibly exist.

Drawings

In order to more clearly illustrate one or more embodiments or prior art solutions of the present specification, the drawings that are needed in the description of the embodiments or prior art will be briefly described below, and it is obvious that the drawings in the following description are only one or more embodiments of the present specification, and that other drawings may be obtained by those skilled in the art without inventive effort from these drawings.

FIG. 1 is a schematic diagram of a software application unauthorized risk detection method according to one or more embodiments of the present disclosure;

FIG. 2 is a diagram illustrating a method for generating a privilege-scope mapping table in a software application unauthorized risk detection method according to one or more embodiments of the present disclosure;

FIG. 3 is a method intent for generating instrumented intermediate representation code in a software application override risk detection method provided in one or more embodiments of the present description;

fig. 4 is a schematic structural diagram of an electronic device for detecting unauthorized risk of a software application according to one or more embodiments of the present disclosure.

Detailed Description

For the purpose of promoting a better understanding of the objects, aspects and advantages of the present disclosure, reference is made to the following detailed description taken in conjunction with the accompanying drawings.

It is to be noted that unless otherwise defined, technical or scientific terms used in one or more embodiments of the present specification should have the ordinary meaning as understood by those of ordinary skill in the art to which this disclosure belongs. The use of "first," "second," and similar terms in one or more embodiments of the specification is not intended to indicate any order, quantity, or importance, but rather is used to distinguish one element from another. The word "comprising" or "comprises", and the like, means that the element or item listed before the word covers the element or item listed after the word and its equivalents, but does not exclude other elements or items. The terms "connected" or "coupled" and the like are not restricted to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "upper", "lower", "left", "right", and the like are used merely to indicate relative positional relationships, and when the absolute position of the object being described is changed, the relative positional relationships may also be changed accordingly.

In one aspect, embodiments of the present specification provide a software application unauthorized risk detection method.

As shown in fig. 1, one or more alternative embodiments of the present specification provide a software application unauthorized risk detection method, including:

s1: acquiring a source code of a software program to be detected, analyzing the source code, determining a permission verification related code and an action range, and correspondingly generating a permission-range mapping table;

some optional methods for obtaining the source code of the software program to be detected upload the compressed package of the source code of the software project to be detected by a user, and automatically pull the source code of the project by designating the code storage position, such as the Github address and the Gitlab address, by the user.

S2: performing authority verification logic instrumentation on the source code according to the authority-range mapping table to generate an instrumentation intermediate representation code;

s3: determining an information flow diagram of the source code according to the instrumentation intermediate representation code;

s4: and selecting a sensitive behavior node in the information flow graph, and performing unauthorized risk path detection by taking the sensitive behavior node as a starting point to determine an unauthorized risk path.

The software application unauthorized risk detection method comprises the steps of analyzing a source code of a software application to determine an authority verification related code and an action range thereof and generating a corresponding authority-range mapping table; according to the authority-range mapping table, when the source code is analyzed to generate an intermediate representation form, authority verification logic pile insertion is carried out in the service logic of the source code, and the intermediate representation form is generated after pile insertion; acquiring a related information flow diagram on the basis of the intermediate representation form; combining the information flow graph represented in the middle with an override behavior detection strategy to detect the override behavior of the system code logic; and acquiring a high-risk path of the unauthorized behavior and a detection result. The method avoids the false negative report of some potential unauthorized behaviors when the third-party framework is used, and simultaneously adopts a method of combining the authority verification logic and the business logic in a way of inserting piles based on intermediate codes, thereby realizing the detection of the unauthorized behavior risk on the basis of not damaging the original source codes, further ensuring the safety of application software and an information system at the source and fundamentally and realizing the comprehensive and accurate detection of the logic loopholes of the unauthorized behaviors which possibly exist.

As shown in fig. 2, in a software application unauthorized risk detection method provided in one or more alternative embodiments of this specification, the parsing the source code, determining the code related to the authority verification and the scope of action, and correspondingly generating the authority-scope mapping table includes:

s201: determining a security framework used by the source code;

s202: according to the semantic rule of the safety framework, an analyzer is used for analyzing the configuration file and annotation information of the source code;

s203: acquiring the authority verification related code and the corresponding action range according to the analysis result, wherein the authority verification related code comprises a package name, a class name, a method function name, a parameter list and a return value type where the authority verification code is located, and the action range refers to a specific package, a specific class, a specific method function and a specific statement corresponding to the authority verification related code;

s204: and generating the authority-range mapping table according to the authority verification related code and the action range.

In the software application unauthorized risk detection method, the used security framework can be determined according to the configuration file of the source code. For example, Java language is widely used in Web application systems and Android platforms for mobile applications of mobile phones, and using Java language programming application software as an example, a used security framework, such as a third-party open source framework like Springsecurity, Shiro, etc., can be automatically identified according to a configuration file of the source code of a Java software project to be tested. Configuration files such as XML and related annotations can be analyzed according to a built-in analyzer of the detection system or a user-defined analyzer of the detection system and the grammar of the corresponding safety detection framework, and related information is extracted, so that the authority verification related codes and the corresponding action range are determined. And then combining the related codes of the authority verification and the acted range to generate an authority-range mapping table, wherein the related codes of the authority verification comprise a package name, a class name, a method function, a parameter list and a return value type of the authority verification code, and the acted range comprises a specific package, a specific class, a specific method function and a specific statement.

As shown in fig. 3, in a software application unauthorized risk detection method provided in one or more alternative embodiments of this specification, the performing, according to the authority-range mapping table, authority verification logical instrumentation on the source code to generate instrumentation intermediate representation code includes:

s301: reading the authority-range mapping table, and determining a corresponding code position in the source code and carrying out code calibration according to the action range corresponding to the range field in the authority-range mapping table;

in some alternative embodiment modes, a permission-range mapping table is read first, where a permission field represents a related code for permission verification, a range field represents a range in which the permission code acts, the above acting range corresponding to the permission code is obtained according to a value of the range field, and the range in which the permission code acts includes a specific packet, a specific class, a specific method function, and a specific statement, and the determined acting range may be stored in a List type. And then scanning the source code position of the Java item matched with the scope of the action of the authority code, and calibrating the code.

S302: determining a permission field corresponding to the range field according to the permission-range mapping table, and determining a corresponding permission verification code according to the permission field;

s303: and performing authority verification logic code instrumentation at the calibrated code position according to the authority verification code to generate the instrumented intermediate representation code.

And acquiring the authority verification code corresponding to the authority-mapping table according to the range value corresponding to the specific position of the calibrated code, performing instrumentation operation on the authority verification code at the position of the calibrated code of the project program to be tested through a writing program, inserting the authority verification logic code corresponding to the authority verification code, and generating the instrumented intermediate representation code.

In one or more alternative embodiments of the present specification, in a software application unauthorized risk detection method, determining a corresponding code position in the source code for code calibration includes:

and if the code object is a specific statement, calibrating the statement.

And performing authority verification logic code instrumentation at the calibrated code position, namely performing authority verification logic code instrumentation operation before the calibrated statement.

In one or more alternative embodiments of the present specification, in a software application unauthorized risk detection method, the performing, according to the permission verification code, permission verification logic code instrumentation at a calibrated code position to generate the instrumented intermediate representation code includes:

In the software application unauthorized risk detection method, authority verification logic code instrumentation is carried out at the position of a calibration code of a source code, the integrity and the originality of the source code are not changed, and therefore, errors caused by the reasons of the integrity and the originality can be avoided when an information flow graph is generated according to the intermediate representation code of the instrumentation.

In one or more alternative embodiments of the present specification, a software application unauthorized risk detection method is provided, where the information flow graph includes a function call relation graph, a control flow graph, and a data flow graph. The function call graph, the data flow graph, the control flow graph and other information flow graphs all contain permission verification logic implanted after instrumentation and are generated based on intermediate representation.

In one or more optional embodiments of the present specification, in a software application unauthorized risk detection method, selecting a sensitive behavior node from an information flow graph, and performing unauthorized risk path detection using the sensitive behavior node as a starting point includes:

the unauthorized sensitive operation list can be set by pre-extraction or manual setting, and is mainly used for reflecting different possible unauthorized behaviors and sensitive operation information corresponding to the unauthorized behaviors.

here, a regular matching mode may be used to determine whether a related function or statement of the override sensitive operation exists in an information flow graph and a position of the related function or statement of the override sensitive operation, and if so, a related node position is obtained and marked; and then, the next item of the unauthorized sensitive operation list needing to be verified and the unauthorized sensitive operation related to the authorization needing to be verified are read again, and matching is carried out again.

For the screened marking nodes, in the information flow diagram, reverse traversal is carried out from the marking nodes, and whether authority verification logic codes exist in a reverse traversal path or not is judged;

the unauthorized behavior mainly comprises a method that an unauthorized user can access to be authenticated and a method that the unauthorized user can access to be authorized, for the concerned unauthorized behavior risk, the operation logic of normally obtaining authentication is to firstly carry out authority authentication, and execute corresponding sensitive operation after the authentication is passed, namely, the corresponding relation between the unauthorized sensitive behavior and the authority verification should exist, therefore, in the software application unauthorized risk detection method, a function or a statement corresponding to the sensitive operation is firstly determined, then, the software application unauthorized risk detection method is traced forwards, the one-to-one corresponding relation between the unauthorized sensitive behavior and the authority verification is judged, specifically, reverse traversal is carried out from a mark node, and whether an authority verification logic code exists in a reverse traversal path is judged;

under the condition that the authority verification logic code is not detected until the end point, the authority authentication is not carried out before sensitive operation is executed, so that the unauthorized risk exists;

if the authority verification logic code exists, judging whether the authority verification logic code is matched with the authority to be verified corresponding to the marking node;

if not, the reverse traversal path from the marking node to the authority verification logic code has an override risk.

Even if the authority verification logic code is detected, the corresponding relation between the detected authority verification logic code and the override sensitive operation still needs to be judged, and the override risk still exists for the condition that the detected authority verification logic code and the override sensitive operation are not matched. In some optional embodiments, the method for determining whether the two match is as follows: and comparing the obtained authority verification logic information with the authority corresponding to the marked node on the path in the override sensitive operation list, wherein the authority includes the operation authority, the user parameter for obtaining the transmission of the authority, the order of the authority verification logic and the like, if the information comparison and verification are the same, the authority verification logic in the path is correct, the detected authority verification logic code is matched with the override sensitive operation, and the risk of override behavior does not exist.

In one or more alternative embodiments of the present specification, in a software application unauthorized risk detection method, the determining an unauthorized risk path includes:

In some optional embodiments, when the unauthorized risk path is restored and converted, the function, the variable and the function call of the corresponding source code and the corresponding position and category are called according to the function name, the variable and the function corresponding to the intermediate code path, and when the unauthorized risk path is output, the position and category information corresponding to the unauthorized operation and the function, variable and function call information of the source code are also output.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

In another aspect, embodiments of the present specification provide an electronic device for software application unauthorized risk detection.

The electronic equipment comprises a memory, a processor and a computer program which is stored on the memory and can run on the processor, wherein the processor executes the program to realize the software application unauthorized risk detection method:

Fig. 4 is a schematic diagram illustrating a more specific hardware structure of an electronic device according to this embodiment, where the electronic device may include: aprocessor 1010, amemory 1020, an input/output interface 1030, acommunication interface 1040, and abus 1050. Wherein theprocessor 1010,memory 1020, input/output interface 1030, andcommunication interface 1040 are communicatively coupled to each other within the device viabus 1050.

Theprocessor 1010 may be implemented by a general-purpose CPU (central processing unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits, and is configured to execute related programs to implement the software application unauthorized risk detection method provided in the embodiments of the present disclosure.

Thememory 1020 may be implemented in the form of a ROM (read only memory), a RAM (random access memory), a static storage device, a dynamic storage device, or the like. Thememory 1020 may store an operating system and other application programs, and when the software application unauthorized risk detection method provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in thememory 1020 and called to be executed by theprocessor 1010.

The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

Thecommunication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 1050 includes a path that transfers information between various components of the device, such asprocessor 1010,memory 1020, input/output interface 1030, andcommunication interface 1040.

It should be noted that although the above-mentioned device only shows theprocessor 1010, thememory 1020, the input/output interface 1030, thecommunication interface 1040 and thebus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only the components necessary to implement the software application unauthorized risk detection method described in the embodiments of the present specification, and not necessarily all of the components shown in the figures.

In another aspect, embodiments of the present specification provide a software application unauthorized risk detection storage medium.

The software application unauthorized risk detection non-transitory computer-readable storage medium provided by one or more embodiments of this specification stores computer instructions for causing the computer to perform the software application unauthorized risk detection method of:

Computer-readable media of the present embodiments, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the spirit of the present disclosure, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of different aspects of one or more embodiments of the present description as described above, which are not provided in detail for the sake of brevity.

In addition, well-known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown in the provided figures, for simplicity of illustration and discussion, and so as not to obscure one or more embodiments of the disclosure. Furthermore, devices may be shown in block diagram form in order to avoid obscuring the understanding of one or more embodiments of the present description, and this also takes into account the fact that specifics with respect to implementation of such block diagram devices are highly dependent upon the platform within which the one or more embodiments of the present description are to be implemented (i.e., specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that one or more embodiments of the disclosure can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative instead of restrictive.

While the present disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic ram (dram)) may use the discussed embodiments.

It is intended that the one or more embodiments of the present specification embrace all such alternatives, modifications and variations as fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of one or more embodiments of the present disclosure are intended to be included within the scope of the present disclosure.