This is a presentation I put together and presented for my colleagues at IBM back in 2006. I started on the section featuring heap exploits and never finished it. I want to finish it someday.
How to write rust instead of c and get away with itFlavien Raynaud
Ever tried optimizing a slow Python application and thought: “Oh! I wish I could just write this bit it in Rust”? Well, turns out you can! Let’s discuss why Rust is a better choice than C, how to use Rust to make your apps lightning fast and how to get away with it; without your users even noticing.
As Infrastructure Engineers at Yelp, the challenge we face everyday is: scale. Yelp is mostly a Python shop, so our work often revolves around making Python applications run faster. Until now, we have been using different techniques: faster interpreters, or, more often, C code.
Given its safety guarantees, performance and promise of better tooling than C, we decided we had to give Rust a try. The initial results helped reinforce that there was a lot of opportunity for Rust to play an important role in our production code.
Yelp heavily relies on the Apache Avro serialization format for its internal infrastructure. During the talk, we will show how we implemented avro-rs, an Avro serialization/deserialization library in Rust, how we were able to call it from Python (and in theory from any other language) with very little code, using tools such as cbindgen, CFFI and Milksnake.
This talk would outline how easy it is to write interoperable code in a performant language like Rust and why a company should invest in Rust, over the many other available alternatives, to run production services.
How to write rust instead of c and get away with itFlavien Raynaud
Ever tried optimizing a slow Python application and thought: “Oh! I wish I could just write this bit it in Rust”? Well, turns out you can! Let’s discuss why Rust is a better choice than C, how to use Rust to make your apps lightning fast and how to get away with it; without your users even noticing.
As Infrastructure Engineers at Yelp, the challenge we face everyday is: scale. Yelp is mostly a Python shop, so our work often revolves around making Python applications run faster. Until now, we have been using different techniques: faster interpreters, or, more often, C code.
Given its safety guarantees, performance and promise of better tooling than C, we decided we had to give Rust a try. The initial results helped reinforce that there was a lot of opportunity for Rust to play an important role in our production code.
Yelp heavily relies on the Apache Avro serialization format for its internal infrastructure. During the talk, we will show how we implemented avro-rs, an Avro serialization/deserialization library in Rust, how we were able to call it from Python (and in theory from any other language) with very little code, using tools such as cbindgen, CFFI and Milksnake.
This talk would outline how easy it is to write interoperable code in a performant language like Rust and why a company should invest in Rust, over the many other available alternatives, to run production services.
Allison Kaptur: Bytes in the Machine: Inside the CPython interpreter, PyGotha...akaptur
Byterun is a Python interpreter written in Python with Ned Batchelder. It's architected to mirror the structure of CPython (and be more readable, too)! Learn how the interpreter is constructed, how ignorant the Python compiler is, and how you use a 1,500 line switch statement every day.
Cassandra Community Webinar | Introduction to Apache Cassandra 1.2DataStax
Title: Introduction to Apache Cassandra 1.2
Details: Join Aaron Morton, DataStax MVP for Apache Cassandra and learn the basics of the massively scalable NoSQL database. This webinar is will examine C*’s architecture and its strengths for powering mission-critical applications. Aaron will introduce you to core concepts such as Cassandra’s data model, multi-datacenter replication, and tunable consistency. He’ll also cover new features in Cassandra version 1.2 including virtual nodes, CQL 3 language and query tracing.
Speaker: Aaron Morton, Apache Cassandra Committer
Aaron Morton is a Freelance Developer based in New Zealand, and a Committer on the Apache Cassandra project. In 2010, he gave up the RDBMS world for the scale and reliability of Cassandra. He now spends his time advancing the Cassandra project and helping others get the best out of it.
lldb kann mehr als nur einfache Breakpoints oder po. In dem Vortrag zeigt Oliver Bayer, wie sich mit Hilfe von lldb Programmcode zur Ausführungszeit manipulieren lässt, ohne das hierfür der Sourcecode anzupassen ist. Sei es, damit Test- oder Debugcode nicht in die produktiv App gelangt, oder weil der Sourcecode für einen Teil der App nicht vorliegt.
Event: macoun, 04.10.2019
Speaker: Oliver Bayer, inovex
Mehr Tech-Vorträge: inovex.de/vortraege
Mehr Tech-Artikel: inovex.de/blog
Course : Introduction to Big Data with Apache Spark : http://ouo.io/Mqc8L5
Course : Spark Fundamentals I : http://ouo.io/eiuoV
Course : Functional Programming Principles in Scala : http://ouo.io/rh4vv
Allison Kaptur: Bytes in the Machine: Inside the CPython interpreter, PyGotha...akaptur
Byterun is a Python interpreter written in Python with Ned Batchelder. It's architected to mirror the structure of CPython (and be more readable, too)! Learn how the interpreter is constructed, how ignorant the Python compiler is, and how you use a 1,500 line switch statement every day.
Cassandra Community Webinar | Introduction to Apache Cassandra 1.2DataStax
Title: Introduction to Apache Cassandra 1.2
Details: Join Aaron Morton, DataStax MVP for Apache Cassandra and learn the basics of the massively scalable NoSQL database. This webinar is will examine C*’s architecture and its strengths for powering mission-critical applications. Aaron will introduce you to core concepts such as Cassandra’s data model, multi-datacenter replication, and tunable consistency. He’ll also cover new features in Cassandra version 1.2 including virtual nodes, CQL 3 language and query tracing.
Speaker: Aaron Morton, Apache Cassandra Committer
Aaron Morton is a Freelance Developer based in New Zealand, and a Committer on the Apache Cassandra project. In 2010, he gave up the RDBMS world for the scale and reliability of Cassandra. He now spends his time advancing the Cassandra project and helping others get the best out of it.
lldb kann mehr als nur einfache Breakpoints oder po. In dem Vortrag zeigt Oliver Bayer, wie sich mit Hilfe von lldb Programmcode zur Ausführungszeit manipulieren lässt, ohne das hierfür der Sourcecode anzupassen ist. Sei es, damit Test- oder Debugcode nicht in die produktiv App gelangt, oder weil der Sourcecode für einen Teil der App nicht vorliegt.
Event: macoun, 04.10.2019
Speaker: Oliver Bayer, inovex
Mehr Tech-Vorträge: inovex.de/vortraege
Mehr Tech-Artikel: inovex.de/blog
Course : Introduction to Big Data with Apache Spark : http://ouo.io/Mqc8L5
Course : Spark Fundamentals I : http://ouo.io/eiuoV
Course : Functional Programming Principles in Scala : http://ouo.io/rh4vv
Exploit Research and Development Megaprimer: Unicode Based Exploit DevelopmentAjin Abraham
Exploit Research and Development Megaprimer
http://opensecurity.in/exploit-research-and-development-megaprimer/
http://www.youtube.com/playlist?list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf
Rooting Your Internals: Inter-Protocol Exploitation, custom shellcode and BeEFMichele Orru
Inter-protocol Exploitation removes browser-based attacks from being
dependent upon browser vulnerabilities.
It increases the number of potential exploits to include many service
vulnerabilities throughout the internal corporate network.
This includes whatever service can be contacted via a browser request.
Multiple protocols like IMAP, SMTP, POP, SIP, IRC and others are "tolerant"
to errors, and they don't reset the connection with the client if they
receive
data that is not compliant with the protocol grammar.
This leads to the possibility of interacting with such protocols with
HTTP requests,
even without the need of a SOP bypass.
During the talk, we will see a demonstration on how to compromise an
IMAP server that sits in the victim's internal network through its
browser hooked
in BeEF.
This will include disabling the browser's PortBanning, identifying the
victim's internal network IP and the live hosts in the subnet,
followed by a port scan and finally sending the custom BeEF Bind
shellcode after the IMAP service
has been localized.
Exploit Research and Development Megaprimer: Win32 EgghunterAjin Abraham
Exploit Research and Development Megaprimer
http://opensecurity.in/exploit-research-and-development-megaprimer/
http://www.youtube.com/playlist?list=PLX3EwmWe0cS_5oy86fnqFRfHpxJHjtuyf
This presentation is designed to provide a basic overview of the following: System Organization, Memory Organization, Stack Organization (For Function Calls), A Vulnerable C Program, Exploiting Buffer Overflow
Need help with this paperThis assignment consists of writing resea.pdfsktambifortune
Need help with this paper
This assignment consists of writing research paper surveying a popular algorithm. Your paper
must conform to
the American Psychological Association (APA) writing style.
There are many good online resources for the APA style.Your paper must use reputable
scholarly references. Most Web sources such as blog, forums, and personal website are not
considered reputable(do not cite or use any Wiki or Answer.com type websites). Your paper
should use 11pt or 12pt font size for the main text. Other text such as figure and table labels and
captions, if applicable, should be no smaller then 10pt. A typical research paper for this
assignment is about 7-10 double spaced pages (not including the cover page or reference page).
Topics:
Choose one of the following algorithms areas to write about. Potential algorithm topics related
to the algorithm area are included in parenthesis as examples.
1.Hashing Algorithms (e.g.SHA-3;Message Digest-5;Cryptography algorithms such as
Advanced Encryption Standard, Blowfish,Elliptic curve cryptography;Digital signature
algorithms; Bitcoin Mining)
2.Compression Algorithms (e.g. LZO, Data differencing, Huffman Coding)
3.String Matching (e.g Google’s PageRank algorithm , DNA sequence algorithms, Spell
checking algorithms)
4.Memory Management (e.g. Garbage Collection, Buddy Methods, Paging
algorithms,Sequential-Fit Methods)
Solution
public final category Huffman non-public Huffman() ;
non-public static category HuffmanNode
}
non-public static category HuffManComparator implements Comparator<HuffmanNode> come
back node1.frequency - node2.frequency;
}
}
/**
* Compresses the string victimisation huffman formula.
* The huffman tree and also the huffman code area unit serialized to disk
*
* @param sentence The sentence to be serialized
* @throws FileNotFoundException If file isn\'t found
* @throws IOException If IO exception happens.
*/
public static void compress(String sentence) throws FileNotFoundException, IOException ought
to atleast have one character.\");
}
final Map<Character, Integer> charFreq = getCharFrequency(sentence);
final HuffmanNode root = buildTree(charFreq);
final Map<Character, String> charCode = generateCodes(charFreq.keySet(), root);
final String encodedMessage = encodeMessage(charCode, sentence);
serializeTree(root);
serializeMessage(encodedMessage);
}
non-public static Map<Character, Integer> getCharFrequency(String sentence) else
}
come map;
}
/**
* Map<Character, Integer> map
* Some implementation of that treeSet is passed as parameter.
* @param map
*/
non-public static HuffmanNode buildTree(Map<Character, Integer> map) whereas
(nodeQueue.size() > 1)
// take away it to forestall object leak.
come nodeQueue.remove();
}
non-public static Queue<HuffmanNode> createNodeQueue(Map<Character, Integer> map)
return pq;
}
non-public static Map<Character, String> generateCodes(Set<Character> chars, HuffmanNode
node) {
final Map<Character, String> map = new HashMap<Character, String>();
doGenera.
Offensive cyber security: Smashing the stack with PythonMalachi Jones
: A necessary step in writing secure code is having an understanding of how vulnerable code can be exploited. This step is critical because unless you see the software from the vantage point of a hacker, what may look to be safe and harmless code, can have multiple vulnerabilities that result in systems running that software getting p0wned. The goal of this tech talk is to provide a step-by-step illustration of how not adhering to secure software design principles such as properly bounds checking buffers can open up computing devices to exploitation. Specifically, we will show that by using a very easy to use scripting language like python, we can do the following: 1) Smash the stack of a system running vulnerable code to gain arbitrary access. 2) Install a key logger that can phone home to a command and control server.
This presentation goes over basic exploitation techniques. Topics include:
- Introduction to x86 paradigms used exploited by these techniques
- Stack overflows including the classic stack smashing attack
- Ret2libc
- Format string exploits
- Heap overflows and metadata corruption attacks
An introduction to exploit development.
I gave this talk at Hack the North 2014, and most of this information is pulled out of classics like Smashing the Stack for Fun and Profit, so there shouldn't be anything novel in here.
1. Software Exploits How the Black Hats do what they do—Stack Overflows (or how a 1337 h4x0r can pwn your system) Kevin C. Smallwood March 2006
2.
3.
4.
5.
6.
7. Typical execve() program stack Low Memory High Memory 4-byte null Bottom of Stack 0xBFFFFFFC: Full pathname of executable—null-terminated env strings—null-terminated TERM=vt100, etc. argv strings—null-terminated argv[0], argv[1], etc. zero-filled padding 0 to 8064 bytes Starting address can easily be calculated: /bin/ls 8-bytes 112-bytes of ELF interpreter information env pointers argv pointers runtime data (from _start, etc.) envp argv argc Top of Stack Parameters to main()
Leet Speak: How an “elite” “hacker” can “own” your system.
Most of us have heard about buffer overflows. We know they are poor programming practices, and we may have heard that they allow the “Black Hats” access to our systems or programs in some way. But how do the Black Hats really exploit a small programming error? Why is a gets(), strcpy(), sprintf(), etc. such a problem? Bottom-line is that the Black Hats use buffer overflows on the stack to overwrite the return address to jump to their supplied code or crash the system. The key is that the Black Hat must control the input of the source buffer in order to overflow the destination buffer. If there is no outside of the program input for the source buffer, and the programmer knows that the source buffer is not larger than the destination buffer, a strcpy() is not a bad thing. You just need to know what to look for!
Knowing the contents of the stack and how functions are called is very important in the understanding of how to exploit a buffer overflow. Details of the stack will be covered in up-coming slides. Sometimes a Black Hat will just cause the exploited software to crash. This can cause a Denial of Service (DoS). If a service (local or remote) is important enough, denial to that service could result in lost revenue or reputation.
Shellcode got its name from the typical functionality of providing a privileged shell on a system. A remote exploit may just provide an entry point for the Black Hat to launch further attacks in order to gain full access to the system. Since the Black Hat can overwrite the return address of a function on the stack, that return address could be changed to the address of a program function that rewards the exploiter by applying credits to an account, zeroing-out a balance, increasing the quantity ordered (but not the total price), etc. A return address could be changed to execute a C-Library call like “execve()” to provide a shell or other privilege. This is one way around non-executable stack protection since the stack is just used to build proper arguments and then return into the library to do the dirty work.
The important items in this example program are in red . The main thing to note is that we are passing argv[2] from outside the program to a function where we do a strcpy() into a set-length buffer of size 400. It is pretty easy to supply more than 400 characters from the command line. Those extra characters will overflow the name[] buffer and over-write items on the stack including the return address.
This diagram is very important to know well. The stack grows from high memory to low memory. The starting address of the environment strings can easily be calculated if you know the full pathname of the command. The area on the stack for environment strings can be used to hold shellcode. The zero-filled padding space on the stack was something introduced in 2.5 for hyper-threading. The runtime data is information first loaded when a program is loaded to execute, but before the main() procedure is called. NOTE: This assumes that Red Hat’s exec-shield is not on.
Assembly code is using AT&T format: CMD <source> <destination>
Here we are saving the caller’s frame pointer along with making room for the local variables--in this case 400 bytes for the “name” character array.
The “leave” instruction restores/pops the save frame pointer to point back at the calling routine. The “ret” instruction pops the return address on the stack into the EIP register where execution will continue at that new address.
Let’s use a real simple code example to demonstrate the exploit.
Assume that the source string (i.e., “my ident”) is being provided from outside the program via the command line, a file, an environment variable, a pipe-line or even a network connection. The point is that the source string comes from outside the program and is under the control of the attacker.
The final result of “normal” and expected (by the software engineer) behavior.
Replacing the ASCII characters with numeric (hex) values.
Again, assume that the source string in the strcpy() is being provided from outside the program by the attacker.
The final result of our strcpy(). We have over-written the saved frame pointer and the return address. Note that with some skill, just over-writing the save frame pointer, we can influence the behavior of the executing program. However, it is much faster and more to the point to over-write the return address to execute our supplied “shell code.”
Here we see what is on the stack in numeric form.
Here is the crux of exploiting a stack (or heap) buffer overflow: executing supplied code not originally in the program.
In some cases, the appearance of a NULL is not critical, but in most cases, shell code should not contain any zero bytes. Our main target for this exploit is to find setuid programs so that we can gain more privileges than we currently have.
Various “tricks” used to avoid NULL bytes (for example, using “xor reg, reg” to zero-out that register).
Notice no NULL bytes.
Here is a simple program to tell us where the value of the environment variable is located on the stack.
Smashing the stack of a setuid root program and executing shell-spawning shell code results in an interactive root shell! Yes!
Five copies of the address copied onto the stack over-writing the return address!
Examples of problems from the Common Vulnerabilities and Exposures list and BugTraq.
Dangerous string handling functions: gets(), strcpy(), strcat(), sprintf(), vsprintf(), sscanf(), vscanf(), fscanf() Many of the insecure string handling functions have more secure functions that use a value to limit the number of characters processed. These include: fgets(), strncpy(), strncat(), snprintf(), vsnprintf() While these are more secure due to one of the parameters limiting the number of characters processed, be careful to fall victim to the off-by-one problem if the function automatically appends a NULL—the destination buffer size is now SIZE-1. Additionally, when concatenating strings in a buffer, the size of that buffer may only be the remaining space in the buffer and not the full size of the original buffer; this is a common programming mistake.
This is only the beginning!
The 24 bytes between the variables was found by experimentation.