I solved a simple bruteforce XOR challenge using cyberchef.
Of course, I wanted more and build a script that do it.
The script should perform XOR test against a specific string.
I don't understand how to manipulate binary in python and this is my issue so far.
ciph = "q{vpln'bH_varHuebcrqxetrHOXEj"
for decim in range(256):
print(decim, ": ", ''.join([chr(ord(char) ^ decim) for char in ciph]))
Of course 'decim' is not a bit so it's not working properly.
I have read stuff about bytearray but no sure how to handle it and if it's relevant here.
Any idea?
Well, my bad, it is working well.
The flag is there but not at the same position as Cyberchief indicated because it performed a XOR bruteforce with Hexadecimal key.
Here I'm doing a XOR bruteforce with Decimal key, so yeah of course the flag is not at the same position ...
Related
Python version 3.8.10
I don't understand what's going on here. I input the following bytestring and it gives a different value on print.
packet = b'\x02\x00\x00\x00\x08\x35\x03\x19\x01\x00\x01\x00\x00'
print(packet) #result b'\x02\x00\x00\x00\x085\x03\x19\x01\x00\x01\x00\x00'
Same thing when using bytearray.
packet = bytearray()
packet.append(2)
...
packet.append(0)
print(packet) #result bytearray(b'\x02\x00\x00\x00\x085\x03\x19\x01\x00\x01\x00\x00')
I know Python handles strings in a specific encoding, but I think that shouldn't matter given the way I input the bytes (not a string). I considered the print function sees the \x3 and evaluates as ASCII, but that makes no sense for this case (for my understanding anyway).
I really just want to understand what's going on. I searched other posts (Google too) and was not able to find a similar situation. Most other posts were from incorrectly handling encode() and decode() for their ASCII values, or issues when packing bits/bytes, which is obviously not the same situation here.
Thanks in advance.
It's the same string/bytes/data anyway. What's the difference here?
b'\x02\x00\x00\x00\x08\x35\x03\x19\x01\x00\x01\x00\x00'
b'\x02\x00\x00\x00\x08 5\x03\x19\x01\x00\x01\x00\x00'
Evidently, b'\x35' == b'5'.
Indeed, 0x35 is the ASCII code for the character '5':
>>> b'\x35'
b'5'
I got a small problem: that I want to split a float variable into parts and then compute these parts (add / subtract etc.). My main problem is that I don't know how to get that splitted parts/variables from the float type variable. I want to operate on those parts using rax / eax registers and b,c,d etc.
Is there somebody who can help me to acquire some knowledge about this and eventually lead me to some code that can do the trick? One restriction of mine is: I can't operate on FPU commands.
As part of my project, I have to insert small codes in a C program called checksum guards. What these guards do is they calculate the checksum value of a portion of code using a function(add, xor, etc.) which operates on the instruction opcodes. So, if somebody has tampered with the instructions(add, modify, delete) in that region of code, the checksum value will change and intrusion will be detected.
Here is the research paper which talks about this technique:
https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/2001-49.pdf
Here is the guard template:
guard:
add ebp, -checksum
mov eax, client_addr
for:
cmp eax, client_end
jg end
mov ebx, dword[eax]
add ebp, ebx
add eax, 4
jmp for
end:
Now, I have two questions.
Would putting the guards in the assembly better than putting it in the source program?
Assuming I put them in the assembly(at an appropriate place) what kind of obfuscation should I use to prevent the guard template to be easily visible? (Since when I have more than 1 guard, the attacker should not easily find out all the guard templates and disable all the guards together as that would leave the code with no security)
Thank you in advance.
From attacker's (without sources) point of view the first question doesn't matter; he's tampering with the final binary machine code, whether it was produced from .c or .s will make zero difference. So I would worry mainly how to generate the correct binary with appropriate checksums. I'm not aware of any way how to get proper checksum inside the C source. But I can imagine to have some external tool running over assembler files created by C compiler, in some post-process way - before compiling the .s files into .o. But... Keep in mind, that some calls and addresses are just relative offsets, and the binary loaded into memory is patched by the OS loader according to linker's table, to make those point to the real memory addresses. Thus the data bytes will change (opcodes will stay fixed).
Yours guard template doesn't take that into account, and does checksum whole opcodes with data bytes as well (Some advanced guards have opcodes definitions, and checksum/encrypt/decipher only the opcodes themselves without operand bytes).
Otherwise it's neat, that the result is damaged ebp value, ruining any C code around (*) working with stack variables. But it's still artificial test, you can simply comment out both add ebp,-checksum and add ebp,ebx making the guard harmless.
(*) notice you have to put the guard in between some classic C code to get some real runtime problems from invalid ebp value. If you would put it at the end of subroutine, which ends with pop ebp, everything would work well.
So to the second question:
You definitely want more malicious ways to guard correct value, than only ebp damage. Usually the hardest (to remove) way is to make checksum value part of some calculation, eventually skewing results just slightly, so serious usage of the SW will be impossible, but it will take time to notice by the user.
You can also use some genuine code loop to add your checksumming to it, so simply skipping whole loop will skip also valid code (but I can imagine this one only added by hand into generated assembly from C, so you will have to redo it after every new compilation of particular C source).
Then the particular guard template can be obfuscated by any imaginable mutation (different registers used, modified order of instructions, instruction variants), try to search about viruses with mutation encoding to get some ideas.
And I didn't read that paper, but from the Figures I would say the main point is to make those guarding areas to overlap, so patching off one of them will affect another one, which sounds to me like that extra sugar to make it somewhat functional (although this still looks like normal challenge to 8bit game crackers ;), not even "hard" level). But that also means you would need either very cunning external tool to calculate that cyclic tree of dependencies, and insert the guard templates in correct order, or do it again manually completely.
Of course when doing manually, you have to do it after each new C compilation, so it's worth of the effort only on something very precious and expensive, or rock solid stable, where you will not produce another revision for next 10y or so... :D
It is possible to get the key used to encrypt a secuence of characters using xor?
Example
Lets say that I Have the following string: 1456, so:
1 - 49 ascii - 00110001 binary
4 - 52 ascii - 00110100 binary
5 - 53 ascii - 00110101 binary
6 - 54 ascii - 00110110 binary
Key: 100
Then I do the following: 1 ^ 100 (talking in binary: 00110001 ^ 01100100), and get the following result: "UPQR", how do I know that I used the key 100 in xor to encrypt "1456" getting "UPQR" as the result.
Thanks in advance!
If you know both the original and the encoded sequence, then for each component it must be that
original[i] ^ encoded[i] == key
If you don't know the original content, then you would have to try with each possible key and see if the results makes any sense (for some definition of sense).
Note Wikipedia's comment about XOR cipher
By itself, using a constant repeating key, a simple XOR cipher can trivially be broken using frequency analysis.
Though if the key is the size of the message (and random, and used only once), you have a one-time pad. That's just unbreakable, period. Though it is too cumbersome for most to use.
If you're in a position of code-breaking, then you should definitely check out Sinkov's Elementary Cryptanlysis and Gaines's Cryptanalysis: A Study of Ciphers and Their Solution. Both of these books go into good depth on key recovery for a Vigenère Cipher, which is fairly similar to a sequential application of XOR operations.
I am trying to learn how to convert a string to an integer. I think I am pretty close. My code works for numbers under 260. Once the numbers entered are greater than or equal to 260, then it just converts them to 0. I think it might have something to do with the size of a BYTE, but I'm not sure how to fix it. Any suggestions?
Some Irvine functions are included, but I'm trying to write my own ReadInt function.
I can see the problem. Rather than giving away the answer completely, here's a hint:
The lodsb instruction loads one byte into al (which is the low 8 bits of eax). The rest of eax is unchanged. What might cause eax to contain extra bits that aren't changed by lodsb?