The keys for your three messages appear to be cf7810d22, 42096edac and 4ea34873a respectively. (Note: those are 9-byte ASCII text strings, not hex numbers, even though clearly all the characters appear to be hex digits!)
OK, so how did I figure that out?
First, before even looking at the code you posted, I just took the messages from your hex dump, ...
The gzip headers are valid, but the deflate compressed data format is violated almost immediately, within less than ten bytes in for all of the files.
For all of the example files provided, the first deflate block is a dynamic block which has an oversubscribed code lengths code. That means that a Huffman code required to decode the code lengths for that ...
In C, this function would look like this:
// some code you haven't pasted here; probably scanf("%d", &a);...
a ^= 3; // xor a with 3
a ^= 2; // xor a with 2
printf("a = %d.\n", a);
I cannot say anything more about it having only the snipped you shared with ...
Well thanks to @IgorSkochinsky's suggestion, I found a disassembler for the Blackfin architecture in the pf0camino/cross-bfin-elf Docker image. Being in Docker meant it was easy to run and I didn't have to mess around with installing cross compilers myself. I was then able to disassemble the image with this command:
bfin-elf-objdump -D -b binary -mbfin ...
It is just addition/subtraction (mod 256).
# These key bytes are the two's complement of the hex sequence mentioned in the question.
# The string appears twice in the decrypted blob, which makes me think it's what is used.
key = [ord(n) for n in "llp_owon"]
with open("AFG1022_V1.2.4.tfb", "rb") as infile:
data = infile.read()
From type == 0 you see that it writes to param_3 and reads from param_4. So those parameters must be pointers to output and input buffers respectively. In fact, if you change them to correct type (byte *), then I believe Ghidra should be able to simplify the rest of the code to easily understandable form.
The part that modifies param_2 is a simple pseudo-...
Here's your code with names given to most variables. That's quite a bit of code so I'll try to only iterate the important parts. I also added a few comments in the code to help reading, although I didn't try to cover all code with comments. Make sure you go over the named parameters, I believe those will help you understand the code quickly. Viewing the code ...
No scripting required.
In OllyDbg's disassembly window, left-click on line .text:00403855 32 C3 xor al, bl to select the line, then right-click on the selected line and choose Breakpoint → Conditional log....
In the breakpoint dialog box that opens up, use the following options:
Press OK, run the program, and every time .text:00403855 32 ...
The number returned by _atol() is XOR'ed with 0x28C and then XOR'ed again with 0x1104. Since XOR is an associative operation, this is equivalent to XOR'ing the number returned by _atol() with 0x1388.
a) Is that a way of encryption ? I mean, is it so that they try to
encrypt the string pointed by lpCmdLine?
There's not enough context in your snippet ...
What may be confusing you is the fact that memory on x86 processors uses little-endian layout. The four bytes 31 32 31 32, when interpreted as a 4-byte integer (dword), become 0x32313231. If we perform xor operation on it:
And putting 0x33127756 back into little-endian memory order we get:
56 77 12 33
As you have just started into RE, try looking into SAT solvers. Z3 is a great tool that will help you in such simple tasks with APIs in all major languages. Here is a solution I tried in python.
password = BitVec("password",64)
magicValuePass = BitVec("magicValuePass",64)
s = Solver()
idx = 7
magicValuePass = (((password&(0xff<<(8*idx)))>>(...
When it comes to break some encrypted texts, you have to take a few hypothesis and check it with caution (it may make you loose a lot of time... believe me).
The first Base64 decoding seems to be quite promising and lead to some hexadecimal blob that you should analyze first before trying to step further.
I would advise you to make a frequency analysis of ...
While there's no way to know with 100% certainty what was the original value before the AND operation, you can find some possible values producing the same result, and sometimes that's enough.
Basically, for x & N = z, you can start from z and set any bits to 1 where you have are 0 in N. z itself will always work too.
For example, if we know that x &...
The data appears to be a lookup table to support the functions in the C library header <ctype.h>
Specifically, the bit-field values being used here represent, for each character -
0x01 => Upper Case
0x02 => Lower Case
0x04 => Digit
0x08 => Space
0x10 => Punctuation
0x20 => Control
0x40 => Blank
0x80 => Hex Digit
These values ...
How about generating many logins from a password?
To start, algorithm 1 looks like the weakest link. Algorithm 2 is a one directional hash function and there's no way you can extract the characters by only knowing the magic number and the password bias. It involves some advanced math work and time. I explain the process of breaking Algorithm 2 in the second ...
The command you refer to is a good example for CISC architectures:
XOR DWORD PTR DS:[ECX+EAX],1234567
This first add the values of ECX and EAX, then interprets the sum as a memory address and xors the value at that location with 1234567
Also, please note that the EAX register is always 4-byte sized. For less bytes, you may use ax, al or ah and for higher (...
Use dd to extract the data what you need, e.g. (using bash syntax):
dd if=foo.dat bs=1 skip=$((0x88)) count=$((0x80)) of=xorkey.bin
dd if=foo.dat bs=1 skip=$((0x108)) of=data1.bin
Then convert it using simple Python code:
def str_xor(data, key):
for i in range(len(data)):
data[i] ^= key[i % len(key)]
The code between 80484c5 and 80484ce sets up the stack canary, and 80484e7 to 80484f3 checks it. gcc omits the stack checking from your second function, since it can determine (uses no pointers, doesn't call subroutines) that there's no way to overwrite the stack here. Your xor eax, eax isn't neccesary per se (you don't need to zero registers before storing ...
It is almost impossible to provide any meaningful help here.
upload the actual executable,
or run it on a virtual machine on your side (log everything using strace),
or upload more of those strings to see if there is a pattern.
This looks like it could be some hash over the original filename, and because they have 32 characters in length, it's likely to be a md5 hash. Or, it might be one of the sha* variants, cut after 32 characters.
If you have access to a linux system, you could try something like
$ echo -n 'introduction.ogg' | md5sum
and if ...