I am supposed to decode this string: IConIT0xdSoldit1GTJ2GTIudRkxdigidTQgMyoZMXY0KiIZdiAZJTQ/NjJ2Zzs=
I first recognize that this is in base64 format, so i decode it to hex and get 202a27213d31752a25762b7519327619322e751931762822753420332a193176342a221976201925343f363276673b.
Then I tried using this solution to decipher the text but it isn't working.
I've been stumped for days trying to figure this out. Can anyone provide me with a clue as how to proceed with this?
You're on the right track. The decrypted string has some unusual properties, and you're unlikely to be able to detect it with frequency analysis. You can narrow down the possibilities a little by considering the range that the XORed characters will end up in, but the easiest approach will be to just try them all and print the results.
The correct XOR key is between 0x40 and 0x5f.
Related
My question is: Is there a reliable way to detect if a hex / base64 string is actually encrypted, or just encoded?
(I did a quick search but I only seem to find whats the difference between encryption and encoding none seems to say how to detect encryption in general...)
I don't need to know what kind of encryption it is, just detect whether it is encrypted or not and send error if not encrypted, thus enforce encryption.
String size may vary from couple of bytes to kilobytes...
Is there a C/C++ library available for that?
If you think you're working with encoded/encrypted plaintext, the most obvious thing to do would be to try and decode with various standard encodings, and see if what you get back looks like plain English, or at least what you're looking for.
Beyond that, there's a few things you could try:
If you had a perfectly encrypted string, it would be indistinguishable from random noise, so if you can see significant correlations in your string, you probably have imperfectly encrypted data, or straight up encoded plaintext.
To find this, you can find the "Index of Coincidence" for the string, or look for repeated blocks of code. If you find repeats, it's either unencrypted, or, if the repeats are multiples of 16 bytes (or another suitable block length) long, then it might be ECB encoded (i.e. with the same 16 bytes key repeated through the data).
I would say your best bet would be to see how random your string is, if it's really hard to find correlations, then it's probably well encrypted. If the same bits of encrypted/encoded text keep popping up, it's probably just encoded.
This seems like a really simple problem. I just can't seem to figure it out.
A message was encrypted using a Block Cipher that seems to follow an Electronic Codebook method. I know that they took it in blocks of 3 characters at a time. I know what the message says and I know what the cipher text says; but I want to know the keys. The problem says that it was encrypted using the same method twice but with different keys. Is it possible to find the keys without brute forcing it?
If not, then how would I minimize the time needed to brute force the key?
BTW: The key is in hex and it can only be 6 characters long maximum. So the biggest key possible in decimal would be 16777215
I was hit by a ransomware infection that encrypts the first 512 bytes at the top of the file and puts them at the bottom. Upon looking at the encrypted text it seems to be some type of XOR cipher. I know the whole plain text of one of the files that was encrypted, so i figured in theory i should be able to xor it to get the key to decrypt the rest of my files. Well i am having a very hard time with this because i don't understand how the creator xor'ed it really. Im thinking he would use a binaryreader to read the first 512 bytes into an array, XOR it, and replace it. But does that mean he XOR'ed it in HEX? or Decimal? Im quite confused at this point, but i believe i am simply missing something.
I have tried Xor Tool with python, and everything it attempts to crack looks like non sense. I also tried a python script called Unxor that you give the known plain text to, but the dump file it outputs is always blank.
Good Header file dump:
Good-Header.bin
Encrypted Header file dump:
Enc-Header.bin
This may not be the best file example to see the XOR pattern, but its the only file i have that also has the original header 100% before encryption. In other headers where there is more changes the encrypted header changes with it.
Any advice on a method i should try, or application i should use to try and take this further? Thanks so much for your help!
P.S Stackoverflow yelled at me when i tried to post 4 links because im so new, so if you would rather see the hex dumps on pastebin than download the header files, please let me no. The files are in no way malicious, and are only the extracted 512 bytes and not a whole file.
To recover the keystream XOR the plaintext bytes with the cyphertext bytes. Do this with two different files so you can see if the ransomware is using the same keystream or a different keystream for each file.
If it is using the same keystream (unlikely) then your problem is solved. If the keystreams are different, then your easiest solution is to restore the affected files from backups. You did keep backups, didn't you? Alternatively research the particular infection you have got and see if anyone else has broken that particular variant, so you can derive the key(s) they used and hence regenerate the required keystreams.
If you have a lot of money then a data recovery firm might be able to help you, but they will certainly charge.
A rule of thumb to tell a decent cipher from a toy cipher is to encrypt a highly compressible file and try to compress it in its encrypted form: a dumb cipher will produce a file with a level of entropy similar to that of the original one, so the encrypted file will compress as well as the original one; on the other side, a good cipher (even without an initialization vector) will produce a file that will look like a random garbage and thus will not compress at all.
When I compressed your Enc-Header.bin of 512 bytes with PKZIP, the output was also 512 bytes, so the cipher is not as dumb as you expected — bad luck. (But it does not mean that the malware has no weak spots at all.)
I am working with a device that generates a PDF417 barcode upon receiving data. The barcode is read as below (I'm attaching 4 different example outputs by the same device). If anyone can point me in how to decode this please.
Vsh9t+rTEIJxFIzQu/Os1BDsceAcGWe/7WZREL8fv9aTbZGuhnyZirI01z/aXzTPB2JN+4riIhrXTQINGD43WqGHzQCCGJkAsmpTByAgICAgMTE2MDIraFMHICAgIEJvc3MgUFFVSUNLU09CUAAAnwAAKgcAAAAAAAAA
OX0Sn6mPqJABPJtstRzmlvqjRfSXMyKqKTP5yL6JaKhetNupKiFFgRI32TDbm4MxKovt7q8s185KaNCNQGJmtaGHzQB5GJkANmpTByAgICAgMTE1OTmwZ1MHICAgIEJvc3MgUCAgIDQ0U09CPAAAdwAAXgUAAAAAAAAA
7SQ2PN28/K46uo9tkh2AIz8U7t8z4XVeT8FvDn2mqWd/Y6W4DC1VQCFev3yVFZPpMgotFi52zoNyyBOtRmsMo6GHzQB/GJkAiGpTByAgICAgMTE2MDECaFMHICAgIEJvc3MgUFFVSUNLU09CUAAAnwAAKgcAAAAAAAAA
aR9KHkCNZNtiuAE4OU5/cR/JTY3q7u2jZ4iAEFcCmu2yM4Ji6FscuWl3wTdNt0TQlzaGxovgeECgx3EjydlsQqGHzQB8GJkAX2pTByAgICAgMTE2MDDZZ1MHICAgIEJvc3MgUFFVSUNLU09CJgAASwAAXwMAAAAAAAAA
This might be Base-64 encoded data.
I've popped it through a base64 decoder and get binary data with some strings in it.
Noticeable they all have variations on Boss PQUICKSOB as field a near the end.
I'm trying to reverse engineer a file from an application to learn more about the data it is storing on me. Based on the name, it appears to be XML data, but it is obviously either saved in binary or encrypted. I thought it may have been some form of .Net (or other) serialization, and have tried decoding it that way. But, no love. Inspection in hex has not given any clues either.
Maybe someone with more 'skilz' can give me some insight into it. Here is the file
Voted down and answering: the file is exactly N * 16 bytes in size, does not contain any repetition as far as I can see, and it seems to be filled with random bytes. The first bytes seems completely random as well, hinting that this is not a plain protocol.
This would probably hint that the file is AES CBC encrypted. DESede (or any cipher with a 8/16 blocksize) could of couse also have been deployed. Without the key (if any) this all is not going to help you much (if it was, I would not be answering you).
The entropy of first file is high above 7.7 that might indicate encryption. The first 28h bytes (320-bit) of the files match. Is that possible that's the key and the encoded data starts at 28h?