American Fuzzy Lop (AFL) is a security-oriented fuzz testing tool.
In this talk, I demonstrate how dead-simple AFL is to use. I show how I used it to fuzz a Python library, discovering a subtle bug in the process.
Game Programming 04 - Style & Design PrinciplesNick Pruehs
Chapter 4 of the lecture Game Programming taught at HAW Hamburg.
Introduction to naming conventions, type and member design, exception design and common .NET interfaces.
American Fuzzy Lop (AFL) is a security-oriented fuzz testing tool.
In this talk, I demonstrate how dead-simple AFL is to use. I show how I used it to fuzz a Python library, discovering a subtle bug in the process.
Game Programming 04 - Style & Design PrinciplesNick Pruehs
Chapter 4 of the lecture Game Programming taught at HAW Hamburg.
Introduction to naming conventions, type and member design, exception design and common .NET interfaces.
Slides for a college course at City College San Francisco. Based on "Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software", by Michael Sikorski and Andrew Honig; ISBN-10: 1593272901.
Instructor: Sam Bowne
Class website: https://samsclass.info/126/126_S17.shtml
Steelcon 2014 - Process Injection with Pythoninfodox
This is the slides to accompany the talk given by Darren Martyn at the Steelcon security conference in July 2014 about process injection using python.
Covers using Python to manipulate processes by injecting code on x86, x86_64, and ARMv7l platforms, and writing a stager that automatically detects what platform it is running on and intelligently decides which shellcode to inject, and via which method.
The Proof of Concept code is available at https://github.com/infodox/steelcon-python-injection
Ice Age melting down: Intel features considered usefull!Peter Hlavaty
Decades history of kernel exploitation, however still most used techniques are such as ROP. Software based approaches comes finally challenge this technique, one more successful than the others. Those approaches usually trying to solve far more than ROP only problem, and need to handle not only security but almost more importantly performance issues. Another common attacker vector for redirecting control flow is stack what comes from design of today’s architectures, and once again some software approaches lately tackling this as well. Although this software based methods are piece of nice work and effective to big extent, new game changing approach seems coming to the light. Methodology closing this attack vector coming right from hardware - intel. We will compare this way to its software alternatives, how one interleaving another and how they can benefit from each other to challenge attacker by breaking his most fundamental technologies. However same time we go further, to challenge those approaches and show that even with those technologies in place attackers is not yet in the corner.
[2012 CodeEngn Conference 06] beist - Everyone has his or her own fuzzerGangSeok Lee
2012 CodeEngn Conference 06
퍼징 기술의 입문자, 중급자에 초점을 맞추었고 퍼징 기술에 대한 백그라운드 설명부터 시작하여 최근의 퍼징 기술에는 어떠한 것들이 있는지 살펴보고 퍼징 기술이 버그 찾기에 어떻게 쓰일 수 있는지 부터 시작하여 효율적인 퍼징 테크닉은 어떤것들이 있는지 설명한다. 또한, 각 퍼징 기법들의 한계점과 단점에 대해서 지적하며 왜 자신만의 퍼징 노하우와 방법이 필요한지 설명하면서 퍼징 기술의 복잡성과 다양성, 해커들은 어떤 기법을 선호하는지 소개한다. 발표자가 사용하고 있는 기법이나 노하우에 대해서도 공유 할 예정이다.
http://codeengn.com/conference/06
Session - Debugging memory stomps and other atrocities - Stefan Reinalter - T...Expert Insight
Stefan has spent many nights debugging hard-to-find bugs. Memory overwrites leading to random crashes, well-hidden stack overflows and other atrocities that will eventually give each programmer nightmares. In this talk, Stefan shares tips and tricks how to identify the root cause of such problems and how to debug them with little or no help from a debugger. He will also go into detail about which memory management techniques can be applied in order to prevent some of those bugs in the first place.
Readers will learn techniques that help with finding and identifying problems that are due to the low-level access granted by C++ and the sometimes careless use of pointers. The presented techniques are applicable to the PC as well as console platforms.
This is the slides accompanying the talk I gave at BSides Hannover 2015, discussing the reverse engineering and exploitation of numerous vulnerabilities in Icomera Moovmanage products along with the post exploitation of such, including the potential creation of a firmware rootkit
Slides for a college course at City College San Francisco. Based on "Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software", by Michael Sikorski and Andrew Honig; ISBN-10: 1593272901.
Instructor: Sam Bowne
Class website: https://samsclass.info/126/126_S17.shtml
CNIT 126: 10: Kernel Debugging with WinDbgSam Bowne
Slides for a college course at City College San Francisco. Based on "Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software", by Michael Sikorski and Andrew Honig; ISBN-10: 1593272901.
Instructor: Sam Bowne
Class website: https://samsclass.info/126/126_F18.shtml
Slides for a college course at City College San Francisco. Based on "Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software", by Michael Sikorski and Andrew Honig; ISBN-10: 1593272901.
Instructor: Sam Bowne
Class website: https://samsclass.info/126/126_S17.shtml
Steelcon 2014 - Process Injection with Pythoninfodox
This is the slides to accompany the talk given by Darren Martyn at the Steelcon security conference in July 2014 about process injection using python.
Covers using Python to manipulate processes by injecting code on x86, x86_64, and ARMv7l platforms, and writing a stager that automatically detects what platform it is running on and intelligently decides which shellcode to inject, and via which method.
The Proof of Concept code is available at https://github.com/infodox/steelcon-python-injection
Ice Age melting down: Intel features considered usefull!Peter Hlavaty
Decades history of kernel exploitation, however still most used techniques are such as ROP. Software based approaches comes finally challenge this technique, one more successful than the others. Those approaches usually trying to solve far more than ROP only problem, and need to handle not only security but almost more importantly performance issues. Another common attacker vector for redirecting control flow is stack what comes from design of today’s architectures, and once again some software approaches lately tackling this as well. Although this software based methods are piece of nice work and effective to big extent, new game changing approach seems coming to the light. Methodology closing this attack vector coming right from hardware - intel. We will compare this way to its software alternatives, how one interleaving another and how they can benefit from each other to challenge attacker by breaking his most fundamental technologies. However same time we go further, to challenge those approaches and show that even with those technologies in place attackers is not yet in the corner.
[2012 CodeEngn Conference 06] beist - Everyone has his or her own fuzzerGangSeok Lee
2012 CodeEngn Conference 06
퍼징 기술의 입문자, 중급자에 초점을 맞추었고 퍼징 기술에 대한 백그라운드 설명부터 시작하여 최근의 퍼징 기술에는 어떠한 것들이 있는지 살펴보고 퍼징 기술이 버그 찾기에 어떻게 쓰일 수 있는지 부터 시작하여 효율적인 퍼징 테크닉은 어떤것들이 있는지 설명한다. 또한, 각 퍼징 기법들의 한계점과 단점에 대해서 지적하며 왜 자신만의 퍼징 노하우와 방법이 필요한지 설명하면서 퍼징 기술의 복잡성과 다양성, 해커들은 어떤 기법을 선호하는지 소개한다. 발표자가 사용하고 있는 기법이나 노하우에 대해서도 공유 할 예정이다.
http://codeengn.com/conference/06
Session - Debugging memory stomps and other atrocities - Stefan Reinalter - T...Expert Insight
Stefan has spent many nights debugging hard-to-find bugs. Memory overwrites leading to random crashes, well-hidden stack overflows and other atrocities that will eventually give each programmer nightmares. In this talk, Stefan shares tips and tricks how to identify the root cause of such problems and how to debug them with little or no help from a debugger. He will also go into detail about which memory management techniques can be applied in order to prevent some of those bugs in the first place.
Readers will learn techniques that help with finding and identifying problems that are due to the low-level access granted by C++ and the sometimes careless use of pointers. The presented techniques are applicable to the PC as well as console platforms.
This is the slides accompanying the talk I gave at BSides Hannover 2015, discussing the reverse engineering and exploitation of numerous vulnerabilities in Icomera Moovmanage products along with the post exploitation of such, including the potential creation of a firmware rootkit
Slides for a college course at City College San Francisco. Based on "Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software", by Michael Sikorski and Andrew Honig; ISBN-10: 1593272901.
Instructor: Sam Bowne
Class website: https://samsclass.info/126/126_S17.shtml
CNIT 126: 10: Kernel Debugging with WinDbgSam Bowne
Slides for a college course at City College San Francisco. Based on "Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software", by Michael Sikorski and Andrew Honig; ISBN-10: 1593272901.
Instructor: Sam Bowne
Class website: https://samsclass.info/126/126_F18.shtml
https://youtu.be/rT7qVmQpfJg
https://github.com/utmgdsc/2023-c-workshop
C Workshop
Sam Chan on February 24, 2023
CSC108 level of knowledge required, CSC148 basics recommended
Friday 24th, 5pm
What you’ll learn:
* C vs. Python: what are the main diffs?
* Structs, typedefs and pointers
* Manual memory management
* What can go wrong (segfaults, UB)
* Stack and heap
* Memory management best practices (malloc, free)
Scripting experts from Inductive Automation cover general best practices that will help you add flexibility and customization to HMI, SCADA, IIoT, and other industrial applications. Some specific tips about using scripting in the Ignition platform will be included as well.
In this webinar, learn more about:
• Common scripting pitfalls and how to avoid them
• The best programming languages to use
• Things to consider before using scripting
• How scripting environments work
• Scripting timesavers
• And more
Scripting experts from Inductive Automation cover general best practices that will help you add flexibility and customization to HMI, SCADA, IIoT, and other industrial applications. Some specific tips about using scripting in the Ignition platform will be included as well.
In this webinar, learn more about:
• Common scripting pitfalls and how to avoid them
• The best programming languages to use
• Things to consider before using scripting
• How scripting environments work
• Scripting timesavers
• And more
Time Series Anomaly Detection with Azure and .NETTMarco Parenzan
f you have any device or source that generates values over time (also a log from a service), you want to determine if in a time frame, the time serie is correct or you can detect some anomalies. What can you do as a developer (not a Data Scientist) with .NET o Azure? Let's see how in this session.
Know thy cost (or where performance problems lurk)Oren Eini
Performance happens. Whether you're designed for it or not it doesn’t matter, she is always invited to the party (and you better find her in a good mood). Knowing the cost of every operation, and how it distributes on every subsystem will ensure that when you are building that proof-of-concept (that always ends up in production) or designing the latest’s enterprise-grade application; you will know where those pesky performance bugs like to inhabit. In this session, we will go deep into the inner working of every performance sensitive subsystem. From the relative safety of the client to the binary world of Voron.
Making Scala Faster: 3 Expert Tips For Busy Development TeamsLightbend
In this special guest webinar with Mirco Dotta, co-founder of Triplequote LLC (the creators of Hydra), we take a deeper look into what affects Scala compilation speed, why a combination of language features, external libraries, and type annotations make compilation times generally unpredictable, and what you can do to speed it up by orders of magnitude. We’ll go through:
* Understanding some of the most common bottlenecks in Scala builds.
* Effective use of type class auto-derivation for cutting compilation times.
* What are some average compilation speeds, and how to know if you have a productivity blocker.
0507 057 01 98 * Adana Çukurova Klima Servisleri, Adana Çukurova Klima Servisi, Adana Çukurova Klima Servisleri, Arçelik Klima Servisi Adana Çukurova, Beko Klima Servisi Adana Çukurova, Demirdöküm Klima Servisi Adana Çukurova, Vestel Klima Servisi Adana Çukurova, Aeg Klima Servisi Adana Çukurova, Bosch Klima Servisi Adana Çukurova, Ariston Klima Servisi Adana Çukurova, Samsung Klima Servisi Adana Çukurova, Siemens Klima Servisi Adana Çukurova, Profilo Klima Servisi Adana Çukurova, Fujitsu Klima Servisi Adana Çukurova, Baymak Klima Servisi Adana Çukurova, Sharp Klima Servisi Adana Çukurova, Mitsubishi Klima Servisi Adana Çukurova, Alaska Klima Servisi Adana Çukurova, Aura Klima Servisi Adana Çukurova, Adana Çukurova Klima Servisleri, Alarko Klima Servisi Adana Çukurova
Thursday night is fine with us know what time we should go and if you are approached to make sure you get the best for the wonderful and soon they were going on the top management across
Similar to Preventing Complexity in Game Programming (20)
2. What this is about
• The things that you should do at the beginning of a game
(or similar) project to simplify debugging, adding
features, optimization, build and release.
• We are talking about the technical and code aspect of
this problem, but some of the ideas are generalizable to
the rest of the team.
• I can only give you some tips, not a streamlined process.
That's your job.
• Seasoned programmers and developers will definitely
know what I'm talking about and will agree with most of
this. Less-experienced programmers have to trust me (to
some extent.)
3. Process, Process, Process (1/3)
• Do {Conceptualize -> Build -> Import ->
Integrate -> Test } while (0 == 0);
• Iteration time is the most important and under-
estimated factor in game development process.
• Ideally, you should never have to exit the game
to change anything (code, assets, configuration,
scripts,...)
• More realistically, you should never have to exit
the game to change anything except for code.
4. Process, Process, Process (2/3)
• Data-driven design and code is king!
• Keep engineers out of the loop. Seriously!
• Code reviews are good things, even
informal ones.
• Agile philosophy is fantastic for small
game developers.
5. Process, Process, Process (3/3)
• Automate as much as you can, as early as
possible, and keep adapting. Tools, tools,
tools!
• Transparency and discoverability
• Source control, asset control, versioning,
branches, tags and issue tracking are not
just fancy words.
6. Naming and Directory Structure
• A name is a unifying concept. Helps
develop common views and more efficient
and less error-prone communication.
• ??? (No one knows what you need!)
• When choosing a name, consider how that
name looks to these entities:
– Yourself, in 6 months
– Other people
– Scripts and tools
7. Build System (1/4)
• Quick, configurable, dependable, minimal.
• Think about header and source layout, very
carefully and very deliberately.
• The compiler is your friend. Each compile-time
error is potentially one less runtime or logical
error you'd have to chase down.
• Ideally, wrong code should not compile. (Static
assertion, type traits, template
metaprogramming, type system design, etc.)
8. Build System (2/4)
• Code build time is important. Make it as
short as possible.
– Plan the dependencies (inside your code.)
– Use precompiled headers.
– Modularize your code (into libraries.)
– Use abstract interfaces (but consider the
performance costs of polymorphism.)
– Eliminate unnecessary inter-class
dependencies.
– Use forward definitions.
9. Build System (3/4)
• Build variations
– Full debug
– Optimized debug
– Profiled release
– Developer release (with debug information)
– Retail
– and a couple more...
10. Build System (4/4)
• Strive to always have a build that is
always:
– Playable
– Performant
– Progressing
– In Memory
– Stable
12. Decisions to be Made
• Coding Style
• To OOP or not to OOP...
• Exceptions
• RTTI
• Templates vs. Polymorphism
• Smart pointers vs. Handles vs. Raw pointers
• RAII
• Lifetime and Ownership Management (and a bag full of
problems)
• Intrusive code instrumentation
• String format
• and much much much more...
13. Love Thy Compiler (1/2)
• Use EVERY little obscure compiler and platform facility
that can possibly help.
• But wrap them up, even if you don't care about portability
(in case of a change in compilers/libraries, or if you want
to disable a feature, etc.)
• Don't be afraid of assembly. Learn to read through what
your compiler produces. Love doesn't necessarily imply
trust!
• Memory is NOT fast (except on an SPU.) LOVE YOUR
CACHE TOO. Even more than your compiler.
14. Love Thy Compiler (2/2)
• Learn all about compiler #pragmas and intrinsics.
• Use intrinsics instead of inline assembly, because asm
usually hinders compiler optimizations.
• Learn about pointer aliasing, restricted pointers and
every other hint that you can give the compiler to
produce better (faster) code.
• Don't be afraid of assembly. Sometimes compilers
generate really bad code. Hand-crafted assembly is and
always will be an option.
• ...but not for the faint of heart. Don't drop to assembly
lightly, specially on PC.
15. Type System (1/3)
• Consider implementing your own containers (STL is
too frivolous with memory.)
• Type metadata and reflection
• Try not to use common type keywords (int, short,
float, etc.) Typedef them all.
– i32, u32, i16, u64, i8, u8, byte, ch8, ch16, ...
– f32, f64, v128
• ..or use stdint.h, which is a standard header but
missing from Visual C++ (still!) There are free and
conforming implementations available though.
16. Type System (2/3)
• Types that are equal physically, but not
semantically:
– Use different classes with no assignment
operators (or at least correct ones.) For example:
Degree vs. Radian, NormalizedVector3 vs.
Vector3
– Hungarian Notation (commonly misapplied, e.g.
in Win32 headers and docs!)
• degAngle = radAngle; is most probably
wrong and the good thing is that it indeed
looks WRONG.
17. Type System (3/3)
• Strings
– ASCII is dead (mostly.)
– At least differentiate between these usages:
• File names and paths.
• User input and text shown to the user.
• Internal entity names, IDs and the like.
• Text file and script contents, etc.
• And many more.
– Realize that some strings are (mostly) constant during
their lifetime. (Optimization opportunity!)
18. Pointers
• Don't use T* to represent a pointer to T. At least
typedef something like TPtr and use that instead (or
Ptr<T>.)
• Don't use T* to represent an array. Use a struct with
size information (templated for arrays with known sizes
at compile-time, or a member size_t (or smaller data if
suitable) if not.)
• NULL is not the only invalid pointer value (0xcdcdcdcd,
0xcafebabe, 0xdeadc0de, …) Don't use comparison
with NULL to detect this. Use a macro.
• Don't just use NULL for passing optional values. You can
use boost::optional, or at the very least abstract out
the concept.
19. Standard Library Independence
• File Handling and asynchronous I/O
• Directory handling
• Random numbers
• Math
• Time handling
• ...
20. Debugging
Consider the idea that the purpose of
writing code is not running it. Write code
for debugging.
• Logging
• Assertion
• Context metadata
• Crash handling and crash dump
• Visualizing data
21. Debug: Logging
• Do NOT overwhelm!
• Collect as much as possible, show as little as
needed.
• A good logging library should be:
– runtime controllable
– able to send logs to multiple targets
– able to filter what is sent where based on audience,
source, target, etc.
– fast, fast, fast
– as non-intrusive as possible
– Employed from day 0.
22. Debug: Assertion
• You do use them, don't you?!
• Never use the standard assert!
• Assert whenever you can, but nowhere
you shouldn't. (Hint: don't assert when a
configuration file is not found; make a new
one!)
23. Debug: Context metadata
• Should be totally and partially disable-able.
• Including, but not limited to:
– Machine name, user name, code revision, build number, build
parameters, time, environment, frame number, etc.
– Where does the execution flow come from? (Stack trace)
– Where are we now? File, line, function, instance.
– Which subsystem called this piece of code? Graphics? AI?
Animation? Sound?
– Why did it call this? Was it initializing? Loading data? Looking for
a collision? Walking the scene graph? Visiting AI actors?
– How long did the function take to execute?
– How Many times was it called in this frame?
– How many memory allocations did it perform?
– … (use your imagination!)
24. Debug: Crash handling and crash
dump
• If you have to fail, fail as soon as possible and
as loud as possible.
• Gather as much data as you possibly can: place,
time, what happened before, what was going to
happen after, context, hardware environment,
software environment, user settings, etc.
• Use a “Black Box” type construct. Collect some
data all the time, but store it only when crashing.
• Consider automatically submitting this info to
your issue tracker (during development) or
emailing it to your team (after release.)
25. Debug: Visualizing Data
• There is much more going on in a game than
graphics (which can be seen already!)
– Lots of data involved.
– No clear picture from mere numbers.
– Hard to understand in a single slice of time.
• Add visual representations for non-visual
objects: physics, bounding volumes, AI
algorithms, behavioral decisions, etc.
• Real-time graphs and bars too!
26. Memory
• NEVER use naked new/delete in real code.
• NEVER EVER use naked new/delete in real code!
• Write your own memory manager, even if it is just a
wrapper over new/delete.
• Don't forget malloc() and friends.
• Don't forget third-party libraries.
• Always be conscious about who uses how much
memory. Always.
• Always override the memory management in third party
libraries (including STL) unless you have reason not to.
• Writing a memory bug detector is quite easy. Write one
or find one.
• Memory allocation is usually a source of performance
bottlenecks as well as bugs.
27. In-game console
• Useful for debugging and interactive
experimentation.
• Tied-in to the scripting system.
• Make it like a good OS shell.
• Can think about it as a higher-level debugger
(inter-object relationships, etc.)
• Give access to everything you can, but consider
that the designers and artists will have to use it
too.
28. Serialization
• Useful for much more than saving/loading or
network communication.
• Template magic? Some form of IDL?
Übermacros?
• Consider two interchangeable formats: one
optimized binary and one human readable.
• Make everything you can serializable.
• Consider interactions with source control.
• Plan for evolution of data structures over the
course of development.
29. Runtime Asset management
• Everything other than code that
constitutes the game.
• Consider going beyond simple files.
• Consider treating asset management
more like writing a DBMS, than a file
system.
• Consider integrating asset fingerprinting,
change management, versioning, change
detection, hot reloading, etc.
• Consider asynchronous operations.
30. Time
• Do NOT underestimate time management.
• Never just use direct calls to OS to get the time for game
subsystems.
• Familiarize yourself with higher-resolution timers
(RDTSC, QueryPerformanceCounter(),
gettimeofday(), ...)
• Familiarize yourself with multi-core issues, power
management issues, Windows issues(!), user issues,...
• Consider the difference between wall clock, game clock,
camera clock, level clock, animation clock, etc.
• The more time you put in time, the better the times you'll
have when the time of debugging time comes!
31. Screen capture and Game Replay
• Capturing still images is a must.
• Capturing video is a big plus.
• Capturing metadata (DEM files, anyone?) to be
able to replay a scenario is a huge plus.
• The game replay subsystem can be
implemented with varying levels of complexity
and functionality. Even a simple system can
have considerable benefits.
32. Runtime Statistics
• Please invest in this!
• You must know your own game. This is
one very good way.
• Anything from frame-rate and tri-count to
number of memory allocations and file
accesses per frame, per second or per-
level.
• Find interesting ways to display these
data.
33. Automated Testing
• Full unit testing is the Holy Grail!
• Testing of games and features is usually very
time consuming. Any automation helps.
• Any change in code or assets can have
undesired side-effects: regression testing.
• You can even have automatic screen-shot
comparisons!
• Auto test non-visual parts, if you can't manage
more sophisticated methods.
34. Questions?
"I know that you believe that you
understood what you think I said, but I
am not sure you realize that what you
heard is not what I meant.”
This is a modified version of what I presented at CGS10 in Sharif University. A few slides has been added.
Hungarian Notation: The idea is to add information about the usage of a value to the name of its variable. Commonly, the only information added is about the type (e.g. pFoo for a pointer or dwHeight for a DWORD) which is useless and stupid. This is not how the concept was intended to be employed.
Did I mention that static and global data are evil?!