New answers tagged

1

Infinte printf loop Reeplace \u00 with the byte you want. while true ; do printf "\u00" ; done | yourapp C++ code: #include<cstdio> int main(){ char out=Byte; while(true) fwrite(&out,sizeof(out),1,stdout); } Compile: reeplace Byte with the value you want. g++ -O3 -o bin file.cpp -D Byte=0x01 Use ./bin | yourapp


0

There are IDs / UUIDs in real (drives) and virtual (LVM, MD) hardware and in file systems. The file system UUIDs can be easily changed. Hardware IDs cannot be changed. start cmd: # blkid /dev/sda2 /dev/sda2: UUID="b7d3900a-b6bc-4a40-b8dd-30d8df0037d0" SEC_TYPE="ext2" TYPE="ext3" PTTYPE="dos" PARTUUID="00097464-02"


0

After many reading, and thanks to Bibek_G's answer which helped me to find some links on the internets, I finally understood what I need and how to make thing work. Actually, what I want to do doesn't need screen... The right command was : sudo echo 1 > /dev/cu.HC-06-DevB It didn't work at the beginning because I didn't use sudo. By the way, I also ...


1

Well, hex 804 is actually two bytes, typically written as 0x0804. The first byte is 0x08 (the "major" number), the second is 0x04 (the "minor" number). Converting them to decimal, that's where 8, 4 comes from. You can find out what the 8 means from /proc/devices, which gives block device 8 as sd, which is SCSI disk. It's the first one in there, which is how ...


1

Unless I am misreading your question, the answer is yes; were it not possible to do, no device drivers could exist. You won't be able to read any USB device as plaintext or anything like that, though, and you will need direct access to the usb device node. Drivers may interfere with reading from them. But on a theoretical level, yes, one may read data from ...


0

First, the bash does not print to a screen nor framebuffer device directly. It just writes its output to a simple file descriptor. Second, linux supports both graphics mode consoles and text mode consoles. So, when your configuration does not use framebuffer driver then the text mode console is activated. There is a good article at wikipedia on the topic.


0

Here's the manual for screen. Look for the specific command line options to the screen that you're interested in. For example, -r reattaches to a detached screen process. -R reattaches if possible and starts a new session otherwise. I think this is the option you're looking for. So, I'd do: $ screen -R /dev/tty.HC-06-DevB Also from the manual page: ...


4

With mknod, you create device-special files that allow raw access to the hardware. That is, the kernel looks at the device-special file's permissions to decide whether a given user is allowed raw acess to hardware, not to anything in configuration or some such. E.g., on Debian, devices related to optical drives are created with 0660 permission bits, user ...


7

If you could call mknod arbitrarily, then you could create device files owned and accessible by you for any device. The device files give you unlimited access to the corresponding devices; therefore, any user could access devices arbitrarily. For instance, suppose /dev/sda1 holds a file system to which you have no access. (Say, it is mounted to /secret). ...


4

After the regular, FIFO and socket file types, mknod can also create device files. These are used to access devices. Granting access to devices is considered a privileged operation. Generally, we don't want to create arbitrary device nodes and make them accessible to regular users. That would be Bad. [Aside: Typically device access is granted by ...


0

You could use mknod to access device files in a chroot "prison" (e.g. the device for the root file system)



Top 50 recent answers are included