Search the Community: Showing results for tags 'MLB'.
Found 3 results
Pattern of MLB (Main Logic Board) serial Alert: If you are seeking for some quick single click iMessage fix, this is not about that at all.. This research digs a much deeper, it's about an aspect of building computer, which is able to run properly OS X. This post is purely educational. Understanding of this subject also requires knowledge of some basics of ICT. This topic isn't for sure for Windows dumb user, who wants some sort of OS X single click installations. For single click solutions buy a genuine Mac. Since Apple has made several changes on services, hardware identification becomes more and more important. For proper activation is needed a valid stable device. Device serial numbers, various hardware id's etc are part of identification and authentication. Just for clarity. Abbreviation MLB is shortened form of phrase Main Logic Board, which is a hardware part (motherboard). Abbreviation MLB is used by custom comp builders community also as Serial ID of Main Logic Board, which is an identification code of single unique hardware part. In this post MLB can refer to both, serial id of main logic board or main logic board itself. So, pay attention to the context when your read this post. MLB as hardware part id (barcode), is used by various services on OS X based comp, especially on Yosemite. So, you don't need only a good serial number in your SMBIOS settings, but also a good MLB, which matches logically (not by letter) your serial number. It's obvious at this point, that proper serial number isn't enough anymore. You need a good combination of serial number, MLB, etc. Those values should remain persistent. If someone told you, that MLB and serial number aren't related, you couldn't relay on this information, as MLB and serial number are logically related with each another. Probably I don't have to remind you - system serial number reveals your system model. Probably you haven't heard that MLB reveals exact model of your system Main Logic Board (hardware part) too. The Genesis of Apple computer ID's You can think about Serial Number as an "external id" and MLB as an "internal id". Computers are built from inside out. For first main board, then other parts and finally gets boxed. Serial Number reveals entire product box (comp, device) sold to the customer, MLB reveals the main hardware part inside of this product. Serial Number and MLB are like two puzzle pieces from same unique puzzle. MLB tells even more about your hardware than a serial number. Mac device gets first the MLB id and later the Serial Number. So MLB is the primary identification for Mac hardware before it's assembled completely for selling!!!! Also Apple repair services have who forgot sometimes to burn Serial Number back to the new replacement logic board. Logic boards come from factory without Serial Number. Below is the genesis of genuine Mac comp ID's. Main Logic Board ID -> Serial Number So, your MLB ID is born before the Serial Number! Based on that I recommend to start from generating system and hardware id's in this order: MLB Serial ROM/MAC address System Serial If you have chosen too complicated option for your system serial, you might have a trouble when generating properly matching MLB. Before you read forward, keep in mind, I'm not a hardware engineer, so I'm not familiar with all specifics related to computer hardware. Pay attention - 2 different patterns! General pattern for system serials (barcode) is the same: Manufacturing location | Year | Week | Production number of given week | Model ID Apple uses 2 different main patterns for serials (product serial, hardware part serial etc) now. Before Apple used 11 char serials for product and 13 char for MLB. Later Apple started to use a new standard to fit needs of increased production. Product serial length is 12 chars (Barcode Code 128) and MLB 17chars. Old serials have a bit common pattern for both, products and hardware parts and new ones have also a common pattern. Below is the difference of 11 and 12 char system serials: 11 chrs serial: PPYWWSSSCCC 12 chrs serial: PPPYWSSSCCCC MLB's pattern/length was also upgraded when system serials become updated. Thats why there are 13 and 17 char MLB's available. For new pattern Apple has modified the "Y" component to include a letter code instead of a number, and the new system will reflect in that code not only the year of manufacture, but also whether it was manufactured in the first or second half of the year. The new week format utilizes one of 27 alphanumeric characters to denote the week of manufacture, beginning with 1-9 and moving on to letters, omitting 0, vowels A, E, I, O, and U, as well as B, S, and Z. Because the 27 possible characters can not account for all of the weeks in the year, the "W" component must be paired with the "Y" component to determine whether the machine was manufactured in the first or second half of the year, with the "W" codes recycling every six months. System serials and hardware ids are serving various logistical purposes (barcode). They should be easy to use by barcode reader and should be easy to decipher with simple regular expressions (regex). Its wise to use common general pattern everywhere. So, it's obvious that some pattern might occur for both, system serials and hardware part ids. About 13 char MLB Perhaps someone can complement my research about 13 char MLB. As you see below, there is a certain pattern hidden in MLB. I have found this pattern first after examination of approx. 50 MLB's and is conformed by additional research later. Based on this pattern MLB is easily reversible. Name your MLB and I'm able to tell to you to which Mac model it belongs, where and when made, and so on. It's not a random string. PPYWWSSSSCCCC ID - Manufacturing location? (Defined in Apple database,) Year of manufacturing: 2011 Week on manufacturing (01-52) Production number, within this week (base-36???) ID - Model of hardware part (Defined in Apple database) Please note, it's easy interpret wrongly this pattern, as it has similarities with 11char serial.. Some are guessing that they can use serial number parts for MLB. It's not true. Manufacturing location and model id's aren't shared between serial number and MLB. Definitions in serial number aren't valid for MLB. Do not try to use serial number location or model ids for MLB, those aren't valid. MLB uses its own definitions. If you have any additional or more adequate information about this pattern, please let me know! * * * About 17char MLB's 17 char MLB is a bit harder to decipher. I have found this pattern after examination of approx. 10 MLB's. I suspect that Apple is using a new system for year and week identification for 17 char MLB. I guess that YW pattern occurs in 17char MLBs, but location is shifted and there is only one char used for week. PPPYWXXXXXXCCCCCC I don't have enough data to decipher the 17char MLB pattern yet. You are welcome to help. * * * Apple collects data about you and your hardware Don't fool yourself! You need proper and matching hardware id's for your custom built comp. If you are trying to use any of Apple's online services, Apple collects some data about you and your hardware. You couldn't make a fake Apple ID as it goes trough credit card validation. So, banks are doing identifying of persons for Apple. Using someones credit card and personal data without a proper legal authorisation is criminal activity on most western countries. For second, Apple collects data about you hardware. For example all your devices a listed on iCloud or on another appropriate support pages. Below is screenshot of iCloud Settings page, where all devices, from which you have accessed the service. On certain cases Apple checks for System Serial, on some cases for ROM/MLB pair etc. Your hardware should match on MLB and Serial Number to avoid any too obvious suspicious behaviour. How to slice a MLB? 13 char MLB should be sliced as shown below. XX X XX XXXX XXXX The last part of 13 char MLB can be sliced additionally this way, where XXX is EEE code. XXX X . 17char (still a rough guess) XXX X X XXXXXX XXXXXX The last part of 17 char MLB can be sliced additionally this way, where XXXX is EEE code. XXXX XX You are welcome to support this research. Thank You! * * * How to setup MLB For first, pay attention: getting a good combination of serial, MLB and ROM etc is an exact science. Do not try to guess or randomly generate those values. Invalid values will cause a head-heck and if you are trying to use some Apple services, you get banned for those services soon or later, especially iMessage and FaceTime. Your system serial and MLB are sent to Apple! MLB and system serial should match logically. Do not contact Apple's support in any case, even if you have this kind alert. You are not eligible for Apple support with custom built computer. Please note also, you couldn't just convert Serial Number into MLB. You can bake a MLB, but you couldn't convert Serial Number directly into MLB. Do not try. Similarity is confusing, MLB and serial number are sharing only overall barcode pattern. Serial number is good point from where to start, thats obvious, as MLB and serial should have logical match, but not match by letter. You couldn't use MacPro logic board on MacBook, it's obvious and super easy to check by Apple. So, pieces of puzzle should fit with each another. I guess it's smart to use similar production time with system, just set MLB production time up to 6 months earlier of system production time. Production number is easy to calculate. Trickiest parts are the beginning and the end as there is no easily accessible public info avilable about these parts for MLB. The best option to inject proper values into your system, is to use Clover boot-loader, which injects all those values properly. An option to setup MLB is to open your Clover configuration file with text editor and add/edit appropriate values. Second option is to use some GUI for editing Clover configuration file. Read Clover Wiki for more details. Below is an screenshot how to setup MLB with Clover Configurator. Serial Number should be a good one to imitate Apple's hardware and also should be appropriate to your system. MLB should be either 13 chars or 17 chars and match the appropriate pattern. Also hardware model info in MLB should be logically adequate to your system defined in Serial Number. ROM part is defined in SmUUID and should be 12 chars and match the Apple's MAC address standard, otherwise illegal. Do not use any random UUID generator for this purpose, for example uuidgen on Mac OS X. Validate your ROM part of SMUUID before usage with Apple ROM validator. If motherboard manufacturer supports flashing comp MAC addresses, you can also try to rewrite original MAC addresses with valid Apple type MAC addresses. On this scenario value is taken directly from hardware. Flashing of MAC address is also the most bullet proof option to keep ROM value unchanged. Read about flashing on this post: Flashing Mac Address. Important note. For Clover use for all values UPPER CASE letters. I got a huge head heck with iMessage/FaceTime by using lowercase values. Note, If your serial is 11 chars, it's recommended to use 13 chars MLB. If you are using 12 chars Serial Number, you should use 17char MLB. It's not the 100% rule, but somewhere between 2007-2010 Apple started to use a new pattern for identification numbers (product serial, hardware serials etc). iCloud / iMessage / FaceTime errors Apple provides 44 different online services for his customers. Most of these require some sort of identification/authentication. Before signing into any Apple's services from custom built comp, think twice. And after that, think twice again! Are you Apple's customer at all? Do you have any genuine Apple device, which grants access to Apple's services? If yes, it's a bit up to you from where you access these services, from your custom built mac or from iDevice or from iCloud webpage etc. Whatever you do, do not attack Apple or anyone else! NB! Most of iMessage Fixing guides available on Internet are invalid today. Be very careful! If you got error shown below on your custom made comp, I do not recommend contact Apple support. This error isn't authentication related at all! It's related to hardware identification, usually related to an invalid ROM/MLB combination. Error shown above on custom made comp indicates usually that all of these ids or some of these are invalid: System Serial Number, Main Logic Board Serial (MLB), ROM. Apple is trying to protect users from spying/fraud etc. This error means that Apple suspects some sort of dangerous activity. So, they want to protect their customers privacy, etc. To check that your Apple ID is fine: login into your comp as Guest and try to log in into iMessages. If you see something like below, it's 100% hardware identification issue.Your Apple ID is fine, but Apple doesn't like your hardware. Any custom comp builder, who is trying to access Apples services with invalid serial, MLB or ROM, gonna have some sort of trouble. Most of services require a valid system serial. System serial should match appropriate pattern. The same applies to MLB, which should match the MLB pattern. Some services require both, the proper MLB and ROM. If you have a good serial and proper MLB, you still might have trouble, if your ROM is invalid and doesn't match MAC address standards. Also you need properly configured network card. All those values should be persistent. Do not use any randomly generated values if you want access Apple's services. Same values should be injected on each reboot / wake. Some users have tried to use genuine MLB/ROM values extracted from some another Mac. If you reuse these values, yo mightu put yourself into huge risk, which might end by terminating your Apples account. So be careful, do not steal those from someone. A lot of users have followed misleading instructions by using random values. It's exact science how to generate those values. Several standards are involved into Serial Number, MLB and ROM generation. If you miss something, you have an invalid value, which is unable to bypass Apples validation. You need a good combination of MLB/ROM/serial, which doesn't violate related standards! Do your science, don't relay on guesswork. Building a custom built comp, which runs an OS X, is a branch of computer science, not a some kind dumb-users Windows installation. Serial validation: genuine mac and self generated serial Conclusion and alert When you are building you own custom hardware based OS X comp, you have to generate a VALID COMBINATION of serial number, MLB, ROM etc. Hardware combination (system model and hardware part) should match in serial number and MLB. The best boot loader to get job done properly, to inject those values into OS X memory, is Clover. Forgot xBeast / Chimera installers. Do not use Chimera. Once again do not Chimera. TonyMac will sued soon by Apple too. Do not try to sign into any Apple's services before you have made a rock solid combination of serial number and hardware id's. MLB, ROM and Serial etc for your custom made comp should be globally unique values and match appropriate Apple's pattern. MLB and Serial should have logical match. Make sure that your system serial does not belong to anyone else! Those values should be used only in one single computer, nowhere else. Do not share your comp serial numbers, hardware ID's etc with anyone who you don't trust 100%. Do not post it any public forum, blog etc. Don't share it with your friends, colleagues etc. Some old news too Thx! I thank everybody who have helped me and still helping me on this research. Thank you for your contribution. Related tools Apple MAC Hack
buttcrap posted a topic in OSx86 10.10 (Yosemite)So I'm running Yosemite on an HP Sandy Bridge laptop with MacBook 8,2 system definition, and I just picked up the same year(2011) Sandy Bridge MacBook Pro 8,2 that is ridiculously close to the end of it's life. I don't plan on using iMessage or FaceTime if I even use the MBP at all (it's screen is cracked, missing keys, aluminum falling apart, it's had a rough life). So I've taken the SMBIOS variables using iMessage_debug V2, but I'm not sure on what the best way to apply these is and I've seen a lot of conflicting information in the many forums I've checked out. I've seen people imply that MLB and ROM are the only really important variables here, and that if you're taking these values from a real mac that these ones are the only ones you should take while separately generating a serial number, smUUID etc from Clover Configurator or uuidgen. I've also seen people recommend to simply make sure the output of iMessage_debug exactly replicates your hack and real Mac (in the case where the system definition matches the Mac that you're getting the variables from). I've seen people say that you shouldn't take any variables, ever, at all, even from a retired Mac that you already own. A good chunk of the material I've found on this subject is over 5 years old, which is why I think I'm finding a lot of conflicting information. In addition to that most guides etc are written from the standpoint of someone that does not have another mac to take the variables from, and if they do mention scenarios like this it's so briefly touched that I'm still left unsure. Does anyone more experienced have any personal recommendations for someone specifically in my case, where I own a Mac that matches the system definition I'm using for my hack?
Florian U. posted a topic in OSx86 10.11 (El Capitan)Dear Mac users, I'd like to talk about iMessage, El Capitan and Yosemite. I've been using Mac OS X on a Maximus V Gene motherboard with an i7-3770K processor for quite some time now. With the introduction of Yosemite I needed to figure out a way to make iMessage work as it included changes around the same time with validation of MLB and ROM values that were reported by the system and the NVRAM. Here's my basic setup: Chameleon boot loader (previously regular flavor, now ENOCH), drop the Chameleon.plist, insert SMBIOS.plist, FakeSMC, IntelE1000-Ethernet.kext and my systems is working. To enable iMessage I had to install the FileNVRAM.kext (1.1.4 package) and FileNVRAM.dylib (1.1.4 package) file onto the USB stick containing the chameleon boot loader. With this setup, I was able to boot Yosemite fine and get a working NVRAM. However, keep in mind that you have to create the /Extra folder on the hard drive of your OS X install and make it writable by anyone. Then the FileNVRAM.kext is able to create the nvram.1d34-12d4d1234-1d341234.plist ( ) which contains the data you have written. Whenever I needed to boot the system with -v -f or when doing software updates, I had to use a second Chameleon stick that did not include the FileNVRAM.kext and dylib files. (If booting with -v -f and FileNVRAM installed, the system would crash on caching the kexts) I would then boot the system, run kext utility or similar permissions-checking and kext-caching applications and reboot with the FileNVRAM-USB stick. This was my full working arrangement. Tedious, but worked excellent. Never had a problem with iMessage, FaceTime, iPhone Calls, AppStore, iTunes or iCloud. So far so good, but it was time to move to El Capitan. In El Capitan I encountered the problem that kexts cannot be passed through the Chameleon boot loader but have to be installed directly into /S/L/E and have to be cached by a running system (usually just boot the same SSD from a real Mac). This forced me into a predicament with the FileNVRAM.kext which had to be loaded through Chameleon as it wouldn't otherwise boot. So by trial and error I examined a problem with the FileNVRAM.kext on 10.11.3 which resulted in it not being loaded, no matter where you put it. Reason why? The Info.plist of the FileNVRAM.kext has the following code written in it: <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOStorageFamily</key> <string>1.0b1</string> <key>com.apple.kpi.bsd</key> <string>8.0b1</string> <key>com.apple.kpi.iokit</key> <string>7.0</string> <key>com.apple.kpi.libkern</key> <string>8.0d0</string> <key>com.apple.kpi.mach</key> <string>8.0d0</string> <key>com.apple.kpi.unsupported</key> <string>8.0b1</string> </dict> Not sure if you spotted the error yourself, but the IOStorageFamily version is too low for El Capitan. This OS X ships with 2.1 instead and the kext simply refuses to load. If you change this value in the Info.plist file, the kext is loadable. This is more of a dirty patch than a correct solution. So what happens next: I got my El Capitan working again with the same approach as above, but no FileNVRAM module or kext anywhere, neither Chameleon, nor OS X. When the system is booted up I would install the FileNVRAM.kext into /S/L/E, onto the /E/E on the Chameleon stick and in the /E/E folder on the hard drive. Same with the module, /E/E on both hard drive and chameleon stick. Now I would have to run kext utility again to precache the FileNVRAM.kext into the system and reboot. Sometimes it wouldn't boot up, sometimes it would "break" the system (fixable by dropping FileNVRAM from all instances and touching /S/L/E and running kextcache -u / from single-user mode or external system) - but most of the times it just works. NVRAM is capable of saving and creating the /Extra/nvram.xxxxxx.plist file and returning the required MLB/ROM values after being saved - even after reboot. Thus I have managed to get FileNVRAM.kext working by this trick in El Capitan. Despite this solution working for me and probably others, my hope is that there is someone capable of updating the FileNVRAM.kext file for El Capitan and its latest Xcode? The kext itself is still working, but the dependencies are off and thus causing the issues. Thank you and have fun! Florian P.S. Edit: Here's the files I used. (dylib and kext) http://uploaded.net/file/uc9c18wc(zip-file of the Extra folder)