144 replies to this topic

[Sean]

I'm writing it mainly because I'm feeling too bored, so you may simply ignore it.

Although I think Laszlo and other users have done great jobs so far, however, the real beauty of this approach hasn't still been revealed yet, IMO. Maybe because it's a bit unsafe to be exposed in public? I don't know.

OK, I'll be specific. I've been waiting for the code which disables (and re-enables) the Ctrl+Alt+Del key-combination at will purely from AHK. This place is the forum of AutoHotkey, and AutoHotkey is mainly about hotkeys/key-combinations, and Ctrl+Alt+Del may be the only (well-known) key-combination which can't be controlled by AutoHotkey. A challenge enough... No?

PS. I can already do it by other means, so probably I won't bother to do it. BTW, it's not the one once posted in this forum which had a bug to re-enable it.

[tic]

regarding olfens post

MCode(ByRef code, hex) { ; allocate memory and write Machine Code there
   VarSetCapacity(code,StrLen(hex)//2)
   Loop % StrLen(hex)//2
      NumPut("0x" . SubStr(hex,2*A_Index-1,2), code, A_Index-1, "Char")
}


XTEA_encipher := "5589E55383EC148B450C8B008945F88B450C83C0048B008945F4C745EC00000000C745E8B979379EC7"
. "45F0000000008B45F03B4508737D8B45F489C2C1E2048B45F4C1E80531D089C3035DF48B45EC83E0038D0C85000000008"
. "B55108B45EC03041189DA31C28D45F801108B55E88D45EC01108B45F889C2C1E2048B45F8C1E80531D089C3035DF88B45"
. "ECC1E80B83E0038D0C85000000008B55108B45EC03041189DA31C28D45F401108D45F0FF00E97BFFFFFF8B550C8B45F88"
. "9028B550C83C2048B45F4890283C4145B5DC3"

XTEA_decipher := "5589E55383EC148B450C8B008945F88B450C83C0048B008945F4C745ECB979379E8B45EC0FAF450889"
. "45E8C745F0000000008B45F03B4508737D8B45F889C2C1E2048B45F8C1E80531D089C3035DF88B45E8C1E80B83E0038D0"
. "C85000000008B55108B45E803041189DA31C28D45F429108B55EC8D45E829108B45F489C2C1E2048B45F4C1E80531D089"
. "C3035DF48B45E883E0038D0C85000000008B55108B45E803041189DA31C28D45F829108D45F0FF00E97BFFFFFF8B550C8"
. "B45F889028B550C83C2048B45F4890283C4145B5DC3"

MCode(enc, XTEA_encipher)
MCode(dec, XTEA_decipher)

; 128 bit key
VarSetCapacity(k, 16, 0)
NumPut(0x11111111, k,  0, "UInt")
NumPut(0x22222222, k,  4, "UInt")
NumPut(0x33333333, k,  8, "UInt")
NumPut(0x44444444, k, 12, "UInt")


v = Tiny !!! ; 64 bit
DllCall(&enc, int,64, uint,&v, uint,&k)
MsgBox % v
DllCall(&dec, int,64, uint,&v, uint,&k)
MsgBox % v


VarSetCapacity(v, 8, 0) ;64 bit
NumPut(1122334455667788, v, 0, "Double")
MsgBox % NumGet(v, 0, "Double")
DllCall(&enc, int,64, int,&v, int,&k)
MsgBox % "Enc: " . NumGet(v, 0, "Double")
DllCall(&dec, int,64, int,&v, int,&k)
MsgBox % "Dec: " . NumGet(v, 0, "Double")

where is it setting the length of the of the input string to only be 8 characters long?

DllCall(&enc, int,[color=red]64[/color], int,&v, int,&k)

i tried changing that but it still encodes only the first 8 characters. im sure im being dumb, but please could ou show me. thanks

[Laszlo]

That 64 is the number of rounds: how many mixing passes the XTEA algorithm performs. It always processes 64 bits = 8 bytes at a time. For larger input encipher each block of 8 bytes separately, and concatenate the results (ECB encryption mode). You can XOR the previous result to the input block (starting with a given block, the Initial Vector = IV), which is the Cipher Block Chaining (CBC) encryption mode. There are dozens of encryption modes, XTEA is only the primitive (the slowest) operation they use.

BTW, the key could be set simpler, and you don't need to store the machine code in an AHK variable as I demonstrated above.

[Laszlo]

code which disables (and re-enables) the Ctrl+Alt+Del key-combination at will purely from AHK.

I think the keyboard driver catches the Ctrl+Alt+Del key-combination. You can replace the driver, patch it, or change the action to be triggered. They don't need machine code functions, but to get into Windows internals. (Editing the registry is a possibility, but the user has to be prevented to edit it back…)

[tic]

Sean...

Maybe this i something that you want or have already tried....

<!-- m -->http://msdn.microsof... ... =true#fig8<!-- m -->

[olfen]

2tic:

Below is some code that shows how to encrypt\decrypt data consisting of multiple 64bit (8 byte) blocks. To properly process data with a length that is not a multiple of 8 bytes, it is neccessary to pad the data at the end, so that its length becomes a multiple of 8 bytes.
But I don't know, which padding method is best used. There is a very nice article on block cipher operating modes at wikipedia. Among others it describes the following teqnique:

Slightly more complex is the original DES method, which is to add a single one bit, followed by enough zero bits to fill out the block; if the message ends on a block boundary, a whole padding block will be added.

Maybe Laszlo can answer if this would be a good choice.

The code below demonstrates the weakness (please note Laszlo's objection below regarding "weakness"; it rather is a property) of using XTEA (block ciphers in general) in ECB mode:

The disadvantage of this method is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus, it does not hide data patterns well.

So working on using it in CBC mode seems mandatory to me.

#NoEnv
SetBatchLines -1

MCode(ByRef code, hex) { ; allocate memory and write Machine Code there 
   VarSetCapacity(code,StrLen(hex)//2) 
   Loop % StrLen(hex)//2 
      NumPut("0x" . SubStr(hex,2*A_Index-1,2), code, A_Index-1, "Char") 
} 

MCode(enc, "5589E55383EC148B450C8B008945F88B450C83C0048B008945F4C745EC00000000C745E8B979379EC745F0000000008B45F0"
. "3B4508737D8B45F489C2C1E2048B45F4C1E80531D089C3035DF48B45EC83E0038D0C85000000008B55108B45EC03041189DA31C28D45F"
. "801108B55E88D45EC01108B45F889C2C1E2048B45F8C1E80531D089C3035DF88B45ECC1E80B83E0038D0C85000000008B55108B45EC03"
. "041189DA31C28D45F401108D45F0FF00E97BFFFFFF8B550C8B45F889028B550C83C2048B45F4890283C4145B5DC3")

MCode(dec, "5589E55383EC148B450C8B008945F88B450C83C0048B008945F4C745ECB979379E8B45EC0FAF45088945E8C745F000000000"
. "8B45F03B4508737D8B45F889C2C1E2048B45F8C1E80531D089C3035DF88B45E8C1E80B83E0038D0C85000000008B55108B45E80304118"
. "9DA31C28D45F429108B55EC8D45E829108B45F489C2C1E2048B45F4C1E80531D089C3035DF48B45E883E0038D0C85000000008B55108B"
. "45E803041189DA31C28D45F829108D45F0FF00E97BFFFFFF8B550C8B45F889028B550C83C2048B45F4890283C4145B5DC3")

MCode(k, 11111111222222223333333344444444) ; 128 bit key

v = 
( Join
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!
Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny !!!Tiny 1KB
)

len := StrLen(v)
Loop % len/8
  DllCall(&enc, "int",64, "uint",&v+(A_Index-1)*8, "uint",&k)
MsgBox % v

;ReadMemory("output.enc", &v, len) 
;FileGetSize, len, output.enc 
;WriteMemory("output.enc", v, len)

Loop % len/8
  DllCall(&dec, "int",64, "uint",&v+(A_Index-1)*8, "uint",&k)
MsgBox % v

Using Sean's FileHelper disk I/O could be done by adding the following code between encryption and decription:

ReadMemory("output.enc", &v, StrLen(v))
FileGetSize, nSize, output.enc
WriteMemory("output.enc", v, nSize)

2Laszlo:

Would the following code give us cryptographically secure initialization vectors for CBC mode?

MCode(k, 11111111222222223333333344444444)

; create 64 bit initialisation vector
Random, iv1
Random, iv2
VarSetCapacity(iv, 8)
NumPut(iv1, iv, 0, "UInt"), NumPut(iv2, iv, 4, "UInt")
DllCall(&enc, int,64, uint,&iv, uint,&k)

Edit 20070921: Added a remark regarding "weakness"
Edit 20070922: Changed code to correctly work for disk I/O

[Laszlo]

Padding: making the length of the data a multiple of 64 bits. Any method is OK, which you can reverse. There is no security issue with any of the reasonable choices. (Public key cryptography is different, there you have to be careful.) The most common padding scheme is what you describe. It can be easily reversed: remove all the trailing 0's from the decrypted data and the 1 bit preceding them. The drawback is that if you have a multiple of 64 bits to be encrypted a whole extra block have to be appended.

Padding increases the length. If you have at least 64 bits of data to be encrypted, another method, ciphertext stealing, could be better. It does not increase the length of the data.

The code below demonstrates the weakness of using XTEA in EBC mode, so working on using it in CBC mode seems mandatory to me

It is ECB, and XTEA has no weakness in this mode. It is the property of block-by-block encryption: identical plaintext blocks encrypt to identical ciphertext blocks. In some cases it may not be desirable, like in storage encryption. CBC is only slightly better. It has a whole lot of similar "weaknesses". This is why we in the IEEE P1916 standard group defined another encryption mode: XTS. For even higher security you have to use large block encryption modes, like ABL, XCB, EME*, or even the Windows Vista Bitlocker method.

Would the following code give us cryptographically secure initialization vectors for using XTEA in CBC mode?

The choice of the IV does not effect the security, as long as it is "unpredictable" (that is, it is not correlated to the first plaintext block, even if this block was chosen maliciously by your adversary). It is also public: you have to attach it to the encrypted message, otherwise the recipient cannot decrypt. It is customary to use an encrypted sequence number or the encrypted current time, by any secret key. Using AHK's built in random number generator is not as good: in about 65,000 runs there will be 50% chance of a repeated IV.

[olfen]

Laszlo, thanks for your response! Please give me some time to digest and read up.

[Sean]

Maybe this i something that you want or have already tried....
<!-- m -->http://msdn.microsof... ... =true#fig8<!-- m -->

Looks like this one attempts to disable TaskMgr via LL hook which AHK already uses or Group Policy/Registry. Those actually don't/can't disable SAS, i.e., Ctrl+Alt+Del, just disable the trigger of TaskMgr.

[Sean]

I think the keyboard driver catches the Ctrl+Alt+Del key-combination. You can replace the driver, patch it, or change the action to be triggered.

I meant to do it without replacing any driver/system files. What I meant was the one here:
<!-- m -->http://www.autohotke... ... hlight=SAS<!-- m -->
<!-- m -->http://www.codeproje...onioWinLock.asp<!-- m -->

[Sean]

Using Sean's FileHelper disk I/O could be done by adding the following code between encryption and decription:

olfen, glad to see you utilize FileHelper.ahk. I already saw you using it once in your another great post. Thanks.

[olfen]

olfen, glad to see you utilize FileHelper.ahk. I already saw you using it once in your another great post. Thanks.

Thank you for sharing it!

As for the Ctrl+Alt+Del blocking: Maybe these are useful resources?
NOCAD.ASM
Art of Assembly Language: Chapter 20 - The PC Keyboard

And another link describing Using SHORT (Two-byte) Relative Jump Instructions,
in case it is necessary to manually patch jump addresses in disassembled machine code for use in AHK.

[Sean]

As for the Ctrl+Alt+Del blocking: Maybe these are useful resources?
NOCAD.ASM
Art of Assembly Language: Chapter 20 - The PC Keyboard

Thanks for the links. However, I'm not sure if it could be used from AHK.
Looks like it's for the real-mode apps or driver files, but I may be wrong.

[olfen]

It is ECB, and XTEA has no weakness in this mode. It is the property of block-by-block encryption: identical plaintext blocks encrypt to identical ciphertext blocks. In some cases it may not be desirable, like in storage encryption. CBC is only slightly better.

Typo is corrected. I realise that I have used the term weakness in a very careless manner, what I meant is that unfortunate property.

It has a whole lot of similar "weaknesses". This is why we in the IEEE P1916 standard group defined another encryption mode: XTS. For even higher security you have to use large block encryption modes, like ABL, XCB, EME*, or even the Windows Vista Bitlocker method.

Could you provide any good links on XTS? I didn't find much.

If you have at least 64 bits of data to be encrypted, another method, ciphertext stealing, could be better.

I'll try to implement CBC with ciphertext stealing, if I find the time.

[olfen]

Here's a little function XOR'ing operand a with b and saving the result in a (for 64 bit blocks):

/* C function:

EXPORT void XOR64_(unsigned long* a, unsigned long* b) {

  a[0] ^= b[0];

  a[1] ^= b[1];

}

*/



MCode(XOR64, "5589E58B4D088B55088B450C8B00330289018B4D0883C1048B550883C2048B450C83C0048B00330289015DC3")



MCode(a, 1234567822222222) ; 64 bit

MCode(b, 3333333312345678) ; 64 bit



r .= Bin2Hex(&a, 8) . "`n"

DllCall(&XOR64, "uint",&a, "uint",&b)

r .= Bin2Hex(&a, 8) . "`n"

DllCall(&XOR64, "uint",&a, "uint",&b)

MsgBox % r .= Bin2Hex(&a, 8)