I want to move my program to USB memory stick. It will run only on memory stick and would not be copied (written on C# and has nearly 3GB of database).
Where can I find a good source for that and/or how can I do that?
What you described can't reasonably be done. If a user can run the program, they can run it. It doesn't matter whether they loaded it from your USB stick or not. You can write it such that it assumes it's being run from the USB stick (with relative paths, per #Kos's comment) but that will in no way prevent people from copying it to their hard drives and running it. Since you don't know where a USB stick will be mounted ahead of time, you can't even use absolute paths.
Allow me to disagree with nmichaels, it is possible to check in C# if your running from removable storage or hard drive.
Check this thread: How to detect if any specific drive is a hard drive?
However, it would be too easy to reverse the thing and allow it to run on hard drives.
As an additional protection, you can read the USB drive serial and if it doesn't match, kill the program.
OR... you if want to be hardcore, use a specific USB drive model, and read the VID/PID, or the chip itself (check mass production tool).
In the end, if the program worths it, someone would still reverse it and break the protection scheme :)
Related
I work on-the-side doing computer repair. Standard operating procedure is to pop out the HDD/SSD, mount it to a backup machine, and pull the client's data (i.e., in case the drive fails/something goes horribly wrong, their data is protected). More and more often, my office is seeing SSDs soldered directly to the motherboard, making this technique impossible.
I was wondering if any of you knew of a some method that would allow direct disk access without drive removal. An analogue would be mounting a phone in Mass Storage Device mode, I suppose. This may be possible already by doing something with a Linux LiveUSB, but I'm not sure how. Booting from a LiveUSB and transferring files over the network is unacceptably slow given the volume of computers we see and amount of data involved.
On Apple computers, this is simple--plug in a Thunderbolt/Firewire connector and use Target Disk Mode to pull directly from the drive.
tl;dr: making a backup of a Windows computer without opening them: how do?
Boot a live Linux from a large USB3 HDD, and use the same disk to copy the client's data to with about USB3 speed.
I'm using Borland C++ Builder for a project which connects to a database.
There is a configuration which does backups to a USB drive. The problem with the current approach is that the drive is manually configured by the end user and sometimes things get messed up. E.g. People move the USB drive to a different port, get a different letter and then the back up process no longer works. As a side note, we have other "better" processes for backing up to the cloud, etc., however some locations don't have internet access and aren't running on a RAID... so backing up to USB gives them a saving grace from a HD crash.
I'm hoping to do some coding to help remove this issue. I'm hoping to be able to get a handle to the OS (Windows 8/7/XP) and be able to identify the drives on the machine. Once I have those, I can then iterate through them and check for a path location (e.g. File marker, so if a the file exists, I know its the USB we supplied). Then once I have that, I can do the back up.
As a worse case scenario, I will be able to iterate through all 26 letters to test each drive. However I'm using this as a learning opportunity and hoping to get a handle to the OS so reduce the number of checks/fails I can run into. Besides, I'm curious if anyone has a better approach :)
I don't think there's much to be gained by trying to do something more advanced than iterating over the 26 drive letters.
Before attempting to check whether or not the marker path exists you could add a call to GetDriveType and compare the return value against DRIVE_REMOVABLE. This will make sure that your code doesn't spin up the CD/DVD drive, or hit the network in the case of a mapped share.
For a variety of reasons, revolving around cost of copy and the travails of the Windows filesystem, I need to mount a stream encoder as a drive, so that incoming data can simply be blindly directed at this "drive", aggregated, and encoded, without the source program being any the wiser. This would be basically trivial on Linux, but seems to be an uphill struggle on windows.
Specifically, I'd like to be able to "mount" a tar builder, which I know sounds odd, but there's a compelling reason for doing this. Is there a utility or library that deals with this? Perhaps an obscure part of the Windows API?
This looks promising... but it seems intended to mount folders or similar, rather than "devices." I do have control of where the data is written, so I can specify an arbitrary path.
Having experience with virtual drives (see our Virtual Storage product line) I can say that your task needs some redefining. As said in comments, drives (or, better say, filesystems) in Windows are expected to be namely filesystems (unlike Unix world), and as such they must support certain reading and enumeration operations, which is not something you'd expect.
Probably the closest you can do is a virtual drive in memory whose contents are then passed to your application in some way. The user will drag the data to your drive and on unmounting (or on other command) drive contents are passed to other program.
Several of our products can be used for your task (see CallbackDisk, Callback File System and SolFS OS Edition on Virtual Storage page), yet they are all commercial products. If you have a one-time or short-term task, you can build something for your use with a trial key.
There exist free approaches to your task, namely Pismo File Mount and Dokan, but I don't know how well they fit.
When I boot up Linux Mint from a Live CD, I am able to save files to the "File System". But where are these files being saved to? Can't be the disc, since it's a CDR. I don't think it's stored in the RAM, because it can only hold so much data and isn't really intended to be used as a "hard drive". The only other option is the hard drive... but it's certainly not saving to any partition on the hard drive I know about, since none of them are mounted. Then where are my files being saved to??
Believe it or not, it's a ramdisk :)
All live distros mount a temporary hard disk in RAM memory. The process is completely user-transparent and is all because of the magic of Linux kernel.
The OS, in fact, first allocates an area of your RAM memory into a virtual device, then mounts it as a regular hard drive in your file system.
Once you reboot, you lose all your data from that ramdrive.
Ramdrive is needed by almost all software running on Live CDs. In fact, almost all programs, in particular desktop managers, are designed in order to write files, even temporary, during their execution.
As an example, there are two ways to run KDE on a Live CD: either modify its code deeply in order to disallow you to change wallpaper etc. (the desktop settings are stored inside ~/.kde) or redeploy it onto a writable file system such as a ramdrive in order to avoid write fails on read-only file systems.
Obviously, you can mount your real HDD or any USB drive into your virtual file system and make all writes to them permanent, but by default no live distro mounts your drives into the root file system, instead they usually mount into specific subdirectories like /mnt, /media, /windows
Hope to have been of help.
It does indeed emulate a disk using RAM; from Wikipedia:
It is able to run without permanent
installation by placing the files that
typically would be stored on a hard
drive into RAM, typically in a RAM
disk, though this does cut down on the
RAM available to applications.
RAM. In Linux, and indeed most unix systems, any kind of device is seen as a file system.
For example, to get memory info on linux you use cat /proc/meminfo, where cat is used to read files. Then, there's all sorts of strange stuff like /dev/random (to read random crap) and /dev/null (to throw away crap). ;-)
To make it persistent - use a USB device - properly formatted and with a special name. See here:
https://help.ubuntu.com/community/LiveCD/Persistence
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.