A method and system for recovering electronic data of GoIP device

Abstract

Disclosed are a method and system for recovering electronic data from a GoIP device. The system includes, in response to a current file offset position (CurrentOffset) being less than the size (FileSize) of a GoIP unallocated cluster file or a GoIP deleted data block, sequentially applying IMEI and IMSI integrity judgment rules and short message validity judgment rules to the data at the CurrentOffset position; in response to a successful rule judgment, reading the corresponding data into a corresponding result database, incrementing CurrentOffset, and repeating the above judgment until CurrentOffset is greater than or equal to FileSize; and displaying the deleted and recovered IMSI, IMEI, and short message. This application can extract and recover IMEI / IMSI and SMS data from unallocated clusters and deleted blocks, and can be applied to data recovery scenarios involving GoIP remotely deleted data or other novel devices with other communication modules.

Description

Technical Field

[0001] The present invention relates to the technical field of data recovery, and in particular to a method and system for recovering electronic data of a GoIP device. Background Art

[0002] GOIP works by converting digital signals from IP networks, such as text messages and voice messages, into signals in the mobile communication frequency band for transmission over the mobile communication network. Because GOIP supports the simultaneous use of multiple SIM cards, it enables group text messaging and group dialing. Combined with a remote server, it can also enable remote dialing. Criminals have exploited this feature to effectively separate human and machine identities, thereby evading crackdowns by relevant authorities. Therefore, GOIP devices primarily store configuration information, including the IMEI / IMSI number associated with the communication module, call logs and text messages related to group dialing and group messaging, and IP addresses and accounts related to remote services.

[0003] As GOIP devices are increasingly used by criminals, a growing number of manufacturers are conducting forensic research targeting them. The technology for recovering electronic data deleted from GOIP devices is a hot topic in the fields of embedded smart device security and information security. Currently, there are no mature solutions for recovering electronic data deleted from GOIP devices, and the literature is limited, failing to meet the needs of the development of IoT embedded forensic security. Summary of the Invention

[0004] In order to solve the above technical problems existing in the prior art, the present invention proposes a method and system for recovering electronic data of a GOIP device to solve the above technical problems.

[0005] According to one aspect of the present invention, a method for recovering electronic data of a GoIP device is provided, comprising:

[0006] S1: In response to the current file offset position CurrentOffset being smaller than the size FileSize of the GoIP unallocated cluster file or the GoIP deleted data block, the IMEI integrity judgment rule, the IMSI integrity judgment rule, and the short message validity judgment rule are sequentially applied to the data at the CurrentOffset position;

[0007] S2: In response to the rule being judged successfully, read the corresponding data into the corresponding result database, increment the CurrentOffset, and repeat S1 until the CurrentOffset is greater than or equal to the FileSize;

[0008] S3: Displays the deleted and restored IMSI, IMEI and SMS messages.

[0009] In some specific embodiments, the IMEI integrity judgment rule, the IMSI integrity judgment rule, and the short message validity judgment rule are sequentially performed on the data at the CurrentOffset position in S1, specifically including:

[0010] S11: Perform IMEI integrity check on the data at the CurrentOffset position. If the check succeeds, read the corresponding data into the IMEI result database, set CurrentOffset = CurrentOffset + 15, and jump to S1 to check whether CurrentOffset is greater than or equal to FileSize. If not, go to S12.

[0011] S12: Perform IMSI integrity check on the data at the CurrentOffset position. If the check succeeds, read the corresponding data into the IMSI result database, set CurrentOffset = CurrentOffset + 15, and jump to S1 to check whether CurrentOffset is greater than or equal to FileSize. If not, proceed to S13.

[0012] S13: Apply the short message validity judgment rule to the data at the CurrentOffset position. If the judgment is successful, read the corresponding SMS data stored in the corresponding rule into the result database, set CurrentOffset = CurrentOffset + DmsLen, and jump to S1 to determine whether CurrentOffset is greater than or equal to FileSize. If not, set CurrentOffset + 1 and jump to S1.

[0013] In some specific embodiments, the IMEI integrity determination rule includes performing IMEI feature and verification on the incoming 15-byte data block to determine whether the 15 bytes of data starting at the position meet the following conditions:

[0014] The first two bytes of the data are traversed and matched with the elements in the set MEGC, and are equal to one of the elements MEGCN. The set MEGC is the set of the first two digits of the IMEI number TAC of the GoIP device.

[0015] The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9;

[0016] The Luhn algorithm is used to calculate the check value Dvalue on the first 14 bytes of data. Dvalue is equal to the 15th digit.

[0017] In some specific embodiments, the IMSI integrity determination rule includes performing IMSI feature and verification on the incoming 16-byte data block to determine whether the 16 bytes of data starting at that position meet the following conditions:

[0018] The first three bytes of the data are traversed and matched with the elements in the set MSGC, and are equal to one of the elements MSGCN. The set MSGC is a set of MMC codes of domestic IMSI numbers.

[0019] The 4th and 5th bytes of the data are traversed and matched with the elements in the set MSNC, and they are equal to one of the elements MSGCN;

[0020] The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9;

[0021] The 16th byte in the data block is the terminator of the hexadecimal digits \x00, \x0a, or \x0d.

[0022] In some specific embodiments, the short message validity judgment rule includes judging the short message characteristics and checking the incoming data block. The valid short message data meets the following conditions:

[0023] The first N bytes of the data are traversed and matched with the elements of the SMS feature set DMS, and they are equal to one of the elements DMSN;

[0024] The data offset CurrentOffset = CurrentOffset + 4 is increased byte by byte. Each additional match is equal to '|E', and DmsEndOffset = CurrentOffset is recorded.

[0025] Extract the data between DmsStartOffset and DmsEndOffset and split the string using the '|' symbol. The number of strings after the split must be at least greater than or equal to 4, and the third string is a time string with a size of 19 bytes. Save and record the second string, the phone number, and the fourth string, the SMS content, respectively. Both are not empty, and record (DmsEndOffset-DmsStartOffset) as DmsLen.

[0026] According to a second aspect of the present invention, a computer-readable storage medium is provided, on which one or more computer programs are stored. When the one or more computer programs are executed by a computer processor, any one of the above methods is implemented.

[0027] According to a third aspect of the present invention, a system for recovering electronic data of a GoIP device is provided, the system comprising:

[0028] a rule judgment unit configured to, in response to a current file offset position CurrentOffset being smaller than a size FileSize of a GoIP unallocated cluster file or a GoIP deleted data block, sequentially perform an IMEI integrity judgment rule, an IMSI integrity judgment rule, and a short message validity judgment rule on data at the CurrentOffset position;

[0029] a reading unit configured to, in response to a successful rule determination, read corresponding data into a corresponding result database, increment CurrentOffset, and repeat S1 until CurrentOffset is greater than or equal to FileSize;

[0030] The data display unit is configured to display the deleted and restored IMSI, IMEI and short messages.

[0031] In some specific embodiments, the rule judgment unit specifically includes:

[0032] S11: Perform IMEI integrity check on the data at the CurrentOffset position. If the check succeeds, read the corresponding data into the IMEI result database, set CurrentOffset = CurrentOffset + 15, and jump to S1 to check whether CurrentOffset is greater than or equal to FileSize. If not, go to S12.

[0033] S12: Perform IMSI integrity check on the data at the CurrentOffset position. If the check succeeds, read the corresponding data into the IMSI result database, set CurrentOffset = CurrentOffset + 15, and jump to S1 to check whether CurrentOffset is greater than or equal to FileSize. If not, proceed to S13.

[0034] S13: Apply the short message validity judgment rule to the data at the CurrentOffset position. If the judgment is successful, read the corresponding SMS data stored in the corresponding rule into the result database, set CurrentOffset = CurrentOffset + DmsLen, and jump to S1 to determine whether CurrentOffset is greater than or equal to FileSize. If not, set CurrentOffset + 1 and jump to re-judge the rule.

[0035] In some specific embodiments, the IMEI integrity determination rule includes performing IMEI feature and verification on the incoming 15-byte data block to determine whether the 15 bytes of data starting at the position meet the following conditions:

[0036] The first two bytes of the data are traversed and matched with the elements in the set MEGC, and are equal to one of the elements MEGCN. The set MEGC is the set of the first two digits of the IMEI number TAC of the GoIP device.

[0037] The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9;

[0038] The Luhn algorithm is used to calculate the check value Dvalue on the first 14 bytes of data. Dvalue is equal to the 15th digit.

[0039] In some specific embodiments, the IMSI integrity determination rule includes performing IMSI feature and verification on the incoming 16-byte data block to determine whether the 16 bytes of data starting at that position meet the following conditions:

[0040] The first three bytes of the data are traversed and matched with the elements in the set MSGC, and are equal to one of the elements MSGCN. The set MSGC is a set of MMC codes of domestic IMSI numbers.

[0041] The 4th and 5th bytes of the data are traversed and matched with the elements in the set MSNC, and they are equal to one of the elements MSGCN;

[0042] The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9;

[0043] The 16th byte in the data block is the terminator of the hexadecimal digits \x00, \x0a, or \x0d.

[0044] In some specific embodiments, the short message validity judgment rule includes judging the short message characteristics and checking the incoming data block. The valid short message data meets the following conditions:

[0045] The first N bytes of the data are traversed and matched with the elements of the SMS feature set DMS, and they are equal to one of the elements DMSN;

[0046] The data offset CurrentOffset = CurrentOffset + 4 is increased byte by byte. Each additional match is equal to '|E', and DmsEndOffset = CurrentOffset is recorded.

[0047] Extract the data between DmsStartOffset and DmsEndOffset and split the string using the '|' symbol. The number of strings after the split must be at least greater than or equal to 4, and the third string is a time string with a size of 19 bytes. Save and record the second string, the phone number, and the fourth string, the SMS content, respectively. Both are not empty, and record (DmsEndOffset-DmsStartOffset) as DmsLen.

[0048] This paper proposes a method and system for recovering electronic data from GoIP devices. This data deletion recovery method, based on IMEI / IMSI code features and short message keyword features, can automatically identify key IMEI / IMSI and SMS data in GoIP unassigned clusters and deleted blocks based on a set of input features. This method provides an effective analysis method for complex forensic analysis scenarios, such as damaged IMEI module nameplates and remote deletion of GoIP device data. With the development of IoT technology, this method can be applied not only to complex scenarios such as remote GoIP data deletion, but also to data recovery scenarios for new devices using 3G, 4G, and 5G communication modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated into and constitute a part of this specification. The accompanying drawings illustrate the embodiments and, together with the description, serve to explain the principles of the invention. Other embodiments and many of the intended advantages of the embodiments will be readily apparent as they become better understood by reference to the following detailed description. Other features, objects, and advantages of the present application will become more apparent upon reading the detailed description of the non-limiting embodiments made with reference to the following drawings:

[0050] Figure 1 is a flow chart of a method for recovering electronic data of a GoIP device according to an embodiment of the present application;

[0051] Figure 2 This is a flowchart of a method for recovering electronic data of a GoIP device according to a specific embodiment of the present application;

[0052] Figure 3 This is a framework diagram of a GoIP device electronic data recovery system according to an embodiment of the present application;

[0053] Figure 4 It is a structural diagram of a computer system suitable for implementing the electronic device of the embodiment of the present application. DETAILED DESCRIPTION

[0054] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the relevant invention are shown in the accompanying drawings.

[0055] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0056] Figure 1 FIG. 1 shows a flow chart of a method for recovering electronic data of a GoIP device according to an embodiment of the present application. Figure 1 As shown, the method includes:

[0057] S101: In response to the current file offset position CurrentOffset being smaller than the size FileSize of the GoIP unallocated cluster file or the GoIP deleted data block, the data at the CurrentOffset position is sequentially subjected to IMEI integrity judgment rule, IMSI integrity judgment rule and short message validity judgment rule.

[0058] In a specific embodiment, sequentially performing the IMEI integrity judgment rule, the IMSI integrity judgment rule, and the short message validity judgment rule on the data at the CurrentOffset position specifically includes:

[0059] S11: Perform IMEI integrity check on the data at the CurrentOffset position. If the check succeeds, read the corresponding data into the IMEI result database, set CurrentOffset = CurrentOffset + 15, and jump to S1 to check whether CurrentOffset is greater than or equal to FileSize. If not, go to S12.

[0060] S12: Perform IMSI integrity check on the data at the CurrentOffset position. If the check succeeds, read the corresponding data into the IMSI result database, set CurrentOffset = CurrentOffset + 15, and jump to S1 to check whether CurrentOffset is greater than or equal to FileSize. If not, proceed to S13.

[0061] S13: Apply the short message validity judgment rule to the data at the CurrentOffset position. If the judgment is successful, read the corresponding SMS data stored in the corresponding rule into the result database, set CurrentOffset = CurrentOffset + DmsLen, and jump to S1 to determine whether CurrentOffset is greater than or equal to FileSize. If not, set CurrentOffset + 1 and jump to S101.

[0062] S102: In response to the rule being judged as successful, the corresponding data is read into the corresponding result database, CurrentOffset is incremented, and S101 is repeated until CurrentOffset is greater than or equal to FileSize.

[0063] In a specific embodiment, the IMEI integrity judgment rule includes performing IMEI feature and verification judgment on the incoming 15-byte data block, and judging whether the 15 bytes of data starting from this position meet the conditions: the first two bytes of the data are traversed and matched with the elements in the set MEGC, and are equal to one of the elements MEGCN, and the set MEGC is the first two digits of the GoIP device IMEI number TAC allocation agency code set; the 15 bytes of data in the data block are all binary-encoded decimal numbers 0-9; the first 14 bytes of data are calculated by the Luhn algorithm to obtain the check value Dvalue, and Dvalue is equal to the 15th digit.

[0064] In a specific embodiment, the IMSI integrity judgment rule includes performing IMSI feature and verification judgment on the incoming 16-byte data block, and judging whether the 16 bytes of data starting at this position meet the following conditions: the first 3 bytes of the data are traversally matched with the elements in the set MSGC and are equal to one of the elements MSGCN, where the set MSGC is a set consisting of MMC codes of domestic IMSI numbers; the 4th and 5th bytes of the data are traversally matched with the elements in the set MSNC and are equal to one of the elements MSGCN; the 15 bytes of data in the data block are all binary-coded decimal numbers 0-9; and the 16th byte in the data block is a terminator of the hexadecimal digits \x00, \x0a, or \x0d.

[0065] In a specific embodiment, the short message validity judgment rule includes judging the short message features and verification of the incoming data block. The valid short message data meets the following conditions: the first N bytes of the data are traversed and matched with the elements of the SMS feature set DMS, and are equal to one of the elements DMSN; the data offset CurrentOffset = CurrentOffset + 4, increases byte by byte, and each additional match is equal to '|E', and DmsEndOffset = CurrentOffset is recorded; the data between DmsStartOffset and DmsEndOffset is extracted, and the string is split using the '|' symbol. The number of split strings must be at least greater than or equal to 4, and the third is a time string with a size of 19 bytes. The second string phone number and the fourth string SMS content are saved and recorded respectively, and neither is empty, and (DmsEndOffset-DmsStartOffset) is recorded as DmsLen.

[0066] S103: Display the deleted and restored IMSI, IMEI and short messages.

[0067] Continue to refer Figure 2 , Figure 2 A flowchart of a method for recovering electronic data of a GoIP device according to a specific embodiment of the present application is shown. Figure 2 As shown, the line of sight process of this method mainly includes the following steps:

[0068] Step 1: Assume that the size of the GoIP unallocated cluster file or the GoIP deleted data block is FileSize, use the variable CurrentOffset to represent the current file offset position, and the initial value is 0.

[0069] Step 2: Determine whether CurrentOffset is greater than or equal to FileSize. If so, jump to step 7. If not, jump to the next step.

[0070] Step 3: Perform the "IMEI integrity judgment rule" on the data at the CurrentOffset position. If the judgment is successful, read the corresponding data into the IMEI result database, CurrentOffset = CurrentOffset + 15, jump to step 2, if not jump to the next step.

[0071] Step 4: The data at the CurrentOffset position is judged according to the "IMSI integrity judgment rule". If the judgment is successful, the corresponding data is read into the IMSI result database, CurrentOffset = CurrentOffset + 15, and the process goes to step 2. If not, the process goes to the next step.

[0072] Step 5: The data at the CurrentOffset position is judged according to the "Short Message Validity Judgment Rule". If the judgment is successful, the corresponding SMS data stored in the rule is read into the result database. CurrentOffset = CurrentOffset + DmsLen, and the process goes to step 2. If not, the process goes to the next step.

[0073] Step 6: Assign CurrentOffset = CurrentOffset + 1, and jump to step 2.

[0074] Step 7: If the deleted and restored IMSI / IMEI and SMS are not empty, they will be displayed.

[0075] Step 7: The process ends here.

[0076] In the embodiments of the present application, IMEI (International Mobile Equipment Identity) is defined in detail in the 3GPP TS 22.016 International Mobile Station Equipment Identity Code specification published by the international 3GPP standards organization and the Technical Requirements for International Mobile Equipment Identity (IMEI) for 2GHz TD-SCDMA / WCDMA Digital Cellular Mobile Communication Networks published by the Ministry of Industry and Information Technology of China. As shown in the following table:

[0077] TAC SNR CD / SD NNXXXXYY ZZZZZZ D

[0078] The IMEI consists of three parts: TAC (Type Allocation Code), SNR (Serial Number), and CD / SD, totaling 15 digits. All digits are binary-coded decimal numbers from 0 to 9. Numbers outside this range are invalid.

[0079] The TAC is an 8-digit number. The first two digits, NN, represent the identifier of the issuing authority, and the remaining six digits, XXXXYY, are the mobile device model identifier defined by the authority. The SNR, consisting of six digits, ZZZZZZ, uniquely identifies each mobile device model. The CD / SD (Check Digit / Spare Digit) check digits are used to perform arithmetic verification on the TAC and SNR digits. This is calculated using the Luhn algorithm in Appendix B of 3GPP TS 23.003.

[0080] IMSI (International Mobile Subscription Identity) is defined in detail in the 3GPP TS 23.003 Technical Specification Group Core Network and Terminals: Numbering, Addressing, and Identification Specifications published by the international 3GPP standards organization. As shown in the following table:

[0081] MCC MNC MISN CCC XX / XXX CC+MOM1M2M3+ABCD

[0082] IMSI consists of three parts: MCC (Mobile Country Code), MNC (Mobile Network Code), and MSIN (Mobile Subscriber Identification Number), also a total of 15 digits. All digits are binary-coded decimal numbers from 0 to 9. Numbers outside this range are invalid.

[0083] The MCC is the three-digit mobile country code, such as 460 for China and 284 for Bulgaria. The MNC consists of two or three digits, the length of which is determined by the MCC value. It can be two digits (European standard) or three digits (North American standard). The European standard two digits are used in China, such as 01 for China Mobile and 02 for China Unicom. The MSIN is assigned by the carrier and is typically nine or ten digits long. The general structure is CC+M0M1M2M3+ABCD. The CC is managed and assigned by the carrier. M0M1M2M3 can be coded based on region and may correspond to H0H1H2H3 in the MDN number. The ABCD digits are freely assignable. The MDN (Mobile Directory Number) is the mobile directory number. The MDN number is the number that the calling user needs to dial when a mobile user on the network is called. The MDN number is structured as CC+MAC+H0H1H2H3+ABCD, where CC is the country code; China uses 86. MAC: Mobile access code, such as 133 for China Unicom. H0H1H2H3: HLR identification code, assigned by China Unicom headquarters. ABCD: Mobile subscriber number, assigned by each HLR.

[0084] The SMS storage format is typically customized by the device manufacturer during development. Therefore, we can only identify common feature tags based on the storage formats used by common GoIP device manufacturers. For example, mainstream GoIP device manufacturers often store SMS data with the header tag '|SMS'. By identifying this tag and combining it with features such as the time and content of the message, we can recover the SMS data.

[0085] The present invention identifies GoIP data key features for unallocated clusters and deleted data blocks of GoIP chip mirrors, and designs corresponding key feature parsing functions to parse the data, thereby recovering GoIP key data.

[0086] For IMEI / IMSI data recovery, the IMEI / IMSI device serial number rules, such as specific country codes and organization codes, are used to match the starting position of the defined serial number. Other serial number structures, such as the checksum, are then combined to confirm the serial number's integrity. For SMS data recovery, a feature library is generated by analyzing SMS data from GoIP device manufacturers. Each feature in the library has a corresponding feature parsing function, which is used to parse and process the corresponding feature data. The identification rules and conceptual assumptions are as follows:

[0087] 1) Assume that the set MEGC = {86, 35, 01, 91, ..., MEGCN} is the set of the first two digits of the IMEI number TAC of the GoIP device, where 86 is the China TAC agency code, 35 corresponds to the UK BABT agency code, 01 corresponds to the US CTIA agency code, and 91 is the India MSAI agency code.

[0088] 2) Assume that the set MSGC={460, 284, ..., MSGCN} is a set of MMC codes of common IMSI numbers in China, where 460 represents China, 284 represents Bulgaria, etc. Domestic GoIP devices are generally Chinese, so the set retains 460.

[0089] 3) Assume that the set MSNC={01, 02, 03, ..., MSNCN} is a set consisting of the MNC mobile network operator codes of major domestic IMSIs, where 01 represents China Mobile, 02 represents China Unicom, and 03 represents China Telecom.

[0090] 4) Assume that the set SF={SF0, SF1, SF2, ..., SFN} is a set of short message deletion data feature recognition functions, such as SF0 is the SMS feature '|SMS' recognition and analysis function, which is used to determine the interception of valid SMS data.

[0091] 5) IMEI integrity judgment rule: the incoming 15-byte data block is judged by IMEI characteristics and verification. If the following conditions are met at the same time, the data block is judged to be IMEI serial number data. The specific conditions are as follows:

[0092] The first two bytes of the data are traversed and matched with the elements in the set MEGC, and are equal to one of the elements MEGCN;

[0093] The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9;

[0094] The Luhn algorithm is used to calculate the check value Dvalue on the first 14 bytes of data. Dvalue must be equal to the 15th digit.

[0095] The 15 bytes of data starting from this position meet the above three conditions.

[0096] 6) IMSI integrity judgment rule: The incoming 16-byte data block is judged by IMSI characteristics and verification. If the following conditions are met at the same time, the data block is judged to be IMSI serial number data. The specific conditions are as follows:

[0097] The first 3 bytes of the data are traversed and matched with the elements in the set MSGC, and are equal to one of the elements MSGCN;

[0098] The 4th and 5th bytes of the data are traversed and matched with the elements in the set MSNC, and they are equal to one of the elements MSGCN;

[0099] The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9;

[0100] The 16th byte in the data block is the terminator of the hexadecimal number \x00 or \x0a or \x0d;

[0101] The 16 bytes of data starting from this position meet the above three conditions.

[0102] 7) Short message validity judgment rule: The incoming data block is judged by short message characteristics and verification. If the following conditions are met at the same time, the data block is judged to be valid short message data. Now take the element feature '|SMS' in the SMS feature set DMS as an example. The corresponding feature parsing function SF0 has a data starting offset of DmsStartOffset = CurrentOffset. The specific conditions are as follows:

[0103] The first N bytes of the data are traversed and matched with the elements of the SMS feature set DMS, and are equal to one of the elements DMSN. Here, the feature element '|SMS' is taken as an example, and the corresponding feature parsing function is SFN in the feature parsing function set SF;

[0104] The data offset CurrentOffset = CurrentOffset + 4, and continues to increase byte by byte. Each time a match is added, it is checked whether it is equal to '|E'. If they are equal, it means that the condition is met, and DmsEndOffset = CurrentOffset is recorded. If they are not equal, the condition is not met;

[0105] Extract the data between DmsStartOffset and DmsEndOffset and split the string using the '|' symbol. The resulting string must contain at least four characters, with the third character being the time string, which is 19 bytes long. Also save the second character string, the phone number, and the fourth character string, the text message content. Both must be non-null. Record (DmsEndOffset - DmsStartOffset) as DmsLen.

[0106] Although GoIP's key data files such as IMEI / IMSI and short messages can be deleted remotely, the local device's chip image unallocated clusters or garbage collection areas still store the deleted data. This application uses features such as IMEI / IMSI and the device manufacturer's short message storage format to recover data. For example, the various segment structures and checksums defined in the IMEI and IMSI standard protocols are used as recovery reference features, and the device manufacturer stores text messages with special character features. Based on the above data features, this application proposes an electronic data deletion recovery method based on GoIP data features. This method can automatically identify the key IMEI / IMSI and text message data in the GoIP unallocated clusters and deleted blocks based on the input feature set. With the development of Internet of Things technology, in addition to being applied to complex scenarios such as GoIP remote data deletion, it can also be applied to data recovery scenarios of new devices using 3G, 4G, 5G and other communication modules.

[0107] Continue to refer Figure 3 , Figure 3 The framework diagram of the system for recovering electronic data from a GOIP device according to an embodiment of the present invention is shown. The system specifically includes a rule judgment unit 301, a reading unit 302, and a data display unit 303. The rule judgment unit 301 is configured to, in response to the current file offset position CurrentOffset being less than the size FileSize of the GoIP unallocated cluster file or the GoIP deleted data block, sequentially perform the IMEI integrity judgment rule, the IMSI integrity judgment rule, and the short message validity judgment rule on the data at the CurrentOffset position; the reading unit 302 is configured to, in response to a successful rule judgment, read the corresponding data into the corresponding result database, increment the CurrentOffset, and repeat S1 until the CurrentOffset is greater than or equal to the FileSize; and the data display unit 303 is configured to display the IMSI, IMEI, and short message that have been deleted and recovered.

[0108] Reference below Figure 4 , which shows a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. Figure 4The electronic device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0109] like Figure 4 As shown, the computer system includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage unit 408 into a random access memory (RAM) 403. Various programs and data required for the operation of the system 400 are also stored in the RAM 403. The CPU 401, ROM 402, and RAM 403 are connected to each other via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0110] The following components are connected to the I / O interface 405: an input section 406 including a keyboard, a mouse, and the like; an output section 407 including a liquid crystal display (LCD) and speakers; a storage section 408 including a hard disk; and a communication section 409 including a network interface card such as a LAN card or a modem. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the I / O interface 405 as needed. Removable media 411, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 410 as needed, so that computer programs read therefrom can be installed into the storage section 408 as needed.

[0111] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 409, and / or installed from the removable medium 411. When the computer program is executed by the central processing unit (CPU) 401, the above-mentioned functions defined in the method of the present application are executed. It should be noted that the computer-readable storage medium of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including, but not limited to, an electromagnetic signal, an optical signal, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0112] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0113] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0114] The modules described in the embodiments of the present application may be implemented in software or hardware.

[0115] As another aspect, the present application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiment; or it may exist independently and not be assembled into the electronic device. The above computer-readable storage medium carries one or more programs. When the above one or more programs are executed by the electronic device, the electronic device: in response to the current file offset position CurrentOffset being less than the size FileSize of the GoIP unallocated cluster file or the GoIP deleted data block, the electronic device sequentially performs the IMEI integrity judgment rule, the IMSI integrity judgment rule and the short message validity judgment rule on the data at the CurrentOffset position; in response to the rule judgment being successful, the corresponding data is read into the corresponding result database, the CurrentOffset is incremented and the above judgment is repeated until the CurrentOffset is greater than or equal to the FileSize; and the deleted and recovered IMSI, IMEI and short message are displayed.

[0116] The above description is merely a preferred embodiment of the present application and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also encompasses other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned inventive concept. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for recovering electronic data of a GoIP device, characterized in that: include: S1: In response to the current file offset position CurrentOffset being smaller than the size FileSize of the GoIP unallocated cluster file or the GoIP deleted data block, sequentially performing an IMEI integrity judgment rule, an IMSI integrity judgment rule, and a short message validity judgment rule on the data at the CurrentOffset position; S2: In response to the rule being judged successfully, read the corresponding data into the corresponding result database, increment the CurrentOffset and repeat S1 until the CurrentOffset is greater than or equal to the FileSize; S3: Displays the deleted and restored IMSI, IMEI and SMS messages; The step S1 sequentially performs IMEI integrity judgment rule, IMSI integrity judgment rule and short message validity judgment rule on the data at the CurrentOffset position, specifically including: S11: Perform the IMEI integrity judgment rule on the data at the CurrentOffset position. If the judgment is successful, read the corresponding data to the IMEI result database, set CurrentOffset=CurrentOffset+15, and jump to the S1 to determine whether the CurrentOffset is greater than or equal to the FileSize. If not, proceed to S12; S12: The data of the CurrentOffset position is subjected to the IMSI integrity judgment rule. If the judgment is successful, read the corresponding data to the IMSI result database, set CurrentOffset = CurrentOffset + 15, and jump to the S1 to determine whether the CurrentOffset is greater than or equal to the FileSize, if not, proceed to S13; S13: Apply the short message validity judgment rule to the data at the CurrentOffset position. If the judgment is successful, read the corresponding SMS data stored in the corresponding rule into the result database, set CurrentOffset=CurrentOffset+DmsLen, and jump to S1 to determine whether the CurrentOffset is greater than or equal to the FileSize. If not, set CurrentOffset+1 and jump to S1.

2. Short message The method for recovering electronic data of a GoIP device according to claim 1, characterized in that: The IMEI integrity judgment rule includes performing IMEI feature and verification judgment on the incoming 15-byte data block, and judging whether the 15 bytes of data starting from the CurrentOffset position meet the following conditions: The first two bytes of the data are traversed and matched with the elements in the set MEGC, which is the first two digits of the IMEI number TAC of the GoIP device, and are equal to one of the elements MEGCN; The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9; The Luhn algorithm is performed on the first 14 bytes of data to obtain a check value Dvalue, which is equal to the 15th digit.

3. The method for recovering electronic data of a GoIP device according to claim 1, characterized in that: The IMSI integrity judgment rule includes performing IMSI feature and verification judgment on the incoming 16-byte data block, and judging whether the 16-byte data starting from the CurrentOffset position meets the following conditions: The first three bytes of the data are traversed and matched with the elements in the set MSGC, satisfying equality with one of the elements MSGCN, where the set MSGC is a set of MMC codes of domestic IMSI numbers; The 4th and 5th bytes of the data are traversed and matched with the elements in the set MSNC, and are equal to one of the elements MSGCN. The set MSNC is a set of MNC mobile network operator codes of major domestic IMSIs. The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9; The 16th byte in the data block is the terminator of the hexadecimal digits \x00, \x0a, or \x0d.

4. The method for recovering electronic data of a GoIP device according to claim 1, characterized in that: The short message validity judgment rule includes judging the short message characteristics and checking the incoming data block. The valid short message data meets the following conditions: The first N bytes of the data are traversed and matched with the elements of the SMS feature set DMS, and they are equal to one of the elements DMSN; The data offset CurrentOffset = CurrentOffset + 4, increases byte by byte, and each additional match is equal to '|E', and DmsEndOffset = CurrentOffset is recorded; Extract the data between DmsStartOffset and DmsEndOffset and split the string using the '|' symbol. The number of strings after the split must be at least greater than or equal to 4, and the third string is a time string with a size of 19 bytes. Save and record the second string, the phone number, and the fourth string, the SMS content, respectively. Both are not empty, and record DmsEndOffset - DmsStartOffset as DmsLen.

5. A computer-readable storage medium having one or more computer programs stored thereon, characterized in that: When the one or more computer programs are executed by a computer processor, the method according to any one of claims 1 to 4 is implemented.

6. A GoIP device electronic data recovery system, characterized in that: The system comprises: a rule judgment unit configured to, in response to a current file offset position CurrentOffset being smaller than a size FileSize of a GoIP unallocated cluster file or a GoIP deleted data block, sequentially perform an IMEI integrity judgment rule, an IMSI integrity judgment rule, and a short message validity judgment rule on the data at the CurrentOffset position; a reading unit configured to, in response to a successful rule judgment, read corresponding data into a corresponding result database, increment the CurrentOffset, and repeat the judgment of the rule judgment unit until the CurrentOffset is greater than or equal to the FileSize; A data display unit configured to display deleted and recovered IMSI, IMEI and short messages; The rule judgment unit specifically includes: S11: Perform the IMEI integrity judgment rule on the data at the CurrentOffset position. If the judgment is successful, read the corresponding data to the IMEI result database, set CurrentOffset=CurrentOffset+15, and jump to the S1 to determine whether the CurrentOffset is greater than or equal to the FileSize. If not, proceed to S12; S12: The data of the CurrentOffset position is subjected to the IMSI integrity judgment rule. If the judgment is successful, read the corresponding data to the IMSI result database, set CurrentOffset = CurrentOffset + 15, and jump to the S1 to determine whether the CurrentOffset is greater than or equal to the FileSize, if not, proceed to S13; S13: Apply the short message validity judgment rule to the data at the CurrentOffset position. If the judgment is successful, read the corresponding SMS data stored in the corresponding rule into the result database, set CurrentOffset=CurrentOffset+DmsLen, and jump to S1 to determine whether the CurrentOffset is greater than or equal to the FileSize. If not, set CurrentOffset+1 and jump to re-judge the rule.

7. Short message The GoIP device electronic data recovery system according to claim 6 is characterized in that: The IMEI integrity judgment rule includes performing IMEI feature and verification judgment on the incoming 15-byte data block, and judging whether the 15 bytes of data starting from the CurrentOffset position meet the following conditions: The first two bytes of the data are traversed and matched with the elements in the set MEGC, which is the first two digits of the IMEI number TAC of the GoIP device, and are equal to one of the elements MEGCN; The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9; The Luhn algorithm is performed on the first 14 bytes of data to obtain a check value Dvalue, which is equal to the 15th digit.

8. The GoIP device electronic data recovery system according to claim 6, characterized in that: The IMSI integrity judgment rule includes performing IMSI feature and verification judgment on the incoming 16-byte data block, and judging whether the 16-byte data starting from the CurrentOffset position meets the following conditions: The first three bytes of the data are traversed and matched with the elements in the set MSGC, satisfying equality with one of the elements MSGCN, where the set MSGC is a set of MMC codes of domestic IMSI numbers; The 4th and 5th bytes of the data are traversed and matched with the elements in the set MSNC, and are equal to one of the elements MSGCN. The set MSNC is a set of MNC mobile network operator codes of major domestic IMSIs. The 15 bytes of data in the data block are all binary-coded decimal numbers from 0 to 9; The 16th byte in the data block is the terminator of the hexadecimal digits \x00, \x0a, or \x0d.

9. The GoIP device electronic data recovery system according to claim 6, characterized in that: The short message validity judgment rule includes judging the short message characteristics and checking the incoming data block. The valid short message data meets the following conditions: The first N bytes of the data are traversed and matched with the elements of the SMS feature set DMS, and they are equal to one of the elements DMSN; The data offset CurrentOffset = CurrentOffset + 4, increases byte by byte, and each additional match is equal to '|E', and DmsEndOffset = CurrentOffset is recorded; Extract the data between DmsStartOffset and DmsEndOffset and split the string using the '|' symbol. The number of strings after the split must be at least greater than or equal to 4, and the third string is a time string with a size of 19 bytes. Save and record the second string, the phone number, and the fourth string, the SMS content, respectively. Both are not empty, and record DmsEndOffset - DmsStartOffset as DmsLen.

Images