We have an auto update for our software that is installed via USB key (with the auto run). If I wanted to ensure that only authorized USB Keys were used, what's the best way?
Our installer is already signed, and it won't run otherwise. But I'm more wanting to inspect the USB Key for a signed installer, and if it's not there, just ignore, or even "Eject" the USB device.
And I should be able to tell the difference (in code) between a usb storage device, and say a camera, or keyboard.
I'm only wanting to disable non-authorized storage devices.
Thank you for your ideas.
non-authorized storage devices? This depends on how secure you want it to be. For the most secure level, it would consist of:
special firmware written to the flash drive to get extra "meta info" (read: expensive custom manufacturing of flash drives)
special windows driver to read that meta info from the flash drive
your program talking to that device driver to confirm it's authorized.
Or to the least secure level you have these options:
using a hidden file and a special key(possibly hashed time of last filesystem modification or something?) (dd breakable)
dropping below the filesystem level and recreating your own very simple filesystem.. (more security through obscurity though and dd could break that)
Also, for the "most secure" option, you really need a more secure way of running the program than auto-run and a device driver(which could be half-baked to make anything appear authorized). Why do you want it to only update from an authorized flash drive anyway?
You might be able to read the USB drive's serial number (assuming you get USB drives that have serial numbers; not all do). Then your application could call home to get the latest list of authorized serial numbers, and check to see if there is a match.
Earlz response is good, though I don't think you'd need custom manufacturing of flash drives... you would just need flash drives with some sort of unique firmware encrypted identifier. Perhaps something in the Kingston Data Traveler Line might do the trick. (I've never actually used one of these encrypted usb sticks, so I'm a bit foggy on the actual implementation details).
Related
I want to create an application or modify USB in a way so that, upon insertion into any PC, I can get the information that PC was inserted.
eg. upon insertion, I can read PC name and make an API call with this as post data so I'm able to know that my USB was inserted in some PC. But this should happen right away as USB is read by the machine, so even if the user formats it thereafter, it should not matter.
If it was earlier windows, I could write autorun and that would work. But I want this detection mechanism for Windows 7 and above.
I have done some research on the topic but could not find any reliable content. Some articles were related to USB based hacking attacks by changing wiring (USB hardware, to harm the computer) or something like that. But I totally don't want to do that. Just the detection, that USB was used.
I live in Estonia where citizens, e-residents etc can use their ID card to prove identity by signing documents, open encrypted files that are intended for a specific individual and so on.
For that purpose we here use card readers (of course).
The problem is, unlike USB mice, USB keyboards and such things, to get it work I need first to restart my Mac. In other cases keychain won't see this device and I won't be able to do anything with it.
Is there a way to make my ID card work and seen by keychain without restarting my machine every time I want to use it?
Maybe there's a way to somehow restart just keychain or something.
All right, that was easy enough.
If somebody experiences kind of same issue, just reset NVRAM and SMC.
Got a customer request but no idea can it be done. So need your opinions on this. This might be a utterly stupid thing to ask but yet need some facts so can work out best solution.
Scenario,
My Customer is an OEM Manufacturer. They make an automated system with a embedded touch screen (Windows XPe) this system got a button panel with some LED indicators (apart from keyboard) and 7 USB Ports. These button panels and USB ports are checked before sending to QC process. Currently a USB thumb drive with standalone executable with all indicators and controls flags is inserted to one of the USBs and then will run the exe. This exe capture user inputs from button panel and indicate which button is pressed so that it can be verify as working. And from program user can set LED indicators to different states (flashing, steady and off) so they can be verified as well. Once this is done then USB thumb drive will be inserted to each port and will verify it recognise. But after each verify step it needs to safely remove the drive from task bar. Once each test is finish user required to fill up the sheet with all pass and fail states for the entire button panel, indicators and USB ports. This is a quite length process when its come to mass production.
Apart from this embedded system all other components which suppose to connect to one of above embedded systems are tested via a program which I make and records all test outputs as they are tested. This program installed and components are connected to a testing embedded system.
Requirement,
What customer asks, can my program test completed embedded system with our host system (testing embedded system, may be via USB to USB) Its more like Testing a PC from another PC. Any ideas ?
Additional Info.
Apart from USBs there is one Network Port.
Thanks for looking, Feel Free to ask any questions. Any opinion is appreciated.
I'm not an expert on this topic, but it seems like this would be problematic because USB is an assymetrical protocol. There are hosts and there are devices. Hosts make the requests, and devices fulfill the requests. The problem is that PCs are USB hosts, not USB devices, so you would have two hosts trying to get the guy on the other side to do what he wants. Testing with a USB thumb drive worked because the thumb drive is a device.
It sounds like the unit to be tested doesn't have an ethernet port, which is a shame, because that would be the easiest way to go. If it has a serial port you could do it that way, but that is both slow and a hassle.
Regarding guidInstance in DIDEVICEINSTANCE
Microsoft says:
Unique identifier for the instance of the device. An application can save the instance globally unique identifier (GUID) into a configuration file and use it at a later time. Instance GUIDs are specific to a particular computer. An instance GUID obtained from one computer is unrelated to instance GUIDs on another.
So, if I connect my device to the computer and my program does enumeration and finds the guid, do I ever have to enumerate again? Even if the user plugs and unplugs the device. If another device of the same type is plugged in, does it still recognize that the second device is not the same as the first and therefore requires a different guid? Should I just renumerate all the interfaces all the time my program runs to find my device or is once enough for a given pc?
Thanks.
I'm actually trying to solve a similar problem. According to the MSDN here, it looks like InstanceGUID is supposed to always be the same on the same computer. I've verified that if I unplug my USB device and plug it into a different port, it does indeed keep the same Instance GUID. However, if a different user logs into the same PC, DirectInput shows the same device having a different InstanceGUID!! I can't find any acknowledgement from Microsoft that this is a known problem.
So, I can partially answer your question. If you have two identical devices, you will get different InstanceGUIDs, and identical ProductGUIDs. Those InstanceGUIDs will stay consistent if you unplug your devices and move them to different USB ports. HOWEVER you will get different InstanceGUIDs if a different user logs in. At least I can verify that this is an issue on Windows 7 64bit.
The InstanceGuid will always be a unique identifier for every device plugged in - but if you remove the installation information (e.g. uninstalling a usb device) you also lose that InstanceGuid. The device will get some new unpredictable Guid when plugged in again.
The ProductGuid will always be the same for one device, since it's stored in the devices USB HID chip. It may happen though that two devices of the exact same type have the same ProductGuid. If they do, you can only identify them by their InstanceGuid (which may become invalid in some cases, as written above...).
I need to modify the MBR of Windows, and I would really like to do this from Windows.
Here are my questions. I know that I can get a handle on a physical device with a call to CreateFile. Will the MBR always be on \\.\PHYSICALDRIVE0? Also, I'm still learning the Windows API to read directly from the disk. Is readabsolutesectors and writeabsolutesectdors the two functions I'm going to need to use to read/write to the disk sectors which contain the MBR?
Edit from from what I've learned on my own.
The MBR will not always be on \\.\PHYSICALDRIVE0. Also, you can write to the bootsector (at least as Administrator on XP) by call CreateFile with the device name of the drive that contains the MBR. Also, you can write to this drive by simply calling WriteFile and passing the handle of the device created by calling CreateFile.
Edit to address Joel Coehoorn.
I need to edit the MBR because I'm working on a project that needs to modify hardware registers after POST in BIOS, but before Windows will be allowed to boot. Our plan is to make these changes by modifying the bootloader to execute our code before Windows boots up.
Edit for Cd-MaN.
Thanks for the info. There isn't anything in your answer, though, that I didn't know and your answer doesn't address my question. The registry in particular absolutely will not do what we need for multiple reasons. The big reason being that Windows is the highest layer among multiple software layers that will be running with our product. These changes need to occur even before the lower levels run, and so the registry won't work.
P.S. for Cd-MaN.
As I understand it, the information you give isn't quite correct. For Vista, I think you can write to a volume if the sectors being written to are boot sectors. See http://support.microsoft.com/kb/942448
Once the OS is started the MBR is typically protected for virus reasons - this is one of the oldest virus tricks in the books - goes back to passing viruses from floppy to floppy.
Even if it wasn't restricted, you have to write low level code - it isn't part of the file system, but exists on a specific location on the hard drive.
Due to that, you pretty much are restricted to writing low level (most programs implement this in assembly) or C code targeting 16 bit DOS.
Most of these programs use the BIOS interface (13h, I believe) to access the sectors of the disk directly. You can access these in C using some inline assembly, or compiler provided interfaces. You will generally not get access to BIOS without the cooperation of the OS, though, so your program, again, will be restricted to DOS. If you can access these you're almost home free - the nice thing about BIOS is you don't have to worry about what type of HD is in the system - even RAID cards often insert themselves into the BIOS routines so they can be accessed without knowing where in memory the ATA or SATA controller is, and executing commands on that low level.
If you absolutely must access it within an OS, though, you pretty much have to write a device driver to access the BIOS or the memory space where the HD controllers exist. I wouldn't recommend it, though, as this is very tricky to deal with - modern computers put the HD controllers in different spots in memory, with different IRQs, and each chipset has become a little more esoteric because they can provide a minimum interface to bios for bootup, and then a specific driver for Windows. They skip all the other interface niceties that would be considered compatible with other controllers because it's more expensive to be compatible.
You may find that at the driver level inside windows you'll have methods for accessing the drive sectors directly (or pseudo directly), but again, they are likely very well protected due to the aforementioned virus issues.
Good luck!
Modifying the bootloader is bad, bad idea. Here are just a few of the possible gotcha's:
it will potentially kill full disk encryption products (Truecrypt, PGP, Vista's BitLocker, etc)
it will potentially trip up AV products (scaring users)
it will potentially kill complicated booting scenarios (chained boot loaders, etc)
it will kill off the chain of trust when using the TPM module (because it checks the MBR for change before executing it)
direct disk access is not allowed starting from Vista (only using drivers)
Alternatives (like modifying the hardware register during the Windows bootup via a driver which is set to load at boot time or after Windows has booted) should really be considered. If the modification is as simple as writing to a port, ie:
OUT AX, BL
then drivers exists for all versions of Window which can do this (reading/writing a value from/to a certain port) which can be called from user mode.
Maybe a PXE boot scenario could help you? Simply boot on your crafted PXE image which modify the hardware registers you need to modify, and then return the control to the Master Boot Record or to the active partition's boot record.
This way you don't have to modify the boot records.