Jump to content

meklort

Developers
  • Content count

    148
  • Joined

  • Last visited

  • Days Won

    4

meklort last won the day on August 14 2013

meklort had the most liked content!

About meklort

  • Rank
    InsanelyMac Geek

Profile Information

  • Gender
    Male
  1. Using vfs_context_current was done by design. If you use vfs_context_create, it'll use the current tasks permission. This becomes an issue when sandboxing is taken into account. Binaries like blued can no longer cause the nvram plist to be written, and things break. So, if you change it, yes, it'll usually work, but certain cases will break. EDIT: Some further clarification: Using context_create / rele in the *current* location (where mCtx is set) would probably be fine. Using the functions when you call read/write_buffer would not would due to the above issue.
  2. Please submit a bug report that shows a usermode app having the ability to things it shouldn't with FileNVRAM. Once you do, and I can reproduce the issue, then I can fix it. I'm still not sure how you can call an arbitrary function in kernel mode from usermode... or how you are bypasssing the root check that is explicitly in filenvram, but if you submit a bug report, I'll look into it and fix it properly.
  3. Pike, Apps *cannot* call arbitrary functions in a kext. There are a specific subset of functions that they can call. FileNVRAM validate that the user is root before allowing the write to continue. Read the code, this is *already* taken into account. Yes, It's well know that File IO is strongly discouraged. It's easy to mess up.
  4. Please explain this security issue to me. You've hard coded the kext to now use /Extra/NVRAM/nvram.plist. If someone previously wanted to modify a file, they could do so as root. Sure, they could tell FileNVRAM to point to a different file path, but they'd have to be root to do so (only root can write nvram variables). So... you're previous options were... be root... or be root. How is that any different from the new option of.... be root? My understanding is that root is now locked out from modifying certain system files, and so would this kext as it uses the root context. Perhaps a *good* fix would be something like the following: (1) Does the file pointed to exists? (2) If File does not exists, continue, file path is OK (3) If file does exist, verify that it's contents are an XML dictionary in the FileNVRMA format. (4) If contents OK, file path is ok (5) If contents are bad, yell at the user and don't use the path. Something like that yes, although I don't remember the proper usage of is_module_loaded (it might just be "FileNVRAM"). Also, if you are calling nay symbols in FileNVRAM directly, you must either (1) Be running as a module or (2) Look up the symbols at runtime using the module system apis. FileNVRAM is not a signed kext. So, to load it, you have to disable the CSR, or bypass it somehow. Additionally, the nvram file the FileNVRAM uses should use the additional security enhancements that Apple's added to lock out even root from touching it (and still have some way to touch it by itself).
  5. mCtx is referenced by FileIO.c This is compiled as a C file and cannot access C++ names without having them managed first. Additionally, mCtx is a member variable of the FileNVRAM class. You cannot access it without the class pointer. If read/write_buffer needs to access it, these functions need to instead be moved into the class as member functions so that they can access the variable. So... the short answer is... revert the changes to that file, and it'll work. Alternatively, move the functions into FileNVRAM.cpp (and set the names properly, and declare them properly in FileNVRAM.h) The simple explanations is... OS X blocks until NVRAM is available. The module makes it happen early for FileNVRAM. If you don't use the kext, apple's default one takes over and lets the boot happen quickly. The other explanations were more for people with a programming background. Yes, FileNVRAM could be use to assist the CSR changes for 10.11, but there are security implications that have to be taken into account properly. As mentioned before... I've never tried the kext or module with 10.11 (or 10.10), so I didn't know there was a problem. Additionally... I received a grand total of 0 bug reports. I also don't think anyone has sent me an email or a pm about it either. If nobody tells me there's an issue, I'll assume there isn't one. So... please file bug reports if you find them.
  6. Correct, I do mean injecting the properties via the bootloader. As for deleting the properties after use, see below: if (bootnvram) { copyEntryProperties(NULL, bootnvram); bootnvram->detachFromParent(root, gIODTPlane); } Please note that this deletes /choosen/nvram, but causes /options/nvram to be populated, just like the standard Apple NVRAM kext. Again, I haven't looked at the 10.11 kext, but this behaves the same way as prior OS releases. Ya, the ctx check is definitely good. As for the mCtx usage inside of it, my way and your way can both be misused. In the previous case, the root ctx was not used by default, and a kext had to provide the ctx on it's own. Granted, you could just grab the cached value from the kext... With your changes, another kext simply has to call the function and they'll automatically get the root context. Perhaps a safer option would be to make the symbol private / force inline of the function so that it can't be called by anyone else. (easily). Then again, the source is available, and it uses public APIs form Apple, so it's not like someone couldn't just re-use the code. Anyway, you're correct, you cannot target 10.4 with the latest xcode. I have a separate build machine specifically setup with Xcode 3.6 for building FileNVRAM for release.
  7. For those of you playing along at home, I'm going to do a slight information dump about FileVNRAM: FileNVRAM was developed in conjunction with the same chameleon module. Yes, you *can* use it without bootloader support, however, if you do so there is a race condition that occurs. This can result in early program / kernel code using un-set or incorrect nvram variables. Once the boot completes, the variables will be updated in the kext, however, at this point the incorrect variables may have been read out already. So... the kext itself (as-is) can be used with any bootloader (I often use it on my mac), however, there are cases where things can break with it if the bootloader also doesn't support it. The kext itself doesn't need any modifications to be supported by Clover, you just need to pass in the proper information in the device tree. Once that's done, the initial nvram values will be populated, in addition to the path to store the nvram file. Finally, please note that if you do *not* have bootloader support, the OS will take longer to startup. There are a couple of kexts that block the boot process by waiting for the NVRAM kext to register with the PlatformExpert. If bootloader support is not available, FileNVRAM will wait to register until after vfs / root have finished mounting. This means that the blocking kexts are now waiting longer (usually FileNVRAM on chameleon finishes initializing well before root is mounted) and as a result, the boot process will take longer. Pike: I noticed you changed the file io read/write functions. Yes, it's good to verify that the ctx is non-null (which should be added in my repo), however, you've modified the routines to now be FileNVRAM specific, they were originally designed to be fairly generic and not specific to the kext. Additionally, I've noticed that you changed the target from 10.4 to 10.11. The original kext was setup so that it works on any x86 and x86_64 os that apple has released. This was done by design. Other than that... it's kinda hard to see if you changed anything else in the diff (well, except replacing all spaces with tabs) For anyone wanting to do development with FileNVRAM: As for any extensions to FileNVRAM (such as in relation to CSR): Please note that the FileNVRAM module provides a public API for chameleon that allows it to set, delete and modify nvram variables. These should be used if you want to change the behavior, instead of modifying the module directly. If you have a diff that you would like me to add to the official repo, you can do so using the following link: https://public.xzenue.com/differential/diff/create/Once you do so, I'll add any comments about things that I'd like changed before merging it in. Related to the CSR, FileNVRAM (the root context) needs to be able to write to a file on disk, as such, there really isn't a good way to properly secure this kext on 10.11 to block root / normal users from writing to this file, while still allowing FileNVRAM access. I haven't tried 10.11 yes, so there might be a way to grant special privileges to the kext itself, but again, I haven't looked into it.
  8. I want to learn how to patch kernels and stuff

    I don't know of any real guide / tutorial that'll help you out.. but there are some pretty good resources. Anyway, I really just want to respond to post a link (cause, awesome link).... For source patches, I suggest you read this. For non-kext based patches, I'd also suggest developing kernel patches using the kext based method in the kernel patcher module... although I'm a little biased (and I don't think anyone had done so yet, although it's *really* easy - no need for assembly) For binary patches, good luck and have fun. There are some techniques that I use, although I haven't written anything up about them. Maybe I will sometime. Until then, It's really your standard debugging techniques that always apply (figure out what works / what doesn't. Figure out where it's broken and how to fix it.
  9. The short answer is that the message is harmless and you can ignore it. The long answer is that it's indirectly caused by the KernelPatcher module and/or the FileNVRAM module These modules enable a code path in the kernel that allows kexts to be loaded even though you're loading a prelinked kernel. This is normally disabled by Apple, however it's needed to inject kexts during bootup w/o regenerating the prelinked kernel. If you take a look at the XNU source code, the kext loading code that gets executed in this case parses all sections in the memory map. If these sections are not kexts it throws the warning and skips over them. Ideally the kernel should be modified to only parse kexts that start with the Kext or MKext name (all kexts that are injected by the booloader start with this, I believe). I've never bothered to file a bug report with apple about it, because it's harmless and they probably don't care about it.
  10. Later builds of FileNVRAM use an updated api for the module system that is not backwards compatible - this is probably causing the reboot.
  11. There's already a kernel patcher version in my svn that lets you build c (kext style) kernel patches... It's pretty useful if you're lazy / don't like going assembly or binary patches. I believe there was a slight issue with it and global variables, but otherwise it works pretty nicely.
  12. Hmm... I wonder how that got there...
  13. Help on converting hex to x64 binary

    Try xxd -i <filename> to generate a c style header.
  14. KernelPatcher Source Code

    For those wodnering, there are two methods to extend the kernel patcher without modifying the source code: (1) Create a module that registers for the "Kernel Patched" hook. This will pass the kernel address, as well a symbol information to your module, allowing for your code to lookup function addresses and perform patches -- or -- (2) Create a new kext in Xcode, write your function in C, and compile it. If the kext is located in a special location and has a few properties in it, it'll result in the functions you wrote being used instead of ones in kernel. Currently it's only written for 32bit kernels (I need to update it for 64bit), but it does allow for easy and nice patches to be written. If you'd like an example of a patch or two, let me know. EDIT: actually, I just added in the LAPIC patch to the examples/ folder in svn. Take a look at it for an example on how to write the patches in C. You may want to compare the source to the original xnu source to see what changed.
  15. Chameleon won't load modules?

    If you do plan on using a config file... I'm going to suggest using just using a plist. It's already built into chameleon (and *please* use the full plist capabilities, don't stuff integers in strings like chameleon tends to do... just use <integer>some_num</integer>.
×