Hp Whitelist Removal Tool
Vangele Ioannidis
You don't need to mod the bios to take advantage of the Intel Turbo Boost feature of the CPU on the IdeaPad Y500. All you need to do is get Throttlestop, set the multipliers to a suitable level below 34 that won't raise the core temperatures above 105 degrees Celsius, and uncheck the box for "BD PROCHOT". Also, I will also mention something went wrong with the multipliers when I first used Throttlestop, and it tried to overclock my CPU to 6.0 ghz by mistake once. I'm not sure about using speeds beyond 3.4 ghz if you are seeking to do that because I've never tried it. There are some posts I saw in Y500 unlocked bios thread about raising TDP, etc, and stuff like that:
I did a successful bios recovery on my laptop using an LED flash drive formatted to FAT32. I used the backup I made prior to flashing the modded bios using the file name "QIWY3.BIN" and the same bios recovery method that was used to do a bios recovery for the Y510P that is described here: -y510p-v305-bios-bricked-crisis-recovery-solved/
I downloaded some files from here as well after I was permitted to do so, but there seems to be a limit of 5 files per month. I thought my original wait time was 24 hours from the time of downloading my first 5 files, but I could be wrong.
I am also a new member waiting to be promoted to access these files. I have an intel 7260 ac card coming in the mail next week and I was looking to prepare my bios in time for its arrival so it's just plug and play.
anyway, I looked at the y500 white list removal thread as I was wondering how you remove the whitelist after modifying the bios. is there a particular setting you must change in the bios? or does this mod remove the whitelist automatically?
Awesome, just one more question as I am quite new to flashing bios firmware. Would I be able to flash the firmware back to 2.02 (or whatever the modified firmware version it is to remove whitelist) if I have a more current version? e.g v3.0??
Because we are still anxiously awaiting the documentation on the workings of the whitelist in System Preferences > Security and Privacy > Full Disk Access (previously Application Data in earlier betas), I report the following experimental results with macOS 10.14 Beta 7 (18A365a): [Edit 2018-08-22: Beta 8 seems to be the same.]
Although whitelisting a certain .app will enable its main executable and any child processes, it will not enable a helper/child app when the helper/child is launched by others in the background. The helper/child must itself be explicitly present in the whitelist.
If anyone can confirm, deny, or elaborate on these conclusions, I would really appreciate it. There is maybe only four weeks to go, and it appears that I have a lot of work to do. Was the breaking of command line tools in Beta 4 intentional?
In my experience, I have found that helper tools need to be app bundles in order to inherit any privileges granted by the "Full Disk Access" category. In my case, I had 2 different helper tools. One was embedded in my app, and the other was external. In my initial testing, I found that the embedded helper tool inherited the "Full Disk Access" privilege when I added my app to that category. However, when I added the external helper tool to the category, it did not get full access. This puzzled me for quite a while, as to why the embedded tool worked but the external one didn't. Then it dawned on me that the embedded one was an app bundle and the external one was a command-line tool. So I converted my external tool to be an app bundle, added it to the "Full Disk Access" category, and found that it now, indeed, had full access, just like the embedded tool.
One clarification. I did not have to add the embedded helper, separately, in order for it to work. All I had to do was add the main app (i.e. the app that the embedded helper was within) to the category. Once the main app was added to "Full Disk Access", all of its embedded helper apps were automatically granted full access too.
As you can see, (1) the bundle identifier com.sheepsystems.BookMacster.Worker is stated in the embedded Info.plist of the helper tool Sheep-Sys-Worker, (2) it is a child of the main app's bundle identifier com.sheepsystems.BookMacster, and (3) it matches the tool's code signing identifier.
It did work until Beta 4, although I had to explicity add the helper to the Application Data Full Disk Access whitelist. I explained this in Bug 42602218 on July 25, and this bug has recently been marked Closed Duplicate 41034701. What I have been trying to determine is: Does Closed mean we're going to fix it before the GM, or does it mean the security team has decided that denying access to command-line helpers is intended behavior. Because we're up to Beta 8 now and it's still broken, I suspect the latter, but if you could verify that I'd really appreciate it.
Thank you for the clarification, fschilling. First of all, let me clarify for other readers that your embedded helper is in fact an app bundle and not a command-line tool, and we all agree that app bundles work.
I am a user of the backup app Arq. I manually command Arq to perform a backup each night before leaving the computer. Back in July, I found that Arq reported errors accessing Mojave-protected files unless I explicitly and separately added its helper Arq Agent to the Application Data Full Disk Access whitelist. Although there was one glitch a couple weeks ago when I had to re-add it, everything worked until this morning, when my Arq report for last night indicated that it again could not access Mojave-protected files. So I did this:
To my delight, it worked. So I agree with you that, now, in Mojave Beta 8, whitlelisting a main app will enable its enclosed helper, if the helper is itself packaged as an application. That is really good news, because digging into the package and adding the helper would have scared away most users. Another improvement I've seen recently is that users can drag and drop apps into the whitelist.
I am still concerned, though, that there have been two occasions in the last month when I've needed to re-add Arq to the whitelist. This morning's failure may have been caused by me poking around yesterday in the whitelist, removing and adding my own app and its helper. But I did not touch the entries Arq or Arq Helper. They were still in the list this morning. I also wonder if users are going to need to re-add our apps to the whitelist each time our apps are updated. I hope that y'all keep up the testing, discussion, and bug reporting.
The whitelist in System Preferences > Security & Privacy > Full Disk Access now has a contextual menu with one item: Show in Finder. But now, it does not matter that much because it apparently works by code identity as Quinn suspected. That is, I can drag the app from the Xcode Build folder into the whitelist, copy the app to /Applications, run from there, or vice versa, and it still gets access to Mojave-protected files even though Show in Finder in the whitelist is not the copy which is running.
I still see no requirement for code signing, though. Apps get access to Mojave-protected files whether code signed or not. And there is still no access when debugging (debugger attached). That I recall being stated in the WWDC 2018 session.
Regarding my original concern, a helper tool installed via the Service Management API gets access to Mojave-protected files if its parent main app is in the whitelist, and even after the parent is quit, but only when it is launched by Service Management. If you launch the helper's executable from the command line, it is denied access. So I presume that a bundle-less command-line helper in Contents/Helpers, as discussed in my original post, would likewise be denied.
I can live with this, and it makes sense. I just wish it was documented somewhere, so I don't spend the next few weeks re-architecting my intermittently-running command-line tool into a constantly-running service under the Service Management API, only to have the rug pulled out in the Mojave GM.
I don't think we are going to get such an API, at least not in Mojave 10.14.0. You could do what I do in my demo app, which is to try to access a Mojave-protected file. Sorry, wrote in Objective-C because I was in a hurry ?
Then return YES if nil error. But pick a better file to test for your application, because, last time I checked, Safari's Bookmarks.plist does not exist in a virgin macOS user account until after the user adds one of their own bookmarks, and most users under the age of 50 nowadays have no idea what a bookmark is ?
The ideal thing would be an API call that causes a prompt to the logged-in user to grant the app Full Disk access because there's no way to trigger a prompt like that right now, and that's what backup apps need.
Enhancement requests have probably already been filed, by the participants in this thread. The post by me on August 31 contains text for such an enhancement request, which all are welcome to plagiarize.
We have a similar situation with some helper tools being located outside our main App, but we did not succeed in making your solution work: Our helper tools get EPERM erors when attempting to access the files in the protected user folders.
I thought that using the bundle identifiers describing the dependance of the main app and its helpers located else where as you explained on August 23, would allow us to keep our architecture and let the user allow only one App, the main app located in /Applications/MyCompany/MyProduct.app. (Plan A.)
c80f0f1006