This question doesn't sound trivial, but I'll give it a try.
What I need to do, is to create a virtual filesystem and mount it as if it was an hard drive. When my application starts, a new hard drive should appear in the list of available devices. Now, I need that drive to be virtual. In particular, I need to be able to generate the content in a dynamic way.
Basically, I would want to be able to:
import some magic library
register the callbacks for, like, list folder, get the content of this file at these bytes, and so on
run my program
a new drive appears, and when I do an ls, it's my program that answers that ls via a callback
Is this even possible? In principle, I should be able to simulate a drive, but I wouldn't even know where to start.
On Linux FUSE library is built into the OS. On MacOS X there's OSXFUSE which is similar to FUSE on Linux.
On Windows there's CBFS Connect by our company, which offers its own API and a FUSE compatibility layer.
Mobile platforms (iOS, Android) neither offer such functions nor give a way to implement them.
Related
I have a linux executable running on my Ubuntu Machine. I want to grant access to a user in order to execute the program, but I don't want this program to be copied.
I was thinking into making a simple crypter app that will decrypt the program at run time an run it from memory.
Is this feasable ?
You can
chmod -r program
The executable will still be runnable, but you cannot copy it.
I just tested that on Ubuntu 14.04 with a downloaded eclipse binary - it worked.
Please note that this will only work for binaries. It will not work for script files that need to be read and interpreted by a shell or interpreter.
It depends hard on the kind of attack a potential user would be able to do which relates typically to the commercial value of a successful attack.
First of all:
If a user have physical access to the storage there is no chance to protect anything from copying. Simply by booting with another OS make all system internal protections baseless. This will be true for the protected program and also all the programs which do some kind of obscure security features like decryption. You can boot a pc from usb or any other media. Forget about something like rights managements supported by the OS.
To hack the mac address on a pc is something that can be done in a few seconds. Load a kernel driver which register a pseudo network card and you will get any fake mac you want. Who will protect the pc for running with modified kernel?
The next is, that any kind of decryption will result in a memory map which hold the executable during runtime of the prog. Any low privileged hacker can get a copy of this memory and can create a application to get this image to run on any other machine.
As you can see on real world licensing models, the only chance is to use additional hardware which is fully secured like crypto usb sticks or other kind of ciphering agents. Another trick can be some kind of online key repository. But all this can not be done by simply implementing some crypto algos.
If you have a product which must be protected against illegal usage, you have to use a commercial protection.
Sorry that I can not see which is your intention from your question. If you only want to keep a simple application with no commercial value on one pc for a "friend" or you have to secure the income of your business :-)
If I'm understanding, you have a user logged in who needs to run program X but not copy program X?
One way, if this is a compiled executable, is to set execute only, but double check your suid_dumpable kernel setting.
If it's a script, or if you have configuration files that go along with it and those need protection, then the /etc/shadow pattern applies: users need to be able to read that file, but not copy it elsewhere for attack. For this pattern, the solution is to use a mediator program. Specifically, the program can temporarily increase its privilege to read the file, but cannot be coerced into providing access to anything in the file beyond what exactly is needed to run.
The accepted answer to this question explains nicely the variety of options. I personally like the sudo approach.
I am going to implement a file system in C and i'm wondering how can i test it without installing it in the kernel nor using FUSE API. Ideally what i'd like to do is to use dd command to create a virtual hard drive and interact with it using linux system calls like write and read (the idea is to not write drivers). Is that posible?
(I'm sorry if i misspelled words, but eanglish isn't my first language. Also i'm sorry if this is off-topic, it's my first question)
Thanks.
If you are really implementing a file system, you can test it in virtual machine.
Otherwise, you can implement a file system in a file which exist in real file system, and implement some functions like read/write/etc...
Virtual hard drive and virtual filesystem are a bit different things, - you write different functions and handle different requests when implementing them. Given that you implement a filesystem, your best bet on linux is to expose your filesystem via FUSE for testing. Then write different tests that will access your FUSE-based filesystem to perform various tasks.
Unfortunately testing a filesystem is hard and requires writing many tests. Manual testing with different software (file managers) is also required.
I am wondering if it's possible to write an application that will access a foreign filesystem, but without needing support for that filesystem from the operating system. For example, I'd like to write an app in C that runs on Mac OS X that can browse / copy files from an ext2/ext3 formatted disk. Of course, you'd have to do all the transfers through the application (not through the system using cp or the Finder), but that would be OK for my purpose. Is this possible?
There are user space libraries that allow you to access file systems.
The Linux-NTFS library (libntfs) allows you to access NTFS file systems and there are user space programs like ntfsfix to do things to the file system.
E2fsprogs does the same for ext2, ext3 and ext4 filesystems.
As Basile mentioned, Mtools is another one that provides access to FAT partitions.
There was even a program that does exactly what you're looking for on Windows. It's called ext2explore and allows you to access ext2 partitions from Windows.
It is possible. For example the GNU mtools utility are doing that (assuming a way to access the raw device or partition) for MS-DOS FAT file systems.
However, file systems inside the kernel are usually very well tested and optimized.
Yes and No. For a regular user Application is usually not possible because access to block devices is restricted to root only. Every block device should give read/write to the needed block device for that effect. This would need at best a server/client approach where a service is started on the machine and configured to give the permissions on a per block device manner.
The somewhat easier alternative would be you to use the MacFUSE implementation.
Look here:
http://code.google.com/p/macfuse/
http://groups.google.com/group/macfuse?pli=1
The MacFuse project seems no longer mantained, but can give you a starting point for your project.
The dirty and quick approach is the following as root chmod 666 /dev/diskN
You can hijack syscalls and library calls from your application and then redirect reads/writes to anything like a KV store or a distributed DB layer (using the regular calls for the "virtual devices" that you do not support).
Then, the possibilities are boundless because you don't have to reach the physical/virtual devices when someone asks for them (resolving privilege issues).
I am new to android kernel and Mobile Operating Systems and I have a few questions regarding android kernel.
1) Does Android OS has Kernel Mode and a User mode like Normal desktop OSs ? Also does it support things like Virtual Memory ? Also I heard about Dalvik VMM. Is a copy of dalvik VMM created for each and every process ?
2) Another Question is I heard android creates a separate file system for each and every process(every application). Is this true ? If so How OS maintains these file systems and where are they mounted. Does it have a hierarchy like Unix based systems ?
3) Another Question is regarding IPC in android. What are binders in android ? How does it differ from normal IPC mechanisms like pipes, msg queues etc.
4) Another Question not related to android but How does the driver address Flash based disks like Solid state drives etc. For ex: normal HDD block can be identified by cylinder, sector and a track.
1. The "Android kernel" is the Linux kernel.
1a. No, you didn't hear about the "Dalvik VMM", you heard about the "Dalvik VM", which is simply a new kind of Java VM. It runs Java apps. No magic. No, there isn't somehow a Dalvik VM associated with "every process", but yes, each application runs in an independent process.
2. No. There's a directory structure, not distinct filesystems.
3. Why Binder?
4. Android uses the usual Linux MTD and MTD-Block devices. And the world is LBA, whether for flash or hard drives. CHS is only for those time-travelling thirty years to the past.
Does the Android kernel have a kernel space and user space?
The kernel used on Android powered devices is a 2.6 kernel providing the core system services like memory management, process management, network stack, and driver model.
So yes it does have a kernel and user space. You have the regular /proc file system for kernel/user space communication for example.
It is true that every application runs in its own process with its own instance of DVM.
You can read more about it on the What is Android? page.
How does the application file structure look like on Android?
Yes every applications has its own directory structure for application data like databases, shared preferences and other application specific files which looks like this.
/data/data/packagename
Other than that the actual .apk files are located in
/data/app
I'm not quite sure about your question if it is a UNIX based hierarchy system. I guess you want to know if applications will be placed in /usr/bin/ and so on. Then no. Except you write some binaries yourself and build your custom image then you should definitely place your system binaries in the default FSH places.
On question three. I'm not quite sure what you are referring to. If you mean the UNIX IPC then well it's a 2.6 kernel with all it's core functionalities like states above. If you are referring to Remote procedure calls of the APIs then you might take a look at Remote procedure calls.
Question four is beyond my knowledge or I didn't get your question.
Generally I'd recommend you some very interesting reads.
What is Android? like stated above.
Android Application Fundamentals
Android Sources page
Hope it helped somehow.
1) If you want permissions for various operations you need to enable them in the manifest.
2) Yes. Each application has its own file-system, but the files are accessed by file name only (no path). If you want to use external memory such as an SD card, you need to enable permission in the manifest, and use a fully qualified path/file-name.
3) I am not familiar with android binders (though I see them while debugging), but passing messages between tasks is very straightforward.
4) Flash based memory blocks are identified by address. Flash is not RAM, but it is random access.
I like programming challenges, and writing a kernel seems a programming challenge.
Unfortunately, kernels are particularly hard to test because they are basically the core of operating systems and so they can't be easily ran on top of an operating system.
However, I know about applications called Virtual Machines that can emulate computer hardware.
What is the easiest/best way to develop and test kernels(C+Assembly) using Virtual Machines?
While BOCHS seems to be better at letting you know when something goes horribly wrong with your pet OS... it is very slooooow! I use VirtualPC for general purpose testing and BOCHS when things get murky.
Also, you will more than likely be booting the OS every 2 minutes, so it helps to have some sort of automated way to build a boot image & fire off the Virtual PC.
I built a GRUB boot floppy image with all the necessary stuff to get it to boot the Kernel.Bin from the root. I use a batch file to copy this file to the virtual project directory, use FAT Image Generator to copy my kernel to the image. Then just launch the VirtualPC project. Vola!
Excerpt from my batch file:
COPY Images\Base.vfd Images\Boot.vfd /Y
fat_imgen.exe modify Images\Boot.vfd -f Source\Bin\KERNEL.BIN
COPY Images\Boot.vfd Emulators\VirtualPC\ /Y
START Emulators\VirtualPC\MyOS.vmc
One last suggestion: Set the VirtualPC process priority to low - trust me on this one!
I'd be happy to exchange some code!
Tools: DGJPP, NASM, GRUB.
Code: osdev.org, osdever.net
You might be interested in looking at HelenOS. Its a from scratch microkernel that has been ported to many architectures (boots just fine on bare metal) developed using simulators such as Simics and QEMU.
We use a static grub that is copied to the final ISO during the build process. Some things just have to be that way until the OS becomes self hosting. I highly recommend NOT implementing your own userspace C library unless you really do want to do everything from scratch .. you'll become self hosting much sooner :)
Though Simics is non-free, I highly recommend it (and its built in debugging/profiling tools) while making your kernel. Once you have some kind of kernel console and logger in place, QEMU does a very nice job.
It's straightforward. Set up a virtual machine, write your kernel, copy it to the virtual machine, boot the virtual machine.
You'll need to be more specific if you want more specific advice.
Probably just setting up a machine (x86, I guess), and then investigate exactly how it behaves during boot. There should be one or more files in the host machine's file system that act as the virtual machine's file system, and then you'd need to put some boot sector information there that causes your in-development kernel to boot.
That would of course mean that the build system on the host has a way to write the kernel to the virtual machine's file system, which might vary in difficulty.
Picking one at random, bochs seems to support editing the boot media from the outside using standard tools like dd etc.
The first question that you need to ask yourself is what hardware architecture are you targeting? I'll assume for the sake of this discussion that you are targeting the IA_32 architecture, which would probably be a wise choice as there is plenty of readily-available documentation on that processor.
If you're truly serious about this undertaking, then you will definitely want to run your debug/code/build/deploy cycle against an emulator or VM. Someone mentioned BOCHS, which is very popular. If emulation speed is your thing, there is also an emulator called Qemu that is faster than BOCHS.
I'd suggest that your development environment run under Linux or Windows, which again would probably be a wise choice due to the available documentation for those dev environments.
Make is your friend. Use it to automate the build/execute process. I'd advise you to pick your toolsets/compilers up front, and spend some time learning them well. It will save you in the long run.