OpenRCE: Blog

Reverse Engineering Of Strong Crypto Signatures Schemes

Tue, 21 Aug 2007 04:21:49 -0500

Hi,

The english version of my last paper can be viewed here:

http://evilcry.altervista.org/tuts/StrongCryptoTrsl.zip

See you to the next post

Xmas Cryptanalisys :)

Mon, 25 Dec 2006 04:25:51 -0600

First of all, i would give you my best wishes for a Peaceful and Happy Christmas, i've published this post because, as someone already said, "this make me fell alive"

Here i'll talk about the cryptanalysis of a simple Binary Addition, but this can be usefull for people that have some Psion5 PDA file Encrypted ;)

Psion 5 PDA implements a very weak encryption system, here i'll demonstrate how we can obtain a fully clear plaintext from an encrypted block (a Cipher Only Attack).

The algorithm used is a simple Binary Addition:

Encryption phase: The key entered is added character by character (byte by byte) to the data to be encrypted. Here addition modulo 256 is used. The key is applied cyclically, once all bytes of the key have been used, the algorithm reverts to the first character until the text has been completely encrypted.

Decryption phase: The characters of the key have to be subtracted from the encrypted text modulo 256.

As previously said a Cipher Only Attack can be performed, we need to know:

1)Statistical Frequency: The characters which occur most frequently), but if we don't know this parameter, there is no problem, because we can use statistical tables, or at least a small bruteforce it's range is truly small, only 26 as the number of letters, more if we are working with not common languages (xenographyc tables are useful in this case).

2)The key length: We can determine the keylenght using Autocorrelation (which is an index of similarity for differents portions of text).
Each character had not an equal probability occurs, but the probability of two identical characters occurring is relatively large if they are separated by a multiple of the key length. Thanks to the Autocorrelation analisys, we can determine a "distance value", calculated between equal frequency values, this value is our Derived Key Lenght.

3)Discovering The Key: After we know the Key Lenght, throughout the Histogram analisys of every character of the key, we can determine the correct key char. It's important to underline that, in this process we have to assume a Most Common Character,
for example on english texts we can assume the 'e' OR the space ' '.

--------------------[Background Philosophy]----------->

The base concept that allowed this attack, is the The Unicity Distance, which is one of the fundamentals of Cryptanalisys.
The Unicity Distance, is the minimum amount of ciphertext (expressed in number of of chars) required to allow a computationally unlimited adversari to recovery the Encryption Key.

We can express this concept in more strict terms, as No = H(K)/D, where
No=Expected Unicity Distance
H(K)=Entropy of Key Space
D=Plaintext Redundancy (Referred to the Histogram Analisys)

In our case we have to introduce another parameter, t which is the period of our cipher. Assuming D as 3.2 bits/chars we have:

H(K)/D=lg(t!)/3.2

Using Stirling's Approximation we can rewrite the previous as:

t! Approximately Is Sqrt((2Pi*t))* (t/e)^t

As usual i exceded in the Math Back-Ground analysis :)
but reported informations should be enough for people that want to implement some Automatic Cryptanalisys Proggie :)

Again Merry Xmas and see you to the next post ;)

Kartoffel and Vulnerable Device Drivers

Sun, 22 Oct 2006 03:22:16 -0500

Some days ago i'v founded a nice and useful, Kartoffel Driver Verification Tool, that allow us a rapid verification of some of the most common Device Driver weaknesses, as untrusted IOCTLs.

For example, we can see that mrxsmb.sys (which is directly related to cscdll.dll) does not trust User Mode ingoing buffer)

>kartoffel -s \\.\Shadow -n 0 -o 0x10 -z 0 -Z 0x18 -U VALUE,HANDLES -c 2000 -I 141047

In other work we're "overflowing" the CTL code 141047, output result of Kartoffel

Input Size:[0x0000] Ouput Size:[0x0018] IOCTL:[0x00141047] -> Response received [IOM notified] [ RESULTS ] _________________________________________________________ Test ID [ 0x0001 ] ------------------------------------------------------------ [ FUZZING ] - Input Buffer Size: (0x0000) Method: "" Submethod: "" - Output Buffer Size: (0x0018) Method: "VALUE" Submethod: "HANDLES" - IOCTL [ 0x00141047 ] => DEVICE: FILE_DEVICE_NETWORK_FILE_SYSTEM => ACCESS: ANY ACCESS => FUNCTION: 0x0411 => METHOD: METHOD_NEITHER [ FLAW ] - POSSIBLE DEADLOCK DETECTED - [ BUFFERS ] [INPUT BUFFER] = NULL Original Data [OUTPUT BUFFER] [0x000]: 000007E8 000007E8 000007E8 000007E8

Oh, here is the link

hXXp://www.reversemode.com/index.php?option=com_remository&Itemid=2&func=fileinfo&id=17

..and it's also Open Source!

See you to the next post

MFC Undeclared Identifier

Sun, 08 Oct 2006 05:06:08 -0500

Yesterday, i tried to use OpenSCManager() and the other common CreateService(), but VS compiler refuses to compile, the
reason was Undeclared Identifier: , but all headers were ok.

Thanks to a little discovery, i finally builded my application, here i'll share this, because could help in a variety of similar problems, when using not many common APIs on MFC.

Into stdafx.h there is:

#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers

by clearing this line, all not common functio prototipes will be working :)

See you to the next post

Something about Firewall hooking and Packet Filtering (2)

Tue, 26 Sep 2006 11:01:30 -0500

Let's introduce some more specification, to make previous blog entry more clear.

The last struct showed, is the _FIREWALL_CONTEXT_T, and as can be seen there is DIRECTION_E that could be a little obscure, so here is reported:



typedef enum _IP_DIRECTION_E {

          IP_TRANSMIT,

          IP_RECEIVE

       } DIRECTION_E, *PDIRECTION_E;

Represents easly a packet is Receiver or Transmitted.

The return values by the filter-routine can be:

FORWARD = 0
DROP = 1
ICMP_ON_DROP = 2

That are proprer of FORWARD_ACTION

As previously said, to implement IP_SET_FIREWALL_HOOK_INFO, it's necessary to write a filter function for \device\IP, so the pointer (to IP) self can be obtained easly by calling
IoGetDeviceObjectPointer( )

Now can be installed the filter function, by passing througout IP's pointer the address of the filtering function self, with IoBuildDeviceIoControlRequest(IOCTL_IP_SET_FIREWALL_HOOK,IpDeviceObject,.....)
It's important to say also (according to DDK documentation) that IOCTL_PF_SET_EXTENSION_POINTERregisters filter-hook callback to the IP filter driver, to "make known" \device\IP to reroute every packet received or transmitted, and finally this same IOCTL clears the filter function from IP device. All these specifications could be made, by filling up the proper structure of this IOCTL, that will go to constitute the InputBuffer of IoBuildDeviceIoControlRequest:

PF_SET_EXTENSION_HOOK_INFO, that inside have another struct PacketFilterExtensionPtr which specifies the pointer to the filter hook callback, and when ins FALSE clears the filter.





typedef  PF_FORWARD_ACTION 

(*PacketFilterExtensionPtr)(

  IN unsigned char *PacketHeader,    //Pointer to Ip header of packet

  IN unsigned char *Packet,          //Points a buffer with informations in the packet

                                     //that filter-hook receives 

  IN unsigned int PacketLength,      //Length of the packet

  IN unsigned int RecvInterfaceIndex,//Index number for the interface adapter (InGoing)

  IN unsigned int SendInterfaceIndex,//Index number for the interface adapter (OutGoing) 

  IN IPAddr RecvLinkNextHop,         //IP address for the interface adapter that received the packet

  IN IPAddr SendLinkNextHop          //IP address for the interface adapter that will transmit the packet

  );

It's also important to notice that only on filter function per time can be installed, if others resides functions are stil working this one will not work.

See you to the next post