Search the Community

Note: If you’re decent at vim and want your mind blown, check out Advanced Vim. I’ve compiled a list of essential vim commands that I use every day. I then give a few instructions on how to making vim as great as it should be, because it’s painful without configuration. Cursor movement (Inside command/normal mode) w - jump by start of words (punctuation considered words) W - jump by words (spaces separate words) e - jump to end of words (punctuation considered words) E - jump to end of words (no punctuation) b - jump backward by words (punctuation considered words) B - jump backward by words (no punctuation) 0 - (zero) start of line ^ - first non-blank character of line (same as 0w) $ - end of line Advanced (in order of what I find useful) Ctrl+d - move down half a page Ctrl+u - move up half a page } - go forward by paragraph (the next blank line) { - go backward by paragraph (the next blank line) gg - go to the top of the page G - go the bottom of the page : [num] [enter] - Go To that line in the document Searching f [char] - Move to the next char on the current line after the cursor F [char] - Move to the next char on the current line before the cursor t [char] - Move to before the next char on the current line after the cursor T [char] - Move to before the next char on the current line before the cursor All these commands can be followed by ; (semicolon) to go to the next searched item, and , (comma) to go the the previous searched item Insert/Appending/Editing Text Results in insert mode i - start insert mode at cursor I - insert at the beginning of the line a - append after the cursor A - append at the end of the line o - open (append) blank line below current line (no need to press return) O - open blank line above current line cc - change (replace) an entire line c [movement command] - change (replace) from the cursor to the move-to point. ex. ce changes from the cursor to the end of the cursor word Esc - exit insert mode r [char] - replace a single character with the specified char (does not use insert mode) d - delete d - [movement command] deletes from the cursor to the move-to point. ex. de deletes from the cursor to the end of the current word dd - delete the current line Advanced J - join line below to the current one Marking text (visual mode) v - starts visual mode From here you can move around as in normal mode (hjkl etc.) and can then do a command (such as y, d, or c) V - starts linewise visual mode Ctrl+v - start visual block mode Esc - exit visual mode Advanced O - move to Other corner of block o - move to other end of marked area Visual commands Type any of these while some text is selected to apply the action y - yank (copy) marked text d - delete marked text c - delete the marked text and go into insert mode (like c does above) Cut and Paste yy - yank (copy) a line p - put (paste) the clipboard after cursor P - put (paste) before cursor dd - delete (cut) a line x - delete (cut) current character X - delete previous character (like backspace) Exiting :w - write (save) the file, but don't exit :wq - write (save) and quit :q - quit (fails if anything has changed) :q! - quit and throw away changes Search/Replace /pattern - search for pattern ?pattern - search backward for pattern n - repeat search in same direction N - repeat search in opposite direction :%s/old/new/g - replace all old with new throughout file (gn is better though) :%s/old/new/gc - replace all old with new throughout file with confirmations Working with multiple files :e filename - Edit a file :tabe - make a new tab gt - go to the next tab gT - go to the previous tab Advanced :vsp - vertically split windows ctrl+ws - Split windows horizontally ctrl+wv - Split windows vertically ctrl+ww - switch between windows ctrl+wq - Quit a window Marks Marks allow you to jump to designated points in your code. m{a-z} - Set mark {a-z} at cursor position A capital mark {A-Z} sets a global mark and will work between files ‘{a-z} - move the cursor to the start of the line where the mark was set ‘’ - go back to the previous jump location General u - undo Ctrl+r - redo . - repeat last command Making Vim actually useful Vim is quite unpleasant out of the box. For example, typeing :w for every file save is awkward and copying and pasting to the system clipboard does not work. But a few changes will get you much closer to the editor of your dreams. .vimrc My .vimrc file has some pretty great ideas I haven't seen elsewhere. This is a minimal vimrc that focuses on three priorities: adding options that are strictly better (like more information showing in autocomplete) more convenient keystrokes (like [space]w for write, instead of :w [enter]) a similar workflow to normal text editors (like enabling the mouse) Installation Copy this to your home directory and restart vim. Read through it to see what you can now do (like [space]w to save a file) mac users - making a hidden normal file is suprisingly tricky. Here’s one way: in the command line, go to the home directory type nano .vimrc paste in the contents of the .vimrc file ctrl+x, y, [enter] to save You should now be able to press [space]w in normal mode to save a file. [space]p should paste from the system clipboard (outside of vim). If you can’t paste, it’s probably because vim was not built with the system clipboard option. To check, run vim --version and see if +clipboard exists. If it says -clipboard, you will not be able to copy from outside of vim. For mac users, homebrew install vim with the clipboard option. Install homebrew and then run brew install vim. then move the old vim binary: $ mv /usr/bin/vim /usr/bin/vimold restart your terminal and you should see vim --version now with +clipboard Plugins The easiest way to make vim more powerful is to use Vintageous in sublime (version 3). This gives you Vim mode inside sublime. I suggest this (or a similar setup with the Atom editor) if you aren't a vim master. Check out Advanced Vim if you are. Vintageous is great, but I suggest you change a few settings to make it better. Clone this repository to ~/.config/sublime-text-3/Packages/Vintageous, or similar. Then check out the "custom" branch. Alternatively, you can get a more updated Vintageous version by cloning the official repo and then copying over this patch. Change the user settings (User/Preferences.sublime-settings) to include: "caret_style": "solid" This will make the cursor not blink, like in vim. sublime might freeze when you do this. It’s a bug; just restart sublime after changing the file. ctrl+r in vim means "redo". But there is a handy ctrl+r shortcut in sublime that gives an "outline" of a file. I remapped it to alt+r by putting this in the User keymap { "keys": ["alt+r"], "command": "show_overlay", "args": {"overlay": "goto", "text": "@"} }, Add the ability to toggle vintageous on and off Mac users: you will not have the ability to hold down a navigation key (like holding j to go down). To fix this, run the commands specified here: https://gist.github.com/kconragan/2510186 Now you should be able to restart sublime and have a great vim environment! Sweet Dude. Switch Caps Lock and Escape I highly recommend you switch the mapping of your caps lock and escape keys. You'll love it, promise! Switching the two keys is platform dependent; google should get you the answer Other I don’t personally use these yet, but I’ve heard other people do! :wqa - Write and quit all open tabs (thanks Brian Zick) Source: http://vimsheet.com/

Smite Xbox One Beta Giveaway

Avast Internet Security 2015 Serial Keys Till 2017 .

GitHub has revoked an unknown number of cryptographic keys used to access accounts after a developer found they contained a catastrophic weakness that came to light some seven years ago. The keys, which allow authorized users to log into public repository accounts belonging to the likes of Spotify, Yandex, and UK government developers, were generated using a buggy pseudo random number generator originally contained in the Debian distribution of Linux. During a 20-month span from 2006 to 2008, the pool of numbers available was so small that it made cracking the secret keys trivial. Almost seven years after Debian maintainers patched the bug and implored users to revoke old keys and regenerate new ones, London-based developer Ben Cartwright-Cox said he discovered the weakness still resided in a statistically significant number of keys used to gain secure shell (SSH) access to GitHub accounts. "If you have just/as of late gotten an email about your keys being revoked, this is because of me, and if you have, you should really go through and make sure that no one has done anything terrible to you, since you have opened yourself to people doing very mean things to you for what is most likely a very long time," Cartwright-Cox wrote in a blog post published Monday. "It would be safe to assume that due to the low barrier of entry for this, that the users that have bad keys in their accounts should be assumed to be compromised and anything that allowed that key entry may have been hit by an attacker." Cartwright-Cox told Ars that he found about 94 keys on GitHub that contained the Debian-derived weakness. He said that after he reported his finding to GitHub officials in March he learned the actual number of site users was much higher. GitHub revoked the keys early last month, he said. GitHub officials didn't respond to a request to comment. Separately, the UK developer said he found nine GitHub SSH keys that contained woefully insufficient numbers of bits. Two of them had only 256 bits, making it possible for him to factor them and clone the private key in less than an hour. The remaining seven had only have 512 bits. During the time the Debian bug was active, the pool of bits available when generating OpenSSH keys was so limited that there were only 32,767 possible outcomes for a given architecture, key size, and key type. Cartwright-Cox said attackers could have used the same methods he employed to find weak keys and then used several techniques to gain unauthorized access to the accounts the keys protected. The task would have been aided by obtaining the list of insecure Debian SSH keys off one or more public sites, such as this one. In an e-mail, he elaborated: If I wanted to be more noisy I could have just done what I said [in the blog post] and looped though the keys, that may or may not have set off alarms at Github itself (I'd give it a 25% chance that it would). So the breakdown of how this could have been done is the following: Grab the bad key list. It contains the public and private parts of all the SSH keys that would have been made if the user had a version of OpenSSH that had Debian RNG bug, then get each private key on the list, and try to log into GitHub's ssh with them. Depending on what key you succeed with it will tell you what user name it matches up with, in the example I provided since my key is loaded it tells me "Hi benjojo! You've successfully authenticated, but GitHub does not provide shell access." but if I was to try with a weak key that matched up with another user it would say "Hi {user}! You've successfully authenticated, but GitHub does not provide shell access." and then I know what user I can compromise with that. Technically, attackers don't even need the private key to see if a site accepts authentication from a user, HD Moore, chief research officer at Rapid7 and co-founder of the Metasploit hacking framework, told Ars. Just the public key and this Metasploit module will do. "This trick can also be used to see what internet-facing servers allow logins from what public keys, even if the private key is not available, which is a neat reconnaissance/opsec technique," Moore said. The randomness bug was introduced in late 2006, when Debian maintainers removed two lines of code in the OpenSSL code base in an attempt to fix warnings received by some users. In the process, the maintainers wiped out almost all of the entropy that OpenSSL relied on for its randomness engine. The epic mistake, which eventually migrated to the Ubuntu distribution of Linux as well, wasn't diagnosed for 20 months, and by that time an untold number of cryptographic keys had been generated. The bug was unusual in that installing a patch was only the beginning of the healing process. To fully recover, users had to revoke any keys made during that 20-month period and generate new ones using the updated OS. The discovery that GitHub users continued to rely on these hopelessly weak keys eight years after they came to light is testament to just how monumental the Debian debacle was and how hard it is for users to mop up after the mess it created. Source

http://incloak.com/ 7921952 7743499 1627809 8407371 3103436 6372048 1171704 9474799 7725061 4516984 7108043 3304803 1346819 9292694

Security researchers at the Central Intelligence Agency (CIA) have worked for almost decade to target security keys used to encrypt data stored on Apple devices in order to break the system. Citing the top-secret documents obtained from NSA whistleblower Edward Snowden, The Intercept blog reported that among an attempt to crack encryption keys implanted into Apple's mobile processor, the researchers working for CIA had created a dummy version of Xcode. CIA’s WEAPON TO HACK APPLE DEVICES Xcode is an Apple’s application development tool used by the company to create the vast majority of iOS apps. However using the compromised development software, CIA, NSA or other spies agencies were potentially allowed to inject surveillance backdoor into programs distributed on Apple's App Store. In addition, the custom version of Xcode could also be used to spy on users, steal passwords, account information, intercept communications, and disable core security features of Apple devices. The latest documents from the National Security Agency’s internal systems revealed that the researchers’ work was presented at its 2012 annual gathering called the "Jamboree" -- CIA sponsored secretive event which has run for nearly a decade -- at a Lockheed Martin facility in northern Virginia. KEYLOGGER FOR MAC COMPUTERS According to the report, "essential security keys" used to encrypt data stored on Apple’s devices have become a major target of the research team. Overall, the U.S. government-sponsored researchers are seeking ways to decrypt this data, as well as penetrate Apple's firmware, using both "physical" and "non-invasive" techniques. In addition to this, the security researchers also presented that how they successfully modified the OS X updater -- a program used to deliver updates to laptop and desktop computers -- in an attempt to install a "keylogger" on Mac computers. HACKING ENCRYPTION KEYS Another presentation from 2011 showed different techniques that could be used to hack Apple's Group ID (GID) -- one of the two encryption keys that Apple places on its iPhones. One of the techniques involved studying the electromagnetic emissions of the GID and the amount of power used by the iPhone’s processor in order to extract the encryption key, while a separate method focused on a "method to physically extract the [Apple's] GID key." Although the documents do not specify how successful or not these surveillance operations have been against Apple, it once again provoke the ongoing battle between spy agencies and tech companies, as well as the dishonesty of the US government. 'SPIES GONNA SPY' On one hand, where President Barack Obama criticized China for forcing tech companies to install security backdoors for the purpose of government surveillance. On the other hand, The Intercept notes that China is just following America's lead, that’s it. "Spies gonna spy," said Steven Bellovin, a computer science professor at Columbia University and former chief technologist for the FTC. "I’m never surprised by what intelligence agencies do to get information. They’re going to go where the info is, and as it moves, they’ll adjust their tactics. Their attitude is basically amoral: whatever works is OK." We have already reported about NSA and GCHQ’s various surveillance programs including PRISM, XkeyScore, DROPOUTJEEP, and many more. Source

The need to defend confidentiality of our sensitive information against persistently rising cyber threats has turned most of us toward using encryption on a daily basis. This is facilitated by easy-to-use GUI tools like TrueCrypt that offer advanced encryption without hassles. TrueCrypt offers ‘on-the-fly’ encryption, which means we do not have to wait for large files to decrypt after entering the correct passphrase; files are immediately accessible. Many of us have come to trust TrueCrypt to defend extremely sensitive personal and business secrets. However, there is no such thing as absolute security. Vulnerabilities always exist, and in this paper we look at some of the ways in which TrueCrypt security can be “beaten”. Please note that these attacks may not target a flaw in TrueCrypt itself, but rely on ‘bypassing’ TrueCrypt security or taking advantage of user negligence. This paper seeks to address TrueCrypt users who wish to understand known attacks against TrueCrypt, and forensics analysts who are interested in defeating TrueCrypt during the course of criminal investigations. Downloads: Evil Maid USB image Memory image and encrypted TrueCrypt volume Tools Used: TrueCrypt 7.1 (source code) Truecrack Unprotect Inception Volatility Aeskeyfinder Bulk Extractor\ Known Attacks against TrueCrypt In this paper, we will progress via attacks that are easily understood, and move toward attacks that require advanced understanding of TrueCrypt functionality and encryption systems. Dictionary Attacks The concept of a dictionary attack is simple. We sequentially try all entries in a dictionary file as potential passphrases until we succeed. However, there are obvious downsides to this approach. Most users who are using TrueCrypt to protect their sensitive information are smart enough to use complicated passphrases that would not be found in dictionaries. Also, this attack can get very time-consuming, depending on the size of the dictionary selected. Here, we use a tool called ‘truecrack’ to implement a dictionary attack on a protected TrueCrypt volume. We created a dummy dictionary with 7 phrases, the last of which was the correct passphrase [Figure 1]. Figure 1 Note: Such dictionary attacks on TrueCrypt are incredibly slow, since it uses the Password-Based Key Derivation Function 2 (PBKDF2) that is meant to slow down the password cracking process using key stretching. Brute Force Attacks Brute force attacks deploy a similar concept to dictionary attacks, except here every possible combination of characters is tried from a pre-determined set. To simulate a brute force attack on a TrueCrypt volume, we used the tool ‘unprotect.info’. First, we point it to the encrypted volume [Figure 2]. Figure 2 Next, we set the parameters to be used while implementing the attack [Figure 3]. These parameters will determine the total number of possible combinations. Note that we set the password to the encrypted volume as ‘haha’—a simple combination of 4 characters—to save time during experimentation. Figure 3 For example, in this case we knew the password to be 4 characters long and having all lower case characters. We set the parameters accordingly which gave us a total of (26*26*26*26) =456976 possible passphrases [Figure 4]. Figure 4 The tool sequentially tried all possible combinations until it got to the correct passphrase, which was then displayed to us [Figure 5]. Figure 5 As with dictionary attacks, PBKDF2 used in TrueCrypt would considerably slow down the brute force attacks. DMA Attacks DMA (Direct Memory Access) is used to acquire control of the RAM via the FireWire port. The attacker can then take a full memory dump even if a computer is locked or logged off. If the protected TrueCrypt volume is mounted while the memory dump is taken via a FireWire port, the resulting image would contain the cryptographic keys needed to decrypt and mount the TrueCrypt volume (as explained later in this paper). ‘Inception’ is a free tool that allows one to perform a FireWire attack. The best mitigation against this attack is to simply disable the FireWire drivers in the Operating System and render the port non-functional. Bootkit Attacks Rootkits are a form of advanced malware that facilitate stealthy deployment and operation of programs on a system. Bootkits are variants of rootkits that infect the Master Boot Record (MBR) or a boot sector Wik1. In case full disk encryption is being used, such bootkits are capable of manipulating the original bootloader and replacing it with an infected copy. Such an attack was implemented by researchers Alex Tereshkin and Joanna Rutkowska Ale2. This “evil maid” attack drew attention to the need for physical security of the device that holds the encrypted TrueCrypt volume. The idea is that even if the user is protecting his sensitive information using full disk encryption, the MBR itself is not encrypted and can be infected. Hence, if an attacker can boot your computer using a USB stick, he can overwrite the original bootloader and insert a type of “sniffer” that would “hook” a TrueCrypt password function and save the passphrase the next time the volume is mounted. This passphrase is then extracted by the attacker at a later time. Note: If you wish to replicate this experiment, you would need a copy of the Evil Maid infector image (see Downloads above), and a device that is using full disk encryption. Also note that it is best to use TrueCrypt 6.3a during this test since Evil Maid is no longer updated and is known to corrupt the bootloader when used against TrueCrypt 7.1a. Cached Passphrase Attacks Cached passphrases allow automatically mounting containers without requiring the user to enter the passphrase every time. This cached passphrase is located in ‘TrueCrypt.sys’. In case the user has explicitly told TrueCrypt to ‘cache’ passphrases [Figure 6], an attacker could locate this passphrase in a memory dump. Volatility framework provides a plugin called ‘TrueCryptpassphrase’ especially for the retrieval of cached passphrases from memory. Note that once the attacker has access to the passphrase, he would not need to know the details of the encryption algorithm used or the cryptographic keys. Figure 6 Decrypting and Mounting a TrueCrypt Volume using Cryptographic Keys Extracted from Memory Analyzing the Protected TrueCrypt Volume The first thing we need to do is make sure that we are, in fact, dealing with an encrypted TrueCrypt volume. TrueCrypt volumes are identified based on certain characteristics such as sizes that are multiple of 512 (block size of cipher mode), missing headers, etc. Volatility framework offers a ‘TrueCryptsummary’ plugin that can be used to locate information germane to TrueCrypt within our memory image [Figure 7]. Figure 7 Looking at the results, we know that TrueCrypt 7.0a was being used on the system and the protected volume was mounted while the memory was dumped. Also, we notice that ‘ppp.challange.vol’ is the TrueCrypt container. Understanding Cryptographic Keys TrueCrypt provides ‘on-the-fly‘ encryption, which means that the cryptographic keys have to be loaded in memory at all times while the protected TrueCrypt volume is mounted. By default, TrueCrypt uses AES encryption along with XTS, and the 256 bit primary and secondary keys are concatenated together to form one master key of 512 bits. You may search for these keys on RAM (system memory) or ‘hiberfile.sys’ (a file created during hibernation). Here, it is important to note that hiberfile.sys can only be expected to contain the keys if the protected TrueCrypt volume was mounted while the system went into hibernation. In case the protected volume was dismounted during hibernation, it is futile to look for the cryptographic keys on the RAM dump or hiberfile.sys. The keys are not stored on disk due to obvious security concerns Mic3. Searching for Cryptographic Keys in Memory Before we can extract keys from memory, we need to identify them. One approach is to attempt decryption of known plaintext using every possible combination of bytes. However, in the presence of bit errors in memory, this approach gets highly convoluted JAl084. Another approach is to cycle through each byte in memory and to treat the following block of a certain size as a key schedule. Then, a hamming distance is calculated pertaining to this word and the word that should have been generated based on surrounding words. If the number of bits that violate constraints germane to correct key schedule is small, the key is discovered JAl084. ‘Aeskeyfind’ implements this approach, and we use it to search for AES keys in our memory image [Figure 8]. Figure 8 Alternatively, you can use ‘bulk extractor’ to locate keys in memory [Figure 9]. Note that this tool also locates other information in memory such as emails, IP addresses, URLs, etc.\ Figure 9\ Figure 10 Figure 11 At this point, we know the two 256 bit primary and secondary AES keys and we can use these to mount the protected volume. However, we first need to fake a header. Faking a TrueCrypt Header Since we do know the actual passphrase pertaining to the protected volume, we will create a template containing a known passphrase and copy this to the protected volume. Later, we can use this known passphrase and the extracted AES keys to mount or decrypt the protected volume. ./TrueCrypt –text –create –encryption=aes –filesystem=FAT –hash=RIPEMD-160 –password=pranshu –random-source=/dev/random –size=33600000 –volume-type=normal anothvol Figure 12 Here, we are using TrueCrypt in ‘text’ mode to create a volume with default AES encryption, RIPEMD-160 hash, and a FAT file system. Please note that the size of the encrypted volume is 33.6 MB or 33600000 bytes. We need this TrueCrypt volume (with known password) to be of the same size [Figure 12]. In order to copy header information from this volume to the protected volume, we use ‘dd’ [Figure 13]: dd bs=512 count=1 conv=notrunc if=/root/TrueCrypt/Main/anothvol of=/root/ppp.challenge.vol Figure 13 Hard Coding Keys into TrueCrypt Source Code We now need to “patch” TrueCrypt so that it accepts the discovered AES keys. Here, we have patched TrueCrypt 7.1 (see Downloads above). For this purpose, we modify the ‘VolumeHeader.cpp’ file and hard code the AES keys in there Mic15 [Figure 14]. Figure 14 Now, we compile this modified source code and attempt to mount the protected volume using the known password [Figure 15]. ./TrueCrypt –text –mount-options=readonly –password=pranshu /root/ppp.challenge.vol /mnt/pranshu Figure 15 We have successfully mounted the protected TrueCrypt volume at ‘/mnt/pranshu/’ using the known password and hard coded AES keys. We can now view the sensitive file inside the volume [Figure 16]. Figure 16 Conclusion The purpose of this paper—like many researchers who studied and implemented attacks on TrueCrypt—is to make a TrueCrypt user aware of what protection is truly being offered. A false sense of security is highly perilous. For instance, it is imprudent to neglect physical security of the device while using TrueCrypt lest you fall prey to a bootkit attack or a DMA attack. On the other hand, keeping the protected volume mounted at all times, or for extended periods, increases the likelihood of getting cryptographic keys stolen from memory. Note that we have intentionally avoided discussing any commercial recovery software in this paper. As of this writing, there is a vague warning on TrueCrypt website that apprises users of “security issues” in TrueCrypt. There is no detailed information on this warning yet, however, if you wish to pay heed to it, you may use ‘Veracrypt’ as an alternative to TrueCrypt. References [1] Wikipedia. [Online]. http://en.wikipedia.org/wiki/Rootkit#Bootkits [2] Joanna Rutkowska Alex Tereshkin. The Invisible Things Lab’s blog. [Online]. http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-TrueCrypt.html [3] Michael Ligh. Volatility Labs. [Online]. http://volatility-labs.blogspot.com/2014/01/TrueCrypt-master-key-extraction-and.html [4] Seth D. Schoen, Nadia Heninger, William Clarkson, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, Edward W. Felten. J. Alex Halderman, “Lest We Remember: Cold Boot Attacks on Encryption Keys,” in Proc. 17th USENIX Security Symposium (Sec ’08), San Jose, CA, 2008. [5] Michael Weissbacher. Michael Weissbacher. [Online]. http://mweissbacher.com/blog/2011/05/17/plaidctf-writeup-fun-with-firewire/ [6] Michael Ligh, “Mastering TrueCrypt: Windows 8 and Server 2012 Memory Forensics,” in Open Memory Forensics Workshop, 2013. Source

1. Introduction In this third part of the series, we will see something similar to the second article but a little bit more advanced. This article will cover the Digital Signature Algorithm (DSA) and Digital Signature Standard (DSS). 2. Tools Needed The target file (CryptoChallenge3.exe) DSAK: My own DSA/DSS Keygenerator (requires dotNetFx4) PEiD .NET Reflector Reflexil 3. What is DSA/DSS? Digital Signature Algorithm (DSA) is a public-key signature scheme developed by the U.S. National Security Agency (NSA). It was proposed by the U.S. National Institute of Standards and Technology (NIST) back in 1991 and has become a U.S. Federal Information Processing Standard (FIPS 186) called the Digital Signature Standard (DSS). It is considered to be the first digital signature scheme recognized by any government. DSA is a variant of the ElGamal Signature Scheme. A. Parameters P = A prime number in range 512 to 1024 bits which must be a multiple of 64 Q = A 160 bit prime factor of P-1 G = H^((P-1)/Q) mod P. H is any number < P-1 such that H^((P-1)/Q) mod P > 1 X = A random number < Q Y = G^X mod P Public keys are: (Q, P, G and Y). Private key is X (To find X one must solve the DLP Problem). B. Signing To sign a message (M) follow these steps: Generate a random number K where (K < Q) Compute: R = (G^K mod P) mod Q Compute: S = (K^-1*(SHA(M) + X*R)) mod Q The pair C(R,S) is the signature of M. C. Verifying Given the signature C(R,S) one would verify it as follows: Compute: W = S^-1 mod Q Compute: U1 = (SHA(M) * W) mod Q Compute: U2 = (R*W) mod Q Compute: V = ((G^U1 * Y^U2) mod P) mod Q Confirm that V == R D. Example Using the tool that I’ve recently made, “DSAKEYGENERATOR“, we’ll be able to see the previous steps in action. The tool is user friendly and gives full control, meaning you can either generate keys and test them and/or input your own keys and work on them. Prime P bits size from 512 to 1024. Generate new keys. To test the keys. Calculate Y in case you’ve already had the keys from somewhere else. Generate new G and X keys, Y will also be calculated automatically. Clicking “TEST” will cause a new window to show up: A checkbox that generates a random K every one second (checked by default and must be unchecked when trying to sign). Button to sign a message. Button to verify a message. 4. Target analyses Here we have the challenge as you see in the picture below: We load up the challenge in PEiD: That’s something new, we have a non-packed/protected .NET application, not like the previous two challenges which were made in MASM, but that’s not a problem. Since it’s a .NET application, we cannot use OllyDbg, instead we’ll use .NET Reflector. So load up the assembly in Reflector and keep expanding until you reach Form1: There are a lot of methods as you might see, but what interests us more is the method btn_check_Click since it’s related to the only button in this challenge. Click that method and you shall see: The code is easy to understand, we have the typed name put in a variable ‘text’ and the typed serial in ‘input’ name length must be between 3 and 15. Serial length must be between 0x4f (79d) and 0×51 (81d). After that a method called isHex(string x) does some checking, let’s find out what’s inside: This method uses Regex’s isMatch method to see if the typed serial matches the Regex string “^[0-9A-Fa-f]{40}[-][0-9A-Fa-f]{40}?$”. Let me explain each Regex symbol: ^: Start of string. [0-9A-Fa-f]: One from 0 to 9, A to F or a to f. {40}: Exactly 40 characters. [-]: one hyphen. ?: Once or none. $: End of string So the serial must contain 40 hexadecimal characters, a hyphen ‘-’ and another 40 hexadecimal characters. If name and serial are okay, the serial will be split into two parts, the first part before the hyphen and the second part after the hyphen, and put in a string array called strArray. After that, a method is called to check whether the serial is right or wrong; this method has three string parameters verify(string name, string rx, string sx) and returns a bool. Let’s get inside that method: If we compare the variables (integer8, exp, integer10 and integer11) with the verifying steps of DSA we’ll know that: modulus = order Q n = prime P integer3 = generator G integer4 = public key Y integer6 = rx = R = strArray[0] which is the first part of the serial integer8 = sx = S = strArray[1] which is the second part of the serial integer8 = W exp = u1 integer10 = u2 integer11 = v Now we have everything we need, the only problem is that it will take so much time to solve DLP since P, G and Y are 512 bits size. So what we are going to do is to change the challenge’s keys with new ones that we will have their private key X, meaning we are going to patch the target. And that’s the job of Reflexil. First open DSAKeygenerator and generate some 512 bit keys. Leave it open. Assuming you have already downloaded Reflexil. Extract the rar file and you’ll find a dll inside a folder, it’s called “Reflexil.Reflector.AIO.dll”. Move it to somewhere else where it won’t be deleted (C for example). Now go back to Reflector and do as shown in the pictures below: Choose the dll file and close. Now go back to menu Tools and click Reflexil. Right Click on Offset 0 and click Edit. Change the operand at offset 0 with the generated Q in DSAKeygenerator. The same to offset 13 with P, offset 26 with G and offset 39 with Y. I’ve got the following keys generated in DSAKeygenerator: Q = EEFBBFE158DBB7C602BE9540B89FF681EED0310D P = 86CC13E777A3ED808B3B17B3AC6C78D5ABA5F15746B1A68C72B6F530A6B723390B486228E0F715DBB593206801DF48E3E56DF57336E2BD6219EE8DEFD001F6E7 G = 1E342C53DBE73C97FF8D8022B8EB18329181B821B10A5DBFC2688DDCC9DB5DF84079DA58E81FEEA43AAD38A8C1D3901E25859C7AB63AFEE1145EFD02DCC9B1AA X = AF12001D2043D47E8E1B661958177B6068C8FAA2 Y = 2C166A5F90BD4B40D159CD48CC4391A8322BF3839DB58DA6EB0EEDF9D322AC3446EBAB0362F6BFB7127320C6CCED2CF77C915A1B56E5CE57A1758B53DAFA9C45 The result in Reflexil must look like: Now on the assembly browser, right click on the main assembly (1) and do as follows: Now that we have the challenge patched with the new keys, we must generate the signature (R,S) using DSAKeygenerator (Hope you didn’t close it! If so just fill each key with the one on top without clicking the ‘generate keys’ button) and click TEST as shown below: I’ve changed M to “Jamal Chahir” and unchecked the “RAND” checkbox so that I can get a fixed R and S. Now all we’ve got to do is fill in the name and serial in the patched challenge with what we’ve got: Name: Jamal Chahir Serial: R-S = 5DD88D3FE73B83F8027BB0AD3A53D404F887840B-E189F0BAC17C03EDA24FD5FD837FA397D6501321 The above picture shows that we have successfully registered the application. That’s it. 5. Conclusion The whole idea behind this article was to show you that the key size is no problem once you completely understand the algorithm. But there still plenty of ways to manage that problem, depending on how the programmer thinks. Download links: Target: https://www.dropbox.com/s/u7ywze2gsmweskk/CryptoChallenge3.rar?dl=0 DSAK: https://www.dropbox.com/s/b7lveh2lc8fukcs/DSAK.rar?dl=0 PEiD : PEiD Download - Softpedia .NET Reflector: .NET decompiler: decompile any .NET code | .NET Reflector Reflexil: reflexil.net Sources: http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Source