PDA

View Full Version : Unencrypting encrypted text



minestrone
20th July 2015, 11:32
I have a DB that contains 150,000 12 char encrypted strings, I don't know the encryption mechanism and I am not sure if they have been salted. I'm basically wanting to explore the possibility of working out if the encryption can be reversed in a bulk process.

We know the 8 char strings that the encrypted text came from but they are on scanned PDFs and it would be a manual process to sort them which really is not an option.

I just wondered if anyone has any experience of this sort of thing, I am aware that there are tools that might be useful but really not sure where to start. I'm thinking maybe if we know the inputs and the output is only 12 chars then it could be reversed.

Obvious disclaimer that the data is ours and it's all above board, the code that did the encryption has been lost.

Cheers

stek
20th July 2015, 11:42
Try Kali Linux, it's a pen test/ethical hacking Linux with all these tools preinstalled - might not do what you want but worth a look.

It's free and there are prebuilt VM's as well....

minestrone
20th July 2015, 11:47
Cheers, ill give that a whirl, seems there is an EC2 image so I'll look at firing up an instance later in the week when I get some time and report back.

DaveB
20th July 2015, 11:55
I have a DB that contains 150,000 12 char encrypted strings, I don't know the encryption mechanism and I am not sure if they have been salted. I'm basically wanting to explore the possibility of working out if the encryption can be reversed in a bulk process.

We know the 8 char strings that the encrypted text came from but they are on scanned PDFs and it would be a manual process to sort them which really is not an option.

I just wondered if anyone has any experience of this sort of thing, I am aware that there are tools that might be useful but really not sure where to start. I'm thinking maybe if we know the inputs and the output is only 12 chars then it could be reversed.

Obvious disclaimer that the data is ours and it's all above board, the code that did the encryption has been lost.

Cheers

It sounds like it may be easier to convert the PDF's to text and write some code to sort them based on the unencrypted string.

Even if you can identify the encyption method used, without the original encryption key and salt you are still looking at a pretty much insurmountable problem as most "proper" encrption methods are one way. Even knowing the key and salt you can't reverse the encrption on the encypted text to get the original.

What you would have to do is use the key and salt to geneate a rainbow table of all possible encryption results from the original data space and then match that against the encrypted values to find the originals.

minestrone
20th July 2015, 12:07
I did think of looking into the PDF text but they are scanned letters, images and stuff like that.

I think there is enough evidence in the general quality of work from the creator in this system to suggest that they used the most basic encryption available without salting.

I remember working for a place that took passwords and added 50 onto each char. :laugh

DaveB
20th July 2015, 12:15
I did think of looking into the PDF text but they are scanned letters, images and stuff like that.

I think there is enough evidence in the general quality of work from the creator in this system to suggest that they used the most basic encryption available without salting.

I remember working for a place that took passwords and added 50 onto each char. :laugh

In which case it might be worth posting some plain text/encrypted text pairs (assuming you can identify them) on a technical puzzle solving forum, or even here to see if anyone can work out the cypher that was used. Once you know that the rest is easy if it really was just a rotation/char swap jobbie.

DaveB
20th July 2015, 12:34
Alternatively, find the guy that wrote it and get the rubber hoses out.

http://imgs.xkcd.com/comics/security.png

minestrone
20th July 2015, 14:30
I'm sure there was bobage involved in this work, anyways the text is car registrations.

DL13 UHU

->

Mw+w2j5CLBc=

All the encrypted text ends in a '=' which makes me think that 11 chars + '=' is the work of someone who is not exactly rigorous. The space might be removed before encryption but not sure really.

stek
20th July 2015, 14:58
I'm sure there was bobage involved in this work, anyways the text is car registrations.

DL13 UHU

->

Mw+w2j5CLBc=

All the encrypted text ends in a '=' which makes me think that 11 chars + '=' is the work of someone who is not exactly rigorous. The space might be removed before encryption but not sure really.

It's a white Vauxhall Astra SRi!

SpontaneousOrder
21st July 2015, 14:13
I'm sure there was bobage involved in this work, anyways the text is car registrations.

DL13 UHU

->

Mw+w2j5CLBc=

All the encrypted text ends in a '=' which makes me think that 11 chars + '=' is the work of someone who is not exactly rigorous. The space might be removed before encryption but not sure really.

= is the base64 padding to fill out the block size. You'll always get that if the size of your data doesn't fit the block size exactly.

**edit** 'block size' is the wrong terminology and I just realised it could make it sound like a symmetric AES block size or something.

Base64 works on 24 bit strings of 3 octets. And log2 of 64 = 6: i.e. 4 6 bit values per 24 bit string.

Those 6 bit values map to ASCII (not by the ascii code though) to get your Base64 representation of binary data.

If you don't have enough data at the end to make a full 24 bits, then padding is added ('==' or '=') as necessary.

SpontaneousOrder
21st July 2015, 14:16
And my suggestion would be to not bother trying.

Contreras
21st July 2015, 16:06
You should know if it is salted because the salt values would be stored as well. Alternatively query for duplicate encrypted strings, unless the represented data (car reg.) is unique in which case that won't help.

A sample of one isn't very useful. Post a few more if you can.

SpontaneousOrder
21st July 2015, 16:37
You should know if it is salted because the salt values would be stored as well. Alternatively query for duplicate encrypted strings, unless the represented data (car reg.) is unique in which case that won't help.

A sample of one isn't very useful. Post a few more if you can.

Surely they would;t be salted if they were encrypted?

stek
21st July 2015, 16:54
If you pay peanuts you get salted.

xoggoth
21st July 2015, 21:50
It does look like base64 encoding that has been hacked a bit. I did that in Excel VBA to protect my passwords list, took a standard online GNU script and fiddled about with a few lines.

DL13 UHU comes out as QT/xMBEVRUX< in my script unfortunately so not the same hack.

SpontaneousOrder
21st July 2015, 23:19
It does look like base64 encoding that has been hacked a bit. I did that in Excel VBA to protect my passwords list, took a standard online GNU script and fiddled about with a few lines.

DL13 UHU comes out as QT/xMBEVRUX< in my script unfortunately so not the same hack.

Looks to me like it's been encrypted with something where the output is the same size (rounding up to a block), and then that binary output has been base64 encoded for storage (rather than storing raw bytes).

I say that because it doesn't look like a plate number using any of the character encodings I used for the base64 decoded binary.

I don't think its RSA encrypted because it would grow substantially bigger.
I don't know much about hashing algorithms but I know MD5 would make it a lot larger too.

Maybe just synchronous AES encryption with base64 encoding.


But if the key is good then you've got no chance.


All that said, I'm far from expert.

d000hg
22nd July 2015, 09:03
You should know if it is salted because the salt values would be stored as well.Unless they salt with a constant, or some other field such as date/name/whatever that is not labelled as the salt.

Contreras
22nd July 2015, 09:34
Unless they salt with a constant, or some other field such as date/name/whatever that is not labelled as the salt.

True, although a constant salt is just one step up from useless.

I have an idea of the method and how it could be trivially attacked. But with a sample data set of only 1 it might as well be a random number generator.

minestrone
22nd July 2015, 09:46
Here are a few more...

( again not sure if space has been removed )

AE07 GVD -> 4ZRxfz6IfsY=
PJ56 EDU -> IYE31M+sx5E=
YT51 YZM -> q8EXdgQXoOg=

The system creators are the types to find the first thing on google that they could copy and paste.

Contreras
22nd July 2015, 11:01
Here are a few more...

( again not sure if space has been removed )

AE07 GVD -> 4ZRxfz6IfsY=
PJ56 EDU -> IYE31M+sx5E=
YT51 YZM -> q8EXdgQXoOg=

The system creators are the types to find the first thing on google that they could copy and paste.

haha well that bolluxed my theory :laugh

What is clear though is that the encrypted strings are all 8-chars, and so far the plaintext strings are also all 8-chars.


$~ base64 -d <<< Mw+w2j5CLBc= | od -An -t x1
33 0f b0 da 3e 42 2c 17
$~ base64 -d <<< q8EXdgQXoOg= | od -An -t x1
ab c1 17 76 04 17 a0 e8
$~ base64 -d <<< IYE31M+sx5E= | od -An -t x1
21 81 37 d4 cf ac c7 91
$~ base64 -d <<< 4ZRxfz6IfsY= | od -An -t x1
e1 94 71 7f 3e 88 7e c6


The next thing would be to inspect other reg's starting with D, A, P or Y, and reg's not 8-chars in length.

Or get hold of the source code!

minestrone
22nd July 2015, 14:38
Cheers for having a look.

darrylmg
22nd July 2015, 22:26
Someone elwe with a similar sort of story here : http://ask.metafilter.com/218270/Help-me-decode-what-looks-like-base64

What database system is this?

Edit: it looks like standard DES encoded in base64.
See the tool here: http://www.tools4noobs.com/online_tools/encrypt/
You'll need to find the routine that was used to encrypt it to find the key.

NickFitz
23rd July 2015, 18:37
It does look like base64 encoding that has been hacked a bit. I did that in Excel VBA to protect my passwords list, took a standard online GNU script and fiddled about with a few lines.

DL13 UHU comes out as QT/xMBEVRUX< in my script unfortunately so not the same hack.

Without the space:



echo DL13HTU | base64
REwxM0hUVQo=

darrylmg
24th July 2015, 00:10
Without the space:



echo DL13HTU | base64
REwxM0hUVQo=


But what about DL13 UHU ? Not HTU.

Contreras
24th July 2015, 00:47
But what about DL13 UHU ? Not HTU.

http://www.modelcarworld.de/relaunch/foto.php?d=184878

minestrone
25th July 2015, 13:56
Someone elwe with a similar sort of story here : Help me decode what looks like base64 - encode encryption | Ask MetaFilter (http://ask.metafilter.com/218270/Help-me-decode-what-looks-like-base64)

What database system is this?

Edit: it looks like standard DES encoded in base64.
See the tool here: Online encrypt tool - Online tools (http://www.tools4noobs.com/online_tools/encrypt/)
You'll need to find the routine that was used to encrypt it to find the key.

Cheers, going to give this some time over the weekend hopefully.

NickFitz
26th July 2015, 22:23
But what about DL13 UHU ? Not HTU.

REwxM1VIVQo=

Not sure why I was trying HTU… :ohwell

darrylmg
26th July 2015, 22:47
I'm sure there was bobage involved in this work, anyways the text is car registrations.

DL13 UHU

->

Mw+w2j5CLBc=

All the encrypted text ends in a '=' which makes me think that 11 chars + '=' is the work of someone who is not exactly rigorous. The space might be removed before encryption but not sure really.

Weirdly, if I search google for this encoded string, it takes me to the Paragon Motors website.

Dark Black
17th August 2015, 15:48
Here are a few more...

( again not sure if space has been removed )

AE07 GVD -> 4ZRxfz6IfsY=
PJ56 EDU -> IYE31M+sx5E=
YT51 YZM -> q8EXdgQXoOg=

The system creators are the types to find the first thing on google that they could copy and paste.

In fact, Googling each of those encrypted values comes up with (different) dealer websites referencing the correct type of car for matching reg.

Assumption then is that you're working on car dealer database software or similar?

WTFH
17th August 2015, 15:56
Are you certain it's the car reg and not something else?

DaveB
17th August 2015, 17:17
In fact, Googling each of those encrypted values comes up with (different) dealer websites referencing the correct type of car for matching reg.

Assumption then is that you're working on car dealer database software or similar?

Looks like it.

The assumption then being that there has to be a way to get from the encrypted string used to identify the cars without using the Reg Number, back to the Reg Number.

At this point Minnie tells us that the bit thats fecked and needs fixing.

NotAllThere
18th August 2015, 05:39
4ZRxfz6IfsY=

Google search produces Used Mitsubishi Lancer Saloon 2.0 Evo Ix Mr Fq-360 4dr in Birmingham, West Midlands | Wynford Specialist Motors Limited (http://www.wynfordmotorsbirmingham.co.uk/used-cars/mitsubishi-lancer-2-0-evo-ix-mr-fq-360-4dr-birmingham-201507175279784)

This is part of the source.
<ul class="vehicle-data">
<li class="advert-id">201507175279784</li>
<li class="year">2007</li>
<li class="reg">07</li>
<li class="price">&pound;17,495</li>
<li class="depositAmount">3499</li>
<li class="vehicleMileage">58,000</li>
<li class="vehicleType">Cars</li>
<li class="make">MITSUBISHI</li>
<li class="registration">4ZRxfz6IfsY=</li>
</ul>


This indicates to me that the decryption algorithm is widely available. Or that they're all using the same bit of software.

WTFH
18th August 2015, 08:10
Google search produces Used Mitsubishi Lancer Saloon 2.0 Evo Ix Mr Fq-360 4dr in Birmingham, West Midlands | Wynford Specialist Motors Limited (http://www.wynfordmotorsbirmingham.co.uk/used-cars/mitsubishi-lancer-2-0-evo-ix-mr-fq-360-4dr-birmingham-201507175279784)

This is part of the source.
<ul class="vehicle-data">
<li class="advert-id">201507175279784</li>
<li class="year">2007</li>
<li class="reg">07</li>
<li class="price">&pound;17,495</li>
<li class="depositAmount">3499</li>
<li class="vehicleMileage">58,000</li>
<li class="vehicleType">Cars</li>
<li class="make">MITSUBISHI</li>
<li class="registration">4ZRxfz6IfsY=</li>
</ul>


This indicates to me that the decryption algorithm is widely available. Or that they're all using the same bit of software.


The bottom of each page says "Powered by Auto Trader", so it's all the same software.


Does the OP work for Auto Trader, or are they trying to reverse engineer the AT code?


...this might help (haven't read it, but it was one of the first hits when I googled "auto trader source code":
http://www.mpgh.net/forum/showthread.php?t=605049

Contreras
18th August 2015, 09:22
...this might help (haven't read it, but it was one of the first hits when I googled "auto trader source code":
AutoTrader source code - MPGH - MultiPlayer Game Hacking & Cheats (http://www.mpgh.net/forum/showthread.php?t=605049)

print '$numberOfPotionsIAmOffering:' . $numberOfPotionsIAmOffering . ' $numberOfPotionsBuyerIsOffering:' . $numberOfPotionsBuyerIsOffering . "\n";
if($numberOfPotionsIAmOffering==0 && $numberOfPotionsBuyerIsOffering>=1){
print "\t" . 'I GIVE NO POTION ... YOU GIVE 1+ POTION ... WE GOT A DEAL ... ;-))' . "\n";
$bool_acceptTrade=1;

Nice try, but... :rollin:

I think it's clear that the field is base64 encoded representation of the encrypted car reg:


"DL13 UHU" --> 33 0f b0 da 3e 42 2c 17 --> Mw+w2j5CLBc=
"AE07 GVD" --> e1 94 71 7f 3e 88 7e c6 --> 4ZRxfz6IfsY=
"PJ56 EDU" --> 21 81 37 d4 cf ac c7 91 --> IYE31M+sx5E=
"YT51 YZM" --> ab c1 17 76 04 17 a0 e8 --> q8EXdgQXoOg=

The term 'encrypted' could be use loosely, but I would say it is not a simple obfuscation. So you need to guess the algorithm (e.g. rc2/des/aes/?) and the key and you still don't know if obfuscation was on top. Without any source code for hints it's a pretty tall order.