Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


vit9696 last won the day on January 11

vit9696 had the most liked content!

1 Follower

About vit9696

  • Rank
    InsanelyMac Sage

Profile Information

  • Gender
  1. Lilu — kext and process patcher

    Thanks for the links and notes. Just as you said, the use cases for such functionality could broadly vary. 4 years ago, when AppleALC was not even planned, Lilu prototype was actually a modern replacement to SIMBL. However, when it comes to software modification there are two points to think about: Security Target audience SIMBL was pretty impressive several years ago, where numerous developers created their extensions to patch different things. Later on their enthusiasm disappeared, and even though SIMBL still works on modern macOS versions (with some hacks and SIP workarounds), its userbase is largely dead. Basically the same with Cydia Substrate and Jailbreak itself, which no longer belong to the common sense. More than that, SIMBL or a working Lilu-based solution with a SDK opens a possibility for malware writers and similar shady people to write harmful software at no effort. And that's if we forget about other possible bugs. Regarding the "kernel privileges and stuff". We followed the exact model you described during the creation of an initial prototype of MiniSubstrate with 07151129. And it was badly wrong. Making it possible to let the user to dynamically load an extension during the system runtime causes an extreme security risk, having a plugin management system injected in every process is an additional risk to system stability, and a possibility to swap one dylib with another is another great security risk. The only way it could actually appear (and is actually implemented in Lilu) is to have a kext that is bundled with all the extensions with a defined process list, which is only loaded at boot time. If you think of it, this is similar to how Cydia Substrate works with a 'respring'. Do not take me wrong though, obviously nobody executes any code with kernel privileges, it uses app privileges and is no different from any other dylib. As a bonus this approach is in fact more performant. All in all, while I still consider a possibility of this project going live, I remain unconvinced about the existence of an audience, which would actually write useful plugins. Perhaps, more actual projects and demand could work better here, but such a revival will take time.
  2. Lilu — kext and process patcher

    Hi, what do you need this functionality for? In brief, it is possible and the code for this exists, yet primarily in private as a part of the project Lilu codebase is based on. Some parts were published with Shiki, some others found its way to the latest Lilu release. You in fact do not even need a dylib with Lilu, since everything could be done entirely in memory. As I said, a reasonably large codebase (userspace sdk) remains private for several reasons. It is a discussible question whether it should be published or not, so I would like to hear the reasons you need this in detail.
  3. AppleALC — dynamic AppleHDA patching

    Lilu and AppleALC both target Mountain Lion (10.8) and higher (as well as all the prebuilt binaries on github releases). When it comes to compiling, you will need a compiler with C++14 support. Normally Lilu and AppleALC would compile on Mavericks and newer, since clang from Xcode 5.1.1 does not fully support c++14. However, I made some changes to Lilu and AppleALC (other kexts may follow) to let the buildsystem use the preliminary C++14 support on Mountain Lion's Xcode as well. However, you should really avoid compiling with old Xcode if you could, as its bundled compiler is less reliable and may provide less optimised code.
  4. AppleALC — dynamic AppleHDA patching

    Ok, let me clarify the verb changes in the latest release. It should indeed be the case for the underlying AppleALC implementation to have everything CodecCommander offers. I.e. sending codec commands (verbs) at boot and wake. Previously I did not see any necessity in this feature, but since even higher end motherboards started to require this functionality it was implemented in AppleALC. However, it does not mean that AppleALC has all the resources updated with the necessary verbs to let you delete CodecCommander and get it work out of the box. For some confugurations (mentioned in the changelog) we blindly added an EAPD fix verb to WakeConfigData, but obviously it is not present in all the necessary places. It also goes without saying that more verbs may be needed to wake your codec after sleep. It is not really possible for us to monitor every existing codec, so we are hoping for the community to provide the changes via pull-requests. To give you a technical idea, AppleALC will send codec verbs on wake if WakeVerbReinit is present in pin configurations plist (note, it is now merged into AppleALC by the build system by default). Wake verbs are read from either WakeConfigData if it is present, or from ConfigData otherwise.
  5. AppleALC — dynamic AppleHDA patching

    These files are present in Lilu debug kext (in its SDK). Check whether anything could have gone wrong during its extraction.
  6. After some time of iTunes testing with the latest betas, we came up with a conclusion that iTunes patching is still required for 10.13.4. It just happens that iTunes crashes got much rarer, and a lot of people believed they are gone. I committed a change that reenables iTunes crashfix autodetect: https://github.com/vit9696/Shiki/commit/1b8677744aa6631cc9a9304da494a7636f53d786 To avoid making a rush of the releases we will wait till 10.13.4 is out. Those affected may compile themselves. HTML5 DRM video on NetFlix and similar requires hardware DRM support. Unless your discrete GPU implements it, you are doomed, because Intel support is broken. You may still use other browsers, which do not rely on FairPlay.
  7. AptioMemoryFix

    Well, I hope it works for someone too. Now that you said reduced memory map, is there any chance it does not fit here: https://github.com/vit9696/AptioFixPkg/blob/master/Platform/AptioMemoryFix/BootFixes.c#L46 You could try increasing to 128, although so far it was not necessary to anyone. I added the notes regarding TB, SGX and stuff to the readme. In case anyone has the same issue as you did, the actions to try will at least be known.
  8. AptioMemoryFix

    Then you are most likely out of luck, I am afraid. The logic was not to pass slide values if no valid one was found. So it was entirely up to macOS which slide would be chosen in this case. I modified it to fallback to the slide with the largest memory chunk available in the latest commit. You may try, but from your report I guess it won't help unfortunately. https://github.com/vit9696/AptioFixPkg/commit/76ae0a9380e25cc7fedbfc8cd2d9cd9bf5e86665
  9. AptioMemoryFix

    Hi, you may try slide=0, I guess. I cannot promise but 288 MB may be enough for macOS to boot. If it works, perhaps, I should change the code to pick a slide for the largest chunk of memory after it fails to find any (definitely) working one after all.
  10. Lilu — kext and process patcher

    Fixed it, thanks.
  11. Which OS do you have? Check the stuff above, you may need to reset DRM config if you are on 10.13.4.
  12. Well, it's simply an invalid value, which will fallback to the model-based scan and then the default port if it fails, that's all. It is kind of interesting that Sandies have 2 frames you cannot use anyhow without patching the kext, but it is probably not too special. The ids I listed are the only valid existing ids in 10.13 for Sandy.
  13. Unlike Ivy Bridge and newer there are no frame-ids in the table. The framebuffer identifier is read at an index returned by the getPlatformID function. I did give you the source code with a clear definition of the frame structure. It is capable of printing all the framebuffers from all the known kexts. With all due respect to cecekpawon, the stuff you printed is inadequate garbage. Why did you attempt to read it instead of trying to follow the code @_@? Here is the function responsible for framebuffer decision. I simplified some stuff.
  14. No, you should not inject them for desktops obviously. Looks like there was a bug before your commit =) I added some snb-platform-id and board-id additional matching details as well, by the way. Will update the template later. I think it was not fully published previously: https://applelife.ru/threads/zavod-intel-quick-sync-video.817923/page-132#post-720434
  15. Hm, these keys are now only added for laptops. Strange, I think I remembered them being injected for desktops as well. if I remember correctly, they are reasonably necessary to get the backlight working. As for crashes, this one does not look related to AppleGVA issues at all. It seems to be a separate back in font rendering code. To be honest, I would rather wait and see how it goes. At the moment things are not very stable, but judging from the crashlogs I think the original AppleGVA part is fixed at least.