Here's a simple program that spoofs an ARP reply for a given IP address. If I spin up two terminal sessions on the same machine. Run this code in one window % ./spoof en0 192.168.1.7 Listening on en0 for ARP requests to 192.168.1.7 Spoofing MAC: 00:0c:87:47:50:27 And in the second window cause the OS to issue an ARP_REQ % ping 192.168.1.7 You will see the program respond to the ARP request. (Wireshark will see the ARP_REQ and ARP_REPLY packets) however my arp table isn't updated with the MAC for the IP address. There is no firewall active. % arp -a|grep 192.168.1.7 (192.168.1.7) at (incomplete) on en0 ifscope [ethernet] This is running on a MacBook pro M3 (OSX 15.4). HOWEVER, on a MacBook pro M4 (OSX 15.2) is does Work !!!!! Can anyone explain why its not working? spoof.txt

I need to read data from the user. For convenience, the data will be in a property list, so it's easy to get a dictionary containing the property list data. But, since it's coming from outside, I need to validate that the data is in the required format, i.e. it has the right keys and the right sort of data for each key, e.g. <name> has a string, <keys> has an array of appropriate values. Since this is part of a long-established product, and targets 10.13, I want to do this in Objective-C if possible. I've been working mostly with Swift in recent years, so I've forgotten a lot of what I used to know about Objective-C, I'm sure. My first thought was to obtain the value for each key and check the class type with isa, but I see that's deprecated in macOS 13 with no replacement. I don't see another way to check the class. I'm sure other people have solved the same problem, but my searches have not turned up any answers.

My MacOS swift app [myStuckApp5] refuses to close when running on Monterrey (The app becomes unresponsive after finishing its work, and needs to be forcefully closed). However, it closes as expected when running MacOS 13 and above. How can I troubleshoot this error? I'm attaching the content of the sys Log related to the app while it was stuck (too long to copy here...) This is the content of the related sys Log

Hi, I develop a Mac application, initially on Catalina/Xcode12, but I recently upgrade to Monterey/Xcode13. I'm about to publish a new version: on Monterey all works as expected, but when I try the app on Sequoia, as a last step before uploading to the App Store, I encountered some weird security issues: The main symptom is that it's no longer possible to save any file from the app using the Save panel, although the User Select File entitlement is set to Read/Write. I've tried reinstalling different versions of the app, including the most recent downloaded from TestFlight. But, whatever the version, any try to save using the panel (e.g. on the desktop) results in a warning telling that I don't have authorization to record the file to that folder. Moreover, when I type spctl -a -t exec -v /Applications/***.app in the terminal, it returns rejected, even when the application has been installed by TestFlight. An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost... It suspect a Gate Keeper problem, but I cannot found any info on the web about how this system could be reset. I tried sudo spctl --reset-default, but it returns This operation is no longer supported... I wonder if these symptoms depend on how the app is archived and could be propagated to my final users, or just related to a corrupted install of Sequoia on my local machine. My feeling is that a signature problem should have been detected by the archive validation, but how could we be sure? Any idea would be greatly appreciated, thanks!

I'm writing some code, intended to be run on macOS (not IOS). My code could greatly benefit from using IOReport, which is an undocumented IOKit API for obtaining various metrics like energy consumption on an Apple processor. I don't plan to submit my program to the App Store, but I do plan on making the Git repo containing my code public. My understanding is that using undocumented IOKit APIs is strictly forbidden for IOS or macOS applications intended to be made available on the App Store. But what about programs not intended to be submitted to the App Store, like in my case? I'm wondering if anybody knows what Apple's policy is regarding using undocumented APIs in such a way on macOS.

Hi. I have three disk partitions on my MacBook Air M1. The one with Monterey, the one with Sonoma, and the one with Sequoia (15.3.1 in particular). When I try to download the 15.4 Beta from software update in settings, everything would go "fine" - the download process is being completed, the computer says it's going to restart in 60seconds, the countdown begins, etc. However, when restarting several times, I am being logged in once again into previous macOS (15.3.1) version, with a kernel panic report. I had the same panic on macOS 15.3 when attempting to download 15.4 Beta. I've upgraded my macOS to 15.3.1, as I thought I'd need the very last available version of regular macOS to participate in the newest beta. However, the panic occurs, pointing to some t8020dart.c file. I don't even theoretically know what is this and couldn't find any reference to that C file. Attaching a part of panic report: panic(cpu 3 caller 0x0): t8020dart 0xfffffdf02c980000 (dart-disp0): Can't ignore lock validation @t8020dart.c:535 Debugger message: panic Memory ID: 0xff OS release type: Not set yet OS version: Not set yet Kernel version: Darwin Kernel Version 24.4.0: Sat Feb 15 22:43:38 PST 2025; root:xnu-11417.100.533.501.4~3/RELEASE_ARM64_T8103 Fileset Kernelcache UUID: 232D67A6D42C66E14780A24B3C0AE05D Kernel UUID: F2602757-A486-30A9-8D8E-714224E5FE4A Boot session UUID: 575CD5EA-6898-47ED-9AEC-05E318135695 iBoot version: iBoot-11881.100.964.0.1 iBoot Stage 2 version: iBoot-11881.100.964.0.1 secure boot?: YES roots installed: 0 Paniclog version: 14 KernelCache slide: 0x00000000181d8000 KernelCache base: 0xfffffe001f1dc000 Kernel slide: 0x00000000181e0000 Kernel text base: 0xfffffe001f1e4000 Kernel text exec slide: 0x00000000198d0000 Kernel text exec base: 0xfffffe00208d4000 mach_absolute_time: 0x85b39c4 Epoch Time: sec usec Boot : 0x00000000 0x00000000 Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x00000000 0x00000000 Zone info: Zone map: 0xfffffe120c000000 - 0xfffffe380c000000 . VM : 0xfffffe120c000000 - 0xfffffe17d8000000 . RO : 0xfffffe17d8000000 - 0xfffffe1a72000000 . GEN0 : 0xfffffe1a72000000 - 0xfffffe203e000000 . GEN1 : 0xfffffe203e000000 - 0xfffffe260a000000 . GEN2 : 0xfffffe260a000000 - 0xfffffe2bd6000000 . GEN3 : 0xfffffe2bd6000000 - 0xfffffe31a2000000 . DATA : 0xfffffe31a2000000 - 0xfffffe380c000000 Metadata: 0xfffffe76ce010000 - 0xfffffe76d7810000 Bitmaps : 0xfffffe76d7810000 - 0xfffffe76d8d80000 Extra : 0 - 0 CORE 0 recently retired instr at 0xfffffe0020a9d2d0 CORE 1 recently retired instr at 0xfffffe0020a9d2d0 CORE 2 recently retired instr at 0xfffffe0020a9d2d0 CORE 3 recently retired instr at 0xfffffe0020a9b9ec CORE 4 recently retired instr at 0xfffffe0020a9d2d0 CORE 5 recently retired instr at 0xfffffe0020a9d2d0 CORE 6 recently retired instr at 0xfffffe0020a9d2d0 CORE 7 recently retired instr at 0xfffffe0020a9d2d0 TPIDRx_ELy = {1: 0xfffffe2040392fb0 0: 0x0000000000000003 0ro: 0x0000000000000000 } CORE 0 PVH locks held: None CORE 1 PVH locks held: None CORE 2 PVH locks held: None CORE 3 PVH locks held: None CORE 4 PVH locks held: None CORE 5 PVH locks held: None CORE 6 PVH locks held: None CORE 7 PVH locks held: None CORE 0: PC=0xfffffe002102157c, LR=0xfffffe0021021568, FP=0xfffffebf22637890 CORE 1: PC=0xfffffe00210207a4, LR=0xfffffe0020fe4eb0, FP=0xfffffebf2262b890 CORE 2: PC=0xfffffe002094c790, LR=0xfffffe002094c63c, FP=0xfffffebf22643890 CORE 3 is the one that panicked. Check the full backtrace for details. CORE 4: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2213fed0 CORE 5: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf22163ed0 CORE 6: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2216fed0 CORE 7: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2211bed0 Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe260c042b78: 0 pages, 268 threads: pid 0: kernel_task Panicked thread: 0xfffffe2040392fb0, backtrace: 0xfffffebf22666920, tid: 279 lr: 0xfffffe00209332bc fp: 0xfffffebf226669b0 lr: 0xfffffe0020a93cdc fp: 0xfffffebf22666a20 lr: 0xfffffe0020a91e94 fp: 0xfffffebf22666ae0 lr: 0xfffffe00208dbb94 fp: 0xfffffebf22666af0 lr: 0xfffffe0020932ba0 fp: 0xfffffebf22666ec0 lr: 0xfffffe0020932924 fp: 0xfffffe0031577e90 lr: 0xfffffe00211cb198 fp: 0xfffffe0031577eb0 lr: 0xfffffe002120aae4 fp: 0xfffffe0031577f80 lr: 0xfffffe00211f9104 fp: 0xfffffe0031577fe0 lr: 0xfffffe00208dc3fc fp: 0xfffffebf22666ee0 lr: 0xfffffe0020a82d74 fp: 0xfffffebf22666f30 lr: 0xfffffe00222f9964 fp: 0xfffffebf22667c00 lr: 0xfffffe002107c198 fp: 0xfffffebf22667c90 lr: 0xfffffe002107b79c fp: 0xfffffebf22667dc0 lr: 0xfffffe002107963c fp: 0xfffffebf22667e40 lr: 0xfffffe002107ffc8 fp: 0xfffffebf22667f20 lr: 0xfffffe00208e4f04 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleT8020DART(1.0)[6BE1928B-115D-345C-B457-FD1101FC7E1E]@0xfffffe00222f9120->0xfffffe002230139b dependency: com.apple.driver.AppleARMPlatform(1.0.2)[4EB15554-31E0-3057-9A85-EAA79C69E848]@0xfffffe0021369200->0xfffffe00213bf21f dependency: com.apple.driver.IODARTFamily(1)[8FC5A69F-6052-3F02-9EA3-78D080116812]@0xfffffe0022ec6750->0xfffffe0022eda9cf last started kext at 139867172: com.apple.plugin.IOgPTPPlugin 1340.12 (addr 0xfffffe001fba3f70, size 139368)

Hi guys, I am looking for some help from anyone very desperate I am being hacked at the system level dealing with Malious 3rd party TVapp Exhibited ksophicisted container based persistence Possible Zero Day exploration Active Network connection to cloud infrastructure resistance to standard removal I did attempt to report to apple security and have not had an update but fear loss of account access even with 2fa since they have ability Currently I can't access internet/wifi(EVEN with ethernet cable) Honestly any help from anyone

Hi. I am facing a panic in distributed virtual filesystem of my own making. The panic arises on attempt of copying a large folder, or writing a large file (both around 20gb). An important note here is that the amount of files we try to copy is larger than available space (for testing purposes, the virtual file system had a capacity of 18 gigabytes). The panic arises somewhere on 12-14gigabytes deep into copying. On the moment of panic, there are still several gigabytes of storage left. The problem is present for sure for such architectures and macOS versions: Sonoma 14.7.1 arm64e Monterey 12.7.5 arm64e Ventura 13.7.1 intel Part from panic log from Ventura 13.7.1 intel, with symbolicated addresses: panic(cpu 2 caller 0xffffff80191a191a): watchdog timeout: no checkins from watchdogd in 90 seconds (48 total checkins since monitoring last enabled) Panicked task 0xffffff907c99f698: 191 threads: pid 0: kernel_task Backtrace (CPU 2), panicked thread: 0xffffff86e359cb30, Frame : Return Address 0xffffffff001d7bb0 : 0xffffff8015e70c7d mach_kernel : _handle_debugger_trap + 0x4ad 0xffffffff001d7c00 : 0xffffff8015fc52e4 mach_kernel : _kdp_i386_trap + 0x114 0xffffffff001d7c40 : 0xffffff8015fb4df7 mach_kernel : _kernel_trap + 0x3b7 0xffffffff001d7c90 : 0xffffff8015e11971 mach_kernel : _return_from_trap + 0xc1 0xffffffff001d7cb0 : 0xffffff8015e70f5d mach_kernel : _DebuggerTrapWithState + 0x5d 0xffffffff001d7da0 : 0xffffff8015e70607 mach_kernel : _panic_trap_to_debugger + 0x1a7 0xffffffff001d7e00 : 0xffffff80165db9a3 mach_kernel : _panic_with_options + 0x89 0xffffffff001d7ef0 : 0xffffff80191a191a com.apple.driver.watchdog : IOWatchdog::userspacePanic(OSObject*, void*, IOExternalMethodArguments*) (.cold.1) 0xffffffff001d7f20 : 0xffffff80191a10a1 com.apple.driver.watchdog : IOWatchdog::checkWatchdog() + 0xd7 0xffffffff001d7f50 : 0xffffff80174f960b com.apple.driver.AppleSMC : SMCWatchDogTimer::watchdogThread() + 0xbb 0xffffffff001d7fa0 : 0xffffff8015e1119e mach_kernel : _call_continuation + 0x2e Kernel Extensions in backtrace: com.apple.driver.watchdog(1.0)[BD08CE2D-77F5-358C-8F0D-A570540A0BE7]@0xffffff801919f000->0xffffff80191a1fff com.apple.driver.AppleSMC(3.1.9)[DD55DA6A-679A-3797-947C-0B50B7B5B659]@0xffffff80174e7000->0xffffff8017503fff dependency: com.apple.driver.watchdog(1)[BD08CE2D-77F5-358C-8F0D-A570540A0BE7]@0xffffff801919f000->0xffffff80191a1fff dependency: com.apple.iokit.IOACPIFamily(1.4)[D342E754-A422-3F44-BFFB-DEE93F6723BC]@0xffffff8018446000->0xffffff8018447fff dependency: com.apple.iokit.IOPCIFamily(2.9)[481BF782-1F4B-3F54-A34A-CF12A822C40D]@0xffffff80188b6000->0xffffff80188e7fff Process name corresponding to current thread (0xffffff86e359cb30): kernel_task Boot args: keepsyms=1 Mac OS version: 22H221 Kernel version: Darwin Kernel Version 22.6.0: Thu Sep 5 20:48:48 PDT 2024; root:xnu-8796.141.3.708.1~1/RELEASE_X86_64 The origin of the problem is surely inside my filesystem. However, the panic happens not there but somewhere in watchdog. As far as I can tell, the source code for watchdog is not available for public. I can't understand what causes the panic. Let's say we have run out of space. Couldn't write data. Writing received a proper error message and aborted. That's what is expected. However, it is unclear for why the panic arises.

Issue description: Using Xcodebuild command to build a project using Xcode 16.1 and 16.2, getting multiple device simulator warnings with same os and same model. Please see issue: https://github.com/actions/runner-images/issues/11036 Repro steps: create a Xcode project, build it using below command with Xcode 16 version. run: | echo "Building project manually..." xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 16 Pro,OS=18.2' build | xcbeautify --renderer github-actions

Should I allow the CIJSULAgent to find devices on local network?

I have a multiplatform app that I've been working on that targets iphones, ipad, and macos. I also have a widgetextension that targets all three devices. On iphones and ipads, the widgets show up in the widget gallery with no problems. But on the mac, the widget center does show my app, but its widgets are "from iPhone" meaning that if my app was not install on an iphone, they just won't show up on the mac at all. I have not idea of what I'm doing wrong or how to fix it. Do I need to create a widget extension for the mac seperately?

I have written a small iOS app that I run as a MacOS app using the build target "My Mac (Designed for iPad)". It runs fine, however I cannot find where the app itself is installed on my system. When running the app multiple times I see that a number is appended to the title of my app is incremented indicating that old versions of the app are still installed somewhere. Where are they located on my system? Many thanks for the help!

What is the proper payload for the FDEFileVault? Do I need to provide a user password in the payload to proceed with turning on the FileVault? Isn't that a privacy issue? Why UserEntersMissingInfo does not work for me? How to properly turn off FileVault - every try failed? Below I attach tested payloads and results. Test 1: Enable: "On" Result 1: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 2: Enable: "On" Username: "username on a device" Result 2: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 3: Enable: "On" Username: "username on a device" Password: "password of the user" Result 3: Success: FileVault turned On Test 4: After previously turning On FileVault successfully after restarting a machine. Enable: "Off" Result 4: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 5: Enable: "On" UserEntersMissingInfo: True Result 5: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 6: Enable: "On" Username: "username on a device" UserEntersMissingInfo: True Result 6: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 7: This is example payload from: https://developer.apple.com/documentation/devicemanagement/fdefilevault#Profile-Example Defer: True Enable: "On" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: False Result 7: Success: FileVault turned On Test 8: Same as test 4, but after turning on like test 7. Test 9: Defer: True Enable: "Off" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: False Result 9: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 10: Defer: True Enable: "Off" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: True Result 10: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 11: Defer: True Enable: "Off" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: True DeferForceAtUserLoginMaxBypassAttempts: 0 Result 11: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 12: UserEntersMissingInfo: True Enable: "Off" Username: "username on a device" Result 12: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help.

I'm looking for confirmation on the security aspects of fdesetup authrestart when used on a FileVault-enabled Mac. As I understand it, this command temporarily stores the decryption key in memory to allow the system to restart without requiring manual entry of the FileVault password. However, I have a few security-related concerns: Storage of the Decryption Key: Where exactly is the key stored during an authenticated restart? Is it protected within the Secure Enclave (for Apple Silicon Macs) or the T2 Security Chip on Intel Macs? Key Lifetime &amp; Wiping: At what point is the decryption key erased from memory? Does it persist in any form after the system has fully rebooted? Protection Against Physical Attacks: If an attacker gains physical access to the machine before the restart completes, is there any possibility that they could extract the decryption key from memory? Cold Boot Attack Resistance: Is there any risk that advanced forensic techniques (such as freezing RAM to retain data) could be used to recover the decryption key after issuing an authenticated restart? Malware Resistance: Could a compromised system (e.g., root access by an attacker) intercept or misuse the decryption key before the restart? I understand that on Apple Silicon and T2-equipped Macs, FileVault keys are tied to hardware-based encryption, making unauthorized access difficult. However, I'd like to confirm whether Authenticated Restart introduces any new risks compared to a standard FileVault-enabled boot process.

I'm not quite sure where the problem is, but I will describe what I am doing to recreate the issue, and am happy to provide whatever information I can to be more useful. I am changing the ActivationPolicy for my app in order to make it unobtrusive when in the background (e.g. hiding it from the dock and using only a menu bar status item). When the user activates the app with a hotkey, it changes from NSApplicationActivationPolicyAccessory back to NSApplicationActivationPolicyRegular. This allows normal usage (dock icon, menu bar, etc.) This works fine, except in a rare situation which I finally just tracked down. If there is a window open in the app and I use the hotkey to convert back to an accessory, and then disconnect and reconnect the display on which the app was previously displayed, when I convert the app back to "regular mode", the menu bar has disappeared (and I am left with an empty space at the top of the screen). I can also trigger this bug by having the display in question briefly mirror the other display (effectively "orphaning" the hidden app), and then restoring the original side-by-side configuration before activating the app again. The app otherwise works, but the menu bar is missing. Switching back and forth with other apps does not fix the problem. Quitting and restarting the app resolves the issue. As does disabling the accessory only mode and forcing the app to always remain in "regular mode" with a dock icon (there is a preference for this in my app). Once fixed, I can then re-enable the "accessory mode" and all is well until the bug is triggered again. The bug would normally occur quite sporadically, presumably requiring a particular combination of changing Spaces or displays, or having the computer go to sleep while this app was in accessory mode. Thus far, the above is the only way I have found that can replicate this issue on demand. If I close all windows before hiding the app, then it works fine when I revert to "regular mode". It only happens if there is a window open at the time. Using applicationDidChangeScreenParameters: on my AppDelegate indicates that there is a change in screen, and logging window.screen.frame for each open window in [NSApp orderedWindows] shows that the size changes from e.g. 1920x1080 to 0x0 and back while the display is disconnected or mirrored. There is also an error in the console in Xcode when this happens -- invalid display identifier <some UUID>. I have tried various options for window collectionBehavior, as well as various settings for Spaces (which I normally use). None of these changes has fixed the behavior thus far. I use [NSApp hide:self]; from my AppDelegate to hide the app, and [[NSRunningApplication currentApplication] activateWithOptions:NSApplicationActivateAllWindows];[NSApp unhide:self]; to bring it back to the front. I welcome any ideas for things to chase down, or requests for more specific information that would be useful. Thank you! Fletcher

Mac users often ask whether they should install "anti-virus" software. The answer usually given on ASC is "no." The answer is right, but it may give the wrong impression that there is no threat from what are loosely called "viruses." There is a threat, and you need to educate yourself about it. This is a comment on what you should—and should not—do to protect yourself from malicious software ("malware") that circulates on the Internet and gets onto a computer as an unintended consequence of the user's actions. It does not apply to software, such as keystroke loggers, that may be installed deliberately by an intruder who has hands-on access to the computer, or who has been able to log in to it remotely. That threat is in a different category, and there's no easy way to defend against it. The comment is long because the issue is complex. The key points are in sections 5, 6, and 10. OS X now implements three layers of built-in protection specifically against malware, not counting runtime protections such as execute disable, sandboxing, system library randomization, and address space layout randomization that may also guard against other kinds of exploits. 2. All versions of OS X since 10.6.7 have been able to detect known Mac malware in downloaded files, and to block insecure web plugins. This feature is transparent to the user. Internally Apple calls it "XProtect." The malware recognition database used by XProtect is automatically updated; however, you shouldn't rely on it, because the attackers are always at least a day ahead of the defenders. The following caveats apply to XProtect: ☞ It can be bypassed by some third-party networking software, such as BitTorrent clients and Java applets. ☞ It only applies to software downloaded from the network. Software installed from a CD or other media is not checked. As new versions of OS X are released, it's not clear whether Apple will indefinitely continue to maintain the XProtect database of older versions such as 10.6. The security of obsolete system versions may eventually be degraded. Security updates to the code of obsolete systems will stop being released at some point, and that may leave them open to other kinds of attack besides malware. 3. Starting with OS X 10.7.5, there has been a second layer of built-in malware protection, designated "Gatekeeper" by Apple. By default, applications and Installer packages downloaded from the network will only run if they're digitally signed by a developer with a certificate issued by Apple. Software certified in this way hasn't necessarily been tested by Apple, but you can be reasonably sure that it hasn't been modified by anyone other than the developer. His identity is known to Apple, so he could be held legally responsible if he distributed malware. That may not mean much if the developer lives in a country with a weak legal system (see below.) Gatekeeper doesn't depend on a database of known malware. It has, however, the same limitations as XProtect, and in addition the following: ☞ It can easily be disabled or overridden by the user. ☞ A malware attacker could get control of a code-signing certificate under false pretenses, or could simply ignore the consequences of distributing codesigned malware. ☞ An App Store developer could find a way to bypass Apple's oversight, or the oversight could fail due to human error. Apple has so far failed to revoke the codesigning certificates of some known abusers, thereby diluting the value of Gatekeeper and the Developer ID program. These failures don't involve App Store products, however. For the reasons given, App Store products, and—to a lesser extent—other applications recognized by Gatekeeper as signed, are safer than others, but they can't be considered absolutely safe. "Sandboxed" applications may prompt for access to private data, such as your contacts, or for access to the network. Think before granting that access. Sandbox security is based on user input. Never click through any request for authorization without thinking. 4. Starting with OS X 10.8.3, a third layer of protection has been added: a "Malware Removal Tool" (MRT). MRT runs automatically in the background when you update the OS. It checks for, and removes, malware that may have evaded the other protections via a Java exploit (see below.) MRT also runs when you install or update the Apple-supplied Java runtime (but not the Oracle runtime.) Like XProtect, MRT is effective against known threats, but not against unknown ones. It notifies you if it finds malware, but otherwise there's no user interface to MRT. 5. The built-in security features of OS X reduce the risk of malware attack, but they are not, and never will be, complete protection. Malware is a problem of human behavior, and a technological fix is not going to solve it. Trusting software to protect you will only make you more vulnerable. The best defense is always going to be your own intelligence. With the possible exception of Java exploits, all known malware circulating on the Internet that affects a fully-updated installation of OS X 10.6 or later takes the form of so-called "****** horses," which can only have an effect if the victim is duped into running them. The threat therefore amounts to a battle of wits between you and the scam artists. If you're smarter than they think you are, you'll win. That means, in practice, that you always stay within a safe harbor of computing practices. Malware defence By Linc Davis - https://discussions.apple.com/thread/6460085

Crash dump: `Crashed Thread: 0 tid_103 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGILL) Exception Codes: KERN_PROTECTION_FAILURE at 0x000000016d3bfea0 Exception Codes: 0x0000000000000002, 0x000000016d3bfea0 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: Unity [7873] VM Region Info: 0x16d3bfea0 is in 0x169bbc000-0x16d3c0000; bytes after start: 58736288 bytes before end: 351 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL mapped file 169b00000-169ba8000 [ 672K] rw-/rwx SM=PRV Object_id=4d22156e GAP OF 0x14000 BYTES ---&gt; STACK GUARD 169bbc000-16d3c0000 [ 56.0M] ---/rwx SM=NUL stack guard for thread 0 Stack 16d3c0000-16dbbc000 [ 8176K] rw-/rwx SM=SHM thread 0 Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x1932ee7ac _platform_memset + 108 1 libmonobdwgc-2.0.dylib 0x33977abdc GC_clear_stack_inner + 60 2 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 3 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 4 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 5 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 6 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 7 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 8 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 9 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 10 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 11 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 12 libmonobdwgc-2.0.dylib 0x33976b518 GC_clear_stack + 76 13 libmonobdwgc-2.0.dylib 0x33973c074 mono_gc_alloc_obj + 112 14 libmonobdwgc-2.0.dylib 0x3396e0db4 mono_object_new_specific_checked + 72 15 libmonobdwgc-2.0.dylib 0x3396e116c ves_icall_object_new_specific + 28`

The MDM was installed correctly and other commands are working fine. I have tried to send the InstallProfile with custom configuration to the device, but it was displayed as not signed. How to sign the payload for InstallProfile command and where it should be included in the payload / command? The payload I sent to a mac with MDM installed: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Payload</key> <data> BASE64_HERE </data> <key>RequestType</key> <string>InstallProfile</string> </dict> </plist> Decoded base64 from the payload above was: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>PayloadContent</key> <dict> <key>com.example.myapp</key> <dict> <key>test_key</key> <string>test_value</string> </dict> </dict> <key>PayloadDisplayName</key> <string>My App Configuration</string> <key>PayloadIdentifier</key> <string>com.org_name.mdm.profile.uq_id_here</string> <key>PayloadType</key> <string>com.apple.ManagedClient.preferences</string> <key>PayloadUUID</key> <string>UUID4 HERE</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </array> <key>PayloadDisplayName</key> <string>App Configuration Profile</string> <key>PayloadIdentifier</key> <string>com.example.myapp.config</string> <key>PayloadOrganization</key> <string>ORG NAME</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>ANOTHER UUID4 HERE</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist> System logs from Device: [*] Processing server request: InstallProfile for: <Device> [ERROR] System keychain reported it is unavailable but will proceed as if it is. [*] === CPF_InstallProfile === com.example.myapp.config (user: <Computer>) (source: 'MDM') [*] >>>>> Sending HTTP request (PUT) [Acknowledged(InstallProfile) [*] <<<<< Received HTTP response (200) [Acknowledged(InstallProfile) [*] Processing server request: ProfileList for: <Device> [*] >>>>> Sending HTTP request (PUT) [Acknowledged(ProfileList) [*] <<<<< Received HTTP response (200) [Acknowledged(ProfileList) Also the ProfileList didn't include the installed profile. Is it because it was unsigned? How it should be signed?

Hi, Overview I am using Xcode Cloud for my multi platform app. The macOS test case fails, however the iOS test case runs and succeeds. I don't have any UI test cases written, the test case are simple and have nothing platform (macOS) specific. Questions What can I do to fix this? Is there any user privileges needed to launch the macOS app for testing? I ask because when I ran the UI tests locally it launched the app and asked for my macOS user password. Just wondering if that is the reason it didn't launch in Xcode Cloud. Error: <Appname> encountered an error (Failed to install or launch the test runner. If you believe this error represents a bug, please attach the result bundle at /Volumes/workspace/resultbundle.xcresult.(Underlying Error: Could not launch "AppnameTests. The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed) ))) × Could not launch "<Appname>" × Could not launch "AppnameTests" × AppnameUITests.testExample() Failed to get launch progress for <XCUIApplicationImpl: 0x600000564630 <BundleID> at /Volumes/workspace/TestProducts/Debug-Dev/<Appname>.app>: Could not launch "app name". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed)) AppnameUITests.swift:28 * AppnameUITests.testLaunchPerformance) Failed to get launch progress for «XCUIApplicationimpl: 0x60000054630 <BundleID> at /Volumes/workspace/TestProducts/Debug-Dev/<Appname>.apps: Could not launch "<Appname>". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed)) AppnameUITests.swift:37 g * AppnameUITestsLaunchTests.testLaunch) Failed to get launch progress for «XCUIApplicationimpl: 0x60000054630 <BundleID> at /Volumes/workspace/Testroducts/Debug-Dev/<Appname>.apps: Could not launch "<Appname>". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed.

Macos15照片app需要点击一下，不能直接进入，点击一次后，还要再点击一下，才能看到照片，希望能修复一下