DWORDLONG index = ((((DWORDLONG) i.nFileIndexHigh) << 32) | i.nFileIndexLow);
Given index, I want to find out what the components of i.fileindexhigh and i.fileindexlow are. Is it possible? A general idea would be helpful.
Yes, its possible, you just need to do the inverse operation of what you posted: instead of << and |, >> and &,
nFileIndexLow = index & 0x00000000FFFFFFFF;
nFileIndexHigh = index >> 32;
Consider researching on bitwise operations, or at least put your calculator in hexadecimal/binary mode and play with masks and shifts.
i.nFileIndexHigh == index >> 32;
i.nFileIndexLow == index & 0x00000000FFFFFFFF;
Related
I came across an algorithm that uses a lot of XOR shift like so:
std::uint16_t a = ...
std::uint16_t b = a ^ ( a >> 4 )
I read XOR is used for all kind of good stuff, like finding parity, determining odd/even counts etc. So I'm wondering: Does this operation (on its own) have a certain meaning? Is it a common pattern? Or is it just unique to this algorithm?
No I'm not talking about THE xorshift pseudo-number algorithm.
Let's take a look at what it produces given input 0xIJKL:
0xIJKL
^ 0x0IJK
--------
0xI???
Doesn't seem very meaningful to me by itself, but this pattern seems to be used as a sub step in many parity bit twiddles. For example, a twiddle for calculating parity bit of a word (from https://graphics.stanford.edu/~seander/bithacks.html):
unsigned int v; // word value to compute the parity of
v ^= v >> 16;
v ^= v >> 8;
v ^= v >> 4;
v &= 0xf;
return (0x6996 >> v) & 1;
I've a 8-digit BCD number and need to check it out to see if it is a valid BCD number. How can I programmatically (C/C++) make this?
Ex: 0x12345678 is valid, but 0x00f00abc isn't.
Thanks in advance!
You need to check each 4-bit quantity to make sure it's less than 10. For efficiency you want to work on as many bits as you can at a single time.
Here I break the digits apart to leave a zero between each one, then add 6 to each and check for overflow.
uint32_t highs = (value & 0xf0f0f0f0) >> 4;
uint32_t lows = value & 0x0f0f0f0f;
bool invalid = (((highs + 0x06060606) | (lows + 0x06060606)) & 0xf0f0f0f0) != 0;
Edit: actually we can do slightly better. It doesn't take 4 bits to detect overflow, only 1. If we divide all the digits by 2, it frees a bit and we can check all the digits at once.
uint32_t halfdigits = (value >> 1) & 0x77777777;
bool invalid = ((halfdigits + 0x33333333) & 0x88888888) != 0;
The obvious way to do this is:
/* returns 1 if x is valid BCD */
int
isvalidbcd (uint32_t x)
{
for (; x; x = x>>4)
{
if ((x & 0xf) >= 0xa)
return 0;
}
return 1;
}
This link tells you all about BCD, and recommends something like this asa more optimised solution (reworking to check all the digits, and hence using a 64 bit data type, and untested):
/* returns 1 if x is valid BCD */
int
isvalidbcd (uint32_t x)
{
return !!(((uint64_t)x + 0x66666666ULL) ^ (uint64_t)x) & 0x111111110ULL;
}
For a digit to be invalid, it needs to be 10-15. That in turn means 8 + 4 or 8+2 - the low bit doesn't matter at all.
So:
long mask8 = value & 0x88888888;
long mask4 = value & 0x44444444;
long mask2 = value & 0x22222222;
return ((mask8 >> 2) & ((mask4 >>1) | mask2) == 0;
Slightly less obvious:
long mask8 = (value>>2);
long mask42 = (value | (value>>1);
return (mask8 & mask42 & 0x22222222) == 0;
By shifting before masking, we don't need 3 different masks.
Inspired by #Mark Ransom
bool invalid = (0x88888888 & (((value & 0xEEEEEEEE) >> 1) + (0x66666666 >> 1))) != 0;
// or
bool valid = !((((value & 0xEEEEEEEEu) >> 1) + 0x33333333) & 0x88888888);
Mask off each BCD digit's 1's place, shift right, then add 6 and check for BCD digit overflow.
How this works:
By adding +6 to each digit, we look for an overflow * of the 4-digit sum.
abcd
+ 110
-----
*efgd
But the bit value of d does not contribute to the sum, so first mask off that bit and shift right. Now the overflow bit is in the 8's place. This all is done in parallel and we mask these carry bits with 0x88888888 and test if any are set.
0abc
+ 11
-----
*efg
Right, so I'm trying to keygen this program from crackmes.de
http://crackmes.de/users/lutio/keygenme1_by_lutio/
I'm not asking someone to do this for me, I'm just asking if its possible without brute forcing.
I normally don't have trouble with such things, but for some reason this user doesn't use any variables from the username, only the serial. He also says that brute forcing isn't allowed to solve his keygen. I believe that it is impossible to solve without brute forcing.
Does someone actually know if its possible to solve without bruteforcing? This is basically the code I have:
unsigned int key = 0x1FE339E4; //compute == this for success
unsigned int serialvar = unknown; //gennerated according to serial
unsigned int magic1 = 0x1FE339E7;
for( int i = 0; i < 0x10; i++ ) {
serialvar = (((magic1 * i + serialvar) << 0x10) ^ serialvar) + 0x13371337;
serialvar = (((i * magic1 + serialvar) >> 0x10) ^ serialvar) + 0x73317331;
}
unsigned int computed = 0;
for( int i = 0; i < serialvar; i++ ) {
computed += 0x3C;
}
Right, so at the end of the code, in order to succeed and hit the "goodboy" our unsigned int computed has to be equal to key.
As we know, the "serialvar" is the unknown variable that I have to generate. (Which I will then generate a serial based off of)
At my level of mathematics and boolean algebra, I believe that this equation is impossible to solve.
Now I'm not exactly sure if this math statement is correct... But if I take key and divide it by 0x3C... I don't get an integer!
Doesn't this sort of mean it is impossible to solve? Since key / 0x3C has no integer solution?
if I understand that correctly, you have the final value of computed and you want to know the value of unknown...
first of all you have to solve the equation:
computed = serialvar x 0x3C (mod 2^32)
there you may get multiple values of serialvar.
after that you have to reverse the 16 fold loop..
I don't see any simple way how to solve (((i * magic1 + serialvar) >> 0x10) ^ serialvar) and the other expression for serialvar.
The top 16 bits of serialvar are not changed because >> will make it xor against zeros.
bottom half may be computed by precalculated array. There will probably be multiple solutions (which is very probbable) and your computation will split.
The same with bottom half will hold for the second expression.
This way the total computation expenses will be similar to bruteforcing.
So I have 3 numbers. One is a char, and the other two are int16_t (also known as shorts, but according to a table I found shorts won't reliably be 16 bits).
I'd like to concatenate them together. So say that the values of them were:
10010001
1111111111111101
1001011010110101
I'd like to end up with a long long containing:
1001000111111111111111011001011010110101000000000000000000000000
Using some solutions I've found online, I came up with this:
long long result;
result = num1;
result = (result << 8) | num2;
result = (result << 24) | num3;
But it doesn't work; it gives me very odd numbers when it's decoded.
In case there's a problem with my decoding code, here it is:
char num1 = num & 0xff;
int16_t num2 = num << 8 & 0xffff;
int16_t num3 = num << 24 & 0xffff;
What's going on here? I suspect it has to do with the size of a long long, but I can't quite wrap my head around it and I want room for more numbers in it later.
To get the correct bit-pattern as you requested, you shoud use:
result = num1;
result = (result << 16) | num2;
result = (result << 16) | num3;
result<<=24;
This will yield the exact bit pattern that you requested, 24 bits at the lsb-end left 0:
1001000111111111111111011001011010110101000000000000000000000000
For that last shift, you should only be shifting by 16, not by 24. 24 is the current length of your binary string, after the combination of num1 and num2. You need to make room for num3, which is 16 bits, so shift left by 16.
Edit:
Just realized the first shift is wrong too. That should be 16 also, for similar reasons.
Yes you are overflowing the value that can be stored in long. You can use a arbitrary precison library to store the big number like the GMP.
If I understand correctly what you are doing, I would use:
result = num1;
result = (result << 16) | num2;
result = (result << 16) | num3;
num1out = (result >> 32) & 0xff;
num2out = (result >> 16) & 0xffff;
num3out = result & 0xffff;
The left shift during building is by the width of the next number to insert. The right shift on extraction is by the total number of bits the field was left shifted during building.
I have tested the above code. long long is wide enough for this task with the g++ compiler, and I believe many others.
Im trying to find the most efficient algorithm to count "edges" in a bit-pattern. An edge meaning a change from 0 to 1 or 1 to 0. I am sampling each bit every 250 us and shifting it into a 32 bit unsigned variable.
This is my algorithm so far
void CountEdges(void)
{
uint_least32_t feedback_samples_copy = feedback_samples;
signal_edges = 0;
while (feedback_samples_copy > 0)
{
uint_least8_t flank_information = (feedback_samples_copy & 0x03);
if (flank_information == 0x01 || flank_information == 0x02)
{
signal_edges++;
}
feedback_samples_copy >>= 1;
}
}
It needs to be at least 2 or 3 times as fast.
You should be able to bitwise XOR them together to get a bit pattern representing the flipped bits. Then use one of the bit counting tricks on this page: http://graphics.stanford.edu/~seander/bithacks.html to count how many 1's there are in the result.
One thing that may help is to precompute the edge count for all possible 8-bit value (a 512 entry lookup table, since you have to include the bit the precedes each value) and then sum up the count 1 byte at a time.
// prevBit is the last bit of the previous 32-bit word
// edgeLut is a 512 entry precomputed edge count table
// Some of the shifts and & are extraneous, but there for clarity
edgeCount =
edgeLut[(prevBit << 8) | (feedback_samples >> 24) & 0xFF] +
edgeLut[(feedback_samples >> 16) & 0x1FF] +
edgeLut[(feedback_samples >> 8) & 0x1FF] +
edgeLut[(feedback_samples >> 0) & 0x1FF];
prevBit = feedback_samples & 0x1;
My suggestion:
copy your input value to a temp variable, left shifted by one
copy the LSB of your input to yout temp variable
XOR the two values. Every bit set in the result value represents one edge.
use this algorithm to count the number of bits set.
This might be the code for the first 3 steps:
uint32 input; //some value
uint32 temp = (input << 1) | (input & 0x00000001);
uint32 result = input ^ temp;
//continue to count the bits set in result
//...
Create a look-up table so you can get the transitions within a byte or 16-bit value in one shot - then all you need to do is look at the differences in the 'edge' bits between bytes (or 16-bit values).
You are looking at only 2 bits during every iteration.
The fastest algorithm would probably be to build a hash table for all possibles values. Since there are 2^32 values that is not the best idea.
But why don't you look at 3, 4, 5 ... bits in one step? You can for instance precalculate for all 4 bit combinations your edgecount. Just take care of possible edges between the pieces.
you could always use a lookup table for say 8 bits at a time
this way you get a speed improvement of around 8 times
don't forget to check for bits in between those 8 bits though. These then have to be checked 'manually'