I used buffer overflow and wrote on ret address in stack. When I debug it with gdb, I understood that the eip sets to the address that I want. The address is a gadget in libc. The opcode of the instructions set properly, but it just doesn't execute them and I get this message:
0xb7fa9dd8 in ?? () from /lib/i386-linux-gnu/libc.so.6
Why? What is this message?
Look at the data below please:
(gdb) x $eip
0xb7fa9dd8: 0xfff2a858
The gadget to execute is:
184dd8: 58 pop %eax
184dd9: a8 f2 test $0xf2,%al
184ddb: ff a8 00 00 00 00 ljmp *0x0(%eax)
Related
A C++ project I work on does not have consistent indentation. The lead developer told me it might not be safe to reformat the code. I thought it might not matter to the compiled code. As a test I tried reformatting one file using a Formatter based on the Eclipse "GNU [built-in]" Profile. When I recompiled the file the md5sum changed. I did a hexdump of the file and it showed one byte changed. I disassembled the object file. I also compiled with debugging and I got the source code line. I used diff to get the assembly instruction that changed.
The source was this line
logErr
<< xmlutils.GetErrorMessage() << endl;
Below is the diff output showing the changed assembly
23be: 89 04 24 mov %eax,(%esp)
23c1: e8 fc ff ff ff call 23c2 <_ZN12RerouteAdapt11WriteToFileERKSs+0x64>
23c6: e8 fc ff ff ff call 23c7 <_ZN12RerouteAdapt11WriteToFileERKSs+0x69>
- 23cb: c7 44 24 04 79 01 00 movl $0x179,0x4(%esp)
+ 23cb: c7 44 24 04 84 01 00 movl $0x184,0x4(%esp)
23d2: 00
23d3: 89 04 24 mov %eax,(%esp)
23d6: e8 fc ff ff ff call 23d7 <_ZN12RerouteAdapt11WriteToFileERKSs+0x79>
The ordering of the headers was not changed by the reformat.
I know some C/C++, but very little about assembly. I was wondering if there was a simple explanation for why the object file would change. I thought the C++ compiler (GCC 4.8.2 on RHEL 7) was indifferent to formatting and white space. There were no differences besides this in the assembly.
Thomas and Tim were correct. The value that changed corresponds to the line number before and after formatting. I assumed "logErr" was just a stream. Turns out it is a macro that uses the __LINE__ macro. So the line number is hard-coded in the assembly.
#define logErr theTracer().SetFuncName(__func__); theTracer().SetFile(__FILE__); theTracer().SetLine(__LINE__); theTracer().SetError(); theTracer()
Thank you for your help.
I develop a C++ Library (DLL). When I create a minimal MFC project (VS2017) that links with this DLL its okay. But as soon as any function of the library is used by the MFC application the debugger of the MFC project complains about memory leaks (many lines like the ones below):
Detected memory leaks!
Dumping objects ->
{2255} normal block at 0x000002A4B1F8C360, 48 bytes long.
Data: < > 10 BB F8 B1 A4 02 00 00 B0 BD F8 B1 A4 02 00 00
{2242} normal block at 0x000002A4B1F8BDB0, 48 bytes long.
Data: < > C0 C0 F8 B1 A4 02 00 00 F0 C2 F8 B1 A4 02 00 00
{2220} normal block at 0x000002A4B1F8C2F0, 48 bytes long.
Data: < > 80 C2 F8 B1 A4 02 00 00 10 C9 F8 B1 A4 02 00 00
These are false positives because it occurs also when only an empty test function of the library is called. Moreover this does not happen when the library is linked with a non-MFC project.
What can cause these warnings? Related information:
A VS2013 user said that he can avoid the warnings by changing the
character set of his MFC project. I have tested that in VS2017 but
get still warnings.
A VS2017 user said that the warnings are gone when he delay-loads
the DLL.
In the course of debugging I have compiled the DLL with CMake in order to use settings which are as standard as possible. But no change.
I have a UDP packet which is embedded inside IP packet and not able to calculate the checksum of UDP properly but I can correctly find the CHecksum of IP. Can someone help how the UDP checksum is found.
[45 00 00 53 00 80 00 00 40 11 66 16 0A 00 00 03 0A 00 00 02] CA B1 CA B1 00 3F DF A5
The bits enclosed in bracket is IP packet and the checksum is given in bold.
**UDP Packet**
CA B1 Source port
CA B1 Destination port
00 3F Length
DF A5 Checksum
Here how the checksum "DF A5" came. I did 16 bit addition and took the 1s complement but still not getting the value. Whether I need to consider IP header also to calculate the Checksum of UDP
I'm making use of wxWidgets in my program for directory management and compressing/uncompromising collections of files. As I've been building my file system, I've noticed that I get memory leaks every run. After a lot of testing, I realized that any time I use any functions related to wxFileName, I get a memory leak. I'm using wx widgets 3.0.1, and my standalone example is as follows.
#include <wx\filename.h>
int main()
{
wxFileName::Mkdir("Test");
return 0;
}
The result is the same if I make an instance of the wxFileName class.
How do I make wx widgets not create a memory leak? I want to be able to package large collections of files in one file, and read the data from them with various other libraries (via extracting the zip to a temporary folder and reading the data from there). I haven't been able to get any other library to zip/unzip entire folders, so I really need to be able to use wxWidgets without a memory leak.
I read in another thread that the visual studios debugger is falsely identifying the memory leaks, but I ran it through AQtime and it confirmed that there was indeed a memory leak.
The exact debug output involving the memory leak is as follows:
Detected memory leaks!
Dumping objects ->
{1087} normal block at 0x009B4BC0, 64 bytes long.
Data: <\+= d+= l+= t+= > 5C 2B 3D 00 64 2B 3D 00 6C 2B 3D 00 74 2B 3D 00
{1086} normal block at 0x009B4880, 772 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{1085} normal block at 0x009B4680, 28 bytes long.
Data: < H > 80 48 9B 00 C1 00 00 00 00 00 00 00 CD CD CD CD
Object dump complete.
After a bit of digging (it WOULD be the digging I did AFTER posting the question) I found that when you're using wxWidgets without creating a wxWidgets app object, you need to use the following two functions:
wxInitialize()
and
wxUninitialize()
So the fixed version of my code is as follows:
#include <wx/app.h>
#include <wx\filename.h>
int main()
{
wxInitialize();
wxFileName::Mkdir("Waka Waka");
wxUninitialize();
return 0;
}
I suggest if anyone is using wxWidgets purely for the file management to either call these functions in the constructor and destructor of whatever class handles files, or at the beginning and end of your program's main loop.
I am working on client server application where I need to send the command read from the script file .
The format of the script file is as follows.
CONNECT <www.abcd.com,80>
SEND : AB 40 01 FF 00 00 00 09 01 01 07 00 00 C0 A8 01 87 AE
MATCH<s,10>: AB 40 01 FF 00 00 00 09 01 01 07 00 00 C0 A8 01 87 AE
SEND : AB 34 01 FF00 00 00 0C 01 01 07 00 01 01 07 00 FF FF FF FF AE
DISCONNECT
note: s in match is wait time in seconds.
here second byte is Msg ID.
When it encounter Match Command the Program should wait for match for specified second and then proceed to next command.
I have two thread running in the application
Listener Thread- it will receive data from server.(select() is used here)
it will be launched when the program encounter the connect command and goes off when
encounter disconnect in config.
main thread which will read command from the config file and execute.
Now when match is encounter main thread should send the match string to the
Listener Thread for matching and wait there for signal from Listener Thread.
The Listener Thread will match the string with data received from the server if it matches it will single the event(SetEvent() windows) to main thread and then main thread will log "Match found" other wise if time is elasped then it will log as "Match not found"
I thought of having a global variable char* g_MatchString.The main thread will update this variable whenever there is match command and wait for event(windows event) to be singled and the wait time will be equal to match time.
I need input from you guys whether my approach is correct or not.
Don't use a global. That just creates the potential for race conditions when someone adds complexity in the future. The match string should be passed to the thread as an input argument. You don't say how you're launching the thread, but if you're using _beginthread() you simply allocate a buffer and pass it to _beginthread() in the arglist parameter. When the listener thread terminates, the main thread can safely free the match string buffer. This keeps it nicely self-contained and free of potential race conditions if additional threads are ever added. If you're launching the thread with CreateThread(), you would pass it via the lpParameter parameter.
Other than the global, I think your approach is sound.
Since the main thread is waiting on the listener thread, and the listener thread's sole purpose is to read inbound data, I would suggest just getting rid of the listener thread altogether and let the main thread do the reading directly.