Nytro

Cryptography Tutorials - Herong's Tutorial Examples Cryptography Tutorials - Herong's Tutorial Examples Copyright © 2011 by Dr. Herong Yang. All rights reserved. This cryptography tutorial book is a collection of notes and sample codes written by the author while he was learning cryptography technologies himself. Topics include blowfish, certificate, cipher, decryption, DES, digest, encryption, keytool, MD5, OpenSSL, PEM, PKCS#8, PKCS#12, private key, public key, RSA, secret key, SHA1, SSL, X.509. Table of Contents About This Book Cryptography Terminology Cryptography Basic Concepts What Is Cryptography? What Is Function? What Is Encryption? Introduction to DES Algorithm What Is Block Cipher? DES (Data Encryption Standard) Cipher Algorithm DES Key Schedule (Round Keys Generation) Algorithm DES Decryption Algorithm DES Algorithm - Illustrated with Java Programs DESSubkeysTest.java - DES Key Schedule Algorithm Illustration DES Key Schedule Algorithm Illustration Program Output DESCipherTest.java - DES Cipher Algorithm Illustration DES Cipher Algorithm Illustration Program Output DES Algorithm Java Implementation CipherDES.java - A Java Implementation of DES Java Implementation of DES - Test Cases DES Algorithm - Java Implementation in JDK JCE DES Java Implementation in JDK by Sun Steps of Using DES Algorithm in JDK JCE Testing DES Algorithm in JDK JCE What Is PKCS5Padding? JceSunDesPaddingTest.java - JCE DES Padding Test DES Encryption Operation Modes DES Encryption Operation Mode Introduction What is ECB (Electronic CodeBook) Operation Mode? What is CBC (Cipher Block Chaining) Operation Mode? What is CFB (Cipher FeedBack) Operation Mode? What is OFB (Output FeedBack) Operation Mode? DES Operation Modes in JCE JCE DES Operation Mode Testing Program JCE DES Operation Mode Testing Program Result DES in Stream Cipher Modes Introducting DES Stream Cipher Modes CFB (Cipher FeedBack) as a Stream Cipher OFB (Output FeedBack) as a Stream Cipher CFB and OFB Stream Ciphers Implemented in JCE JCE DES Stream Ciphers Testing Program JCE DES Stream Ciphers Testing Program Result PHP Implementation of DES - mcrypt mcrypt Library for PHP mcrypt Encryption Functions mcrypt DES Encryption Testing Program Block Padding in mcrypt Blowfish - 8-Byte Block Cipher What Is Block Cipher? Blowfish Cipher Algorithm Key Schedule (Sub-Keys Generation) Algorithm BlowfishJ - Java Implementation by Markus Hahn Blowfish Decryption Algorithm First 8366 Hex Digits of PI Secret Key Generation and Management javax.crypto.SecretKey - The Secret Key Interface javax.crypto.KeyGenerator - Generating Secret Keys Converting Secret Keys to and from Byte Arrays JceSecretKeyTest.java - Secret Key Test Program Cipher - Secret Key Encryption and Decryption javax.crypto.Cipher - The Secret Key Encryption Class JceSecretCipher.java - Secret Key Encryption Sample Program Blowfish Secret Key Encryption Tests Private key and Public Key Pair Generation Private and Public Keys and Related Interfaces KeyPair and KeyPairGenerator Classes Key Pair Sample Program - JcaKeyPair.java DSA Private Key and Public Key Pair Sample RSA Private Key and Public Key Pair Sample DiffieHellman Private Key and Public Key Pair Sample PKCS#8/X.509 Private/Public Encoding Standards What Is Key Encoding? PKCS#8 and X.509 Key Encoding Classes java.security.KeyFactory - Reading Encoded Keys JcaKeyFactoryTest.java - Key Factory Test Program Reading DSA Private and Public Key Files Reading RSA Private and Public Key Files Cipher - Public Key Encryption and Decryption javax.crypto.Cipher - The Public Key Encryption Class JcePublicCipher.java - Public Key Encryption Sample Program DSA Public Key Encryption Tests RSA Public Key Encryption Tests MD5 Mesasge Digest Algorithm What Is MD5 Message Digest Algorithm? MD5 Message Digest Algorithm Overview Using MD5 Message Digest in Java Using MD5 Message Digest in PHP Using MD5 Message Digest in Perl SHA1 Mesasge Digest Algorithm What Is SHA1 Message Digest Algorithm? SHA1 Message Digest Algorithm Overview Using SHA1 Message Digest in Java Using SHA1 Message Digest in PHP Using SHA1 Message Digest in Perl OpenSSL Introduction and Installation What Is OpenSSL? Installing OpenSSL on Windows OpenSSL Generating and Managing RSA Keys Generating New RSA Key Pairs Viewing Components of RSA Keys Encrypting RSA Keys OpenSSL Managing Certificates What Is a Certificate? Generating Self-Signed Certificates Viewing Components of Certificates OpenSSL Generating and Signing CSR Why Certificates Need to Be Signed by CA? Generating Certificate Signing Request (CSR) Viewing Components of Certificate Signing Request Signing a Certificate Signing Request OpenSSL Validating Certificate Path What Is a Certification Path? Certification Path Validation Rules Creating a Certificate Path with OpenSSL Validating a Certificate Path with OpenSSL "keytool" and "keystore" from JDK Certificates and Certificate Chains What Is "keystore"? "keytool" - Command Line Tool Generating Private Keys Exporting and Import Certificates Generating CSR (Certificate Signing Request) Cloning Certificates with New Identities "OpenSSL" Signing CSR Generated by "keytool" "OpenSSL" Acting as a CA (Certificate Authority) "OpenSSL" Generating CA's Private Key "OpenSSL" Self-Signing CA's Public Key "keytool" Generating Maria's Private Key "keytool" Generating Maria's CSR "OpenSSL" Signing Maria's CSR "OpenSSL" Managing Serial Numbers when Signing CSR "keytool" Importing CA's Own Certificate ""keytool" Importing Maria's Certificate Signed by CA Migrating Keys from "keystore" to "OpenSSL" Key Files No "keytool" Command to Export Keys "keytool -genkeypair" Generating PrivateKeyEntry "keytool -exportcert" Exporting PrivateKeyEntry "keytool -printcert" Printing Certificate Details "openssl x509" Viewing Certificate Details "DumpKey.java" Dumping Private Keys Out of "keystore" "openssl enc" Converting Keys from Binary to PEM "openssl dsa" Viewing Private and Public Key Pair Certificate X.509 Standard and DER/PEM Formats X.509 Certificate Standard What Is DER (Distinguished Encoding Rules) Encoding? What Is PEM (Privacy Enhanced Mail) Encoding? Certificate in PEM Format "keytool" Exporting Certificates in DER and PEM "OpenSSL" Viewing Certificates in DER and PEM "OpenSSL" Generating Certificates in DER and PEM "keytool" Viewing Certificates in DER and PEM "keytool" Importing Certificates in DER and PEM Migrating Keys from "OpenSSL" Key Files to "keystore" What Is PKCS#8? What Is PKCS#12? "openssl genrsa" Generating Private Key "openssl pkcs8" Converting Keys to PKCS#8 Format "openssl pkcs12" Merging Key with Certificate "keytool -list" Verifying PKCS#12 Files "keytool -importkeystore" Importing PKCS#12 Files Summary - Migrating "OpenSSL" Keys to "keystore" Summary - Migrating "keystore" Keys to "OpenSSL" Using Certificates in IE 7 Why Using Certificates with Web Browsers? Visiting a "https" Web Site with IE Viewing Certificate Details Viewing Certificate Path Installing Certificate Permanently in IE Managing Certificates in Certificate Stores Exporting Certificates Out of IE 7 OpenSSL Viewing Certificates Exported from IE 7 Importing CA Certificate into IE 7 Importing Certificate Path into IE 7 Using Certificates in Firefox 3 Visiting a "https" Web Site with Firefox Viewing Certificate Details Managing Certificates in Certificate Stores Exporting Certificates Out of Firefox 3 OpenSSL Viewing Certificates Exported from Firefox 3 Importing CA Certificate into Firefox Importing Certificate Path into Firefox References Printable Copy - PDF Version Keywords: Cryptography, Encryption, Security, Tutorial, Example Previous Version: Cryptography Tutorials - Herong's Tutorial Notes Sursa: Cryptography Tutorials - Herong's Tutorial Examples

Voi fi intotdeauna activ.

Pe langa faptul ca e o porcarie, uite cata rahatul: for(i=0;i<1;i++)

Daca nu e ceva strict, poti trimite date din server cand exista. Problema e cu keep-alive-ul, dupa ceva timp, ti se taie conexiunea daca nu se trimit date. Cred ca e ok sa faci un request la 15-20 de secunde, desi nu e rapid, nu faci tone de trafic. Dar mai simplu e sa pastrezi o conexiune activa, cu pachete de keep-alive, si din server trimiti datele cand apar.

Eu. Dar nu sunt convins de idei. Cine voteaza? Pe cine? De ce? Pe ce criterii se aleg? Cand se voteaza? Cat timp se voteaza? Conteaza detalii ca vechime, numarul de posturi, numarul de like-uri sau reputatia acelui user?

POC or didn't happen

Cred ca daca pun la vot, "Cati vreti sa NU mai fiu administrator", am o vaga impresie ca va trebui sa imi dau demisia Nu, daca noi decidem ca un moderator a gresit, discutam cu el si se rezolva. Apoi, 5 noiembrie? Cu asta ai stricat tot.

Cu ce l-ar incanta pe un utilizator sa vada IP-urile cu care a intrat? Sigur, sa poata vedea daca altcineva a intrat pe contul sau, dar presupunandu-se ca e un forum de securitate IT, nu prea ar trebui sa fie cazul... PS: Acum ceva timp, tex a dat un UPDATE ... SET ipaddress = "127.0.0.1", fara WHERE, deci intelegti cam care e ideea.

Membri: 85,146 Sa vedeti cati vor fi diseara. :-> Continua Polonic.

Linux Gaming News: Vote on Your Linux Games Now We've known for a while that Valve is bringing Steam to Linux. One of the most exciting Steam projects for Linux gamers is... || Join the chat: http://bit.ly/nixgoogleplus || Steam Greenlight, where we, the gamers, can vote on which games we want to see made. In this week's OS.ALT I discuss Steam Greenlight and how it impacts Linux Games. Via: Facebook...

Merge greu

Live streaming: http://www.privesc.eu/Arhiva/12404/Marsul-unionist-din-16-septembrie-2012 Am scos si eu steagul cu Romania pe geam.

Warn - Categorie gresita.

Acum, haideti cel putin sa incercam, sa vedem ce iese. Vom discuta cei din staff, si vom face categoria respectiva, sper ca diseara.

Si cam ce sugestii aveti in legatura cu numele categoriei: 1355 1337 Zone, Noob Zone, Incepatori, Plm... ?

Pune la vot.

The Case of the PDF Malware 2012.07.31 I’ve been working with PDFs for the past few weeks and since I have a large collection of PDF files, going through them all has been taking a lot of time. I’ve seen a few different exploits, but there is one that especially caught my attention because I thought it was pretty wicked and nicely conceived. It all started after I ran a couple of samples through a script a while ago. The Strange PDF File The PDF in question can be found on Virus Total: MD5: 805538ff200ec714a735ef3bc1fff1f0 SHA256: e108432dd9dad6ff57c8de6e907fd6dd25b62673bd4799fa1a47b200db5acf7c Figure 1. PDF parsing In Figure 1, we can see that the PDF contains data that will be decoded using the /CCITTFaxDecode filter (see Portable Document Format - Wikipedia, the free encyclopedia). Since this is not very common, I decided that it was worth a little more investigation. We know that opening that file will cause Acrobat Reader to attempt to fetch something from a given web server (which is bad for obvious reasons). Once we launch Acrobat Reader and open that file, nothing seems to happen. From a user’s standpoint, it may not be much of a concern, but from ours, it is worrisome. The PDF file gets loaded by AcroRd32.exe and, while the window doesn’t appear, the application is obviously doing something. There is no Heap Spray attempt by any script inside the PDF but there is something running that should not be doing so. Catching Network Activity Since we know that the malware is trying to retrieve something off of the internet, I put a breakpoint inside urlmon.dll. Most malware use urlmon!URLDownloadToFileA() because it’s very simple to call, as all that is required is a URL and a file name. With my breakpoint set up, I let the malware run and lo and behold, we get a hit on the aforementioned API: Figure 2. URLDownloadFileToA call We can see here that the malware has made the call to the API and looking at the stack we can trace it back to see where is exploit is running from. Let’s take a look at the stack: Figure 3. URLDownloadFiletoA stack frame The call seems to emanate from icucnv34.dll, which is a valid DLL loaded by Acrobat Reader. So far, nothing seems to be particularly wrong, but if we look at the caller address a little further, we can see that there’s something fishy about it. As a reminder, before we go ahead, most shell code is located somewhere on the stack or on the heap. For instance, after a successful heap spray, the shell code will be running from some part of the heap allocated by the malicious script. This is where it becomes interesting… Where is the shell code? As we saw in Figure 3, URLDownloadFileToA is called from somewhere within icucnv34.dll (or so it seems). Let’s see what the PEB can tell us. After entering the !PEB command, here’s what Windbg gives us: Figure 4. PEB We’ve spotted our DLL. The module start address is 0x4a800000. In Figure 4, it says that the return address for URLDownloadFileToA is icucnv34+0x456b1, which is 0x4a8456b1. This is rather interesting because the DLL itself is only 300K and obviously not all of it is code. Here are the details: Figure 5. Module Information What did we get here? Base address = 0x4a800000 Size of code = 0x21000 Since the return address of the API is icucnv34+0x456b1, the code is not running inside the DLL code segment! So where is it exactly? Figure 6. Shell code memory dump It appears that the code we are looking at is located right before the modules resources. Going to 0x4a8456b1 and back a little, we can determine the entry point of the shell code. As shown in Figure 6, the URL accessed by the API is located at the end of the code, which starts with a NOP (0x90) followed by a short jump (0xeb 0x11). Initially this shell code is XORed out and the code that is between the beginning and the first jump address is used to XOR the rest of it with 0xA6. As we know, a Windows executable is structured something like this (rough description): Figure 7. Executable structure If some shell code is copied somewhere in between the data and the resources, it will appear to be part of the DLL. Hiding with a module space As we’ve just observed, the shell code is not copied on the heap but within the address space of a chosen DLL. This is pretty wicked because regular shell code detection may be fooled by this, as it would expect the return address of an API to be on the heap/stack and therefore not inside a DLL address space. If your detection is based on checking whether a return address is within the boundaries of a module, this sort of shell code will evade it. What the detection engine must do is to narrow the address range to be within the code segment of the module. In this particular case, the icucnv43.dll is loaded at 0x4a800000 and the code starts at base image + 0x1000, hence 0x4a801000. As the [!dh] showed us, the code size is 0x21000 which means that the runnable code of the DLL is 0x4a801000 – 0x4A822000. Looking at Figure 7, it becomes obvious that the shell code we’re looking at is running outside the .text segment. Since the shell code executes way outside of this range, we can deduct that it is indeed some malicious code and we can report the network activity as well as the use of shell code for that sort of PDF exploit. Emmanuel Thioux on 2012.07.31 Malware Research Sursa: Malware Intelligence Lab from FireEye - Research & Analysis of Zero-Day & Advanced Targeted Threats:The Case of the PDF Malware

[h=2]Getting Tricky With Shellcode[/h]2012.09.11 For those who read my previous blog regarding a very interesting shellcode exploit running inside a PDF, I got a little curious during my spare time and, upon further research, I realized that there is yet another way to insert shellcode inside a Windows program. The assumption here is that the reader knows about the Windows executable format (hence PE headers) and has some knowledge of DEP, ASLR, and some exploit techniques such as ROP chains. [h=3]Bypassing DEP[/h] For a while now, Windows has been using DEP to prevent a lot of exploits from working. The way it works is quite simple. Memory (in the form of subsequent pages) is allocated with certain protection attributes, those being: Read Write Execute Combination of all the above Code is normally flagged as Read/Executable, while data is Read/Write. Some other things like resources (Icons, Bitmaps, etc.) are set as Read Only. If memory is allocated as Read/Write and a program attempts to execute from that location, an exception will be thrown and the program will be stopped. Windows will then inform the user that DEP prevented something bad from happening. Currently, shell code is using ROP as a mean to bypass DEP. By creating ROP gadgets on the stack, the code that is executed is valid and won’t trigger DEP. Most of the time, ROP gadgets will make a call to VirtualProtect: BOOL WINAPI VirtualProtect( _In_ LPVOID lpAddress, _In_ SIZE_T dwSize, _In_ DWORD flNewProtect, _Out_ PDWORD lpflOldProtect ); There are other APIs that can be used to accomplish the same thing, but for simplicity's sake, I will only use VirtualProtect. By using this API, the malware, once the memory has been allocated or found otherwise, will change the protection flags to include EXECUTE. From that point on, the battle is pretty much won since DEP won’t see anything. [h=3]Filling the gap[/h] The issue with the aforementioned approach is that a call to VirtualProtect can be detected fairly easily. So how can we do without it? [h=3]Windows Executable Files And Their Sections[/h] As shown in my other post, a Windows executable is made of several, contiguous chunks of bytes. [TABLE] [TR] [TD=width: 147] DOS headers [/TD] [/TR] [TR] [TD=width: 147] PE headers [/TD] [/TR] [TR] [TD=width: 147] Code segment(s) [/TD] [/TR] [TR] [TD=width: 147] Data segments(s) [/TD] [/TR] [TR] [TD=width: 147] Resources [/TD] [/TR] [/TABLE] You can find a much better explanation here. Let’s look at a real sample. I am running Regedit.exe on Windows XP SP3. Figure 1. PEB In Figure 1, we can see the PEB of Regedit.exe. I have outlined RPCRT4.dll because it is of particular interest. The module is located at 0x77E70000 and here’s the output of [!dh 0x77E70000]: 0:001> !dh 77e70000 File Type: DLL FILE HEADER VALUES 14C machine (i386) 5 number of sections 49E5F46D time date stamp Wed Apr 15 07:51:25 2009 0 file pointer to symbol table 0 number of symbols E0 size of optional header 210E characteristics Executable Line numbers stripped Symbols stripped 32 bit word machine DLL OPTIONAL HEADER VALUES 10B magic # 7.10 linker version 89200 size of code 5C00 size of initialized data 0 size of uninitialized data 628F address of entry point 1000 base of code ----- new ----- 77e70000 image base 1000 section alignment 200 file alignment 3 subsystem (Windows CUI) 5.01 operating system version 5.01 image version 4.10 subsystem version 92000 size of image 400 size of headers 938E3 checksum 00040000 size of stack reserve 00001000 size of stack commit 00100000 size of heap reserve 00001000 size of heap commit 0 DLL characteristics 19C8 [ 436F] address [size] of Export Directory 82290 [ 64] address [size] of Import Directory 8C000 [ 408] address [size] of Resource Directory 0 [ 0] address [size] of Exception Directory 0 [ 0] address [size] of Security Directory 8D000 [ 4488] address [size] of Base Relocation Directory 836EC [ 38] address [size] of Debug Directory 0 [ 0] address [size] of Description Directory 0 [ 0] address [size] of Special Directory 0 [ 0] address [size] of Thread Storage Directory 30468 [ 40] address [size] of Load Configuration Directory 0 [ 0] address [size] of Bound Import Directory 1000 [ 378] address [size] of Import Address Table Directory 0 [ 0] address [size] of Delay Import Directory 0 [ 0] address [size] of COR20 Header Directory 0 [ 0] address [size] of Reserved Directory SECTION HEADER #1 .text name 8274B virtual size 1000 virtual address 82800 size of raw data 400 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60000020 flags Code (no align specified) Execute Read Debug Directories(2) Type Size Address Pointer cv 23 83728 82b28 Format: RSDS, guid, 2, rpcrt4.pdb ( 10) 4 83724 82b24 SECTION HEADER #2 .orpc name 690D virtual size 84000 virtual address 6A00 size of raw data 82C00 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60000020 flags Code (no align specified) Execute Read SECTION HEADER #3 .data name EC8 virtual size 8B000 virtual address C00 size of raw data 89600 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers C0000040 flags Initialized Data (no align specified) Read Write SECTION HEADER #4 .rsrc name 408 virtual size 8C000 virtual address 600 size of raw data 8A200 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40000040 flags Initialized Data (no align specified) Read Only SECTION HEADER #5 .reloc name 4488 virtual size 8D000 virtual address 4600 size of raw data 8A800 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 42000040 flags Initialized Data Discardable (no align specified) Read Only If we look at the optional header values, we can see that the size of the code for the entire module is 0x89200. Now, if you look at the two first sections, [.text] and [.orpc] we can see that [.text] has a size of 0x82800 and [.orpc] has a size of 0x6A00. 0x82800 + 0x6A00 = 0x89200, so far so good. Let’s look closely at those two sections… [.text]: Virtual Address: 0x1000, which goes with the Optional Header. Therefore, the code starts at 0x77E71000 and ends at 0x77EF3800. [.orpc]: Virtual Address: 0x8B000 Therefore, the code starts at 0x77EFB000 and ends at 0x77F01A00. If we were to compute the size of those sections combined we would end up with 0x90A00 which is 0x7800 (30720d) bytes larger than the given code size. [h=3]Section Padding[/h] The 30720 extra bytes are basically just padding. Most are set to zero and some may contain some random looking values. That space between [.text] and [.orpc] is not part of those sections, and its use is unknown. Since it is not declared data or code, we can assume that those bytes can be overwritten. Figure 2. End of .text section As the figure above shows, the end of the [.text] code section ends with some debug info and the rest of the page is padded with zeros. Then, there is more padding until the address reaches 0x77EFB000, which is the start of the [.orpc] section. Those padded gaps are very interesting because they are part of some code section, but obviously are not used. In this particular case, the padding spreads across a fair amount of memory and the protection of that chunk of memory is marked as EXECUTE. Of course, in order to write the shellcode in that spot, we would have to temporarily change the page protection to [W]rite, or call WriteProcessMemory() which would essentially do this for us. Let’s go back to the fictitious ROP exploit I was talking about earlier. Since we know that there is available memory with the proper protection flag, there is no longer a need to bother with VirtualProtect. The compiler used to create the DLL is kind enough to provide our exploit with that little piece of malware heaven. We can now craft a targeted exploit (on the same OS/Service Pack) since we know the location of the padded area, or if we want to be fancy, we could read the sections from the PE header and figure out a spot to write our code into. There is nothing DEP can do about this since the page protection never changes and the shell code resides within the code segment. The only way to detect the shellcode is to validate the address it runs at. For instance, looking at Figure 2, if the shellcode was to be written at [0x77EF3800], we would be able to find it because the section actually ends there. The detection algorithm would have to go through each Code section, calculate the address range and check whether or not the code runs within those limits. By placing the shell code within those tiny gaps in the executable, malware writers could potentially defeat anti-malware software that make sloppy checks as to from where APIs are called. Therefore, it is crucial for the "good guys" to be thorough in their work and to make sure to check every nook and cranny where malware could hide. Emmanuel Thioux on 2012.09.11 Sursa: Malware Intelligence Lab from FireEye - Research & Analysis of Zero-Day & Advanced Targeted Threats:Getting Tricky With Shellcode

Da postati si voi unde apare aia, ca nu am de unde sa stiu: Search, New posts sau cine stie unde.

Baaa, cum sa pui X pe Dinamo - CFR? Se muta la gunoi.

Si cum putem avea garantia ca nu e backdoored? Nu sta nimeni sa analizeze fiecare executabil care se posteaza. Daca are un format video nu e nicio problema. Apoi, desigur, calitatea ar fi mult mai buna. Ai putea incerca sa scapi de aceste aere de expert, nu dau deloc bine.

Ha?