Can any one tell me which API's can be used to search a SPECIFIC Hex String or OPCODES in an executable or any other format file??
Posted on 2003-04-24 09:55:38 by telophase
Uhm, you can use a simple search algorithm : should be ok for small files (less than 500 kb) or use more enhanced algorithms like Boyer Moore (assembly implentation by Hutch at www.movsd.com)...
To deal with files, simply CreateFile/WriteFile... but what you describe sounds like cracking or reverse-engineering related...
Please read our rules carefully and explain why you want to make such a program (I know there is legitimate uses to patchers).
Posted on 2003-04-24 10:03:32 by JCP
I want to create an encrypter which will change a specified hex string in a video or audio file so that only my
program can restore the corresponding file coz it will be keeping a record of what hex modifications have been
made. This is becoz i want to protect my pesonal files
Posted on 2003-04-24 23:55:39 by telophase
Ahh, so you want to protect your pr0n files.......

Why don't you just encrypt the file using public/private key encryption? There is a couple of reasons you may want to consider this:

- it is an industry standard
- you do not need to keep data files listing what byte ranges were encrypted, you just need to keep a record of your public and private keys
- there are API functions that will do the crypting/decrypting for you
- encrypting just a range of bytes does not protect the whole file
Posted on 2003-04-25 02:15:57 by sluggy
But even then how do i encrypt the content using my own encryption routine can u give me an
asm example
Posted on 2003-04-26 10:08:12 by telophase
How can he give you an asm source code of your encryption routine, when you did not even mention how you want to encrypt and such? If you want some encryption routine, search the boards, there are some implenmented encryption routines wrote by some of the members of the forums.
Posted on 2003-04-26 11:11:54 by roticv
I am a newbie 2 assembly so if u can please pin-point where to start encryption from some good tutorials
good books or links???
Posted on 2003-04-28 08:27:16 by telophase
telophase,

In the MASM32 stuff there are a number of very similar encryption routines that are designed for what is called "one pass pads". They are in fact simple to use but the problem is if you want really high encryption, you must use a unique pad for every different thing you encrypt.

As I doubt that you have that problem, what you can look for is different files on your machine that are at least as big as the files you want to encrypt and run the source with the other file as the key.

Unless the NCA are trying to bust you files and take the whole machine to do it, you are probably overkilling the need with this approach.

Some of the other guys in here have a background in block cyphers that are popular at the moment so they may be able to pass you some reference of some code links.

One hint here is that a 24 bit BMP file is usually diverse enough to do the job for less than national security purposes. If you want to hit the big time, you need a classy random sequence generator but they are a bit of work to get going well.

Regards,

hutch@movsd.com
Posted on 2003-04-28 09:57:16 by hutch--
Hutch, I think the term cryptographers usually use is "one time pads" - at least in the crypto books I have here. Both might be viable names, but "one time pad" does give more hits on google :). When you use a key length the same as your source length, _never_ use the same key twice, and have a _100% secure_ key distribution channel, OTPs are definitely the most secure class of encryption (or so I should think). However, you must make sure the key doesn't "repeat", ideally it would probably be generated from a _very_ good PRNG.

There's a lot of things that make OTPs impractical, though. Mainly that you can only use the key (pad) once, otherwise the whole security of the system is nullified. Related to this is the size of the key - it's not very easy to remember a long binary string. The secure channel is also a problem - how do you securily transfer the OTP?

Block ciphers are handy, and the popular ones are subject of _massive_ public (and private) scrutiny, and really they're the only suitable way to deal with mass encryption. A block cipher key is small enough that it can be transmitted orally (if you have a secure line), and for personal keys, you can derive a block cipher key from a passphrase, which would make it possible to memorize. A really nifty thing is "session keys" for encrypted communication. You'd use a key exchange protocol which securely gets point A and B set up with communication keys, and from then on all communication is encrypted. Since it's a _session_ key, if somebody (very unlikely) manages to figure out your key, they'll only be able to decrypt that session. By using a decent communication protocol, you can furthermore avoid replay attacks etc.

Public key encryption is also pretty handy. Let everybody be able to encrypt messages for you, but only you being able to decrypt them. Sign data to prove that you're the author. Secure key exchange, etc. Those algorithms tend to be slow, though, and in the case of pubkey encrypted data transfer, you usually encrypt the data with a block cipher, and the (randomly generated) block cipher key with the pubkey algo.

There's also a lot of other topics, like stream ciphers and steganography, but I think I've already swayed enough from topic :)

--- getting back to the subject ---

What you probably need is a block cipher. If you want to just use one and have security, I would recommend finding an implementation of AES (Rijndael), RC6, or twofish, and use that. If you want to implement it yourself and play with crypto, have a look at the various versions of TEA - it's a simple algorithm, and there's been flaws throughout it fixed in later versions, that should give you some idea about algorithm problems. You might also want to have a look at the stuff hutch mentioned.

For books, have a look at Handbook Of Applied Cryptography. Be warned that it's pretty math intensive.
Posted on 2003-04-28 10:15:54 by f0dder
f0dder,

Thanks for the language lesson, the next time I need to speak a dialect trandslated from English to danish and back to English I may even take notice. :tongue:

============================
you must use a unique pad for every different thing you encrypt. = When you use a key length the same as your source length, _never_ use the same key twice, and have a _100% secure_ key distribution channel, OTPs are definitely the most secure class of encryption (or so I should think). However, you must make sure the key doesn't "repeat", ideally it would probably be generated from a _very_ good PRNG.
============================

The advantage of being a native English speaker I guess. :tongue:

Where you could help is with the TEA and other block cyphers you have worked on. A working example in MASM or similar would be helpful for someone looking for information in this area.

Regards,

hutch@movsd.com

PS: If you wish to produce encryption standard random sequences that can be used with a one pass pad, you ned to download a specialised testing program on the net called ENT. It will tell you things about standard random sequence generators that you don't want to hear like just how bad they are.

The class of results you need have to be as good as radioactive decay seeding before the random sequences are good enough. I have the software developed but I don't intend to post it so I cannot help you there.

Here is a hint on how to do it though. You need two seperate random algos, one integer and the other floating point. I used the version that NaN designed from a park Miller technique for the integer sequence and then you loop reseed each algo to the other using your radioactive decay original or similar.

To make it even messier, i translated each result to string, performed random modifications on the string from reseeding the park Miller algo, chopped out the modified part and converted it back to a floating point number again.
Posted on 2003-04-29 03:24:21 by hutch--
hehe, that sentence did come out rather fooked (sometimes serializing a multitasking mind produces a mess like this) - thanks for noticing ;)

"When you use a key length the same as your source length" should have been "you need to use a key the same size as your source". Your "you must use a unique pad for every different thing you encrypt." doesn't cover the need for sourcelen=keylen, though.

Btw, try googling for "one pass pad" then "one time pad" - OTP is the correct term. Makes sense, too.
Posted on 2003-04-29 03:39:03 by f0dder
I forget the guy's name but it was an American who invented the technique in the 20s for military applications. It has been known by a number of names so if you get to understand how it works, the name won't matter much. :tongue:

Still, I am sure the original poster would be more than happy if you could post a MASM version of TEA or some other block cypher so he could play with it. This should be something easy enough for you to knock up in an hour or so.

Regards,

hutch@movsd.com
Posted on 2003-04-29 03:46:03 by hutch--

I forget the guy's name but it was an American who invented the technique in the 20s for military applications. It has been known by a number of names so if you get to understand how it works, the name won't matter much. :tongue:

True - but if you need to search for information on it, One Time Pad gives plenty, while One Pass Pad... :-)

As for TEA, well... it wouldn't be much work for me to whip up an asm implementation (I've done it a couple of times in the past), but if the guy wants to understand encryption, he should do it himself from an algorithm description. If he just wants to _use_ encryption, he shouldn't bother with tea. If he still wants a ready-to-use masm version, googling for "asm tea implementation" gives bonus on the first hit.

Couple URLs for TEA papers - there's more and better, google.
http://www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
http://cypher.cyber.brad.ac.uk/tea/
Posted on 2003-04-29 03:57:05 by f0dder