Carlo Gulliani wrote:
typedef struct mrim_packet_header_t
{
u_long magic;
Your use of u_long as a 32-bit value will likely fail if your code is
ever compiled for 64-bit. You should use the typedef'ed names that
have an explicit size-number in them, like uint32_t, uint64_t.
NSMutableData *data = [NSData dataWithBytes:&packet length:sizeof
(packet)];
This is wrong. You can't make an NSData into an NSMutableData simply
by assigning it to a variable of that type. You should re-read the
fundamentals of Objective-C. Then you should the class reference doc
for NSMutableData.
int c = 4;
char buf[c];
[data getBytes:buf];
This is a buffer overflow. The variable 'buf' is only 4 bytes long,
but getBytes: copies the entire length of 'data' into buf.
for (i=20; i<[data length]+c; i++)
{
buf[i] = 0;
}
This is another buffer overflow. You are zeroing elements far beyond
the last real element of buf.
data = [NSData dataWithBytes:buf length:[data length]+c];
This is another buffer overflow. It's creating an NSData with random
stuff from well beyond the end of the buf array.
so, i found a dump of binary which must to result
0000 efbeadde 13000100 02000000 01100000 00100000 00000000 00000000
00000000 00000020 00000000 00000000 00000000
but i got
efbeadde 07000100 00000000 01100000 00000000 00000000 00000000
00286930 4cc40000 58e4ffbf 36c90091 00000000
my data is different of correct data, why? I use the same variables
like there
No, you didn't use the same variables.
You're not using the same value for the proto member (you use
0x10007, the reference data shows 0x10013).
You didn't build your header with a dlen of 16 (0x10), which is what
the reference data shows. You built it with a dlen of 0 [self
makePacket:MRIM_CS_HELLO length:0];.
One of the buffer overflows is the most likely cause of the remaining
differences.
You should review the fundamentals of C structs, C memory layouts,
and why uninitialized local variables aren't automatically zeroed.
Once you get the memory contents correct in plain old C, it will be
easy to make a correct NSData that contains the data. You're not
even close to getting the correct C memory layout, though, and
anything you're doing with NSData isn't helping solve that problem at
all.
You should ignore NSData completely at this point and focus on
getting the correct memory buffer contents, with no buffer overflows.
-- GG
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
