Method and device for realizing communication between USB device and mac platform application

Abstract

The application discloses an implementation method and device for communication between a USB device and a mac platform application, and relates to the field of information security. The implementation method comprises a stripping process and a communication process. In the stripping process, the USB device is stripped from a kernel state to a user state. In the communication process, the Libusb interface library is used to realize instruction communication of a normal SCSI protocol between the USB device and the mac platform application. The whole process does not require user participation, and is convenient to use and friendly to user experience.

Description

Technical Field

[0001] This invention relates to the field of information security, and in particular to a method and apparatus for enabling communication between a USB device and a Mac platform application. Background Technology

[0002] In existing technologies, the macOS kernel exclusively controls USB devices using the SCSI protocol, preventing user-mode applications from communicating with these devices. To address this issue, kernel extension drivers (kexts) have been developed, enabling normal SCSI protocol communication between USB devices and macOS applications. However, these kexts require manual user intervention during initial installation, which is cumbersome. Therefore, there is a pressing need for a simpler solution that allows USB devices to communicate normally with macOS applications using the SCSI protocol. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and apparatus for communication between a USB device and a Mac platform application.

[0004] In a first aspect, embodiments of the present invention provide a method for enabling communication between a USB device and a Mac platform application, including a stripping process and a communication process, wherein the stripping process includes:

[0005] Step S1: After the background service is started, initialize the monitoring interface of the interface library;

[0006] Step S2: When the background service detects that a USB device is inserted through the monitoring interface, it opens the USB device to obtain the supplier identification code and product identification code, and determines whether the obtained supplier identification code and product identification code are the specified supplier identification code and product identification code. If yes, proceed to step S3; otherwise, return to step S2.

[0007] Step S3: The background service obtains the device communication interface based on the supplier identification code and the product identification code, searches for the registry entry of the device communication interface, and determines whether there is an IO object in the registry entry. If yes, proceed to step S4; otherwise, return to step S2.

[0008] Step S4: The background service determines whether there is a sub-entry in the IO object. If yes, proceed to step S5; otherwise, return to step S2.

[0009] Step S5: The background service sets a function mask, simulates the plugging and unplugging of the device and enumeration through the function mask, notifies the operating system to delete the sub-entry in the IO object, completes the operation of stripping the USB device from kernel mode to user mode, and returns to step S2;

[0010] The communication process includes:

[0011] Step Y1: The Mac platform application loads the interface library, initializes the monitoring interface of the interface library, enables the monitoring interface of the interface library, and registers the USB device plug-in / plug-out callback function.

[0012] Step Y2: When the monitoring interface detects a Libusb event, it returns a response to the Mac platform application through the USB device plugging / unplugging callback function.

[0013] Step Y3: The Mac platform application determines the type of the Libusb event. If it is an insertion event, proceed to step Y4; if it is a removal event, delete the stored device number and device address.

[0014] Step Y4: The Mac platform application obtains the device number and device address from the inserted USB device, and stores the device number and device address as unique values ​​for the USB device;

[0015] Step Y5: The Mac platform application initializes the communication object, connects to the communication object using a connection token based on the unique value of the USB device, initializes the communication interface, searches for the corresponding device from the obtained USB device list based on the unique value of the USB device, opens the found device and enumerates the communication interface, and communicates with the USB device through the communication interface.

[0016] Secondly, embodiments of the present invention provide an apparatus for communication between a USB device and a Mac platform application, including a stripping module and a communication module, wherein the stripping module includes:

[0017] The initialization unit is used to initialize the monitoring interfaces of the interface library after the background service is started.

[0018] The judgment unit is used to detect USB devices through the monitoring interface. When a USB device is detected to be inserted through the monitoring interface, the USB device is opened to obtain the supplier identification code and product identification code. It is then determined whether the obtained supplier identification code and product identification code are the specified supplier identification code and product identification code. If they are, the search judgment unit is triggered; otherwise, the USB device is detected through the monitoring interface.

[0019] The search and judgment unit is used to obtain the device communication interface based on the supplier identification code and the product identification code, search the registry entry of the device communication interface, and determine whether there is an IO object in the registry entry. If so, the first judgment unit is triggered; otherwise, the opening judgment unit is triggered.

[0020] The first judgment unit is used to determine whether there is a sub-entry in the IO object. If so, the set deletion unit is triggered; otherwise, the open judgment unit is triggered.

[0021] The setting deletion unit is used to set a function mask, simulate the plugging and unplugging and enumeration of the device through the function mask, notify the operating system to delete the sub-entry in the IO object, complete the operation of stripping the USB device from kernel mode to user mode, and trigger the opening judgment unit.

[0022] The communication module includes:

[0023] The loading and registration unit is used to load the interface library, initialize the monitoring interface of the interface library, enable the monitoring interface of the interface library, and register the monitoring USB device plug-in / plug-out callback function.

[0024] The monitoring notification unit is used to return a notification to the deletion determination unit through the monitoring USB device plugging / unplugging callback function after the monitoring interface monitors the Libusb event.

[0025] The deletion determination unit is used to determine the type of the Libusb event. If it is an insertion event, it triggers the acquisition of the storage unit. If it is a removal event, it deletes the stored device number and device address.

[0026] The acquisition and storage unit is used to acquire the device number and device address from the inserted USB device, and store the device number and device address as unique values ​​of the USB device.

[0027] An initialization communication unit is used to initialize a communication object, connect to the communication object using a connection token based on the unique value of the USB device, initialize a communication interface, search for the corresponding device from the obtained USB device list based on the unique value of the USB device, open the found device and enumerate the communication interface, and communicate with the USB device through the communication interface.

[0028] Thirdly, embodiments of the present invention provide an electronic device, the electronic device including at least one processor, a memory, and instructions stored in the memory and executable by the at least one processor, wherein the at least one processor executes the instructions to implement the aforementioned method for communication between a USB device and a Mac platform application.

[0029] Fourthly, embodiments of the present invention provide a computer-readable storage medium comprising a computer program that, when executed on an electronic device, causes the electronic device to perform the aforementioned method for communicating between a USB device and a Mac platform application.

[0030] Fifthly, embodiments of the present invention provide a chip system, including a chip coupled to a memory, for executing a computer program stored in the memory to execute the aforementioned method for communication between a USB device and a Mac platform application.

[0031] Compared with the prior art, the present invention has the following advantages: As a replacement for the kernel extension driver (kext), the technical solution of the present invention strips the USB device from kernel mode to user mode, and realizes the instruction communication between the USB device and the normal SCSI protocol of the Mac platform application through the Libusb interface library. The whole process does not require user intervention, which is convenient to use and user-friendly. Attached Figure Description

[0032] Figure 1 This is a flowchart illustrating the stripping process in a method for enabling communication between a USB device and a Mac platform application, as provided in Embodiment 1 of the present invention.

[0033] Figure 2 This is a flowchart illustrating the communication process in a method for communication between a USB device and a Mac platform application, as provided in Embodiment 1 of the present invention.

[0034] Figure 3 The flowchart illustrates the stripping process achieved by setting root permissions in a method for communication between a USB device and a Mac platform application, as provided in Embodiment 2 of the present invention.

[0035] Figure 4 The flowchart illustrates the stripping process achieved by requesting access permissions in a method for communication between a USB device and a Mac platform application, as provided in Embodiment 2 of the present invention.

[0036] Figure 5 This is a flowchart illustrating the stripping process in a method for communication between a USB device and a Mac platform application, provided in Embodiment 2 of the present invention, which involves requesting access permissions and setting root permissions.

[0037] Figure 6 This is a flowchart illustrating the communication process in a method for communication between a USB device and a Mac platform application, as provided in Embodiment 2 of the present invention. Detailed Implementation

[0038] This application proposes a method and apparatus for communication between a USB device and a Mac platform application. The specific embodiments of this application are described in detail below with reference to the accompanying drawings. Examples of the embodiments are shown in the drawings. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0039] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0040] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings. Example 1

[0041] Embodiment 1 of the present invention provides a method for enabling communication between a USB device and a Mac platform application, including a stripping process and a communication process;

[0042] The peeling process in this embodiment is as follows: Figure 1 As shown, it includes:

[0043] Step S1: After the background service is started, initialize the monitoring interface of the interface library;

[0044] Step S2: When the background service detects that a USB device is inserted through the monitoring interface, it opens the USB device to obtain the supplier identification code and product identification code. It then determines whether the obtained supplier identification code and product identification code are the specified supplier identification code and product identification code. If they are, it proceeds to step S3; otherwise, it returns to step S2.

[0045] Step S3: The background service obtains the device communication interface based on the supplier identification code and product identification code, searches for the registry entry of the device communication interface, and determines whether an IO object exists in the registry entry. If it does, proceed to step S4; otherwise, return to step S2.

[0046] Step S4: The background service determines whether there are child entries in the IO object. If yes, proceed to step S5; otherwise, return to step S2.

[0047] Step S5: The background service sets the function mask, simulates the plugging and unplugging of the device and enumeration through the function mask, notifies the operating system to delete the sub-entry in the IO object, completes the operation of stripping the USB device from kernel mode to user mode, and returns to step S2;

[0048] The communication process in this embodiment is as follows: Figure 2 As shown, it includes:

[0049] Step Y1: The Mac platform application loads the interface library, initializes the monitoring interface of the interface library, enables the monitoring interface of the interface library, and registers the USB device plug-in / plug-out callback function.

[0050] Step Y2: After the monitoring interface detects the Libusb event, it returns a response to the Mac platform application through the USB device plugging / unplugging callback function;

[0051] Step Y3: The Mac platform application determines the type of the Libusb event. If it is an insertion event, proceed to step Y4. If it is a removal event, delete the stored device number and device address.

[0052] Step Y4: The Mac platform application obtains the device ID and device address from the inserted USB device and stores the device ID and device address as unique values ​​for the USB device;

[0053] Step Y5: The Mac platform application initializes the communication object, connects to the communication object using a connection token based on the unique value of the USB device, initializes the communication interface, searches for the corresponding device from the obtained USB device list based on the unique value of the USB device, opens the found device and enumerates the communication interface, and communicates with the USB device through the communication interface.

[0054] In this embodiment, the user saves the program code of the background service in a specified path, and the operating system saves the information required for the background service to start automatically in the automatic configuration file and releases the automatic configuration file to the first path; the automatic configuration file is used by the operating system to create the task process before the user logs in.

[0055] The information required for the background service to start automatically includes: the specified path where the background service is loaded and run, the background service starting immediately after being loaded, and the background service restarting automatically when the system crashes or exits.

[0056] Before step S1, the following steps are also included: after the operating system starts up and before the user logs in or when the background service crashes and exits, the background service is loaded by the operating system as a task process with the root user and then starts working.

[0057] Optionally, in this embodiment, step S4 and step S5 include:

[0058] Step S41: The background service determines whether it has root privileges. If so, it executes step S5; otherwise, it determines that the kernel driver stripping has failed and returns to step S2.

[0059] Furthermore, the process between steps S4 and S41 includes: the background service calling the system's first method to create a security task, calling the system's first interface to enable the security task to determine whether it has permission to access and use the device; if so, requesting permission authorization through the authorization service, refreshing the authorization to make the permission effective, and executing step S5; otherwise, executing step S41.

[0060] Correspondingly, before step S1, the following steps are also included: after the operating system starts and before the user logs in or when the background service crashes and exits, the background service is loaded by the operating system as the root user using a task process and starts working; or, after the operating system starts and before the user logs in or when the background service crashes and exits, the background service is loaded by the operating system as the current user using a task process and starts working.

[0061] Optionally, the process between steps S4 and S5 includes: the background service calling the system's first method to create a security task, calling the system's first interface to enable the security task to determine whether it has the permission to obtain and use the device; if so, requesting authorization for the access permission through the authorization service, refreshing the authorization to make the access permission effective, and executing step S5; otherwise, determining that the kernel driver stripping has failed, and returning to step S2.

[0062] In this embodiment, the user saves the program code of the background service in a specified path, and the operating system saves the information required for the background service to start automatically in the automatic configuration file and releases the automatic configuration file to the second path; the automatic configuration file is used by the operating system to create the task process before the user logs in.

[0063] The information required for the background service to start automatically includes: the specified path where the background service is loaded and run, the background service starting immediately after being loaded, and the background service restarting automatically when the system crashes or exits.

[0064] Before step S1, the following steps are also included: after the operating system starts up and the user logs in, or when the background service crashes and exits, the background service is loaded by the operating system as a task process under the current user's identity and begins to work.

[0065] In this embodiment, if the USB device is unplugged and then plugged back in, step Y4 includes: the Mac platform application obtains the device number (bus_number) and device address (device_address) from the plugged USB device, determines whether the obtained bus_number and device_address are consistent with the stored bus_number and device_address, if they are consistent, then communicates with the USB device through the communication interface; otherwise, the obtained bus_number and device_address are stored as unique values ​​of the USB device, and step Y5 is executed. Example 2

[0066] Embodiment 2 of the present invention provides a method for implementing communication between a USB device and a Mac platform application, applicable to scenarios where command communication is performed using the SCSI protocol. The method of this embodiment includes a stripping process and a communication process. During the stripping process, the background service is enabled by using an authorization file with "com.apple.vm.device-access" permissions to strip the USB device kernel mode to user mode and / or by elevating the root privileges of the background service to strip the USB device kernel mode to user mode.

[0067] The specific process of stripping by elevating the root privileges of the backend service is as follows: Figure 3 As shown, it includes:

[0068] Step 101: After the background service is started, the monitoring interface of the Libusb interface library is initialized through the Libusb_init(Libusb_conttext ** ctx) interface;

[0069] Prior to the method in this embodiment, the program code of the background service is stored in a specified path. The operating system receives and saves the background service auto-start information configured by the user in the created auto-configuration Plist file, and releases the auto-configuration Plist file to / Library / LaunchDaemons.

[0070] Specifically, information related to the background service starting automatically includes: the specified path where the background service is loaded, the background service starting immediately after being loaded, and the background service restarting automatically when the system crashes or exits.

[0071] Before step 101, the following steps are also included: After the operating system starts up (i.e., after the Mac device boots up and before the user logs in, the operating system searches for the auto-configuration Plist file under / Library / LaunchDaemons. If found, a task process is created based on the configuration information in the found auto-configuration Plist file. The operating system immediately loads the background service at the specified path through the task process as the root user. Alternatively, when the operating system detects that the background service has crashed and exited, or when the operating system restarts and before the user logs in, the operating system automatically loads the background service at the specified path through the task process as the root user. Once the background service is loaded, it starts working.

[0072] In this embodiment, the Plist file (full Chinese name: Attribute List file, full English name: PropertyList) is a file format that stores configuration information and structured data. The Libusb interface library provides API interfaces, and applications can directly operate USB devices by calling the API interfaces.

[0073] Step 102: When the background service detects that a USB device is inserted through the monitoring interface, it calls the Libusb_open_device_with_vid_pid interface to open the USB device and obtains the VID and PID from the USB device;

[0074] Among them, VID stands for Vendor ID, and PID stands for Product ID.

[0075] Step 103: The background service determines whether the obtained VID and PID are the specified VID and PID. If yes, proceed to step 104; otherwise, return to step 102.

[0076] Step 104: The background service obtains the device communication interface based on the VID and PID, and searches for the registry entry of the device communication interface;

[0077] Step 105: The background service checks whether an IO object exists in the registry key. If it does, proceed to step 106; otherwise, the kernel driver does not need to be stripped and returns to step 102.

[0078] In this embodiment, the IO object is a file capable of performing input and output operations;

[0079] Step 106: The background service determines whether there are sub-entries in the IO object. If yes, proceed to step 107; otherwise, if there is no kernel driver to be stripped, return to step 102.

[0080] In this embodiment, sub-entries are used to record kernel driver information in kernel mode;

[0081] Step 107: The background service determines whether it has root privileges. If so, it proceeds to step 108; otherwise, the kernel driver stripping fails and returns to step 102.

[0082] In this embodiment, step 107 is a background service self-check process and is not a necessary step. That is, if step 106 determines that it is true, step 108 is executed directly.

[0083] Step 108: The background service sets a function mask, simulates device plugging and unplugging and enumeration through the function mask, and notifies the operating system to delete the sub-entry in the IO object, then returns to step 102;

[0084] In this embodiment, after the background service notifies the operating system to delete the sub-entry in the IO object, the operation of stripping the USB device from kernel mode to user mode is completed, and the process returns to step 102 to perform the stripping operation on other USB devices again.

[0085] For example, in this embodiment, the function mask is kUSBReEnumerateCaptureDeviceMask, which is a mask constant related to USB device enumeration and is used to control the re-enumeration behavior of the USB capture device;

[0086] In this embodiment, the device identifier and function mask are used as parameters to call the system function. The system function sends a termination message to all clients of the IOUSB device (e.g., the IOUSB interface and its driver, as well as the current user client) to simulate the operation of the device being plugged in or unplugged. The device is enumerated through the IOUSB Family.

[0087] Specifically, the system function is: kresult = (*dpriv->device)->USBDeviceReEnumerate(dpriv->device, options), where device is the device identifier and options is the function mask.

[0088] This embodiment requires the user to apply for "com.apple.vm.device-access" permission from Apple. Specifically, the user, using their developer identity, sends an email specifying the project function, the reason for needing the permission, and providing relevant supporting documentation. The email is then sent to Apple's Developer Center. Upon approval, Apple's Developer Center returns an authorization file (including the developer's signature and permission declaration). This authorization file is then used to mark the background service (e.g., authorizing the background service with the authorization file before publishing), granting the background service "com.apple.vm.device-access" permission. In this embodiment, if the background service is determined to have "com.apple.vm.device-access" permission, the stripping operation can be performed. The specific process is as follows: Figure 4 As shown, it includes:

[0089] Step 301: After the background service is started, the monitoring interface of the Libusb interface library is initialized through the Libusb_init(Libusb_conttext ** ctx) interface;

[0090] Prior to the method in this embodiment, the program code of the background service is stored in a specified path, receives and saves the background service auto-start information configured by the user in the created auto-configuration Plist file, and releases the auto-configuration Plist file to / Library / LaunchAgent;

[0091] Specifically, information related to the background service starting automatically includes: the specified path where the background service is loaded and run, the background service starting immediately after being loaded, and the background service restarting automatically when it crashes or exits.

[0092] Before step 301, there is also step A: After the operating system starts and the user logs in, the operating system searches for the configuration Plist file under / Library / LaunchAgent. If found, it creates a task process according to the configuration information in the found automatic configuration file, and immediately runs the background service of the specified path through the task process as the current user. Alternatively, after the system restarts and the user logs in, the background service of the specified path is loaded and run through the task process as the current user.

[0093] Step 302: When the background service detects that a USB device is inserted through the monitoring interface, it calls the Libusb_open_device_with_vid_pid interface to open the USB device and obtains the VID and PID from the USB device;

[0094] Step 303: The background service determines whether the obtained VID and PID are the specified VID and PID. If yes, proceed to step 304; otherwise, return to step 302.

[0095] Step 304: The background service obtains the device communication interface based on the VID and PID, and searches for the registry entry of the device communication interface;

[0096] Step 305: The background service checks whether an IO object exists in the registry key. If it does, proceed to step 306; otherwise, the kernel driver does not need to be stripped and returns to step 302.

[0097] Step 306: The background service determines whether there are sub-entries in the IO object. If yes, proceed to step 307; otherwise, if there is no kernel driver to be stripped, return to step 302.

[0098] Step 307: The background service calls the system SecTaskCreateFromSelf method to create a security task, and calls the system interface SecTaskCopyValueForEntitlement to enable the security task. It then checks whether the background service has the "com.apple.vm.device-access" permission. If yes, proceed to step 308; otherwise, kernel driver stripping fails and returns to step 302.

[0099] Step 308: The backend service requests access permission authorization via IOServiceAuthorsize and refreshes the authorization to make the access permissions effective;

[0100] In this embodiment, IOServiceAuthorsize is a security mechanism related to kernel extensions and hardware service authorization in Apple's iOS / macOS system. It is used to verify the access rights of user-space applications to kernel-level hardware services (such as USB devices, Bluetooth drivers, etc.). It implements hardware interaction authorization management through the IOKit framework, that is, it checks the caller's signature and permission declaration through the system policy database to ensure that only services that have been certified by Apple or explicitly authorized by the user can access sensitive hardware resources.

[0101] Step 309: Set the function mask in the background service. Simulate the plugging and unplugging of the device and enumeration through the function mask. Notify the operating system to delete the sub-entries in the IO object. Return to step 302.

[0102] The stripping operation is performed by enabling the background service and elevating its root privileges using an authorization file with "com.apple.vm.device-access" permissions. The specific process is as follows: Figure 5 As shown, it includes:

[0103] Step 401: After the background service is started, the monitoring interface of the Libusb interface library is initialized through the Libusb_init(Libusb_conttext ** ctx) interface;

[0104] Prior to the method in this embodiment, the program code of the background service is stored in a specified path, receives and saves the background service auto-start information configured by the user in the created auto-configuration Plist file, and releases the auto-configuration Plist file to / Library / LaunchDaemons and / Library / LaunchAgent.

[0105] Specifically, information related to the background service starting automatically includes: the specified path where the background service is loaded and run, the background service starting immediately after being loaded, and the background service restarting automatically when it crashes or exits.

[0106] In this embodiment, the method further includes the following step before step 401:

[0107] Step T1: After the operating system boots up (i.e., the Mac device powers on but before the user logs in, the operating system searches for the auto-configuration Plist file under / Library / LaunchDaemons. If found, it creates a task process based on the configuration information in the found auto-configuration Plist file. The task process immediately loads the background service at the specified path as the root user. Alternatively, if a background service crashes or exits, or if the operating system restarts and before the user logs in, the operating system automatically loads the background service at the specified path as the root user through the task process. Once loaded, the background service starts working.

[0108] Step T2: After the operating system starts and the user logs in, the operating system searches for the configuration Plist file under / Library / LaunchAgent. If found, it creates a task process based on the configuration information in the found automatic configuration file. The task process immediately loads the background service at the specified path as the current user. Alternatively, after the system restarts and the user logs in, the task process automatically loads the background service at the specified path as the current user. Once the background service is loaded, it starts working.

[0109] Step 402: When the background service detects that a USB device is inserted through the monitoring interface, it calls the Libusb_open_device_with_vid_pid interface to open the USB device and obtains the VID and PID from the USB device;

[0110] Step 403: The background service determines whether the obtained VID and PID are the specified VID and PID. If yes, proceed to step 404; otherwise, return to step 402.

[0111] Step 404: The background service obtains the device communication interface based on the VID and PID, and searches for the registry entry of the device communication interface;

[0112] Step 405: The background service checks whether an IO object exists in the registry key. If it does, proceed to step 406; otherwise, the kernel driver does not need to be stripped and returns to step 402.

[0113] Step 406: The background service determines whether there are sub-entries in the IO object. If yes, proceed to step 407; otherwise, if there is no kernel driver to be stripped, return to step 402.

[0114] Step 407: The background service calls the system SecTaskCreateFromSelf method to create a security task, calls the system interface SecTaskCopyValueForEntitlement to enable the security task to determine whether it has the "com.apple.vm.device-access" permission. If so, it requests the access permission authorization through IOServiceAuthorsize, refreshes the authorization to make the access permission effective, and proceeds to step 409; otherwise, it proceeds to step 408.

[0115] In this embodiment, com.apple.vm.device-access is used to indicate whether the application can capture a USB device and use the USB device in the virtual operating system;

[0116] Step 408: The background service determines whether it has root privileges. If so, it proceeds to step 409; otherwise, the kernel driver stripping fails and returns to step 402.

[0117] Step 409: The background service sets a function mask, simulates device plugging and unplugging and enumeration through the function mask, notifies the operating system to delete the sub-entries in the IO object, and returns to step 402.

[0118] The communication process in this embodiment is as follows: Figure 6 As shown, it includes:

[0119] Step 501: Mac platform application loads the interface library Libusb;

[0120] Optionally, the Mac platform application in this embodiment has access to the USB device and does not require root privileges. Step 501 in this embodiment can be replaced with:

[0121] Step 501': The root process loads the interface library Libusb;

[0122] Step 502: Mac platform applications use the Libusb_init(Libusb_context ** ctx) interface to initialize the monitoring interface of the Libusb interface library;

[0123] Step 503: Enable the monitoring interface of the API library in the Mac platform application and register the callback function for monitoring USB device plugging and unplugging;

[0124] Step 504: After the monitoring interface detects the Libusb event, it returns the Libusb event to the Mac platform application through the USB device plug-in / plug-out callback function.

[0125] Step 505: The Mac platform application determines the type of the Libusb event. If it is an insertion event, proceed to step 506; if it is a removal event, proceed to step 509.

[0126] Step 506: The Mac platform application obtains the bus_number and device_address from the inserted USB device and stores the bus_number and device_address as unique values ​​of the USB device;

[0127] In this embodiment, bus_number is the bus number on which the device is located, or simply device number, which is used to define the physical location and topology of the device; device address is the device address, which is an identifier used to identify the device in the communication protocol;

[0128] Optionally, if the USB device is plugged in and then unplugged, then step 506 includes: the Mac platform application obtains the bus_number and device_address from the plugged USB device, determines whether the obtained bus_number and device_address are consistent with the stored bus_number and device_address, if they are consistent, then proceed to step 508; otherwise, the obtained bus_number and device_address are stored as the unique value of the USB device, and step 507 is executed.

[0129] Step 507: The Mac platform application initializes the communication object, connects to the communication object using the ConnectToken based on the unique value of the USB device, initializes the communication interface through the Libusb_init(Libusb_conttext ** ctx) interface, obtains the USB device list, finds the corresponding device from the USB device list based on the unique value of the USB device, opens the found device and enumerates the communication interface;

[0130] In this embodiment, if the found device has not undergone kernel-mode stripping of user mode, the Mac platform application cannot access it, and attempting to access it will result in a message indicating that opening the device has failed and communication is impossible.

[0131] In this embodiment, step 507, opening the found device and enumerating the communication interfaces, includes:

[0132] Step 507-1: The Mac platform application calls the libusb_open function to open the found device and obtain the communication handle;

[0133] The specific implementation of step 507-1 is: libusb_open(libusb_device *dev, libusb_device_handle **dev_handle), where libusb_device *dev is the found device, and libusb_device_handle**dev_handle is the communication handle (communication handle), which is the output parameter of the function;

[0134] Step 507-2: The Mac platform application calls the libusb_claim_interface function with the communication handle as a parameter to enumerate the required interface number (interface_number).

[0135] The specific implementation of step 507-2 is as follows: m_usb_handle = *dev_handle, libusb_claim_interface(m_usb_handle, interface_number);

[0136] Step 507-3: The Mac platform application uses the communication handle as a parameter to call the first lookup function and the second lookup function respectively to obtain the communication read and write port numbers (m_endpoint_in / m_endpoint_out) of the LIBUSB_TRANSFER_TYPE_BULK block attribute.

[0137] Specifically, the second lookup function is: libusb_bulk_transfer(m_usb_handle, m_endpoint_out, (unsigned char *)(&blksend), sizeof(blksend), &resultSize, timeOut), where m_usb_handle is the communication handle, m_endpoint_out is the write data port, blksend is the data to be sent, sizeof(blksend) is the size of the data to be sent, resultSize is the actual size sent, and timeOut is the set timeout period;

[0138] The first lookup function is: libusb_bulk_transfer(m_usb_handle, m_endpoint_in,(unsigned char *)&blkRev, sizeof(UMS_SCSI_CSW),&resultSize,timeOut), where m_usb_handle is the communication handle, m_endpoint_in is the data port to read, blkRev is the data to be read, sizeof(blksend) is the size of the data to be read, resultSize is the actual size read, and timeOut is the set timeout period;

[0139] Step 508: Mac platform applications communicate with USB devices via a communication interface;

[0140] Specifically, in step 508, the Mac platform application communicates with the USB device through the interface number and the communication read and write port numbers. That is, it sends data to the USB device through the port corresponding to the write port number in the interface corresponding to the interface number, and receives data returned by the USB device through the port corresponding to the read port number in the interface corresponding to the interface number.

[0141] Step 509: The interface library deletes the stored bus_number and device_address;

[0142] In this embodiment, after the communication is completed in step 508 and after step 509, the monitoring interface continues to monitor Libusb events. Example 3

[0143] Embodiment 3 of the present invention provides an apparatus for communication between a USB device and a Mac platform application, including a stripping module and a communication module. In this embodiment, the communication module can only communicate normally after the stripping module completes the stripping operation. The stripping module includes:

[0144] The initialization unit is used to initialize the monitoring interfaces of the interface library after the background service is started.

[0145] The open judgment unit is used to detect USB devices through the monitoring interface. When a USB device is detected to be inserted through the monitoring interface, the USB device is opened to obtain the supplier identification code and product identification code. It is then determined whether the obtained supplier identification code and product identification code are the specified supplier identification code and product identification code. If they are, the search judgment unit is triggered; otherwise, the USB device is detected through the monitoring interface.

[0146] The lookup and judgment unit is used to obtain the device communication interface based on the supplier identification code and product identification code, look up the registry entry of the device communication interface, and determine whether there is an IO object in the registry entry. If so, the first judgment unit is triggered; otherwise, the opening judgment unit is triggered.

[0147] The first judgment unit is used to determine whether there are child entries in the IO object. If so, the set deletion unit is triggered; otherwise, the open judgment unit is triggered.

[0148] The set deletion unit is used to set the function mask. The function mask simulates the plugging and unplugging and enumeration of the device, notifies the operating system to delete the sub-entry in the IO object, completes the operation of stripping the USB device from kernel mode to user mode, and triggers the open judgment unit.

[0149] The communication module includes:

[0150] The loading and registration unit is used to load the interface library, initialize the monitoring interface of the interface library, enable the monitoring interface of the interface library, and register the USB device plug-in / plug-out callback function.

[0151] The monitoring and notification unit is used to notify the interface library via the monitoring USB device plugging / unplugging callback function when the monitoring interface detects a Libusb event.

[0152] The deletion unit is used to determine the type of Libusb event. If it is an insertion event, it triggers the acquisition of the storage unit; if it is a removal event, it deletes the storage device number and device address.

[0153] The storage unit is used to retrieve the device number and device address from the inserted USB device, and store the device number and device address as unique values ​​of the USB device.

[0154] The communication unit is initialized to initialize the communication object. It connects to the communication object using a connection token based on the unique value of the USB device, initializes the communication interface, searches for the corresponding device from the obtained USB device list based on the unique value of the USB device, opens the found device and enumerates the communication interface, and communicates with the USB device through the communication interface.

[0155] In this embodiment, the stripping module further includes: a first startup unit, used to load the background service through the operating system as the root user using a task process after the operating system starts up and before the user logs in or when the background service crashes and exits. Once the background service is loaded, it starts working.

[0156] In this embodiment, the stripping module further includes: a second judgment unit, used to determine whether it has root privileges. If it does, the set deletion unit is triggered; otherwise, the kernel driver stripping is determined to have failed, and the open judgment unit is triggered.

[0157] Furthermore, the stripping module also includes: a first authorization judgment unit, which is used to call the first system method to create a security task, call the first system interface to enable the security task to determine whether it has the permission to obtain and use the device. If so, it requests the authorization of the access permission through the authorization service, refreshes the authorization to make the access permission effective, and triggers the setting deletion unit; otherwise, it triggers the second judgment unit.

[0158] Correspondingly, the stripping module also includes: a first startup unit or a second startup unit. The first startup unit is used to load the background service through the operating system as the root user using a task process after the operating system starts and before the user logs in or when the background service crashes and exits. Once the background service is loaded, it starts working. The second startup unit is used to load the background service through the operating system as the current user using a task process after the operating system starts and before the user logs in or when the background service crashes and exits. Once the background service is loaded, it starts working.

[0159] In this embodiment, the stripping module further includes: a first authorization judgment unit, which is used to call the first method of the system to create a security task, call the first interface of the system to enable the security task to determine whether it has the permission to obtain and use the device. If so, it requests the authorization of the access permission through the authorization service, refreshes the authorization to make the access permission effective, and triggers the setting deletion unit; otherwise, it triggers the opening judgment unit.

[0160] Correspondingly, the stripping module also includes a second startup unit, which is used to load the background service through the operating system using the current user's identity as a task process after the operating system starts and the user logs in or when the background service crashes and exits. Once the background service is loaded, it starts working.

[0161] Optionally, in this embodiment, the acquisition and storage unit is specifically used to acquire the device number and device address from the inserted USB device, determine whether the acquired device number and device address are consistent with the stored device number and device address, and if so, communicate with the USB device through the communication interface; otherwise, store the acquired device number and device address as the unique value of the USB device and trigger the initialization communication unit.

[0162] Optionally, embodiments of this application also provide an electronic device, which includes at least one processor, a memory, and instructions stored in the memory and executable by the at least one processor. The at least one processor executes the instructions to implement the method for communication between a USB device and a Mac platform as described in the above embodiments. When the electronic device is a chip system, it can be composed of chips or may include chips and other discrete devices; embodiments of this application do not specifically limit this. The chip is coupled to the memory and is used to execute the computer program stored in the memory to execute the method for communication between a USB device and a Mac platform disclosed in the above embodiments.

[0163] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be entirely or partially in the form of a computer program product. This computer program product includes one or more computer programs. When the computer program is loaded and executed on an electronic device, all or part of the processes or functions described in the embodiments of this application are generated. The computer program can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one base station, electronic device, server, or data center to another via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to the electronic device or a data storage device including one or more servers, data centers, etc., that can be integrated using media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)). In the embodiments of this application, the electronic device may include the aforementioned apparatus.

[0164] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0165] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A method for enabling communication between a USB device and a Mac platform application, characterized in that, This includes a stripping process and a communication process, wherein the stripping process includes: Step S1: After the background service is started, initialize the monitoring interface of the interface library; Step S2: When the background service detects that a USB device is inserted through the monitoring interface, it opens the USB device to obtain the supplier identification code and product identification code, and determines whether the obtained supplier identification code and product identification code are the specified supplier identification code and product identification code. If yes, proceed to step S3; otherwise, return to step S2. Step S3: The background service obtains the device communication interface based on the supplier identification code and the product identification code, searches for the registry entry of the device communication interface, and determines whether there is an IO object in the registry entry. If yes, proceed to step S4; otherwise, return to step S2. Step S4: The background service determines whether there is a sub-entry in the IO object. If yes, proceed to step S5; otherwise, return to step S2. Step S5: The background service sets a function mask, simulates the plugging and unplugging of the device and enumeration through the function mask, notifies the operating system to delete the sub-entry in the IO object, completes the operation of stripping the USB device from kernel mode to user mode, and returns to step S2; The communication process includes: Step Y1: The Mac platform application loads the interface library, initializes the monitoring interface of the interface library, enables the monitoring interface of the interface library, and registers the USB device plug-in / plug-out callback function. Step Y2: When the monitoring interface detects a Libusb event, it returns a response to the Mac platform application through the USB device plugging / unplugging callback function. Step Y3: The Mac platform application determines the type of the Libusb event. If it is an insertion event, proceed to step Y4; if it is a removal event, delete the stored device number and device address. Step Y4: The Mac platform application obtains the device number and device address from the inserted USB device, and stores the device number and device address as unique values ​​for the USB device; Step Y5: The Mac platform application initializes the communication object, connects to the communication object using a connection token based on the unique value of the USB device, initializes the communication interface, searches for the corresponding device from the obtained USB device list based on the unique value of the USB device, opens the found device and enumerates the communication interface, and communicates with the USB device through the communication interface.

2. The method as described in claim 1, characterized in that, Before step S1, the process further includes: after the operating system starts up and before the user logs in, or when the background service crashes and exits, the background service is loaded by the operating system as the root user using a task process and then starts working.

3. The method as described in claim 1, characterized in that, The step between step S4 and step S5 also includes: Step S41: The background service determines whether it has root privileges. If so, it executes step S5; otherwise, the kernel driver stripping fails and returns to step S2.

4. The method as described in claim 3, characterized in that, Between step S4 and step S41, the following further applies: the background service calls the system's first method to create a security task, calls the system's first interface to enable the security task to determine whether it has permission to obtain and use the device. If so, it requests authorization for the access permission through the authorization service, refreshes the authorization to make the access permission effective, and executes step S5; otherwise, it executes step S41.

5. The method as described in claim 4, characterized in that, Before step S1, the following is also included: after the operating system starts up and before the user logs in, or when the background service crashes and exits, the background service is loaded by the operating system as the root user using a task process and then starts working. Alternatively, after the operating system starts and the user logs in, or when the background service crashes and exits, the background service is loaded by the operating system as a task process under the current user's identity and begins to work.

6. The method as described in claim 1, characterized in that, The step between S4 and S5 includes: the background service calls the system's first method to create a security task, calls the system's first interface to enable the security task to determine whether it has permission to obtain and use the device. If so, it requests permission authorization through the authorization service, refreshes the authorization to make the permission effective, and executes step S5. Otherwise, the kernel driver stripping fails, and the process returns to step S2.

7. The method as described in claim 6, characterized in that, Before step S1, the method further includes: after the operating system starts up and the user logs in, or when the background service crashes and exits, the background service is loaded by the operating system as the current user using a task process and then starts working.

8. The method as described in claim 1, characterized in that, Step Y4 includes: the Mac platform application obtains the device number and device address from the inserted USB device, determines whether the obtained device number and device address are consistent with the stored device number and device address, if they are consistent, then communicates with the USB device through the communication interface; otherwise, the obtained device number and device address are stored as the unique value of the USB device, and step Y5 is executed.

9. A device for enabling communication between a USB device and a Mac platform application, characterized in that, It includes a stripping module and a communication module, wherein the stripping module includes: The initialization unit is used to initialize the monitoring interfaces of the interface library after the background service is started. The judgment unit is used to detect USB devices through the monitoring interface. When a USB device is detected to be inserted through the monitoring interface, the USB device is opened to obtain the supplier identification code and product identification code. It is then determined whether the obtained supplier identification code and product identification code are the specified supplier identification code and product identification code. If they are, the search judgment unit is triggered; otherwise, the USB device is detected through the monitoring interface. The search and judgment unit is used to obtain the device communication interface based on the supplier identification code and the product identification code, search the registry entry of the device communication interface, and determine whether there is an IO object in the registry entry. If so, the first judgment unit is triggered; otherwise, the opening judgment unit is triggered. The first judgment unit is used to determine whether there is a sub-entry in the IO object. If so, the set deletion unit is triggered; otherwise, the open judgment unit is triggered. The setting deletion unit is used to set a function mask, simulate the plugging and unplugging and enumeration of the device through the function mask, notify the operating system to delete the sub-entry in the IO object, complete the operation of stripping the USB device from kernel mode to user mode, and trigger the opening judgment unit. The communication module includes: The loading and registration unit is used to load the interface library, initialize the monitoring interface of the interface library, enable the monitoring interface of the interface library, and register the monitoring USB device plug-in / plug-out callback function. The monitoring notification unit is used to return a notification to the determination and deletion unit through the monitoring USB device plugging / unplugging callback function after the monitoring interface monitors the Libusb event. The deletion determination unit is used to determine the type of the Libusb event. If it is an insertion event, it triggers the acquisition of the storage unit. If it is a removal event, it deletes the stored device number and device address. The acquisition and storage unit is used to acquire the device number and device address from the inserted USB device, and store the device number and device address as unique values ​​of the USB device. An initialization communication unit is used to initialize a communication object, connect to the communication object using a connection token based on the unique value of the USB device, initialize a communication interface, search for the corresponding device from the obtained USB device list based on the unique value of the USB device, open the found device and enumerate the communication interface, and communicate with the USB device through the communication interface.

10. An electronic device, characterized in that, The electronic device includes at least one processor, a memory, and instructions stored in the memory and executable by the at least one processor, the at least one processor executing the instructions to implement the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 8.

12. A chip system, characterized in that, The device includes a chip coupled to a memory for executing a computer program stored in the memory to perform the method according to any one of claims 1-8.

Images