In order to recognize a computer in a certain manner (MAC adress not appropriate for some cases, disk ID or hostname neither etc.), I would like to detect a CPU id (or first CPU core id)... How can I achieve this on different platforms? (not necessarily in manner that is robust to OS change on the same computer)
Thanks
The CPU id identifies the processor model, and isn't unique to each computer. See: http://en.wikipedia.org/wiki/CPUID
The MAC address is usually the best way to uniquely identify a system.
Related
Is it safe to use the MAC address as the serial number of a microcontroller in embedded systems? Is it a security threat or can it be duplicated perhaps? (Usually through software from what I read).
MAC Addresses are generated randomly by the manufacturer but as far as I understood there is a slight chance (0.000001% perhaps) that the MAC Address will be duplicate. i.e. it is not entirely unique.
Currently, I must uniquely identify an OS on a computer.
Now I use the serial of a disk and a partition number, which means the OS is installed in that partition of the disk. Because I think only one OS can be installed on one partition on a disk. So, that determines a unique OS.
Or, is there some better way to represent it?
Uniquely is a very slippery concept. Let's say I make VirtualBox machine image, and run five identical instances on my server. They'll all have the same disk serial number and the same partition id. Are they supposed to be the same, or different? Maybe you could add network address to the mix, so that could be the discriminator. But what if they are not networked?
There are many other possible grey areas: I can have a dozen different kernels on the same partition on a Linux system, and boot whichever one I choose at startup time. Should those all be the same, or different?
Early versions of Windows installed on top of a DOS install, and you booted in DOS and then brought up Windows on top of it. Are those two different OS's or just one?
As an exercise in OS X IO/Kit manipulation, I am looking to return a different UUID, Serial, Boot ROM version, perhaps even number of cores and processor type (just any value) to the System Profiler as well as any other program that asks.
From my understanding, this information about the system is stored in the IO/Kit registry which is stored in memory after being compiled at boot time.
How would one go about either over-writing these values in the I/O Kit registry in memory, or intercepting the IO/Kit library calls and returning different values than what is in memory? Would doing it via interception require a custom kernel extension, or some kind of library modification?
Is there anyway to reliably do this at all? Just curious.
Thank you!
I'm building an IOKit CFPlugin driver for OS X. I'll be working with network data coming in that will be translated to MIDI data. No hardware is involved other than the built-in Airport. I have experience with drivers on Windows machines and firmware but this is my first dip into doing it on the Mac. So far things are going pretty well, but the Apple documentation sez: "For safety reasons, you should not load your driver on your development machine."
I only have one Mac. I really don't want two Macs- sorry, Apple. Should I take this warning seriously? Are there things I need to know?
Thanks, Tom Jeffries
You could also consider running OS X inside a VM as your testbed. It would surely be much more convenient that having a separate boot volume.
The warning is rather poorly worded; what you should consider doing is using a separate boot volume (partition) for trying out your driver, since it's possible to arbitrarily hose your system with your driver.
If you're doing kernel development on any OS that isn't isolated from your main system (via a VM, alternate boot disk, etc.), you're crazy!
What may be a bigger issue is that you can't do any kernel debugging, because the only option for that is to use GDB on a remote OS X system. For this, you may want to consider running OS X in virtualization.
you DEFINITELY want to have some way to recover a fubar kext installation: a bootable external drive or something you can quickly restore from-- this is the main reason for Apple's warning against running in-development-kernel-extensions on your production machine.
Nicholas is right that in order to debug using gdb (the only way in kernel space) you do need two machines. I've never tried using a VM as Coxy suggests: but I guess it's feasible (assuming that you run your kext on the virtual machine and use the real host machine to run gdb).
My preferred method for tracing and debugging in the kernel is kprintf() routed to firewire (aka firewire kprintf (man fwkpfv) ). for this you do need two machines with firewire ports.
finally, being an old computer musician myself, I wonder why you want to program a MIDI synthesizer (or transformer) on the network stack level. my guess is that you would have a much more gratifying experience working in userland (where you can use floating point math...)
if you need some hints or tips, feel free to get in touch...
|K<
from the ADC Kernel Programming Guide
Kernel programming is a black art that
should be avoided if at all possible.
Fortunately, kernel programming is
usually unnecessary. You can write
most software entirely in user space.
Even most device drivers (FireWire and
USB, for example) can be written as
applications, rather than as kernel
code. A few low-level drivers must be
resident in the kernel's address
space, however, and this document
might be marginally useful if you are
writing drivers that fall into this
category.
My dad is looking for ways to automate checking the settings of a Windows server for giving it a standards compliance grade. He needs to know if more than one OS is installed, but wants to avoid taking down the server at all costs. Is there any technique within Windows (XP and newer) for programmatically ascertaining whether a machine has multiple OSs installed?
It depends on what you consider "an installed OS".
At the very least you'd have to scan all partitions (including the ones Windows's limited filesystem support can't recognize) for filesystems and then see if they "look" like another OS. If you need to know if the alternate OS is bootable as well, you'll have to scan for boot loaders and their configuration as well.
By the way, what difference does it make if there's another OS installed on the computer?
Not entirely reliably. You could attempt to access the MBR and the partition table and sniff for evidence of the competition if you can persuade Windows to let you open the other partitions as raw devices. It would be a heap of work.
How about doing a checksum of the bootloader and comparing it against a known-good list of Windows OS bootloaders on the HDs?