PaNiC Random Rant (or how we used to call it: .plan)
Using video RAM ...
Since I was playing with some jffs images, I wanted to quickly write to a "dummy" mtd device and test the image from there. I remembered some time ago on slashdot there was an interesting article on how to use the video ram as storage. As I couldn't find it anymore I decided to try it myself.
Usually mounting jffs images requires some steps and the mtd2block kernel module:
losetup /dev/loop0 rootfs.jffs2
modprobe block2mtd block2mtd=/dev/loop0,131072
modprobe jffs2
modprobe mtdblock
mkdir /mnt/loop0
mount -t jffs2 -o ro /dev/mtdblock0 /mnt/loop0
Using the video ram:
1. Find out the starting address of video memory:
> lspci -v
2:00.0 VGA compatible controller: nVidia Corporation G94 [GeForce 9600 GT] (rev a1)
Subsystem: LeadTek Research Inc. Device 2ac1
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at ec00 [size=128]
[virtual] Expansion ROM at feb80000 [disabled] [size=512K]
As above the video memory starts at 0xd0000000
2. Map the video ram into a mtd block
> modprobe slram map=VRAM,0xd2000000,+0x4000000
Note that I maped from 0xd0000000 + 32Mb to let some video memory to be used by framebuffer/X (if you use nv driver you can specify VideoRam 32765 in xorg.conf to limit the memory mappings).
The third parameter (+0x4000000) is the memory size (64Mb)
If everything is ok you should see something like this in dmesg log:
slram: Mapped from 0xf8f00000 to 0xfaf00000
slram: devname=VRAM, devstart=0xd2000000, devlength=0x2000000
devstart and devlength depend on your parameters.
Doing cat /proc/mtd should output:
mtd0: 02000000 00004000 "VRAM"
3. Add the kernel mtd modules and create the mtdblock devices
modprobe mtd
modprobe mtd_blkdevs
modprobe mtdblock
mknod /dev/mtdblock0 b 31 0
mknod /dev/mtd0 c 90 0
Now you can use the /dev/mtdblock0 to write jffs images or use it as a very fast swap (mkswap /dev/mtdblock0, swapon)
Notice that you can't create partitions directly in /dev/mtdblock0 with fdisk and use /dev/mtdblock0p1. Partitions are usually created in a device driver mapping or by specifing mtdparts= parameter at kernel boot.
posted by panic @ 7:39 PM
2 Comments
Hijacking library calls
From time to time you might want to override a function call by a binary or library with your own supplied code. This might be useful for example binding a program to a certain address considering that the program doesn't have an option for that. It can also be used for debugging or other obscure tasks. The attached example it's pretty simple, it saves the real address of connect function from libc to a function pointer named real_connect, reads the address/port information from environment and issues the new parameters after the bind call has been performed to the real_connect function.
For your "library" to be preloaded it has to be added to /etc/ld.so.preload by simply doing:
echo "/path/to/libc-highjack.so" > /etc/ld.so.preload
To use it, before starting a program, export HIGHHACK_PORT and HIGHJACK_IP to the values that you need.
The compiling instructions are in the source code.
uploads-blog/libc-highjack.c
Labels: hacks, libc, programming
posted by panic @ 4:42 PM
0 Comments