Posts

Post marked as solved
1 Replies
239 Views
Hi, Some questions about how to use NEFilterDataProvider. Context: My extension has network rules (NENetworkRule) to filter most of HTTP/HTTPS trafic (port 80 et 443). Allowing a flow is a decision made by consulting custom rules (no NENetworkRule here) that the user can change at any moment. Questions: 1/ By modifying a custom rule, the decision for a flow can change. It is possible to retrieve currently allowed flows (for an application) and change the decision about it ? Can NSFilterFlow be cache to later change a decision ? Is there a way to know when a flow is no longer used ? 2/ An accepted flow seems never filtered again (except by quitting the application). The only way I found to apply new custom rules on currently allowed flow is by restarting the filter (load, NSFilterManager.isEnable=false, save, NSFilterManager.isEnable=true, save). Is it the correct method ? Thanks for you attention.
Posted
by Mox.
Last updated
.
Post marked as solved
2 Replies
294 Views
Hello, I'm using an NEFilterDataProvider to filter the HTTP/S flow of applications (based on bundleId). With the help of this forum, I can now retrieve the bundleId of the application's flow from the audit_token (sourceAppAuditToken). Unfortunately, for some applications (e.g., Safari), I get the bundleId of the isolated process that uses WebKit, but I would like to retrieve the bundleId of the responsible process (Safari). My current solution is to obtain the responsible PID of the WebKit process and then retrieve the bundleId from this PID (SecCodeCopyGuestWithAttributes). What is the correct way to get the bundleId of the responsible process?
Posted
by Mox.
Last updated
.
Post not yet marked as solved
0 Replies
395 Views
Hello !Since I installed the last Mojave Security update (today) I see lots of kernel HID logging in the Console App (like that):par défaut 18:00:36.629857 +0200 kernel >>LogiHidIoObject::setValue(0) par défaut 18:00:36.629857 +0200 kernel <<logihidioobject::setvalue par défaut 18:00:36.629859 +0200 kernel <<logihidiodata::parsereportforvalueobject par défaut 18:00:36.629859 +0200 kernel <<logihidiodata::parsereport par défaut 18:00:36.635666 +0200 kernel >>LogiHidIoDriver::handleReportWithTime(5214028713962, 0x41a0ba00, 0, 0) par défaut 18:00:36.635677 +0200 kernel <par défaut 18:00:36.635705 +0200 kernel <<logihidioobject::setvalue par défaut 18:00:36.635722 +0200 kernel >>LogiHidIoCaps::getInputButtonCaps(0x9, 0x7) par défaut 18:00:36.635739 +0200 kernel <par défaut 18:00:36.635750 +0200 kernel >>LogiHidIoCaps::getInputButtonCaps(0x9, 0xb) par défaut 18:00:36.635764 +0200 kernel The parsed button [0x9,0xc] value is 0 par défaut 18:00:36.635781 +0200 kernel The input button caps is found in the range usage par défaut 18:00:36.635785 +0200 kernel <<logihidioobject::setvalue par défaut 18:00:36.635785 +0200 kernel <<logihidiodata::parsereportforbuttonobject par défaut 18:00:36.635787 +0200 kernel >>LogiHidIoData::parseReportForButtonObject(0x41a0ba00, 0x41a10560) par défaut 18:00:36.635788 +0200 kernel >>LogiHidIoCaps::getInputButtonCaps(0x9, 0xf) par défaut 18:00:36.635788 +0200 kernel The input button caps is found in the range usage par défaut 18:00:36.635789 +0200 kernel bitField:0x2, reportID:0x0, collection:0x2, startBit:0x0 par défaut 18:00:36.635790 +0200 kernel <par défaut 18:00:36.635790 +0200 kernel The parsed button [0x9,0xf] value is 0 par défaut 18:00:36.635792 +0200 kernel >>LogiHidIoObject::setValue(0) par défaut 18:00:36.635792 +0200 kernel <<logihidioobject::setvalue par défaut 18:00:36.635793 +0200 kernel <<logihidiodata::parsereportforbuttonobject par défaut 18:00:36.635794 +0200 kernel >>LogiHidIoData::parseReportForButtonObject(0x41a0ba00, 0x41a10540) par défaut 18:00:36.635794 +0200 kernel >>LogiHidIoCaps::getInputButtonCaps(0x9, 0x10)Is it normal ? Some of you have this ? Is there a way to reduce this loggins ?Regards
Posted
by Mox.
Last updated
.