memcmp multiple BYTEs, not finding address [duplicate] - c++

This question already has an answer here:
SizeOfImage member causing program crash
(1 answer)
Closed 9 years ago.
Im trying to memcmp multiple BYTE's from ASM Instructions but my scanner keeps coming up with nothing. The returning value from my function indicates that the BYTEs are not being found.
Called with
const BYTE Pattern[] = {0x33,0xC0,0xF2,0xAE};
DWORD Address = FindPattern(Pattern,sizeof(Pattern));
Function(Shortend)
DWORD FindPattern(const BYTE* Pattern,SIZE_T PatternSize)
{
...
for(int i = 0;i < (ModuleSize - PatternSize);i++)
{
if(memcmp((void*)(ModuleBase + i),Pattern,PatternSize) == 0)
return ModuleBase + i;
}
return 0;
}

As I replied in your previous similar question, you code worked perfectly fine when i ran it. I tested it against the previous FindPattern function i was using, and both returned the same exact results.
Make sure you have the correct pattern. Its not your function that is failing, its simply not finding what you are looking for.

Related

How does .Byte[] function on a specific byte? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I am working on the following lines of code:
#define WDOG_STATUS 0x0440
#define ESM_OP 0x08
and in a method of my defined class I have:
bool WatchDog = 0;
bool Operational = 0;
unsigned char i;
ULONG TempLong;
unsigned char Status;
TempLong.Long = SPIReadRegisterIndirect (WDOG_STATUS, 1); // read watchdog status
if ((TempLong.Byte[0] & 0x01) == 0x01)
WatchDog = 0;
else
WatchDog = 1;
TempLong.Long = SPIReadRegisterIndirect (AL_STATUS, 1);
Status = TempLong.Byte[0] & 0x0F;
if (Status == ESM_OP)
Operational = 1;
else
Operational = 0;
What SPIReadRegisterInderect() does is, it takes an unsigned short as Address of the register to read and an unsigned char Len as number of bytes to read.
What is baffling me is Byte[]. I am assuming that this is a method to separate some parts of byte from the value in Long ( which is read from SPIReadRegisterIndirect ). but why is that [0]? shouldn't it be 1? and how is that functioning? I mean if it is isolating only one byte, for example for the WatchDog case, is TempLong.Byte[0] equal to 04 or 40? (when I am printing the value before if statement, it is shown as 0, which is neither 04 nor 40 from WDOG_STATUS defined register.)
Please consider that I am new to this subject. and I have done google search and other searchs but unfortunatly I could not found what I wanted. Could somebody please help me to understand how this syntax works or direct me to a documentation where I can read about it?
Thank you in advance.
Your ULONG must be defined somewhere.
Else you'd get the syntax error 'ULONG' does not name a type
Probably something like:
typedef union {unsigned long Long; byte Byte[4];} ULONG;
Check union ( and typedef ) in your C / C++ book, and you'll see that
this union helps reinterpreting the long variable as an array of bytes.
Byte[0] is the first byte. Depending on the hardware (avr controllers are little endian) it's probably the LSB (least significant byte)

C++ UndefinedBehaviorSanitizer:DEADLYSIGNAL [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am trying to solve a problem for code wars, but my code gives an error. I've tested the code on code blocks and it works, but when I test it on their website it gives me some strange error. I looked it on the internet and found out that it might be a segmentation fault because of a deref of a null pointer, but I dont know how to fix it. This is my code and the error. Can you tell me plase what is the problem and why it works on code block, but on the compiler on the website it doesn't.(P.S. Please excuse my english, Im from Romania).
#include <iostream>
#include <vector>
#include <bits/stdc++.h>
using namespace std;
long queueTime(std::vector<int> costumers, int n) {
vector<int> q;
int j, x;
long t;
for (j = 0; j < n; j++)
q.push_back(costumers[j]);
int u = costumers.size();
while (j <= u) {
x = *min_element(q.begin(), q.end());
t = t + x;
for (int i = 0; i < n; i++) {
q[i] = q[i] - x;
if (q[i] == 0) {
q[i] = costumers[j];
j++;
}
}
}
t += *max_element(q.begin(), q.end());
return t;
}
Error message:
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==1==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000042547b bp 0x000000000000 sp 0x7ffec8fa0510 T1)
==1==The signal is caused by a READ memory access.
==1==Hint: address points to the zero page.
==1==WARNING: invalid path to external symbolizer!
==1==WARNING: Failed to use and restart external symbolizer!
#0 0x42547a (/workspace/test+0x42547a)
#1 0x427ffc (/workspace/test+0x427ffc)
#2 0x42686e (/workspace/test+0x42686e)
#3 0x426435 (/workspace/test+0x426435)
#4 0x42609b (/workspace/test+0x42609b)
#5 0x42aad5 (/workspace/test+0x42aad5)
#6 0x42581d (/workspace/test+0x42581d)
#7 0x7fc90f605b96 (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#8 0x404489 (/workspace/test+0x404489)
UndefinedBehaviorSanitizer can not provide additional info.
==1==ABORTING
SEGV would indicate that there is a segmentation fault happening somewhere so you are on the right track with your debugging. Looking at the code you have provided there are few tips that might help you narrow down where things are going wrong.
The first thing that sticks out is that seem to be taking a local copy of costumers on this line:
for (j = 0; j < n; j++) q.push_back(costumers[j]);
Here you make the assumption that n is less or equal to costumers.size() and if n is larger than this then this will try to read from beyond the end of the vector. An alternative here is to use the = operator instead:
vector<int> q = costumers;
If you actually only wanted the first n elements of costumers copied to q then you could use:
if(n < q.size()){
q.resize(n);
}
to shrink it to size afterwards.
Another general style point is that it is good practice to something called "Resource allocation is initialization" (RAII): at the top of your queueTime function you have a bunch of variables declared but not initialized to values:
int j, x;
long t;
The problem here is that these will often be initialized to junk values and if you forget to initialize them later then you may be reading these junk values without knowing. Try instead to declare the variable at the point in the code you assign a value to it, eg fo j:
for(int j = 0; ... )
and x
int x = *min_element(q.begin(), q.end());
or in the case where you need t everywhere in the function scope, at least assign an initial value when you declare it
long t = 0;
Finally when using algorithms that return iterators it is generally good practice to check that they are valid before dereferencing them ie. writing:
auto itr_min_elem = min_element(q.begin(), q.end());
if(itr_min_elem == q.end()){
continue;
}
int x = *itr_min_elem;
so that if q is empty and min_element returns an end iterator then you don't try to dereference it.
Sorry for the wall of text but I hope these offer some help for debugging your function.
As a general note to your question about why it was working on code blocks but not on the website could come down to a number of reasons, likely related to how the code is being compiled. Some compilers will initialize memory to 0s in debug builds and this can have the effect of uninitialized variables behaving nicely in debug but in an undefined way in release. Also depending on the environment the code is executed in there may be differences in the memory layout so reading past the end of an array in one environment may just give junk while in another you may be indexing into protected memory or outside of your programs allocated memory. This would cause the platform running your code to be very unhappy and force it to abort.

C++ DLL Memory Reading Crashes

I've been trying all day how to read properly the memory of a game with my injected DLL, it works correctly but if the DLL reach other type of variable which is not "float" then it crashes. My question is, how can I detect if is float and avoid crashes. Here is my code:
for (DWORD i = 0x1000000; i < 0x2FFFFFF; i += 0x4)
{
DWORD Base = *(DWORD*)(base + i);
DWORD lvl_2 = *(DWORD*)(Base + 0x8);
float* posx = static_cast<float*>((float*)(lvl_2 + 0x90));
Position_x = static_cast<float>(*posx);
if (Position_x > 7.05f && Position_x < 7.20f) //test > 7.05f && test < 7.20f || i == 0x2217710
{
fprintf(file, "Pointer: 0x%x Position x: %.2f \n", i, Position_x);
}
}
This is a scanner I made to update pointer of a game knowing the structs offsets. This code works correctly if I use as condition i == 0x2217710, it returns the correct position x of the player. If I remove the condition it crashes due to the line Position_x = static_cast... is converting other type of variable in float which is illegal for some variables. How could I do this? Thanks in advance.
First, I'm pretty sure the problem isn't that it crashes when you have a pointer that isn't to a float. All binary values 0 - 0xFFFFFFFF are generally valid as float values, but some are "special", such as "not a number" - but as long as you only compare the value, etc, it will work just fine to use such values too - will just come out as false in the comparison.
Your actual problem is that you are making a pointer from base+i, and then using the content at that location as another pointer - but if base+i does not hold a valid pointer {which is pretty much most 32- or 64-bit values in most systems}, then your next fetch will go wrong. Unfortunately, there is no trivial way to check if a memory address is valid or not. In Windows, you could possibly use __try, __except to catch when you are trying to read an invalid memory address and "do something else".

Why can array cells exceed array length [duplicate]

This question already has answers here:
Accessing an array out of bounds gives no error, why?
(18 answers)
Closed 7 years ago.
While debugging I found an error with an int array of 0. In a test document I messed around with array with more cell input than their length.
int array[0];
for(int i = 0; i < 10; i++)
array[i] = i;
for(int i = 0; i < 10; i++)
cout << array[i];
After I compiled and ran the program I got
0123456789
Then I received the message "test.exe has stopped working". I expected both of these, but what I am confused about is why the compiler lets me create an array of 0, and why the program doesn't crash until the very end of the program. I expected the program to crash once I exceeded the array length.
Can someone explain?
The compiler should have at least warned you about a zero size array - if it didn't .. consider changing compiler.
Remember that an array is just a bit of memory just like any other. In your example the array is probably stored on the stack and so writing off the end of it may not cause much of a problem until your function exits. At that point you may find you have written some text over the return address and you get an exception. Writing off the end of arrays are a common cause of bugs in C/C++ - just be thankful you got an error with this one and it didn't just overwrite some other unrelated data.

memset sets random values [duplicate]

This question already has answers here:
Why does "memset(arr, -1, sizeof(arr)/sizeof(int))" not clear an integer array to -1?
(6 answers)
Closed 8 years ago.
Here is the code:
#include <iostream>
#include <cstring>
int main()
{
int win[11];
std::memset(win, 1, sizeof(win));
for (int i = 0; i < 11; ++i)
std::cout << win[i] << ' ';
std::cout << std::endl;
return 0;
}
I think there is no logic flaw here? But instead of getting a string of 1 printed, I got 16843009.
If I change the memset to std::memset(win, 0, sizeof(win)). Then everything is as expected. The content of win is all zeros.
Am I missing something here?
I'm using g++ 4.7.3 on Ubuntu 13.04.
Sorry for this duplicated question.
Here is the answer. Thanks
Why does "memset(arr, -1, sizeof(arr)/sizeof(int))" not clear an integer array to -1?
ints are usually four bytes long. But memset sets the value of individual bytes, so you're setting each value to 0x01010101, which just so happens to equal 16843009.
The memset function writes over memory without understanding its structure in any way. If you write a bunch of random 1's all over an accounting report, will that make the report show that the company has spent $1? I don't think so. Maybe it will show 111111 dollars. Maybe not. Who knows.
To modify an object's value intelligently, you have to understand its structure. The memset function does not understand the structure of win and just scribbles 1 all over its bytes. What that means, memset does not know or care.