Tamper proofing software applications

Abstract

In some aspects, a method of enhancing security of a computing application. The method includes establishing, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port. The method further includes determining, by a bypass check module of the computing application, that the debugger blocking module has been modified. The method further includes, responsive to the determining that the debugger blocking module has been modified, performing, by the computing application, one or more actions to protect the computing application from debugger access.

Description

TAMPER PROOFING SOFTWARE APPLICATIONSFIELD OF USE

[0001] The present disclosure relates generally to software applications, and more particularly, but not by way of limitation, to systems, devices, and methods for preventing access by a debugger or instrumentation tool to a software application.BACKGROUND

[0002] Debuggers and instrumentation tools such as Frida allow an attacker to step through code of an application and learn how the application works. Use of a debugger or instrumentation tool allows code to be reverse engineered and enables unauthorized platform or application access plans to be devised. Such reverse engineering and unauthorized access present significant risks to computing security, data privacy, and application developers’ confidential implementation details and intellectual property associated with an application.

[0003] An attacker may, for example, reverse engineer code for intellectual property theft, to make binary modifications that defeat security measures, or to steal privacy related information. The binary can be decompiled to pseudo source code that is easier for an attacker to understand, and so in many cases the binary is obfuscated to make it more difficult for an attacker to understand. However, an attacker may attach a debugger or instrumentation tool in such cases in order to analyze the application by inspecting code flow.

[0004] This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.SUMMARY

[0005] A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combinationof them installed on the system that in operation or execution causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

[0006] One general aspect includes a method of enhancing security of a computing application. The method includes establishing, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port. The method may also include determining, by a bypass check module of the computing application, that the debugger blocking module has been modified. The method may also include responsive to the determining that the debugger blocking module has been modified, performing, by the computing application, one or more actions to protect the computing application from debugger access.

[0007] Another general aspect includes a system for enhancing security of a computing application. The system includes a memory having executable instructions and a processor in communication with the memory. The processor is configured to execute the instructions to: establish, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port; determine, by a bypass check module of the computing application, that the debugger blocking module has been modified; and responsive to the determining that the debugger blocking module has been modified, perform, by the computing application, one or more actions to protect the computing application from debugger access.

[0008] Another general aspect includes a computer-program product including a non- transitory computer-readable medium. The non-transitory computer-readable medium has computer-readable program code embodied therein. The computer-readable program code is adapted to be executed to implement a method. The method includes establishing, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port. The method also includes determining, by a bypass check module of the computing application, that the debugger blocking module has been modified. The method alsoincludes responsive to the determining that the debugger blocking module has been modified, performing, by the computing application, one or more actions to protect the computing application from debugger access.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various aspects discussed in the present document.

[0010] FIG. 1 illustrates a health management system including an example continuous analyte sensor system (SS) having continuous analyte sensor(s) and sensor electronics, in accordance with certain aspects.

[0011] FIG. 2 illustrates example computing components related to enhancing security of a computing application, in accordance with certain aspects.

[0012] FIG. 3 illustrates an example process for debugger blocking to enhance computing security of a computing application, in accordance with certain aspects.

[0013] FIG. 4 illustrates an example process for instrumentation tool blocking to enhance computing security of a computing application, in accordance with certain aspects.

[0014] FIG. 5 is a flow diagram depicting a process for enhancing security of a computing application, in accordance with certain aspects.

[0015] FIG. 6 is a block diagram depicting a computer system configured for enhancing security of a computing application, in accordance with certain aspects.DETAILED DESCRIPTION

[0016] Effectively preventing debugger or instrumentation tool access to an application is challenging for a number of reasons. For example, taking action to protect security of an application after detecting a connection from a debugger or instrumentation tool can expose the application to risk in the interim between when the connection isestablished and when the action is taken. The connection of a debugger may allow an attacker to learn about and study the operation of the application, which may then be used for reverse engineering. Furthermore, an attacker that is likely to utilize a debugger or instrumentation tool is also likely capable of modifying application code, such as disabling code that is configured to protect against debugger or instrumentation tool access.

[0017] Thus, it is technically challenging to prevent debugger or instrumentation tool access to an application in a way that is sufficiently prompt and that is sufficiently immune to modification from an attacker. Accordingly, applications may be exposed to significant security and privacy risks associated with debugger or instrumentation tool access.

[0018] Furthermore, it is technically challenging to determine whether a security event is associated with an attacker or a victim due to the similarities (e.g., behavior) between those situations or users. For example, malicious code installed on a “victim” user’s device may attempt to connect a debugger or instrumentation tool to an application in a similar manner to that in which an attacker would directly attempt to make such a connection, and it is challenging to automatically determine the difference. Thus, it may be challenging to respond to such events appropriately (e.g., in manner that is suited to an attacker or a victim specifically).

[0019] To address the above problems, an application (e.g., any software application) may be configured with “blocking” code (e.g., debugger port blocking code) that establishes a connection from the application itself to a debugger port associated with the application, thereby preventing any other connections from debuggers or instrumentation tools. Thus, debugger and instrumentation tool access may be preemptively prevented without waiting for such access to be detected to take preventive action, thereby avoiding the risk associated with such a potentially delayed response.

[0020] Furthermore, to address the problem of the potential for modification of code that protects against debugger access, an application may include logic that monitors for modifications to the blocking code, such as by performing a checksum calculation between the current version of the code and a “model” or expected version of the code. The monitoring for one or more modifications to the blocking code may be performed at startup or execution of the application, periodically during execution of the application, etc. If anymodification of the blocking code is detected, action may be taken to protect the application from debugger or instrumentation tool access, such as terminating execution of the application, restricting functionality of the application, notifying a user or other entity of the detected modification, or the like.

[0021] Additionally, to further protect against security risks, the application may be configured with one or more backup or “zombie” code modules that are activated if any modification to the blocking code is detected. Such backup code modules may, when activated, block any debugger or instrumentation tool access, such as by establishing a connection to the debugger port associated with the application. The backup code modules may monitor the blocking code during execution of the application (e.g., by checking a checksum of the blocking code) at one or more times during execution of the application. These backup code modules may provide one or more extra layers of defense that may be difficult for an attacker to locate, identify, and modify. In some aspects, the backup code modules are included as part of a same data structure (e.g., class) as the blocking code. However, to further prevent detection and tampering with such modules, they may alternatively be located in separate data structures from the blocking code, separate data structures from one another, or separate data structures from the blocking code and from one another, such as being located in disparate parts of the application code.

[0022] In some aspects, multiple factors are evaluated in order to determine how to appropriately respond to one or more security events (e.g., blocking code modification, a debugger or instrumentation tool detected, root mode device, etc.). For example, if modification of the blocking code is detected, if an attempt to attach a debugger or instrumentation tool is detected, if it is determined that the device on which the application runs has been placed in a root mode (e.g., device has been “rooted”), or if some combination of these events occur, one or more particular actions may be performed. Such actions may include, for example, terminating execution of the application, restricting functionality of the application, blocking a user or device from installing or running the application, generating one or more notifications (e.g., to the user, to the application developer or provider, or the like), or some combination of these actions, or other preventive actions may be taken.

[0023] When a security event occurs, factors related to the security event may be analyzed in order to determine whether the user associated with the security event is an attacker or a victim (e.g., a user of a device that has been compromised by malicious software but who does not necessarily have malicious intent). One such factor may include whether the application has been reinstalled multiple times on the same device. For example, a universal application identifier may be assigned to each instance of the application when it is installed on a given device, such that a new universal application identifier is assigned each time the application is reinstalled. Since it is not normal behavior for a user to reinstall the application multiple times in succession (e.g., in a short period of time), such behavior may indicate that the user is an attacker that is attempting to iteratively understand, modify the code, or a combination thereof to defeat security restrictions. Thus, if multiple universal application identifiers are associated with the same user or device, then this may be a factor that indicates that the user is an attacker. Other factors may include whether the user is associated with past security events, the types of security events that are detected, the user’s application usage history or patterns, the type of device associated with the security event(s), the type of or operating system associated with the security event(s), a geographic location associated with the user, some combination of these factors, or the like. For example, an attacker’s application usage history or patterns may include use of tools such as debuggers and instrumentation tools and other activity such as binary code modifications and application re-signing while a victim’s history is unlikely to include use of tools but may include binary code modifications. In another example, a user that is located in a geographic region known to be associated with a hostile entity (e.g., nation) may be more likely to be an attacker than a victim, and so a security event associated with the user may be classified as being associated with an attacker (e.g., so that escalated actions or stricter countermeasures may be applied).

[0024] In some aspects, different actions may be taken in response to a security event if it is determined that the security event is associated with an attacker or a victim. For example, if it is determined that a security event is associated with an attacker, then execution of the application may be terminated, a notification may be provided to the application developer or provider, the user or the user’s device may be blocked from installing or executing the application, or the like. Continuing the example, if it isdetermined that a security event is associated with a victim, then less drastic actions may be taken, such as restricting functionality of the application (e.g., preventing the application from executing sensitive, private, or secure functionality, preventing the application from accessing certain data such as PII or PHI, or preventing the application from such execution and such access), notifying the user of the detected security event, some combination of these actions, or the like.

[0025] Thus, techniques described herein overcome the technical challenge of preventing debugger or instrumentation tool access to an application in a manner that is preemptive (e.g., preemptive debugger port blocking) and does not allow even momentary access before such access is prevented. By preemptively blocking debugger and instrumentation tool access to an application through the use of blocking code that establishes a connection from the application to a debugger port associated with the application, techniques described herein prevent any other debugger or instrumentation tool from even establishing a connection to the application. Furthermore, techniques described herein overcome the technical challenge of protecting against an attacker modifying code that is configured to protect against debugger or instrumentation tool access by detecting attempts to modify blocking code and, when such modification is detected, triggering action to protect the security of the application such as terminating execution of the application, restricting functionality of the application, generating notifications, some combination of these actions, or the like. Additionally, aspects of the present disclosure may protect against code modification by configuring the application with backup “zombie” code modules that activate when modifications to the blocking code are detected (e.g., via a checksum) and, when activated, function similarly to the blocking code and prevent debugger or instrumentation tool access to the application.

[0026] Techniques described herein overcome the technical challenge of determining whether a debugger or instrumentation tool related security event is associated with an attacker or a victim, such as to determine how to appropriately handle the security event, by utilizing various factors related to a security event, such as universal application identifiers, application history, device attributes, user attributes, some combination of these factors, or the like, to determine whether a user associated with the security event is anattacker or victim. Thus, aspects of the present disclosure enable dynamically determining actions to perform in response to security events based on whether the user is determined to be an attacker or a victim, such as choosing between terminating execution of the application or restricting functionality of the application. To protect application security, aspects of the present disclosure involve determining whether to take actions such as teiminating execution of the application, restricting functionality of the application, or generating notifications based on whether different events occur, such as attempts to modify blocking code, attempts to connect a debugger or instrumentation tool, or detecting a device with root privileges, based on whether the user is determined to be an attacker or a victim, or based on some combination of these events.

[0027] FIG. 1 depicts a health management system 100 including an example continuous analyte sensor system (SS) 8 having continuous analyte sensor(s) and sensor electronics, in accordance with certain aspects of the present disclosure. For example, SS 8 may be configured to continuously monitor one or more analytes of a user 50, in accordance with certain aspects of the present disclosure. In other implementations, SS 8 may be configured to monitor one or more analytes of user 50 in a non-continuous manner.

[0028] As shown, SS 8 includes sensor electronics module 12 and one or more analyte sensor(s) 10 (individually referred to herein as analyte sensor 10 and collectively referred to herein as analyte sensors 10) associated with sensor electronics module 12. In some aspects, the one or more analyte sensor(s) 10 may comprise one or more continuous analyte sensors configured to provide continuous analyte concentration level measurements. Sensor electronics module 12 may be in wireless communication (e.g., directly or indirectly) with one or more of display devices 110, 120, 130, and 140, and server system 134, or with some subset of these components.

[0029] In certain aspects, the analyte sensor(s) 10 may comprise one or more sensors for detecting analyte(s), measuring analyte(s), or detecting and measuring analyte(s). The analyte sensor(s) 10 may be a multi-analyte sensor configured to continuously measure two or more analytes or a single analyte sensor configured to continuously measure a single analyte as a non-invasive device, a subcutaneous device, a transcutaneous device, a transdeimal device, an intravascular device, or some combination of these devices. Incertain aspects, the analyte sensor(s) 10 may be configured to continuously measure analyte concentration levels of the user 50 using one or more techniques, such as enzymatic techniques, chemical techniques, physical techniques, electrochemical techniques, potentio static techniques, potentiometric techniques, impedimetric techniques, spectrophotometric techniques, polarimetric techniques, calorimetric techniques, iontophoretic techniques, radiometric techniques, immunochemical techniques, and the like. The term “continuous,” as used herein, can mean fully continuous, semi-continuous, periodic, etc. In certain aspects, the analyte sensor(s) 10 provides a data stream indicative of the concentration of one or more analytes of the user 50. The data stream may include raw data signals, which are then converted into a calibrated or filtered (or calibrated and filtered) data stream used to provide estimated analyte value(s) to the user 50.

[0030] In certain aspects, the analyte sensor(s) 10 may be a multi-analyte sensor, configured to continuously measure one or more analytes in a body of the user 50. In some aspects, the one or more analytes may include at least one of sodium ions, potassium ions, hydrogen ions, lithium ions, magnesium ions, calcium ions, chloride ions, sulfite ions, sulfate ions, phosphate ions, ammonium ions, manganese ions, uric acid, urea, ketones, glucose, or some combination of these analytes.

[0031] In certain aspects, the analyte sensor(s) 10 may comprise a percutaneous wire that has a proximal portion coupled to the sensor electronics module 12 and a distal portion with several electrodes, such as a measurement electrode and a reference electrode. The measurement (or working) electrode may be coated, covered, treated, embedded, etc., with one or more chemical molecules that react with a particular analyte, and the reference electrode may provide a reference electrical voltage. The measurement electrode may generate the analog electrical signal, which is conveyed along a conductor that extends from the measurement electrode to the proximal portion of the percutaneous wire that is coupled to the sensor electronics module 12. After the SS 8 has been applied to epidermis of the user 50, analyte sensor(s) 10 penetrates the epidermis, and the distal portion extends into the dermis, the subcutaneous tissue under epidermis, or the dermis and the subcutaneous tissue under epidermis. Other configurations of analyte sensor(s) 10 may also be used, such as a multi-analyte sensor that includes multiple measurement electrodes, eachgenerating an analog electrical signal that represents the concentration levels of a particular analyte.

[0032] Generally, a single-analyte sensor generates an analog electrical signal that is proportional to the concentration level of a particular analyte. Similarly, each multi-analyte sensor generates multiple analog electrical signals, and each analog electrical signal is proportional to the concentration level of a particular analyte. As an illustrative example, analyte sensor(s) 10 may include a single-analyte sensor configured to measure glucose concentration levels, and another single-analyte sensor configured to measure concentration levels of another analyte of the user 50, such as at least one of a sodium ion concentration level, a potassium ion concentration level, a hydrogen ion concentration level, a lithium ion concentration level, a magnesium ion concentration level, a calcium ion concentration level, a chloride ion concentration level, a sulfite ion concentration level, a sulfate ion concentration level, a manganese concentration level, a phosphate ion concentration level, an ammonium ion concentration level, a uric acid concentration level, a urea concentration level, a ketone concentration level, or some combination of these analytes. As another illustrative example, analyte sensor(s) 10 may include a single-analyte sensor configured to measure glucose concentration levels, and one or more multi-analyte sensors configured to measure a sodium ion concentration level, a potassium ion concentration level, a hydrogen ion concentration level, a lithium ion concentration level, a magnesium ion concentration level, a calcium ion concentration level, a chloride ion concentration level, a sulfite ion concentration level, a sulfate ion concentration level, a manganese concentration level, a manganese concentration level, a phosphate ion concentration level, an ammonium ion concentration level, a uric acid concentration level, a urea concentration level, a ketone concentration level, a concentration of lactate, a concentration level of creatinine, etc. As yet another illustrative example, analyte sensor(s) 10 may include a multi-analyte sensor configured to measure glucose concentration levels, a sodium ion concentration level, a potassium ion concentration level, a hydrogen ion concentration level, a lithium ion concentration level, a magnesium ion concentration level, a calcium ion concentration level, a chloride ion concentration level, a sulfite ion concentration level, a sulfate ion concentration level, a manganese concentration level, a manganese concentration level, a phosphate ion concentration level, an ammonium ionconcentration level, a uric acid concentration level, a urea concentration level, a ketone concentration level, a concentration of lactate, a concentration level of creatinine, etc.

[0033] Accordingly, analyte scnsor(s) 10 is configured to generate at least one analog electrical signal that is proportional to the concentration level of a particular analyte, and sensor electronics module 12 is configured to convert the analog electrical signal into an analyte sensor count values, calibrate the analyte sensor count values based on the sensitivity profile of the analyte sensor(s) 10 to generate measured analyte concentration levels, and transmit the measured analyte concentration level data, including the measured analyte concentration levels, to a display device, such as display devices 210, 220, 230, and 240 (or some subset of these display devices), via a wireless connection. For example, sensor electronics module 12 may be configured to sample the analog electrical signal at a particular sampling period (or rate), such as every 1 second (1 Hz), 5 seconds, 10 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes, etc., and to transmit the measured analyte concentration data to the display device at a particular transmission period (or rate), which may be the same as (or longer than) the sampling period, such as every 1 minute (0.016 Hz), 5 minutes, 10 minutes, 30 minutes, at the conclusion of the wear period, etc. Depending on the sampling and transmission periods, the measured analyte concentration data transmitted to the display device include at least one measured analyte concentration level having an associated time tag, sequence number, etc. Additional details regarding analyte concentration level measurement and the configuration of the analyte sensor(s) 10 and sensor electronics unit 12 may be found in one or more of (1) U.S. Non-Provisional Patent Application Serial No. 18 / 241,658 filed on September 1, 2023 and entitled, “DEVICES AND METHODS FOR MEASURING A CONCENTRATION OF A TARGET ANALYTE IN A BIOLOGICAL FLUID IN VIVO,” (2) U.S. Provisional Patent Application Serial No. 63 / 268,417 filed on February 23, 2022 and entitled, “SENSING SYSTEMS AND METHODS FOR PROVIDING DECISION SUPPORT AROUND KIDNEY DISEASE,” (3) U.S. Provisional Patent Application Serial No. 63 / 365,702 filed on June 1, 2022 and entitled, “DIAGNOSIS AND DECISION SUPPORT FOR DIABETES IN PATIENTS WITH KIDNEY DISEASE,” (4) U.S. Provisional Patent Application Serial No. 63 / 376,673 filed on September 22, 2022 and entitled, “SENSING SYSTEMS AND METHODS FOR DIAGNOSING KIDNEY DISEASE,” (5) U.S.Provisional Patent Application Serial No. 63 / 387,078 filed on December 12, 2022 and entitled, “DECISION SUPPORT TECHNIQUES USING PHYSIOLOGICAL PROFILES,” (6) U.S. Provisional Patent Application Serial No. 63 / 377,332 filed on September 27, 2022 and entitled, “SENSING SYSTEMS AND METHODS FOR PROVIDING DECISION SUPPORT AROUND KIDNEY DISEASE AND / OR DIABETES,” (7) U.S. Non-Provisional Patent Application Serial No. 18 / 173,753 filed on February 23, 2023 and entitled, “SENSING SYSTEMS AND METHODS FOR PROVIDING DECISION SUPPORT AROUND KIDNEY HEALTH and / or Diabetes,” (8) U.S. Non-Provisional Patent Application Serial No. 18 / 326,985 filed on May 31, 2023 and entitled, “SYSTEMS AND METHODS FOR MONITORING, DIAGNOSIS, AND DECISION SUPPORT FOR DIABETES IN PATIENTS WITH KIDNEY DISEASE,” (9) U.S. Non-Provisional Patent Application Serial No. 18 / 327,012 filed on May 31 , 2023 and entitled, “SENSING SYSTEMS AND METHODS FOR DIAGNOSING KIDNEY DISEASE,” and (9) U.S. Non-Provisional Patent Application Serial No. 18 / 327,014 filed on May 31, 2023 and entitled, “SYSTEMS AND METHODS FOR OPTIMIZING TREATMENT USING PHYSIOLOGICAL PROFILES,” all of which are incorporated herein by reference in their entireties.

[0034] In certain aspects, analyte sensor(s) 10 may incorporate a thermocouple within, or alongside, the percutaneous wire to provide an analog temperature signal to the sensor electronics module 12, which may be used to correct the analog electrical signal or the measured analyte data for temperature. In other aspects, the thermocouple may be incorporated into the sensor electronics module 12 above the adhesive pad, or, alternatively, the thermocouple may contact the epidermis of the patient through openings in the adhesive pad.

[0035] In certain aspects, sensor electronics module 12 includes electronic circuitry associated with measuring and processing the continuous analyte sensor data, including prospective algorithms associated with processing and calibration of the sensor data. Sensor electronics module 12 can be physically coupled to analyte sensor(s) 10 and can be integral with (non-releasably attached to) or releasably attachable to analyte sensor(s) 10. Sensor electronics module 12 may include hardware, firmware, software, or somecombination of hardware, firmware that enable measurement of levels of analyte(s) via analyte sensor(s) 10. For example, sensor electronics module 12 can include an electrochemical analog front end (e.g., a potentiostat, galvanostat, coulostat, etc.), a power source for providing power to the sensor (including power switches and controlling logic), other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to, e.g., one or more display devices. Electronics can be affixed to a printed circuit board (PCB), or the like, and can take a variety of forms. For example, the electronics can take the form of an integrated circuit (IC), such as an Application-Specific Integrated Circuit (ASIC), a microcontroller, a processor, or some combination of these components.

[0036] Display devices 110, 120, 130, and 140 are configured for displaying displayable sensor data, including analyte data, which may be transmitted by sensor electronics module 12. Each of display devices 110, 120, 130, and 140 may include a display such as a touchscreen display 112, 122, 132, or 142 for displaying sensor data to a patient and, in some aspects, for receiving inputs from the patient. For example, a graphical user interface (GUI) may be presented to the patient for such purposes. In certain aspects, the display devices may include other types of user interfaces such as a voice user interface instead of, or in addition to, a touchscreen display for communicating sensor data to the patient of the display device and, in some aspects, for receiving patient inputs. In certain aspects, one, some, or all of display devices 110, 120, 130, 140 may be configured to display or otherwise communicate the sensor information as it is communicated from sensor electronics module 12 (e.g., in a data package that is transmitted to respective display devices), without any additional prospective processing required for calibration or real-time display of the sensor data.

[0037] The plurality of display devices 110, 120, 130, 140 depicted in FIG. 1 may include a custom or proprietary display device, for example, display device 110, especially designed for displaying certain types of displayable sensor information associated with analyte data received from sensor electronics module 12 (e.g., a numerical value, an arrow, or both, in certain aspects). In certain aspects, one of the plurality of display devices 110, 120, 130, 140 includes a smartphone, such as a mobile phone, based on an Android, iOS,or another operating system configured to display a graphical representation of the continuous sensor data (e.g., including current and, in some embodiments, historic data). In some aspects, one of the plurality of display devices 110, 120, 130, 140 may include a home automation system display or speakers. In certain aspects, health management system 100 further includes a medical delivery device (e.g., an insulin pump or pen). Sensor electronics module 12 may be configured to transmit sensor information or analyte data (or both) to medical delivery device. The medical delivery device (not shown) may be configured to administer a certain dosage of insulin or another medicament to the user based on the sensor information or analyte data or both (e.g., which may include a recommended insulin dosage) received from the sensor electronics module 12.

[0038] Server system 134 may be used to directly or indirectly collect analyte data from SS 8 or the plurality of display devices (or some combination of SS 8 and one or more of the plurality of display devices), for example, to perform analytics thereon, generate universal or individualized models for analyte concentration levels and profiles, provide services or feedback, including from individuals or systems remotely monitoring the analyte data, perform or assist SS 8 and the plurality of display devices with identification, authentication, etc., according to the aspects described herein, so on. Note that, in certain aspects, server system 134 may be representative of multiple systems or computing devices that perform the functions of server system 134 (e.g., in a distributed manner).

[0039] The term “analyte” as used herein is a broad term and is to be given its ordinary and customary meaning to a person of ordinary skill in the art (and is not to be limited to a special or customized meaning), and refers without limitation to a substance or chemical constituent in a biological fluid (e.g., blood, interstitial fluid, cerebral spinal fluid, lymph fluid, urine, sweat, saliva, etc.) that can be analyzed. Analytes can include naturally occurring substances, artificial substances, metabolites, electrolytes, ions, gasses, hormones, proteins, enzymes, neurotransmitters, infectious agents, reaction products, or some combination of these. In some examples, the analyte measured by the sensing regions, devices, and methods is glucose. However, other analytes are contemplated as well, including but not limited to acarboxyprothrombin; acylcamitine; adenine phosphoribosyl transferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acidprofiles (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); andrenostenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); bilirubin, biotinidase; biopterin; c- reactive protein; carnitine; carnosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-P hydroxy-cholic acid; cortisol; creatine; creatine kinase; creatine kinase MM isoenzyme; creatinine; cyclosporin A; d- penicillamine; de-ethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylator polymorphism, alcohol dehydrogenase, alpha 1 -antitrypsin, cystic fibrosis, Duchenne / Becker muscular dystrophy, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, beta- thalassemia, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber hereditary optic neuropathy, MCAD, RNA, PKU, Plasmodium vivax, 21 -deoxycortisol); dcsbutylhalofantrinc; dihydroptcridinc reductase; dipthcria / tctanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acids / acylglycines; free P-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free triiodothyronine (FT3); fumarylacetoacetase; galactose / gal-1 -phosphate; galactose-1- phosphate uridyltransferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione perioxidase; glycerol; glycocholic acid; glycosylated hemoglobin; halofantrine; hemoglobin variants; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyl transferase; immunoreactive trypsin; beta-hydroxybutyrate; manganese; ketones; lactate; lead; lipoproteins ((a), B / A-l, P); lysozyme; mefloquine; netilmicin; oxygen; phenob arbitone; phenytoin; phytanic / pristanic acid; potassium, sodium, some combination of these, or other blood electrolytes; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinine; reverse tri-iodothyronine (rT3); selenium; serum pancreatic lipase; sissomicin; somatomedin C; specific antibodies (adenovirus, anti-nuclear antibody, anti-zeta antibody, arbovirus, Aujeszky's disease virus, dengue virus, Dracunculus medinensis, Echinococcus granulosus, Entamoeba histolytica, enterovirus, Giardia duodenalisa, Helicobacter pylori, hepatitis B virus, herpes virus, HIV-1, IgE (atopic disease), influenza virus, Leishmania donovani, leptospira, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, Myoglobin, Onchocerca volvulus, parainfluenza virus, Plasmodiumfalciparum, poliovirus, Pseudomonas aeruginosa, respiratory syncytial virus, rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Trepenoma pallidium, Trypanosoma cruzi / rangeli, vesicular stomatis virus, Wuchereria bancrofti, yellow fever virus); specific antigens (hepatitis B virus, HIV-1); succinylacetone; sulfadoxine; theophylline; thyrotropin (TSH); thyroxine (T4); thyroxine-binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uric acid; uroporphyrinogen I synthase; vitamin A; white blood cells; and zinc protoporphyrin. Salts, sugar, protein, fat, vitamins, and hormones naturally occurring in blood or interstitial fluids can also constitute analytes in certain examples. The analyte can be naturally present in the biological fluid, or endogenous, for example, a metabolic product, a hormone, an antigen, an antibody, and the like. Alternately, the analyte can be introduced into the body, or exogenous, for example, a contrast agent for imaging, a radioisotope, a chemical agent, a fluorocarbon- based synthetic blood, or a drug or pharmaceutical composition, including but not limited to insulin; ethanol; cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorohydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamines, methamphetamines, Ritalin, Cylert, Preludin, Didrex, PreState, Voranil, Sandrex, Plegine); depressants (barbiturates, methaqualone, tranquilizers such as Valium, Librium, Miltown, Serax, Equanil, Tranxene); hallucinogens (phencyclidine, lysergic acid, mescaline, peyote, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, Percocet, Percodan, Tussionex, Fentanyl, Darvon, Talwin, Lomotil); designer drugs (analogs of fentanyl, meperidine, amphetamines, methamphetamines, and phencyclidine, for example, Ecstasy); anabolic steroids; and nicotine. The metabolic products of drugs and pharmaceutical compositions are also contemplated analytes. Analytes such as neurochemicals and other chemicals generated within the body can also be analyzed, such as, for example, ascorbic acid, uric acid, dopamine, noradrenaline, 3 -methoxy tyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5 -hydroxy tryptamine (5HT), 5-hydroxyindoleacetic acid (FH1AA), and histamine.

[0040] The term “ion” as used herein is a broad term, and is to be given its ordinary and customary meaning to a person of ordinary skill in the art (and is not to be limited to a special or customized meaning), and refers without limitation to an atom or molecule witha net electric charge due to the loss or gain of one or more electrons. Ions in a biological fluid is referred to as “electrolytes.” Non-limiting examples of ions in biological fluids include sodium (Na+), potassium (K+), magnesium (Mg2+), calcium (Ca2+), hydrogen (H+), lithium (Li+), chloride (Cl-), sulfide (S2‘), sulfite (SCh2'), sulfate (SO42'), phosphate (PO43' ), and ammonium (NH4+). An ion is an example of an analyte.

[0041] In certain aspects, one or more software applications configured to perform functionality described above with respect to health management system 100 may include one or more modules that protect against debugger or instrumentation tool access, as described in more detail below with respect to FIG. 2 (e.g., blocking module 210, blocking bypass check module 220, backup module(s) 230, and debugger activity detection module 240). For example, an application running on display device 110, 120, 130, or 140, server system 134, or SS 8 may be configured with one or more of such modules to protect the security of the application as well as the data of user 50. It is noted that while certain aspects are described herein with respect to a health monitoring system, techniques described herein may be used with other types of systems and applications.

[0042] FIG. 2 is an illustration 200 of example computing components related to enhancing security of a computing application, in accordance with certain aspects. In particular, FIG. 2 illustrates example modules for enhancing the security of a computing application such as an application performing functionality described above with respect to FIG. 1.

[0043] A dcbuggcr / Frida blocking module 210 (which may be referred to as blocking module 210) generally represents a module within an application that prevents debuggers and instrumentation tools such as Frida from connecting to the application (e.g., the debugging port of an application). The blocking module 210 may be implemented via a data structure such a class within the application’s code base, and may function by establishing a connection to a debugger port associated with the application. For example, in a Unix based system, the blocking module may execute a “ptrace attach” command. In some aspects, such as in the context of the Google® Android® operating system (OS), the blocking module forks a child process of the main application process and attaches the child process to the main application process as a debugger, such as using a “ptrace attach”command. With the child process attached, further attempts to attach to the parent process (e.g., main application process) will fail. In certain aspects, such as in the context of the Apple® iOS® operating system, where ptrace is not part of the public application programming interface (API), ptrace is not directly called in the code, but is instead called when a ptrace function pointer is obtained.

[0044] Only one debugger or instrumentation tool can be attached to a process at a time (e.g., which is generally an operating system limitation), so the connection established by the blocking module 210 prevents any other connections to the debugger port of the application. For example, the blocking module 210 may execute when the application stalls up, thereby preemptively monopolizing the debugger port before any other debugger or instrumentation tool can be connected to the debugger port. The preemptive nature of the blocking avoids risks associated with waiting to take preventive action until a debugger or instrumentation tool connection (e.g., from an attacker) is detected. This approach differs from anti-debugger detection modules that periodically search for a debugger connection and generate reports or terminate execution of the application (or both) when a debugger connection is detected. Rather than terminating execution of the application when a debugger connection is detected, the blocking code described herein prevents any debugger or instrumentation tool from connecting to the application in the first place.

[0045] An application configured with or including blocking module 210 may further be configured with a blocking bypass check module 220 that monitors for any modifications to the blocking module 210 (e.g., computer executable code, computer readable code, script code, etc.) so that preventive action may be taken when such modification is detected. The blocking bypass check module 220 may, for example, perform a checksum computation to detect any differences between a checksum of the current version of the blocking code and a checksum of an expected version of the blocking code (e.g., which may be stored by the blocking bypass check module 220). In some aspects, the blocking bypass check module 220 may execute upon application startup in order to prevent security risks (e.g., to avoid executing the application with a modified version of the blocking module 210 and thereby exposing the application to the risk of adebugger or instrumentation tool being connected to the application in the absence of the blocking action or blocking functionality of the blocking module 210).

[0046] If the blocking bypass check module 220 determines that the blocking module 210 has been modified (e.g., based on a checksum comparison), then blocking bypass check module 220 may perform one or more actions or provide an indication of the modification to one or more other components that may perform one or more actions. The actions performed by the blocking bypass check module 220 or another component based on determining modification to the blocking module 210 may include, for example, terminating execution of the application, restricting functionality of the application, generating one or more notifications, blocking the user or device from installing or running the application (or both) in the future, some combination of these actions, or the like. Generally, the one or more actions are performed to accomplish the objective of protecting the application from debugger or instrumentation tool access. In some cases, one or more actions are performed if a combination of events occurs, as addressed below.

[0047] In some implementations, multiple factors may be considered when determining whether to perform certain preventive actions. For example, if modification of the blocking code is detected, an attempt to connect a debugger or instrumentation tool is detected, a determination is made that the device has root privileges, or some combination of these factors is detected, then execution of the application may be terminated or functionality of the application may be restricted.

[0048] An application configured with blocking module 210 and blocking bypass check module 220 may also be configured with application logic for determining when a user associated with a debugger-related security event is an attacker or a victim. Appropriate preventive actions for handling security events may vary based on whether the security events are performed in connection with users that are attackers or victims. Thus, various factors may be evaluated in order to automatically predict whether a user associated with a particular security event is an attacker or a victim. For example, each instance of the application may generate a universal application identifier (UAID) upon installation on a given device (e.g., display device 107 of FIG. 1), and the UAID may stay with that instance of the application on that device until it is uninstalled. Such UAIDs may be useful fordetermining whether the application is repeatedly reinstalled on the same device, such as if a single user or device is associated with multiple UAIDs. Such a pattern may indicate that the user is an attacker that is attempting to defeat security measures by installing the application multiple times, such as after repeatedly modifying code to bypass preventive modules. Other factors may include user attributes, device attributes, application history, whether the user or device is associated with previous security events, whether the device has been placed in root mode, or the like.

[0049] A rules-based approach or one or more machine learning models (or a combination or rules and one or more machine learning models) may be used to determine based on such factors whether a user is likely to be an attacker or a victim. For example, certain patterns may be associated in rules with a determination that a user is an attacker or a victim. In another example, a machine learning model may be trained through a supervised learning process based on historical security event data labeled with indications of whether the historical security events were associated with attackers or victims (e.g., based on manual investigation or review and annotation) to output a classification (e.g., attacker or victim) in response to a set of input features (e.g., attributes related to a security event).

[0050] Different actions may be taken based on whether the user is predicted to be an attacker or a victim. For example, if the user is predicted to be an attacker, the application may be terminated and a notification may be provided to an application developer or provider. If the user is predicted to be a victim, functionality of the application may be restricted and a notification may be provided to the user.

[0051] An application configured with blocking module 210 and blocking bypass check module 220 may also be configured with one or more debugger / Frida blocking backup modules 230 (which may be referred to as back up module(s) 230). One or more backup modules 230 may be activated when modification to the blocking module 210 is detected (e.g., be blocking bypass check module 220), and the one or more backup modules 230 may prevent debugger and instrumentation tool access to the application. The one or more backup modules 230 or “zombie” modules may be invoked or otherwise executed only when one or more particular conditions occur, such as modification to the blockingmodule 210 or other security-related events (e.g., detecting an attempt to connect a debugger or instrumentation tool to the application, detecting that the device has root privileges, some combination of these events, or the like). The backup modules 230 may function similarly to the blocking module 210, and may be configured to establish a connection from the application to the debugger port associated with the application, thereby preemptively preventing a debugger or instrumentation tool connection to the application even if the blocking module has been modified to disable its blocking functionality.

[0052] The backup modules 230 may be difficult for an attacker to detect, as they are only activated when certain condition(s) occur, such as when modification to the blocking module 210 is detected, and generally make it more difficult for an attacker to disable the blocking functionality.

[0053] In some aspects, one of a plurality of backup modules 230 is activated at a time and, if modification of one backup module 230 is detected or some other condition occurs (e.g., detection of an unexpected debugger or instrumentation tool connection), another backup module 230 is activated. This cascading approach makes it difficult for an attacker to locate and disable all such backup modules 230. Furthermore, in some implementations, one or more backup modules 230 may be located in a separate data structure, in a different part of the application code, or both in a separate data structure and a different part of the application code than the blocking module 210 or one or more other backup modules 230 (or both the blocking module 210 and one or more other backup modules 230) to further complicate any attempts to locate and disable such modules.

[0054] An application configured with blocking module 210, blocking bypass check module 220, one or more backup modules 230, or some combination of these modules may also be configured with a debugger activity detection module 240. Debugger activity detection module 240 generally monitors for attempts to connect a debugger or instrumentation tool to the application or receives notifications from one or more other modules (e.g., the blocking bypass check module 220), or both, and enables performing preventive actions when debugger-related security events are detected. The debugger activity detection module 240 may monitor for any attempt to connect to the debugger port(e.g., from a component outside of the application), and may trigger one or more actions when such an attempt is detected, such as a notification or logic for determining appropriate preventive or responsive action, or both a notification and such logic. The debugger activity detection module 240 may also be notified (e.g., by the blocking bypass detection module 220) of any detected modification to the blocking module 210, may be notified if some component determines that the device has root privileges, or may be notified if a combination of these or other events occur. In other aspects, an output from the debugger activity detection module 240 (e.g., indicating when a debugger or instrumentation tool connection is detected) is combined with such other data points at another module or component that determines appropriate preventive action based on such data points. Preventive action may include, for example, terminating execution of the application, restricting functionality of the application, generating one or more notifications, some combination of these actions, or the like.

[0055] FIG. 3 illustrates an example process 300 for debugger blocking to enhance computing security of a computing application, in accordance with certain aspects. In various aspects, process 300 may be performed by one or more modules of an application that implements functionality described above with respect to FIG. 1 such as one or more of the modules in FIG. 2. In some aspects, process 300 may be performed by an application receiving analyte values, as described herein.

[0056] At 302, an application starts up. At 304, anti-debugging code of the application executes, such as blocking module 210 of FIG. 2. In some aspects, the anti-debugging code includes a ptrace attach command. Generally, the anti-debugging code involves establishing a connection to the debugger port of the application to prevent other connections to the debugger port. Executing the anti-debugging code immediately upon application startup is advantageous, as it preemptively blocks debugger and instrumentation tool access to the application without allowing a time gap for such access to occur.

[0057] At 310, a trigger condition occurs, such as application startup, expiration of a timer, some combination of these conditions, or the like. In one example, the trigger condition occurs at application startup and then again at regular intervals. At 312,checksum code of the application executes, such as blocking bypass check module 220 of FIG. 2. For example, the checksum code may involve performing a checksum computation with a range that includes the anti-debugging code (e.g., blocking module 210 of FIG. 2). Generally, the checksum code involves determining whether the anti-debugging code has been modified, such as comparing the checksum computed based on the current version of the anti-debugging code as compared to a checksum of a baseline version of the antidebugging code to determine whether there are any differences. In various aspects, the checksum of the baseline version of anti-debugging code may be predetermined (e.g., based on upon the final version of the code of the application that is made available for download). Executing the checksum code immediately upon application startup enables prompt detection of any attempts to modify or modifications of the anti-debugging code so that action may be taken to protect the security of the application.

[0058] At 314, a determination is made of whether tampering has been detected (e.g., if modification to the anti-debugging code was detected at 312). If tampering has not been detected then operations continue at 315, where the application continues with execution (e.g., the standard functionality of the application proceeds). If tampering has been detected, then operations continue at 318, where one or more copies or clones of the antidebugging code are executed, such as one or more backup modules 230 of FIG. 2. For example, the one or more clones of the anti-debugging code may include a ptrace attach command, may otherwise execute identical or similar functionality to the anti-debugging code that executed at 304, or the like. In some aspects, one or more clones of the antidebugging code execute if the main anti-debugging code (e.g., blocking module 210 of FIG. 2) has been bypassed.

[0059] In certain aspects, additional checksum code executes at 316, such as if tampering is detected at 314. For example, the additional checksum code may involve performing a checksum computation with a range that includes the one or more clones of the anti-debugging code (e.g., backup modules 230 of FIG. 2). Generally, the checksum code involves determining whether the one or more clones of the anti-debugging code have been modified, such as comparing one or more checksums associated with the current versions of the one or more clones of the anti-debugging code to one or more checksumsassociated with a baseline version of the clones of the anti-debugging code to determine whether there are any differences. If any modification is detected (e.g., based on a difference in the checksums), this may prompt one or more preventive actions (e.g., 322).

[0060] At 320, detect debugger code executes, such as if tampering is detected at 314. For example, the detect debugger code may determine whether a debugger attempts to connect to or has connected to the debugger port of the application (e.g., an application that performs functionality described above with respect to FIG. 1). If a debugger is detected, this may prompt one or more preventive actions (e.g., 322).

[0061] At 322, defense in depth code executes, such as on an ongoing basis, at regular intervals, when one or more conditions occur (e.g., when a security event occurs, such as modification to anti-debugging code or if a debugger is detected), or some combination of these. For example, the defense in depth code may monitor results of the checksum code at 312 and, in some aspects, 316, the results of the detect debugger code at 320, or results of a checksum of the detect debugger code (e.g., to detect modification of the detect debugger code), or some combination of these. The defense in depth code may also monitor whether the device has been placed in root mode, for one or more other conditions, or for some combination of these conditions. The defense in depth code may take one or more preventive actions upon detection of one or more security events (e.g., modification of any anti-debugging code or debugger detector code, detection of a debugger, detection of the device being placed in root mode, some combination of these events, or the like). Preventive actions may include, for example, terminating execution of the application, restricting functionality of the application, generating one or more notifications, blocking one or more users or devices from installing or using the application, some combination of these actions, or the like. In some aspects, the defense in depth code uses techniques described above to determine whether one or more security events are associated with an attacker or a victim, and chooses which preventive actions to take based upon whether the one or more security events are associated with an attacker or a victim.

[0062] FIG. 4 illustrates an example process 400 for instrumentation tool blocking to enhance computing security of a computing application, in accordance with certain aspects. In various aspects, process 400 may be performed by one or more modules of an applicationthat performs functionality described above with respect to FIG. 1 such as one or more of the modules in FIG. 2. Process 400 is similar to process 300 of FIG. 3, except that process 400 is focused on blocking of instrumentation tools such as Frida, while process 300 is focused on blocking of debuggers. In various aspects, process 400 and process 300 may be combined or performed in combination.

[0063] At 402, an application starts up. At 404, instrumentation tool (e.g., Frida) blocking code of the application executes, such as blocking module 210 of FIG. 2. In some aspects, the instrumentation tool blocking code includes a ptrace command. Frida uses ptrace to inject code into an application process. In some aspects, Frida or an instrumentation tool can be blocked using the same ptrace blocking code used for debugger blocking. In some aspects, the instrumentation tool blocking code further leverages a firewall that whitelists ports that are required by the application and blocks all others. For example, Frida’s Gadget is a shared library meant to be loaded by programs to be instrumented when the injected mode of operation (e.g., using ptrace to inject code into an application process) isn’t suitable. A Frida Gadget component may allow an external Frida server to connect via a socket on an arbitrary port. Thus, a firewall may provide further security by blocking such connections.

[0064] Executing the instrumentation tool blocking code immediately upon application startup is beneficial, as it preemptively blocks instrumentation tool access to the application without allowing a time gap for such access to occur. In some aspects, the blocking code may be placed as early (e.g., in execution order) in the application code as possible to allow blocking of debugger and instrumentation tools as quickly as possible after start of the application.

[0065] At 410, some trigger condition occurs, such as application startup, expiration of a timer, some combination of these conditions, or the like. In one example, 410 occurs at application startup and then again at regular intervals (e.g., periodically). At 412, checksum code of the application executes, such as blocking bypass check module 220 of FIG. 2. For example, the checksum code may involve performing a checksum computation with a range that includes the instrumentation tool blocking code (e.g., blocking module 210 of FIG. 2). Generally, the checksum code involves determining whether the instrumentationtool blocking code has been modified, such as comparing a checksum of the current version of the instrumentation tool blocking code in the application to a checksum of the baseline version of the instrumentation tool blocking code to deteimine whether there are any differences. Executing the checksum code immediately upon application startup enables prompt detection of any attempts to modify the instrumentation tool blocking code so that action may be taken to protect the security of the application.

[0066] At 414, a deteimination is made of whether tampering has been detected (e.g., if modification to the instrumentation tool blocking code was detected at 412). If tampering has been detected, then operations continue at 416, where detect dynamic instrumentation code executes. For example, the detect dynamic instrumentation code may determine whether an instrumentation tool such as Frida attempts to connect to the debugger port of the application. If a dynamic instrumentation tool is detected, this may prompt one or more preventive actions (e.g., 422).

[0067] At 418, root detection code executes (e.g., if an instrumentation tool is detected, at application startup, at regular intervals, if modification to the instrumentation tool blocking code, if some combination of these conditions occurs, or if one or more other conditions occur). The root detection code may determine if the device on which the application executes has been placed in root mode. If the root detection code detects that the device has been placed in root mode, if one or more other conditions occur (e.g., if modification to the instrumentation tool blocking code is detected at 412, if an instrumentation tool is detected at 416, or the like), or some combination of these conditions occur then the application may be crashed at 420. For example, if modification to the instrumentation tool blocking code is detected, an instrumentation tool is detected, and the phone has root privileges, it is highly unlikely (e.g., near zero percent chance) that these security events are a false positive, and terminating execution of the application may be the best option. In some aspects, one or more other actions may be alternatively or additionally performed, such as restricting functionality of the application, generating one or more notifications, some combination of these actions, or the like.

[0068] At 422, defense in depth code executes, such as on an ongoing basis, at regular intervals, when one or more conditions occur (e.g., when a security event occurs, such asmodification to instrumentation tool blocking code at 412 or if an instrumentation tool is detected at 416), or some combination of these. For example, the defense in depth code may monitor results of the checksum code at 412, the results of the detect instrumentation tool code at 416, results of a checksum of the detect instrumentation tool code (e.g., to detect modification of the detect instrumentation tool code), or some combination of these results. The defense in depth code may also monitor whether the device has been placed in root mode (e.g., at 418), for one or more other conditions, or for some combination of these conditions. The defense in depth code may take one or more preventive actions upon detection of one or more security events (e.g., modification of any instrumentation tool blocking code or instrumentation tool detector code, detection of an instrumentation tool, detection of the device being placed in root mode,, some combination of these events, or the like). Preventive actions may include, for example, terminating execution of the application, restricting functionality of the application, generating one or more notifications, blocking one or more users or devices from installing or using the application, some combination of these actions, or the like. In some aspects, the defense in depth code uses techniques described above to determine whether one or more security events are associated with an attacker or a victim and chooses which preventive actions to take based upon whether the one or more security events are associated with an attacker or a victim.

[0069] While not shown, process 400 may also include one or more clones of the instrumentation tool blocking code (e.g., backup modules 230 of FIG. 2), similar to the clones of the anti-debugger code at 318 of FIG. 3. For example, such clones may activate when tampering is detected at 414, and may execute the same or similar functionality to the instrumentation tool blocking code at 404 (e.g., connecting to the debugger port of the application and, in some aspects, utilizing a firewall to block connections to non- whitelisted ports associated with the application).

[0070] FIG. 5 is a flow diagram 500 depicting a process for enhancing security of a computing application, in accordance with certain aspects. In some aspects, the process 500 can be executed, for example, by one or more modules of an application that performs functionality described above with respect to FIG. 1, such as one or more of the modulesin FIG. 2. In addition, or alternatively, the process 500 can be executed, for example, by computing device 600 of FIG. 6, described below.

[0071] At block 502, a debugger blocking module of the computing application establishes a connection to a debugger port associated with the computing application to block other connections to the debugger port. For example, the debugger blocking module may be blocking module 210 of FIG. 2, and may include anti-debugger code similar’ to the code at 304 of FIG. 3 or instrumentation tool blocking code similar’ to the code at 404 of FIG. 4.

[0072] In some aspects, the establishing of the connection to the debugger port associated with the computing application blocks connections to the debugger port by debuggers or instrumentation tools (e.g., Frida).

[0073] In certain aspects, the computing application (e.g., an application that performs functionality described above with respect to FIG. 1) stores data related to a user of an analyte sensor system, and the establishing of the connection to the debugger port associated with the computing application blocks other connections to the debugger port and protects the data related to the user of the analyte sensor system.

[0074] At block 504, a bypass check module of the computing application determines that the debugger blocking module has been modified. For example, the bypass check module may be blocking bypass check module 220 of FIG. 2 and may include checksum code similar to the code at 312 of FIG. 3 or 412 of FIG. 4.

[0075] At block 506, responsive to the determining that the debugger blocking module has been modified, the computing application performs one or more actions to protect the computing application from debugger access.

[0076] In some aspects, the performing of the one or more actions to protect the computing application from debugger access comprises terminating execution of the computing application (e.g., crashing the application). In certain aspects, the performing of the one or more actions to protect the computing application from debugger access comprises activating one or more additional debugger blocking modules of the computing application, wherein each of the one or more additional debugger blocking modules isconfigured to, when activated, establish a respective connection to the debugger port associated with the computing application.

[0077] In some aspects, the performing of the one or more actions to protect the computing application from debugger access comprises restricting one or more operations of the computing application. In certain aspects, the performing, by the computing application, the one or more actions to protect the computing application from debugger access is further responsive to determining that the computer system has been configured in a root access mode.

[0078] Certain aspects further comprise determining, based on one or more attributes associated with the computing application, a classification associated with the determining that the debugger blocking module has been modified, wherein the one or more actions are determined based on the classification.

[0079] In some aspects, the one or more attributes associated with the computing application comprise a universal application identifier assigned at a time that the computing application was installed on the computer system. In certain aspects, the determining, by the bypass check module of the computing application, that the debugger blocking module has been modified is based on a checksum computation with respect to a portion of code associated with the debugger blocking module.

[0080] FIG. 6 depicts aspects of an example communications device 600. In some aspects, communications device 600 is a wearable device, such as the SS 8 described with respect to FIG. 1, or a display device 110, 120, 130, or 140 of FIG. 1, or server system 134 of FIG. 1, or communications device 600 may be representative of some combination of these devices.

[0081] The communications device 600 includes a processing system 605 coupled to the transceiver 655 (e.g., a transmitter, a receiver, or both). The transceiver 655 is configured to transmit and receive signals for the communications device 600 via the antenna 660, such as the various signals and messages as described herein. The processing system 605 may be configured to perform processing functions for the communications device 600, including processing signals received or to be transmitted by the communications device 600 or both.

[0082] The processing system 605 includes one or more processors 610. The one or more processors 610 are coupled to a computer-readable medium / memory 630 via a bus 650. In certain aspects, the computer-readable medium / memory 630 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 610, cause the one or more processors 610 to perform the method 500 described with respect to FIG. 5, or any aspect related to this method. Note that reference to a processor performing a function of communications device 600 may include one or more processors 610 performing that function of communications device 600.

[0083] In the depicted example, computer-readable medium / memory 630 stores code (e.g., executable instructions), such as code for establishing 635, code for determining 636, code for performing 637, code for detecting 638, code for activating 639, and code for storing 640. Processing of the code for establishing 635, code for determining 636, code for performing 637, code for detecting 638, code for activating 639, and code for storing 640 may cause the communications device 600 to perform the method 500 described with respect to FIG. 5, or any aspect related to these methods.

[0084] The one or more processors 610 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium / memory 630, including circuitry for establishing 615, circuitry for determining 616, circuitry for performing 617, circuitry for detecting 618, circuitry for activating 619, and circuitry for storing 620. Processing with circuitry for establishing 615, circuitry for determining 616, circuitry for performing 617, circuitry for detecting 618, circuitry for activating 619, and circuitry for storing 620 may cause the communications device 600 to perform the method 500 described with respect to FIG. 5, or any aspect related to these methods.

[0085] Each of these non-limiting examples can stand on its own or can be combined in various permutations or combinations with one or more of the other examples.

[0086] The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific aspects in which the invention can be practiced. These aspects are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples inwhich only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0087] In the event of inconsistent usages between this document and any documents so incorporated by reference, the usage in this document controls.

[0088] In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In this document, the terms “including” and “in which” arc used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

[0089] Geometric terms, such as “parallel”, “perpendicular”, “round”, or “square”, are not intended to require absolute mathematical precision, unless the context indicates otherwise. Instead, such geometric terms allow for variations due to manufacturing or equivalent functions. For example, if an element is described as “round” or “generally round”, a component that is not precisely circular (e.g., one that is slightly oblong or is a many-sided polygon) is still encompassed by this description.

[0090] Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a computer-readable medium or machine- readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level languagecode, or the like. Such code can include computer readable instructions for performing various methods. The code can form portions of computer program products. Further, in an example, the code can be tangibly stored on one or more volatile, non-transitory, or nonvolatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable media can include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memories (RAMs), read only memories (ROMs), and the like.

[0091] The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) can be used in combination with each other. Other aspects can be used, such as by one of ordinary skill in the ait upon reviewing the above description. The Abstract is provided to comply with 37 C.F.R. § 1.72(b), to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features can be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed aspect. Thus, the following claims are hereby incorporated into the Detailed Description as examples or aspects, with each claim standing on its own as a separate aspect, and it is contemplated that such aspects can be combined with each other in various combinations or permutations. The scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

WHAT IS CLAIMED IS:

1. A method of enhancing security of a computing application, the method comprising, by a computer system: establishing, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port; determining, by a bypass check module of the computing application, that the debugger blocking module has been modified; and responsive to the determining that the debugger blocking module has been modified, performing, by the computing application, one or more actions to protect the computing application from debugger access.

2. The method of claim 1, wherein the performing of the one or more actions to protect the computing application from debugger access comprises terminating execution of the computing application.

3. The method of claim 1, wherein the performing of the one or more actions to protect the computing application from debugger access comprises activating one or more additional debugger blocking modules of the computing application, wherein each of the one or more additional debugger blocking modules is configured to, when activated, establish a respective connection to the debugger port associated with the computing application.

4. The method of claim 1, wherein the establishing of the connection to the debugger port associated with the computing application blocks connections to the debugger port by a debugger or instrumentation tool.

5. The method of claim 1, further comprising determining, based on one or more attributes associated with the computing application, a classification associated with the determining that the debugger blocking module has been modified, wherein the one or more actions are determined based on the classification.

6. The method of claim 5, wherein the one or more attributes associated with the computing application comprise a universal application identifier assigned at a time that the computing application was installed on the computer system.

7. The method of claim 5, wherein the determining, by the bypass check module of the computing application, that the debugger blocking module has been modified is based on a checksum computation with respect to a portion of code associated with the debugger blocking module.

8. The method of claim 1, wherein the performing of the one or more actions to protect the computing application from debugger access comprises restricting one or more operations of the computing application.

9. The method of claim 1, wherein the performing, by the computing application, the one or more actions to protect the computing application from debugger access is further responsive to determining that the computer system has been configured in a root access mode.

10. A method of enhancing security of a computing application, the method comprising, by a computer system: establishing, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port; detecting one or more conditions; and activating, based on the detecting of the one or more conditions, one or more additional debugger blocking modules of the computing application, wherein each of the one or more additional debugger blocking modules is configured to, when activated, establish a respective connection to the debugger port associated with the computing application.

11. The method of claim 10, wherein the detecting of the one or more conditions comprises determining that the debugger blocking module has been modified.

12. The method of claim 11, further comprising terminating execution of the computing application based on the detecting of the one or more conditions.

13. A system for enhancing security of a computing application, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: establish, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port; determine, by a bypass check module of the computing application, that the debugger blocking module has been modified; and responsive to the determining that the debugger blocking module has been modified, perform, by the computing application, one or more actions to protect the computing application from debugger access.

14. A computer-program product comprising a non-transitory computer-usable medium having computer-readable program code embodied therein, the computer-readable program code adapted to be executed to implement a method comprising: storing, by a computing application, data related to a user of an analyte sensor system; and establishing, by a debugger blocking module of the computing application, a connection to a debugger port associated with the computing application to block other connections to the debugger port and protect the data related to the user of the analyte sensor system.

15. The computer-program product of claim 14, wherein the method further comprises performing one or more actions to protect the computing application from debugger access based on detecting one or more conditions.

16. The computer-program product of claim 15, wherein the performing of the one or more actions to protect the computing application from debugger access comprises terminating execution of the computing application.

17. The computer-program product of claim 15, wherein the performing of the one or more actions to protect the computing application from debugger access comprises activating one or more additional debugger blocking modules of the computing application, wherein each of the one or more additional debugger blocking modules is configured to, when activated, establish a respective connection to the debugger port associated with the computing application.

18. The computer-program product of claim 15, wherein the method further comprises determining, based on one or more attributes associated with the computing application, a classification associated with the one or more conditions, wherein the one or more actions are determined based on the classification.

19. The computer-program product of claim 18, wherein the one or more attributes associated with the computing application comprise a universal application identifier assigned at a time that the computing application was installed on a computer system.

20. The computer-program product of claim 14, wherein the establishing of the connection to the debugger port associated with the computing application blocks connections to the debugger port by debuggers or instrumentation tools.

21. The computer- pro gram product of claim 14, wherein the method further comprises determining, by a bypass check module of the computing application, that thedebugger blocking module has been modified based on a checksum computation with respect to a portion of code associated with the debugger blocking module. l. The computer-program product of claim 21, wherein the method further comprises performing one or more actions to protect the computing application from debugger access based on the determining that the debugger blocking module has been modified.

23. The computer-program product of claim 22, wherein the performing of the one or more actions to protect the computing application from debugger access is further responsive to determining that a computer system on which the computing application is running has been configured in a root access mode.

Images