I have a bootable flash disk and it contains customized Ubunto, I want to pass the flash disk to an unknown person and it has some security issues. I want to be sure an unknown person couldn't change flash disk contents. hence I want to calculate hash of flash content and verify it on each boot and prevent booting OS if the verification failed or the hash goes mismatch.
for this purpose, I should do bootloader programming, I looking for UEFI programming but I found a few documents and videos, And also I do not know whether to select UEFI or BIOS.
so I would appreciate you if you could help me and provide a Comprehensive solution or suggest any other solution(except bootloader programming) for my problem.
I think you are going the wrong way. IMHO, the easiest way is to use the secure boot mechanism of UEFI. For that, you just have to sign your kernel and the modules that need to be protected.
How to sign things for Secure Boot.
Related
If I use the IOKit methods to list USB devices, I can get something like "AirPod Case", but I don't know how to get "Francisco's AirPods". I've looked around a the various keys you can ask for, but none I've found bring up these "settable" names, only the standard "product names".
I don't know the answer as a fact, but I can give you some ideas for chasing it down:
The customised name is probably transferred as part of a higher-level protocol, or via vendor specific requests, not via standardised USB device descriptors. There is a small chance it might be advertised via a vendor specific descriptor, but this seems unlikely
I don't own any AirPods, so I don't know what kind of data protocol the AirPod case uses for communicating with a Mac, but you can try to find documentation or source code for that protocol, for example in case anyone has worked out how to use them from Linux and written a tool or library for that.
Finally, you can reverse engineer it yourself, by logging the USB traffic to and from the device when using existing software that is capable of reading the name you are after. On macOS, it's possible to do this using Wireshark. Start logging USB traffic, launch the software that talks to the device, then trawl through the logs to see if you can spot the string, then work out what request caused it to be returned.
I am in need to build a secure application for Mac. For that I am using a master password that only exists in the head of the creator.
To retrieve it the password first needs to be entered in a secure textfield* it can then be used to encrypt and decrypt files. While the application remains open that master password will be stored in a variable, meaning it exists in memory. Would encrypting this password in memory be overkill?
The reason why I am asking this question is that before the master password can be encrypted for memory it already exists as a variable, meaning it's already open for memory scanning attacks. Is this something I should be worried about?
I read the following on https://www.apple.com/macos/security/:
Runtime protections defend at the core. The technically sophisticated
runtime protections in macOS work at the very core of your Mac to help
keep your system safe. Built right into the processor, the XD (execute
disable) feature creates a strong wall between memory used for data
and memory used for executable instructions. This protects against
malware that attempts to trick the Mac into treating data the same way
it treats a program in order to compromise your system. Address Space
Layout Randomization (ASLR) changes the memory locations where
different parts of an app are stored. This makes it difficult for an
attacker to do harm by finding and reordering parts of an app to make
it do something it wasn’t intended to do. macOS brings ASLR to the
memory used by the kernel at the heart of the operating system, so the
same defenses work at every level in your Mac.
Can I conclude that Mac has already build in protection against memory scanning and hijacking?
(* I am aware this might cause keylogger vulnerability)
In every case, you would first derrive a key from the user password, and use this key to encrypt the files. So instead of holding the password in memory, you can immediately calculate the key with a key-derivation-function, and hold the key in memory. The advantage you get is, that an attacker can only learn the key, which allows to decrypt the files, but not the original password, which can possibly be reused.
Some OS offer a specialized SecureString, which is probably the nearest you can get to what you want, it holds a string encrypted in memory and can remove it from there. I do not know whether OSX provides anything like this.
I doubt that an encrypted key in memory is of much use. If an attacker is capable of analysing the memory, (s)he will probably be able to decrypt the memory as well, the application must be able to decrypt the key after all. But certainly it raises the bar and needs more work to do.
The linked article addresses another problem in my opinion, it prevents to place executable code in memory (as input data) and trick the processor to execute it afterwards.
The existence of tools such as mach_inject and Cycript clearly indicate your program's memory is never safe. In iOS world the security of keychain comes from the fact the key is engraved in a separate hardware chip and it's never copied to application memory. If you're doing the encryption/decryption inside your program by definition it's prone to being hijacked in some form. Key things to consider:
what do you want protect? The data? The encryption method? Both?
having access to your binary program an attacker is likely to reverse engineer it, what are the implications?
Do you need the actual encryption/decryption to happen in your program? If at least one crucial step required for the data to be useful would be moved to a external backend it could be way safer
Supplementing your solution with file system encryption like FileVault or TrueCrypt will always improve security
I have an requirement for my client, where in i need to block particular URL based on the user input.
I was thinking to implement this by building a driver, From which i can get the packet response with all the details through this I can block/allow by building an application.(THIS is similar to what "netfilter" driver does in windows)
But as i read through the docs and websites i did not get enough information to proceed with for this particular requirement.(I found about bpf but there was not enough details to proceed with)
As I am very much NEW to the driver field,Can someone suggest me how to proceed in this case.(Steps how to proceed)
Note:I found lot of projects/docs related to USB drivers and all but they were not giving enough idea to proceed for further.
"URL" is very broad, and depending on the kinds of URL (what protocols? What about encryption?) and required granularity, some other solution than a custom kext might be a better approach. Not knowing your requirements, I can't say whether that's the case.
What I can answer, however, is that if you do decide to do this from a kext, Network Kernel Extensions are what you need to look into.
Apple also provides the enetlognke example code to illustrate how to use the NKE APIs.
We're porting our USB device dll's to use the generic WinUsb.
However, WinUsb doesn't support multiple concurrent application accss to the same device (Same VID & PID).
I wanted to know if there is a way to implement this concurrent access using WinUsb?
I read about filter drivers & services.
1. I don't want to use a filter driver because, as I understand, this will have to pass WHQL, and I rather not go this path.
2. Regarding a windows service: How exactly should I implement it? should the service get all of the calls to WinUsb, and if a different application tries to access the same device, it will close the connection to the first application, open a new connection, and back again?
Is the service the right correct solution in this case? Is there another way to implement the solution other that what I wrote?
Thanks.
A filter driver does not need to pass WHQL. You only need to sign the catalog file, needed by the driver package. This only needs a code signing certigficate from verising/... . This should be a good starting place to get to know this.
Nevertheless, a kernel driver can be hard to develop. So maybe a COM server would be a better approach. You implement this sharing from a service, by allowing COM-clients to create objects from your service and then implement some kind of sharing/mutual exclusion in your COM-server.
A COM-exe servers can be written relativly fast.
Question: I have to come up with unique ID for each networked client, such that:
it (ID) should persist once client software is installed on target computer, and should continue to persist if software is re-installed on same computer and same OS installment,
it should not change if hardware configuration is modified in most ways (except changing the motherboard)
When hard drive with client software installed is cloned to another computer with identical hardware configuration (or, as similar as possible), client software should be aware of that change.
A little bit of explanation and some back-story:
This question is basically age old question that also touches the topic of software copy-protection, as some of the mechanisms used in that area are mentioned here. I should be clear at this point that I'm not looking for a copy-protection scheme. Please, read on. :)
I'm working on a client-server software that is supposed to work in a local network. One of the problems I have to solve is to identify each unique client in the network (not so much of a problem), so that I can apply certain attributes to every specific client, retain and enforce those attributes during the deployment lifetime of a specific client.
While I was looking for a solution, I was aware of the following:
Windows activation system uses some kind of heavy fingerprinting mechanism that is extremely sensitive to hardware modifications,
Disk imaging software copies along all Volume IDs (tied to each partition when formatted), and custom, uniquely generated IDs during installation process, during first run, or in any other way, that is strictly software in its nature, and stored in registry or on hard drive, so it's very easy to confuse two.
The obvious choice for this kind of problem would be to find out BIOS identifiers (not 100% sure if this is unique through identical motherboard models, though), as that's the only thing I can rely on that isn't duplicated, transferred by cloning, and that can't be changed (at least not by using some user-space program). Everything else fails as either being not reliable (MAC cloning, anyone?), or too demanding (in terms that it's too sensitive to configuration changes).
Sub-question that I'd like to ask is, am I doing it correctly, architecture-wise? Perhaps there is a better tool for the task that I have to accomplish...
Another approach I had in mind is something similar to a handshake mechanism, where a server maintains an internal lookup table of connected client IDs (which can be even completely software-based and non-unique at any given moment), and tells the client to come up with a different ID during handshake, if a duplicate ID is provided upon connection. That approach, unfortunately, doesn't play nicely with one of the requirements to tie attributes to specific client during lifetime.
It seems to me that you should construct the unique ID corresponding to your requirements. This ID can be constructed as a hash (like MD5, SHA1 or SHA512) from the information which is important for you (some information about software and hardware component).
You can make your solution more secure if you sign such hash with your private key and your software verify during the starting, that the key (signed hash value) is signed (only public key must be installed together with your software). One can expand such kind of solution with different online services, but corporate clients could find online services not so nice.
What you're looking for is the Windows WMI. You can get the motherboard ID (which is unique across the same type of motherboard) or many many other types of unique identifiers and come up with some clever seeded function to generate a UHID. Whoa did I just make up an acronym?
And if you're looking specifically for getting the Motherboard (BIOS) ID:
WMI class: Win32_BIOS
Namespace: \Root\Cimv2
Documentation: http://msdn.microsoft.com/en-us/library/aa394077(VS.85).aspx
Sample code: http://msdn.microsoft.com/en-us/library/aa390423%28VS.85%29.aspx
Edit: You didn't specify a language (and I assumed C++), but this can be done in Java (with a COM driver), and any .NET language, as well.
Many programs use the hostId in order to build a license code (like those based on FlexLM). Have a look at what Matlab does depending on the operative system:
http://www.mathworks.com/support/solutions/en/data/1-171PI/index.html
Also have a look at this question:
Getting a unique id from a unix-like system
Once I also saw some programs basing their licenses on the serial number of the hard drive, an maybe that is the less likely thing to change. Some would suggest to use the MAC of your ethernet card, but that can be reprogrammed.
MAC
DON'T RELY ON MAC! EVER. It is not permanent. The user can easily change it (under 30 seconds).
Volume ID
DON'T RELY ON Volume ID! EVER. It is not permanent. The user can easily change it. It also changes by simply formatting the drive.
WMI
WMI is a service. Can be easily disabled. Actually, I tried that and I find out that on many computers is disabled or broken (yes, quite often broken).
License server
Connection to a validation server may cause you also lots of troubles because:
* your customers may not always be connected to the Internet.
* your customers may connect with special settings (router/NAT/proxy/gateway) that they need to input into your program in order to let it connect to the validation server.
* they may be behind a firewall that will block all programs except a few (my case). In some cases the firewall may not be under their control (valid for MOST corporate users)!
* it is super easy to redirect your program to a local fake webserver that emulates your licensing server.
Hardware data
If you need strong protection you need to rely on hardware. Something that cannot be edited by the user. Something like CPU ID instruction available in the Intel/AMD CPUs and the serial number written into the drive's IDE interface.
The CPU ID and HDD ID are permanent. They will never change, not even after you format the computer and reinstall Windows.
It is doable. For example this library reads the hardware ID of a computer. There is a compiled demo and also sourcecode/DLL. Disclaimer: the link leads to a commercial product (19€/no royalties).