iWin32

Chances are if you’re reading this forum, you are a fan of Apple to some extent. Apple has developed a tech ecosystem that makes anyone with an iPhone or MacBook think twice before switching to Android or a Windows laptop. The key to much of this synergy is software-hardware integration. But other times, it’s simply the tight integration with their services in their own ecosystem that makes using Apple products so appealing. One such service is iMessage. iMessage is how iPhone users text each other, with iMessage supporting images, video, documents, read receipts, and end-to-end encryption out of the box for a rich messaging experience. However, iMessage is exclusive to iOS, iPadOS, macOS, and other Apple operating systems. This means that if users want to message someone who is not an iPhone user (aka Android users), they are forced to use SMS, an outdated and insecure text messaging protocol that doesn’t have any of iMessage’s selling points, including end-to-end encryption. For years, Google as the developer of the Android operating system has pushed for Apple to support RCS, an updated and open messaging standard that allows much of iMessage’s old selling points. This was dubbed the “blue bubble vs. green bubble” debate, as messages sent with SMS in Apple’s Messages app are green while iMessage messages are blue. It was recently announced that Apple would support RCS in a future update to iOS, albeit without end-to-end encryption. For years, there was no way of getting iMessage support on Android. Apple does not offer an iMessage for Android app. And there was no way to get iMessage support on non-Apple devices, including Android, without relying on some Apple device (like a Mac) that you owned yourself or had cloud access to… until recently. Beeper Mini was a new Android app that allowed you to use iMessage on Android, even using your Android phone number. And this was without questionable methods such as logging into a Mac Mini in the cloud. It relied on PyPush, an open-source reimplementation of an iMessage client. This meant that end-to-end encryption was handled on the device, and communicated directly with Apple’s own iMessage servers, all without needing a man-in-the-middle of some sort as before. This truly was a reverse-engineered implementation of iMessage on an Android device. Unfortunately, before you go to the Play Store and start searching for this app to download, I have some bad news. Apple has stepped in and “closed the loophole” that PyPush and Beeper Mini relied on, once again locking iMessage to those with Apple devices. Apple has said that they’re doing this out of concern for the security and privacy of iMessage users, which many tech people have rightfully called out as being BS. Anyway, the developers for PyPush previously discovered a method to continue using iMessage with an Apple ID instead of your Android phone number, but Apple has now shut that down as well. This seems to be the beginning of a cat-and-mouse game, one that Apple would be wise to quit while they’re ahead. If you’ve researched the early days of the Hackintosh scene, you’ll know that Apple also tried a cat-and-mouse game trying to stop people from booting Mac OS X Tiger on their non-Apple computers. One can argue copyright infringement, breaking the EULA, or violating the DMCA’s anti-circumvention provisions as legal reasons why Hackintoshing is illegal. Putting that aside for a second, back when Hackintoshes were primarily using leaked versions of the Intel Developer Transition Kit software, bypassing Apple’s security to get the OS to boot was relatively easy. But when it came time to use updated versions of the OS after the first real Intel Macs sold, there were new obstacles to overcome. The TPM that was used in the DTK wasn’t used at all, and instead, Apple used a different DRM scheme that relied on encrypted binaries and libraries that relied on keys stored in the SMC, a proprietary power management chip that was exclusive to Apple hardware. Apple also used EFI firmware instead of the legacy BIOS that PCs and the DTK used, and the kernel was updated to rely more heavily on the EFI boot process to start. These new challenges meant that for a brief period in 2006, Hackintosh users were stuck on old DTK OS builds. Then, on Valentine’s Day in 2006, a kernel patch was released for Hackintosh users to boot Mac OS X Tiger version 10.4.4 by crg92. Apple struck the first blow in the Hackintosh cat-and-mouse within hours, pushing the 10.4.5 update that broke this patch. Two weeks later, the same hacker developed a patch for that version of Tiger. Then, in early April, Apple pushed the 10.4.6 update, and yet again, hackers developed patches to get the OS to boot on non-Apple PCs. This continued until 10.4.8, which posed all sorts of new challenges in getting the OS to work properly, never mind boot. But hackers developed patches for every version of Tiger. Leopard was a whole new beast, but hackers got patches out there. Then, of course, 2008 introduced the Boot 132 swap CD method to get the vanilla OS to boot and install without relying on a single patch. This made the Mac OS X experience for Hackintosh users a lot more like a Mac, being able to update straight from Apple without issue. Eventually, Apple stopped the cat-and-mouse game for Hackintosh users and started allowing Hackintosh users to continue using the OS, even as technology evolved and newer boot loaders like Clover and OpenCore became commonplace and made the experience closer to what you could expect on official Apple hardware. And what has Apple done about it? Not a whole lot. Apart from refusing to provide support for Hackintosh users, they haven’t done anything to stop people from running macOS on their non-Apple computers, even though that would be well within their rights to do. And it’s not for lack of time. They had ample opportunity to shut it down, but they didn’t. The only time Apple took legal action against Hackintoshes was when a company called Psystar was selling their own computers that ran Mac OS X Leopard. And they won in court. What distinguishes Psystar and Hackintoshes (as well as this Beeper Mini effort) is that no one was profiting from installing Mac OS X on non-Apple hardware. Psystar did, and since losing the lawsuit, they are defunct. And this brings us to an important question. In a YouTube video from The Computer Clan about a similar commercial Hackintosh entity in June 2020, he mentioned what is probably the most-asked question related to Apple’s stance on Hackintoshes: Why doesn’t Apple simply license the ability to install macOS on non-Apple hardware? Ken went on to explain the history of the Macintosh Clone program from the mid-1990s and how Steve Jobs himself shut it down shortly after rejoining the company. Steve explained this as purely financial reasons, as OEMs in the Mac Clone program weren’t willing to pay the higher price Steve Jobs cited as providing a “fair percentage of the cost”. Ken explains that Apple learned from history and decided it wasn’t financially worth the risk. Probably the second most-asked question that’s asked about Apple’s policy on Hackintoshes is, “If running macOS on non-Apple hardware is a violation of Apple’s End-User License Agreement, why hasn’t Apple gone after Hackintosh users, either by pushing out an update that breaks Hackintoshes altogether or by taking legal action against them?” Like the first question, there’s a huge rabbit hole of reasons to go down. The best answer I can come up with is it makes no sense business-wise to do so. Unless you’re making money by selling Hackintoshes or offering commercial Hackintosh services (think Psystar), chances are you’re a tech hobbyist who at the end of the day, is either a current or future Apple customer. I can attest to this. My first experience running Mac OS X was through Hackintoshing, and I eventually bought several Macs and iPhones. Going after individual Hackintosh users would only hurt their own customers. Furthermore, Apple has gone from a malevolent view of Hackintoshes to a more ambivalent view. There were several times over the years before the transition to Apple Silicon that Apple could technically make it extremely hard to boot macOS on non-Apple hardware. For example, when kernel extension (driver) signing was implemented as a way to protect user’s security by not allowing malicious kexts to run, Apple could have used this as an opportunity to stop Hackintosh-only kexts (like FakeSMC) from loading. Instead, it included those kexts on their own exclude list, essentially whitelisting them from these new requirements. And now that the only Intel Macs compatible with the latest versions of macOS have a T2 chip, Apple could have updated their DRM scheme to require the presence of a T2 chip to boot. But they haven’t. Even the Apple Silicon transition (which will one day kill Hackintoshes with Intel Macs) wasn’t done to stop PCs from running macOS. It was done because, much like the PowerPC systems before it, Apple couldn’t create the kinds of Mac computers they wanted with the current trajectory of Intel. When the tech hobbyists who are finding ways to run macOS on non-Apple hardware aren’t otherwise a direct threat to Apple, it makes more sense for them to just let it be. One could argue that Beeper is somehow different than Hackintoshing given the fact they were charging for access to their services. However, you have to remember that unlike Hackintoshing, which uses the entire proprietary OS belonging to Apple in a way that violates its EULA, Beeper Mini isn’t using a lick of Apple’s code, open source or otherwise. It’s more closer to how WINE implements the Win32 APIs on Unix-like operating systems. Someone reverse-engineered how iMessage works and developed an open-source alternative iMessage client that’s not reliant on Apple’s proprietary operating system. And if WINE has a commercial offshoot in CodeWeavers’s CrossOver software without being illegal or unethical, then offering a commercial reimplementation of iMessage isn’t illegal or unethical either. Apple’s cat-and-mouse game against Beeper is only being done to prevent consumer choice. This makes it closer to how DRM developers operate than any sort of innovation or security argument that Apple is saying. And on DRM being a cat-and-mouse game, a wise man once said, “The problem, of course, is that there are many smart people in the world, some with a lot of time on their hands, who love to discover such secrets and publish a way for everyone to get free (and stolen) music. They are often successful in doing just that, so any company trying to protect content using a DRM must frequently update it with new and harder to discover secrets.” Who was that man? Mike Masnick? Cory Doctorow? An EFF staffer? Nope, though I wouldn’t blame you for thinking that. That’s a quote from Steve Jobs himself, in his famous “Thoughts on Music” open letter to the RIAA. In it, Steve Jobs argued for a future where any digital music store can offer DRM-free music for sale, allowing interoperability between devices and ecosystems. And to the record labels’ credit, they listened, and we now live in that future. But Apple’s pro-innovation stance here doesn’t hold up when it comes to Beeper. One of the most ironic things about this whole story is that the great Apple co-founder, the late Steve Jobs, would probably be against to some extent what Apple is doing to Beeper Mini. Sure, Steve Jobs called Android a “stolen product” that he was “willing to go thermonuclear on” to shut it down. But that was likely referring to the suspicion that someone on Apple’s board was also working at Google while the Android OS was in its infancy. Corporate espionage aside, you also have to remember that Steve Jobs and Steve Wozniak got their start in business not at Apple, but by selling “blue boxes” designed to hack the phone network (also known as “Phone Phreaking”). While this was no doubt illegal, Apple later formed from these two as a much more legitimate endeavor. Now, Apple is using its corporate dominance to veto innovation it doesn’t like that is a lot more legal than Phone Phreaking. This isn’t just morally unjustifiable, but it’s a sign of monopolistic behavior. Apple doesn’t want to create iMessage for Android, saying that if people really want to use it, they should buy an iPhone. This is part of their strategy to sell phones. Beeper Mini comes along and does what Apple won’t, and they immediately try to shut it down. This isn’t for security reasons as Apple says. If it were, they wouldn’t be forcing iPhone-to-Android texting users to use an unencrypted protocol like SMS. And even when Apple does implement RCS, it will be without end-to-end encryption even though the standard supports it. Apple is doing this merely to keep their profits because they know that if Android people can use iMessage, that will be one less reason for people to buy an iPhone. That may be a compelling reason to shut down Beeper Mini from a corporate business perspective, but not for consumers. Besides, it’s not like Beeper Mini’s implementation is for the faint of heart. Their latest workaround requires access to a Mac to work. People who want to go out of their way technologically to make iMessage work on Android aren’t a threat to Apple’s iPhone business. If people want a seamless experience with iMessage, the recommendation is still to buy an iPhone, just like the recommendation to people who want to use macOS seamlessly isn’t to Hackintosh their current computer but to go out and buy a Mac. If Apple truly wants to learn from history, as The Computer Clan puts it, they will follow the example of the Hackintosh and leave Beeper Mini alone.

Interesting to note that despite the only supported Macs for Sonoma come with the T2 chip, the lack of a T2 chip hasn't stopped the OS from installing and booting. I guess Hackintoshers can breathe a sigh of relief that Hackintoshing lives to fight another day. (But the day of reckoning is coming once Intel Mac support is dropped.)

Hello everyone, I'm hoping there's someone still lurking this forum way back from the Developer Transition Kit days (the Intel one, not the Apple Silicon one, if it wasn't already clear from my title), as I've just had a strange idea at 1:00 in the morning. But to understand what I'm asking, it's going to take a bit of explaining. So, way back in 2005, when Apple announced they were transitioning the Mac to run on Intel chips, they released a developer transition kit. The Intel DTK had a weaker and substantially different DRM mechanism that any retail Intel mac does. Rather than using proprietary power management controllers and encrypted binaries to lock things down, Apple's DTK used a TPM and a secret key to lock down Rosetta, and only supplying PPC code for crucial processes to get to the GUI/Desktop. Apparently, according to the OSx86 Project's wiki's old article on the TPM, the key that Apple used (which I won't repeat here) is exactly the same as what the SMC has for DSMOS to function. That key is well-known and even appeared in Apple's case against Psystar. But I digress... The newest version of VirtualBox supports emulating TPMs in Virtual Machines. This is likely to officially support Windows 11 in VMs, which relies on a newer TPM 2.0 specification. That post-dates the DTK AFAIK, and is probably too technologically different from what the DTK OS would expect. However, you can actually specify 2 different versions of the TPM you want in VirtualBox: 1.2 or 2.0. According to the docs, you can also specify to use your host TPM, use an externally-emulated TPM, or not use a TPM at all. According to the TPM article, the DTK used TPM 1.1, which while one revision lower than 1.2, should be much closer to 1.2 than 2.0. And even if 1.2 is still too new, we could always find a software solution to emulate a 1.1 TPM and supply that to VirtualBox. I also have Vanilla versions of various DTK builds of Mac OS X Tiger. Unfortunately, most of the patches that early Hackintoshers developed are now lost to time. Right now, these early pre-release versions of Mac OS X Tiger have no way of being run outside of tracking down a DTK that wasn't returned to Apple. But recently, I started thinking: What if we could emulate the TPM in a VirtualBox, supply it the not-so-secret-key from Apple, and attempt to boot the DTK installer inside the VM? Here is how I envision the workflow: Install VirtualBox and create a new virtual machine that emulates TPM 1.2. Inside the VM, boot to Linux or some other Live CD environment. Add the necessary keys to the VM's emulated TPM. Reboot and boot up the DTK's Tiger install DVD.* Install the OS.* Profit! *=May have to use some form of old OpenDarwin kexts in case of incompatibility with the virtualized hardware inside VirtualBox. This may also require following part of old guides using Ditto to copy Tiger over an existing OpenDarwin installation. Obviously, it may be more involved than that, and it may not even work. But I'd be willing to give it a try. There's just one small problem: I don't know how the TPM stored Apple's secret key. Is it just like the SMC with the keys being stored in two halves: OSK0 and OSK1? Or is it something different? And what kind of key was used to add it to the TPM? In case anyone wonders why I might want to use an ancient version of an ancient OS by 2022 standards: It could prove helpful in terms of my still-planned YouTube video documenting the history (technologically and legally) of hackintoshing. It could prove useful in terms of software preservation. I just think it would be cool to do, mm-kay? If anyone is still familiar with the old OSx86 patches that are now lost media and/or had an Intel DTK back in the day and remember how it worked, anything you can provide that may prove helpful would be appreciated. Thanks!

Did someone ever send the file to you? I'm looking for it, too!

Looks like someone else had a similar idea and ran with it. It uses FreeBSD as opposed to Darwin, but that works better from a hardware support perspective, and with what I know about Hackintoshing, I can fully appreciate that! If anyone wants to contribute to the project, I suggest you check it out: https://airyx.org/ It's probably better that someone with significantly more coding experience take on such a project anyway. I hope airyxOS takes off, and I wish the developers all the best!

Random thought I just had: Could we create a Hackintosh-like boot loader that would allow Windows 11 to be installed and run with full functionality (i.e., with access to Windows Update) on unsupported but otherwise compatible hardware? I mean, even in the days of Leopard and Snow Leopard, the Hackintosh community had ways to enable vanilla installs of Mac OS X on PCs and have it run with full functionality, software update, etc., just like you were using a real Mac. Of course, our methods then were crude with a lot of hacks compared to today's boot loaders, but we still got SMC emulation, bypassed EFI requirements, etc. How hard would it be to create a boot loader, drivers, etc. that emulates things like a TPM, mask CPUID for earlier generation processors, and maybe even emulate UEFI with secure boot on legacy PCs? In my mind, if we can program boot loaders to get around Apple's protections to make macOS only run on Apple hardware, getting around Microsoft's checks to make it think it's running on supported hardware should be a piece of cake. Sure, we'll likely get into a cat-and-mouse game with Microsoft releasing updates that break support, but Apple's been doing that already, even as early as Tiger. And then there's the boring ways of either doing a clean install or getting around Windows 11 requirements with Microsoft's own tools, but that sounds boring and would not allow Windows Update to run, leaving your PC in a vulnerable state. Of course, Microsoft would likely be unwilling to provide support to those using this boot loader, but then again, Apple doesn't provide support for Hackintoshes, so that might not bother some people. I could benefit from such a boot loader (depending on its features). My laptop doesn't meet processor requirements for Windows 11, but is otherwise perfectly compatible in every other way. And I'm sure there are others out there who would like to bypass other requirements, like secure boot and TPM support. The lack of Windows Update is what's stopping me from attempting to install Windows 11 on this laptop through other unofficial means, but this boot loader idea, should it come to fruition, would enable me to consider taking the plunge. Besides, I think this challenge could pose interesting, and given the chance Windows Update could be enabled, I think it's worth the effort. Thoughts?

Just wanted to pop on and say that I figured it out... I was able to boot into safe mode, and then I ran this command: sfc /scannow It found and repaired system files. I was able to reboot into Windows successfully and stayed logged in without crashing. I also was able to set up Boot Camp switching, so all is good again! Thanks!!

Hello, I decided recently to upgrade my Acer Predator 15 Hackintosh to macOS Mojave from High Sierra (still rely on 32-bit apps, fight me). I also took the opportunity to switch from Clover to OpenCore. That part was completely painless, believe it or not. Apart from the lack of handoff/continuity/etc. due to a USB Wi-Fi dongle, it's still a completely functional Hackintosh. The problem came when I re-installed Windows... I wanted to try the new OpenCore function that enables Boot Camp/Startup Disk features on non-Apple hardware. So, I started to install the Boot Camp drivers to enable that functionality. During the installation, Windows 10 crashed with kernel security error or something like that (don't remember what it exactly said, and I don't have a screenshot to provide, sadly). Ever since then, Windows 10 does nothing but crash when booting normally. I can get Windows to boot in safe mode, though. Unlike other OpenCore Windows issues, Windows 10 boots fine, and I can log in. The thing is even after 1 minute of idling, Windows 10 crashes after logging in. I thought it could be that OpenCore broke something, and so I thought maybe I should rely on Windows Boot Manager instead, and have it load OpenCore only when wanting to boot macOS. However, attempting to boot Windows directly (i.e., loading Windows without first booting OpenCore), STILL caused Windows to crash. So clearly something else is going on here. Every time since the failed Boot Camp install, the crash is IRQL_NOT_LESS_OR_EQUAL. Most Windows-related forum posts this is either due to failed hardware or a bad driver loading. The fact macOS still works fine and I'm typing this in safe mode with networking after being logged in for almost an hour indicate to me that this isn't a hardware issue. Thus, I'm thinking it's a driver issue. Windows 10 was fully working until I started to install the Boot Camp drivers. Therefore, what I think happened is the Boot Camp installer installed (and maybe loaded) some Boot Camp-related driver from Apple that's causing the issue. Considering the install never completed, Boot Camp doesn't show up in installed programs, and I can't uninstall it in any way. Of course, the issue could be something else completely. I'm attaching four minidumps here (with the earliest one being from the failed installation). Any help figuring out what's going on would be extremely helpful. Thank you in advance! Win10_minidumps.zip

First, mods, if you feel like that this thread belongs in a different board, feel free to move it. The Darwin board seems dead, and I don't have the right permissions to post in the Developers Corner board. There might be an even better fit, so feel free to move it to wherever this sort of thread fits. When Apple announced this year that they would be switching to their own ARM processors at the WWDC, I was a bit disappointed. Not surprised (the rumors of such a switch have been floating around since early 2018 if memory serves), but disappointed. I would have rather seen Apple announce that select Macs would run on their own processors (like MacBooks and Mac Minis) while keeping the more professional line of Macs (like the Mac Pro) on Intel. I'm even a bit skeptical that such a high-end Mac like the Mac Pro could appeal to that base of costumers with Apple Silicon powering the machine, as their workload is not exactly ideal for ARM processors. And I also was disappointed to learn they wouldn't be seeing a way of allowing Windows 10 for ARM to run on their Macs via Boot Camp. While the base that needs Windows on their Macs are small, I doubt people will be excited to go back to emulating the x86 architecture if they need to run Windows for anything. To me, Apple's main objective in switching to ARM is just to kill off Hackintoshes for good and nothing more. I foresee this move is going to hurt the Mac user base more than it helps. But I digress. I was (and still am) planning on creating a video that goes over the history of Hackintoshing from both a technological and legal perspective. I was planning this out well before the announcement. While researching the early days of Tiger Hackintoshing, I went down a rabbit hole surrounding OpenDarwin. I knew when Apple killed OpenDarwin, PureDarwin popped up to attempt to fill in the gap. But that was back in the days of Leopard, and I decided to see if there were any updates since that was technologically eons ago. While PureDarwin Xmas is still a thing, they do have a beta PureDarwin build based on the High Sierra build of Darwin. And that is when I had an epiphany. PureDarwin has a more up-to-date build of the Darwin base, while another project called Darling is aimed at creating a Wine-like compatibility layer for macOS applications on Linux. I've been following developments of Darling from a distance. Indeed, it appears that basic GUI support has been implemented for Darling recently. Both projects are free and open-source. So I began to wonder: Would it be possible to modify and combine code from PureDarwin and Darling to create a 100% free and open-source operating system that is binary compatible with a somewhat recent Intel build of macOS? And thus, my idea, tentatively named courtlandOS was born! Think about it in this way: Wine is to ReactOS as Darling is to courtlandOS. courtlandOS gets its name from another kind of apple called the Cortland (which is a hybrid of the McIntosh and Ben Davis apples). And just like Apple changed the spelling of Macintosh to include an A, thus distinguishing it from the actual McIntosh apple, I added a U to Cortland to distinguish between the Cortland apple and courtlandOS. I'm stylizing the name as courtlandOS to match Apple's OSes names like macOS, iOS, iPadOS, tvOS, etc. courtlandOS would be a lot less in a legal gray area than Hackintoshing, as you wouldn't be violating Apple's EULA by running this OS instead of the actual macOS. Hackintoshing would likely still have its appeal to those who want things like iMessage, FaceTime, iCloud, etc. integrated into their operating system, and Darling can appeal to those who are already running Linux on their systems. But if you just need an operating system that can run Mac-only software and drivers on your PC, this could be a great alternative. Plus, it could potentially keep Intel Mac software and drivers alive and still relevant well after Apple completes its transition to Apple Silicon. One of the biggest challenges actually is license compatibility issues. Darling is licensed under GPL, while many PureDarwin sources originally started under the APSL, which the Free Software Foundation says isn't GPL compatible. I believe PureDarwin itself has its own license, but I'm not sure how different it is from the APSL. Believe it or not, Darling developers are also dealing with this issue, but they seem to believe (which, if true, makes this a non-issue), that as long as there is no mixing of GPL-licensed source code with APSL-licensed source code, you can distribute the project together under multiple licenses without worrying about license compatibility, which is especially true with distributions of operating systems. Technologically, the biggest challenge is expanding ACPI and driver support, as PureDarwin's driver stack is incomplete ever since Apple started closing down more source code for its various macOS drivers. And, of course, implementing Darling code to run on top of PureDarwin could be a challenge, not to mention porting over some kind of Linux graphical shell to run on Darwin to enable GUI support. But I think these would be doable. As I stated elsewhere on this forum, I am not a developer by any stretch of the imagination. I also understand that it's not exactly ideal for a beginner developer to start working on an operating system right off the bat. It's a steep learning curve, but I'm willing to learn, and I'd be more than happy to test any code for anyone. But the reason I'm choosing to share this here is because I looked up the history of Wine and ReactOS and how they got started. They both started when someone had the idea and shared it in Usenet groups (yes, what a throwback to old-school Internet users), and I figured one of the best ways to get this project started would be to emulate this approach on a popular Hackintosh forum that's the home to many developers already. After all, the ideal developer would be someone who's already familiar with the inner workings of macOS and Hackintoshing in general, while also being skilled at low-level programming and development for both Mac and Linux platforms. And most operating systems have a team of developers as opposed to being worked on by one lone developer. I'd love to get a team together to work on this, and all projects have to start somewhere. So, with all that said, any tips on how to move forward would be appreciated! Also, if you're a developer interested in working on this project, feel free to reply to this thread as well. Let's get this thing started!!

ARM-based Mac emulation will eventually happen, no doubt. That being said, depending on your application, I doubt you'd get a full-fledged macOS experience once Apple ships an OS that's just supported on ARM-based Macs. If any app you wish to run requires any sort of graphic acceleration (i.e., Final Cut Pro X, Photoshop), I guarantee you that in the current state of things, you'd be SOL. Anything outside of running macOS natively on x86 hardware, you can't run ANY version of macOS with QE/CI support (unless you use some sort of KVM on Linux or ESXI that supports passing through an internal graphics card to the guest operating system). This was true even in the early PearPC days, and I have my doubt that anything would have been different running old Classic Mac OS emulators from before OS X. At most, you'd be able to get macOS to boot up and run basic applications and maybe even XCode, but anything requiring graphics acceleration would require a real Mac going forward, barring some sort of miracle...

Okay... Crazy update. I rebooted my computer into Windows and used HFS Explorer to attempt to extract a sample to examine it from Windows. And without fail, Windows Defender also recognized the file as malicious. I then removed the file from quarantine and uploaded the file to VirusTotal. Many other AV files also regarded it as a Trojan: https://www.virustotal.com/gui/file/52bc0da3f9c822afd463813264181b8174c9f5260154357ff064ca3646b4a564/detection Noticing how the previously uploaded sample had the .txt extension, I opted to open the file with Notepad. Indeed, it was a .BAT file. It appears to be a command prompt script that, among other things, switches the mouse buttons (i.e., left-click becomes right-click), edits the registry, and disables any kind of Anti-Virus and the built-in Windows Defender security in Windows. So it's far from a false positive. But what remains to be seen is WHY is it mixed with iCloud-related system files, why it keeps being added to my filesystem for the AV to detect it, and what purpose would it serve on the MAC operating system? I have a feeling I will never know...

This is starting to drive me crazy... About every 20 minutes or so, I get a notification on my Hackintosh saying that my Anti-Virus software (provided by my ISP, I believe it is based on F-Secure) found a harmful file and trashed it. The thing is... I'm 95% sure it is harmless, but I can't tell for sure because of weird permissions issues. The file name is always different, but the "extension" and path it was found in is always the same: /Users/(my_username)/Library/Caches/CloudKit/com.apple.bird/com.apple.CloudDocs/9fadf220be21a0ed291ebfea5f836e034473cd93/Assets/*.012332936e2fc5312218189715d7e9cae7f12c1a96 (Where * is always a seemingly random UUID, and it is a different UUID each time this "infection" is detected) According to the Anti-Virus software, it detected it as Malware.BAT/DisableMouse.B, but when I click on more info, it instead takes me to a page about a different Windows Trojan (It must be old, as the screenshots show it infecting a Windows XP machine): https://www.f-secure.com/v-descs/trojan_w32_killwin_ar.shtml Now, as I stated before, I think it's a false positive. But I can't even read the file to be able to do anything with it, let alone determine if it is really malicious. Whenever I try uploading the trashed file to VirusTotal, it shows a progress bar that simply stays at 0% forever. Furthermore, if I try to calculate a checksum so I can look it up on VirusTotal that way, I get a permission denied error. By default, it gives my user read-write permissions but denies any permission to anyone else. Even if I adjust the permissions in the terminal and run it as sudo, I still get a permissions denied error. The owner of the file is my user account, and the group it is associated with is Staff. Moving it out of trash makes no difference, and even then it'll only be a matter of time before my AV software finds it again and re-trashes it. Any idea what could be going on here? I've been running High Sierra on this system for almost a year now and this only started happening recently.

I did manage to get High Sierra installed and working on this laptop. The key was changing the config.plist. I don’t remember which one it was based on, but it had something to do with enabling the iGPU. When I get the chance, I’ll upload my working config.plist. Edit: I've attached my working config.plist. It's for the Clover bootloader. You'll need to add a few SMBIOS settings as I removed them in case the powers that be come across my config file and decide to blacklist me. I hope this helps! config.plist.zip

Sorry... My T key has been sticking lately for some reason!

Hello, everyone! Before I get started with this post, I figured I would introduce myself. I'm Rico, and I've been into Hackintoshing for a while. I started in the tail-end days of Leopard distros, and have since set up several Hackintoshes, including a custom AMD build and an Acer Predator gaming laptop. I'm not a developer or programmer in any sense of the word, but I am fairly knowledgeable when it comes to computers. I also am a musician and an aspiring filmmaker, and I currently run several YouTube channels, including Robdeltonie and RECORE Entertainment. Now, while being quarantined, I recently came up with an interesting YouTube video idea that I'm pretty sure hasn't really been done before. I figured I could look at the history of hackintoshing and the OSx86 scene, from the Apple-Intel transition announcement in 2005 through today, covering Mac OS X Tiger through macOS Catalina. It wouldn't really be a how-to video or a walkthrough of any sort, but rather just an informative look at how much the scene has changed in terms of technologically, practically, and legally. (I know that Hackintoshing is not really the most legal thing depending on your jurisdiction, but you have to admit it's evolved into a more gray area compared to running a heavily-modified leaked version of Tiger from the Developer's Transition Kit back in the day.) As I've stated above, I'm not a programmer, but I want it to be technologically accurate while still being accessible and easy-to-understand for the lay viewer. That being said, I have a few questions that I'm hoping can be answered, most of which goes back to the early days of the Hackintosh scene. First, am I correct in saying the TPM was not even used for DRM back in the days of the Developer Transition Kit? I know for sure that the TPM was not used on real Intel Macs from the start. Either way, I'm sure Apple used some kind of DRM to tie Mac OS X to the Developer Transition Kit, as there were patches and cracks floating around back in the day. Speaking of which, how exactly was the developer transition kit cracked so easily? I tried looking on the forums for more info, but almost every post that could help was either blanked or edited out because of DMCA violations that the mods wanted to avoid. If it's anything like how macOS is tied to Macs today, and I'm understanding it right, several key binaries for the operating system are encrypted with the AES algorithm. A kext called Don't Steal Mac OS X decrypts the binaries on-the-fly by retrieving the "secret haiku" stored in the firmware of the SMC, a proprietary power management controller only found on Apple hardware. If a similar DRM scheme was used on the DTK, you would think it wouldn't be cracked as fast as it would, as the binaries would have to be manually decrypted in order to function, and not just a hard-coded crack to prevent the checks from working. Also, when Leopard was released, I understand that there were new technological changes that made it harder to crack than Tiger. What were they? Was it just the use of EFI? If so, why did it take so long to attempt to create some kind of EFI simulation that was later developed by David Elliot? Also, what is the difference between AppleDecryptor.kext, DSMOS.kext (NOT the official Don't Steal Mac OS X.kext mentioned above), FakeSMC.kext, and VirtualSMC.kext? Finally, I read that Clover will soon be deprecated in terms of new macOS builds in favor of OpenCore (similar to how Chameleon was deprecated in favor of Clover). Is this technologically true? If so, why? I think this just about covers it. Once I have answers to these questions, I'll post a link to a proposed transcript in a Google Doc here, just to be 100% sure that I'm technologically accurate. Thank you all in advance!