<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blog posts on MOGWAI LABS</title><link>https://mogwailabs.de/en/blog/</link><description>Recent content in Blog posts on MOGWAI LABS</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 22 Jan 2026 17:00:35 +0200</lastBuildDate><atom:link href="https://mogwailabs.de/en/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Reporting and Disclosure Obligations in the Cyber Resilience Act</title><link>https://mogwailabs.de/en/blog/2026/01/reporting-and-disclosure-obligations-in-the-cyber-resilience-act/</link><pubDate>Thu, 22 Jan 2026 17:00:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2026/01/reporting-and-disclosure-obligations-in-the-cyber-resilience-act/</guid><description>&lt;p>&lt;strong>TL;DR:&lt;/strong> Starting on 11 September 2026, the Cyber Resilience Act requires vendors to report exploited vulnerabilities and severe incidents to ENISA through a central reporting platform. Reporting deadlines are tight, vendors must improve their vulnerability and incident handling processes accordingly. They should further review the CSAF standard, as it is likely to become the primary format for reporting vulnerabilities to ENISA.&lt;/p>
&lt;p>While much of the discussion (at least on LinkedIn) focuses on NIS2, another EU regulation, the Cyber Resilience Act (CRA), has also entered into force. Parts of the CRA will apply from 11 September 2026. Over the Christmas break, I took the time to read the legal text and derive conclusions on what this regulation means for affected customers.&lt;/p></description></item><item><title>Is this up2date?</title><link>https://mogwailabs.de/en/blog/2025/09/is-this-up2date/</link><pubDate>Tue, 16 Sep 2025 17:00:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2025/09/is-this-up2date/</guid><description>&lt;p>Over the past few weeks, I’ve had to explain multiple times why you can&amp;rsquo;t rely on version numbers in HTTP headers to determine the patch level of a system. I assumed this was common knowledge — but &lt;a href="https://www.knut.fyi/blog/2021-06-23/every-day-somebody-s-born-who-s-never-seen-the-flintstones">every day, somebody&amp;rsquo;s born who&amp;rsquo;s never seen The Flintstones&lt;/a>.&lt;/p>
&lt;p>This post uses Ubuntu as an example, but the principle applies to all Linux distributions that offer Long Term Support (LTS) releases. The focus here is on patching; other factors that may determine whether a system is vulnerable (such as specific configurations) are not covered.&lt;/p></description></item><item><title>c3p0, you little rascal</title><link>https://mogwailabs.de/en/blog/2025/02/c3p0-you-little-rascal/</link><pubDate>Fri, 28 Feb 2025 09:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2025/02/c3p0-you-little-rascal/</guid><description>&lt;p>Since the enforcement of the Java Module System in Java 16, deserialization gadget chains that enable direct remote code execution have become increasingly rare. One notable exception is the gadget from the JDBC connection pool library c3p0.&lt;/p>
&lt;p>c3p0 (along with its dependency mchange-commons-java) provides multiple features that can be useful when exploiting Java applications. The most powerful primitive the possiblity to load classes from an attacker-controlled resource, which still works on the latest Java versions. However, c3p0 is not included in many deserialization scanners, likely because exploitation is not as straightforward as with other gadgets.&lt;/p></description></item><item><title>JNDI Mind Tricks</title><link>https://mogwailabs.de/en/blog/2024/12/jndi-mind-tricks/</link><pubDate>Wed, 18 Dec 2024 13:56:00 +0100</pubDate><guid>https://mogwailabs.de/en/blog/2024/12/jndi-mind-tricks/</guid><description>&lt;p>Injection attacks via the &lt;code>Java Naming and Directory Interface&lt;/code> (JNDI) have been known for years.&lt;/p>
&lt;p>Most security professionals got in contact with JNDI when they had to deal with the infamous Log4Shell vulnerability, which is based on tricking the log4j library into making a JNDI call to an attacker controlled system.&lt;/p>
&lt;p>Over the years, abusing JNDI has been an important part in the Java exploitation toolkit. This is even more true after common deserialization sinks were removed in Java 16/17 (see &lt;a href="https://openjdk.org/jeps/396">JEP 396&lt;/a>).&lt;/p></description></item><item><title>Vulnerability Spotlight: CVE-2023-0264</title><link>https://mogwailabs.de/en/blog/2023/04/vulnerability-spotlight-cve-2023-0264/</link><pubDate>Wed, 19 Apr 2023 12:45:00 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2023/04/vulnerability-spotlight-cve-2023-0264/</guid><description>&lt;blockquote>
&lt;p>Keycloak is an open source identity and access management solution [&amp;hellip;] [to] secure services with minimum effort&lt;/p>
&lt;/blockquote>
&lt;p>&lt;sup id="fnref:1">&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref">1&lt;/a>&lt;/sup>&lt;/p>
&lt;p>Due to it&amp;rsquo;s relative simplicity (at least for a IAM product) and its open source nature Keycloak is a popular authorization server for many of our customers&amp;rsquo; projects. As we do our best to stay up to date on emerging vulnerabilities and give our customers a heads up on what to focus on, CVE-2023-0264 with a CVSS rating of 8.3 caught our attention.&lt;/p></description></item><item><title>Look Mama, no TemplatesImpl</title><link>https://mogwailabs.de/en/blog/2023/04/look-mama-no-templatesimpl/</link><pubDate>Tue, 11 Apr 2023 17:00:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2023/04/look-mama-no-templatesimpl/</guid><description>&lt;p>Due to changes in Java 16, exploiting native deserialization vulnerabilities became much harder. This post will give an overview what has been changed and provides some ideas how attackers can still gain remote code execution.&lt;/p>
&lt;h2 id="project-jigsaw-and-the-java-module-system">Project Jigsaw and the Java module system&lt;/h2>
&lt;p>To understand the underlying issue, we need to talk about the Java Module system and Java Reflection first. I will keep it short, a more detailed explanation can be found in the &lt;a href="https://blogs.oracle.com/javamagazine/post/a-peek-into-java-17-continuing-the-drive-to-encapsulate-the-java-runtime-internals">Java Magazine&lt;/a>.&lt;/p></description></item><item><title>Exploiting Laravel based applications with leaked APP_KEYs and Queues</title><link>https://mogwailabs.de/en/blog/2022/08/exploiting-laravel-based-applications-with-leaked-app_keys-and-queues/</link><pubDate>Fri, 26 Aug 2022 06:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2022/08/exploiting-laravel-based-applications-with-leaked-app_keys-and-queues/</guid><description>&lt;p>&lt;a href="https://laravel.com/">Laravel&lt;/a> is a widespread open-source PHP web framework. It can be used to create complex web applications with relative ease and is used within many popular projects.&lt;/p>
&lt;p>During a recent penetration test of such an application we gained access to the frameworks environment file. This file contains numerous sensitive Laravel configuration settings, including the applications &lt;code>APP_KEY&lt;/code> .&lt;/p>
&lt;p>The APP_KEY is used for multiple security-related tasks, such as singing objects and protecting them from being tampered with. In the past, knowledge of the APP_KEY was a reliable way to gain remote code execution as it was used to sign the (serialized) XSRF token. An attacker with knowledge of the APP_KEY, was able to create a malicious XSRF token, which then lead to RCE through insecure deserialization &lt;a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15133">(CVE-2018-15133)&lt;/a>, using a known gadget chain.&lt;/p></description></item><item><title>Vulnerability Spotlight: RCE in Ajax.NET Professional</title><link>https://mogwailabs.de/en/blog/2022/01/vulnerability-spotlight-rce-in-ajax.net-professional/</link><pubDate>Tue, 18 Jan 2022 12:30:35 +0000</pubDate><guid>https://mogwailabs.de/en/blog/2022/01/vulnerability-spotlight-rce-in-ajax.net-professional/</guid><description>&lt;p>In Fall of 2021, MOGWAI LABS conducted a penetration test for a customer. In the process, our team encountered an out-of-scope application that was on &amp;ldquo;&lt;a href="https://github.com/michaelschwarz/Ajax.NET-Professional/">Ajax.NET Professional&lt;/a>&amp;rdquo;.
A brief analysis of the framworks source revealed a deserialization vulnerability, which MOGWAI LABS reported to the developer (&lt;a href="https://github.com/michaelschwarz/Ajax.NET-Professional/security/advisories/GHSA-6r7c-6w96-8pvw">CVE-2021-23758&lt;/a>).&lt;/p>
&lt;p>This blog post includes findings from &lt;a href="https://twitter.com/mwulftange">Markus Wulftange&lt;/a> (Code White GmbH) who also analyzed the library for a different project and pinned us to some key points during a discussion.&lt;/p></description></item><item><title>Vulnerability notes: Log4Shell</title><link>https://mogwailabs.de/en/blog/2021/12/vulnerability-notes-log4shell/</link><pubDate>Fri, 10 Dec 2021 06:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2021/12/vulnerability-notes-log4shell/</guid><description>&lt;p>&amp;ldquo;Log4Shell&amp;rdquo; (CVE-2021-44228) is a pretty epic vulnerability in the Java logging library &amp;ldquo;Log4j&amp;rdquo;. This blog post (hopefully) contains everything you need to know about this vulnerability and how to mitigate it.
It was written in a hurry, we will add additional details and remarks in the upcoming days.&lt;/p>
&lt;h3 id="introduction">Introduction&lt;/h3>
&lt;p>Log4j is a commonly used logging library in the Java world. It does what a logging library should do, is fast and integrates well with existing application servers. Here a minimal example that uses user provided input to create a log entry.&lt;/p></description></item><item><title>Vulnerability digging with CodeQL</title><link>https://mogwailabs.de/en/blog/2021/09/vulnerability-digging-with-codeql/</link><pubDate>Mon, 13 Sep 2021 14:15:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2021/09/vulnerability-digging-with-codeql/</guid><description>&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>CodeQL is the semantic code analysis engine from GitHub which can be used to discover vulnerabilities in different code bases. It allows us to &lt;em>Query code as if it were data&lt;/em>, and helps to describe and identify insecure code patterns. Especially the ability to easily describe code flows from a source to sink, even if variables are reassigned or modified multiple times, is quite impressive. Over the last two years, several interesting blog posts and vulnerability reports have been published that impressively demonstrated the power of this approach.&lt;/p></description></item><item><title>Exploiting insecure RCCMD installations</title><link>https://mogwailabs.de/en/blog/2021/06/exploiting-insecure-rccmd-installations/</link><pubDate>Fri, 18 Jun 2021 07:00:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2021/06/exploiting-insecure-rccmd-installations/</guid><description>&lt;p>&lt;a href="https://www.generex.de/products/software/rccmd">Generex RCCMD (Remote Control Command)&lt;/a> is an application that allows the UPS (uninterruptible power supply) to gracefully shutdown critical systems before it runs out of power. It is quite popular in Germany, especially in small and midsize companies. In recent years, MOGWAI LABS exploited multiple insecurely configured installations to gain RCE on critical systems, including Domain controllers.&lt;/p>
&lt;h2 id="rccmd-overview">RCCMD overview&lt;/h2>
&lt;p>A typical installation usually contains of a UPS monitoring system/device (UPSMON) and multiple &amp;ldquo;client&amp;rdquo; systems which have the RCCMD service installed. We will focus on the RCCMD service here.&lt;/p></description></item><item><title>An Trinhs RMI Registry Bypass</title><link>https://mogwailabs.de/en/blog/2020/02/an-trinhs-rmi-registry-bypass/</link><pubDate>Sat, 08 Feb 2020 05:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2020/02/an-trinhs-rmi-registry-bypass/</guid><description>&lt;p>&lt;strong>TL:DR:&lt;/strong>
This blog entry analyses the RMIRegistry whitelist filter bypass gadget discovered by An Trinh (&lt;a href="https://twitter.com/_tint0">@_tint0&lt;/a>) in the RMI naming registry. It covers some basic concepts that are commonly used when building deserialization gadgets. With the help of this gadget it is possible to exploit deserialization vulnerabilities in the RMI registry, even if the target is running a current version of Java/OpenJDK.&lt;/p>
&lt;p>&lt;strong>Update&lt;/strong>: This bypass has been fixed by Oracle in &lt;a href="https://www.oracle.com/technetwork/java/javase/8u241-relnotes-5813177.html#JDK-8230967">JDK8u241&lt;/a> which was released on January 14. Thanks to &lt;a href="https://twitter.com/steventseeley">MR_ME&lt;/a> for pointing out.&lt;/p></description></item><item><title>(Ab)using Linux SNMP for RCE</title><link>https://mogwailabs.de/en/blog/2019/10/abusing-linux-snmp-for-rce/</link><pubDate>Wed, 30 Oct 2019 17:00:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2019/10/abusing-linux-snmp-for-rce/</guid><description>&lt;p>&lt;strong>TL:DR:&lt;/strong> If you have a SNMP community with write permissions on a Linux target, you can archive code execution by abusing the NET-SNMP-EXTEND-MIB extension. The SNMP daemon is running as root, which makes this also a nice local privilege escalation vector.&lt;/p>
&lt;p>We recently used this feature to gain root permissions during an assessment. As the Linux systems has been analyzed several times before, we assume that this issue is not common knowledge among other penetration testers. As so often, we are not the first to discover this, in fact there already exists a &lt;a href="https://medium.com/rangeforce/snmp-arbitrary-command-execution-19a6088c888e">write-up by Kert Ojasoo&lt;/a>. In this blog post, we try to give the technical background and how this configuration can be efficiently exploited.&lt;/p></description></item><item><title>Attacking RMI based JMX services</title><link>https://mogwailabs.de/en/blog/2019/04/attacking-rmi-based-jmx-services/</link><pubDate>Sun, 28 Apr 2019 06:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2019/04/attacking-rmi-based-jmx-services/</guid><description>&lt;p>&lt;strong>TL:DR:&lt;/strong> In a previous post we described how Java RMI services can be exploited using various techniques, mainly Java Deserialization. While RMI is commonly no longer used for developing new applications, it is still the standard technology that is used to allow remote monitoring via JMX. Attack techniques against JMX services have been known since several years, however we regularly find insecure/exploitable JMX instances while conducting security assessments.&lt;/p>
&lt;p>This article starts with a brief introduction to JMX and then describes the known attack techniques. Additionally, we will have a look on how to use Java Deserialization against JMX services.&lt;/p></description></item><item><title>Attacking Java RMI services after JEP 290</title><link>https://mogwailabs.de/en/blog/2019/03/attacking-java-rmi-services-after-jep-290/</link><pubDate>Mon, 25 Mar 2019 06:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2019/03/attacking-java-rmi-services-after-jep-290/</guid><description>&lt;p>&lt;strong>TL:DR:&lt;/strong> The introduction of JEP 290 killed the known RMI exploits in ysoserial. However, you can still exploit Java deserialization on the application level if no global filter is active. The article shows you how to replace those methods on the fly, using the scriptable debugger YouDebug.&lt;/p>
&lt;p>As Java RMI (Remote Method Invocation) is based on native Java deserialization, they became one of the major victims of the Java Deserialization Appocalype. This changed with the implementation of JEP 290 in current JDK releases. This blog post describes the changes and describes ways how Java deserialization could still be used on the application level to exploit those services.&lt;/p></description></item><item><title>Repacking iOS applications</title><link>https://mogwailabs.de/en/blog/2019/03/repacking-ios-applications/</link><pubDate>Sat, 02 Mar 2019 09:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2019/03/repacking-ios-applications/</guid><description>&lt;p>&lt;strong>TL:DR:&lt;/strong> You can use &lt;a href="http://www.cydiaimpactor.com/">Cydia Impactor&lt;/a> to resign a patched iOS app. This works way easier then using XCode or the codesign tool.&lt;/p>
&lt;p>We recently had to test a iOS application for one of our customers. Like many business applications, the developers integrated common protections, including jailbreak detection and certificate pinning. In cases like this, we commonly use a dynamic Instrumentation framework like Frida to bypass these protections so that we can freely interact with the application and intercept the communication with the server side backend.&lt;/p></description></item><item><title>jarjarbigs</title><link>https://mogwailabs.de/en/blog/2018/10/jarjarbigs/</link><pubDate>Wed, 31 Oct 2018 20:40:35 +0000</pubDate><guid>https://mogwailabs.de/en/blog/2018/10/jarjarbigs/</guid><description>&lt;p>When it comes to analyzing closed source Java Applications, most researchers quickly fire up decompilers like &lt;a href="http://jd.benow.ca/">JD-GUI&lt;/a> and start analyzing. These tools are fine, however they only allow static analysis. In case of complex code it is often much better to attach a debugger and analyze the application during runtime.&lt;/p>
&lt;p>Unlike dnspy (a decompiler for .NET applications), JD-GUI itself doesn&amp;rsquo;t provide any debugging capabilities. However, it is possible to extend IDEs like Intellij or Eclipse with a decompiler plugin.&lt;/p></description></item><item><title>Vulnerability spotlight: CVE-2016-5072</title><link>https://mogwailabs.de/en/blog/2018/07/vulnerability-spotlight-cve-2016-5072/</link><pubDate>Fri, 13 Jul 2018 09:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2018/07/vulnerability-spotlight-cve-2016-5072/</guid><description>&lt;p>Some time ago, I checked the known vulnerabilities in the open source shop software &amp;ldquo;OXID eShop&amp;rdquo;, which is very popular here in Germany. One issue that caught my interest is the vulnerability &lt;a href="https://oxidforge.org/en/security-bulletin-2016-001.html">OXID Security Bulletin 2016-001 (CVE-2016-5072)&lt;/a>, mainly due to the high impact. From the adivsory:&lt;/p>
&lt;p>&lt;em>An attacker can gain full administrative access to OXID eShop. This includes all shopping cart options, customer data and the database. They also can execute PHP code or inject malicious code into the system and the shop’s storefront. No interaction between the attacker and the victim is necessary.&lt;/em>&lt;/p></description></item><item><title>Static JWT signing Key in dotCMS</title><link>https://mogwailabs.de/en/blog/2018/07/static-jwt-signing-key-in-dotcms/</link><pubDate>Mon, 02 Jul 2018 09:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2018/07/static-jwt-signing-key-in-dotcms/</guid><description>&lt;p>We recently had a look at dotCMS, an open source content management system written in Java. While we analyzed the CMS source for potential deserializiation vulnerabilities, we stumbled over the following &lt;a href="https://github.com/dotCMS/core/blob/044f2463efc7112283901b0da748b054a2ff7224/dotCMS/src/main/java/com/dotcms/auth/providers/jwt/factories/impl/HashSigningKeyFactoryImpl.java#L20">code&lt;/a>:&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" class="chroma">&lt;code class="language-java" data-lang="java">&lt;span class="line">&lt;span class="cl">&lt;span class="nd">@Override&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="w">&lt;/span>&lt;span class="kd">public&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="n">Key&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="nf">getKey&lt;/span>&lt;span class="p">()&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="p">{&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="w"> &lt;/span>&lt;span class="kd">final&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="n">String&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="n">hashKey&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="o">=&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="n">Config&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="w"> &lt;/span>&lt;span class="p">.&lt;/span>&lt;span class="na">getStringProperty&lt;/span>&lt;span class="p">(&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="w"> &lt;/span>&lt;span class="s">&amp;#34;json.web.token.hash.signing.key&amp;#34;&lt;/span>&lt;span class="p">,&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="w"> &lt;/span>&lt;span class="s">&amp;#34;rO0ABXNyABRqYXZhLnNlY3VyaXR5LktleVJlcL35T7OImqVDAgAETAAJYWxnb3JpdGhtdAASTGphdmEvbGFuZy9TdHJpbmc7WwAHZW5jb2RlZHQAAltCTAAGZm9ybWF0cQB+AAFMAAR0eXBldAAbTGphdmEvc2VjdXJpdHkvS2V5UmVwJFR5cGU7eHB0AANERVN1cgACW0Ks8xf4BghU4AIAAHhwAAAACBksSlj3ReywdAADUkFXfnIAGWphdmEuc2VjdXJpdHkuS2V5UmVwJFR5cGUAAAAAAAAAABIAAHhyAA5qYXZhLmxhbmcuRW51bQAAAAAAAAAAEgAAeHB0AAZTRUNSRVQ=&amp;#34;&lt;/span>&lt;span class="p">);&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="w"> &lt;/span>&lt;span class="k">return&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="p">(&lt;/span>&lt;span class="n">Key&lt;/span>&lt;span class="p">)&lt;/span>&lt;span class="w"> &lt;/span>&lt;span class="n">Base64&lt;/span>&lt;span class="p">.&lt;/span>&lt;span class="na">stringToObject&lt;/span>&lt;span class="p">(&lt;/span>&lt;span class="n">hashKey&lt;/span>&lt;span class="p">);&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="w">&lt;/span>&lt;span class="p">}&lt;/span>&lt;span class="w">
&lt;/span>&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>As the key is not changed/generated during the dotCMS installation every default installation of dotCMS uses the same key to sign Json Web Tokens (JWT). This made us curious as JWT is often used for user authentication. When we checked the security best practices section of the documentation, we noticed that the dotCMS team also &lt;a href="https://dotcms.com/docs/latest/security-best-practices#LoginSecurity">recommends to change this key on production environments&lt;/a>.&lt;/p></description></item><item><title>CANAPE workshop slides</title><link>https://mogwailabs.de/en/blog/2018/06/canape-workshop-slides/</link><pubDate>Fri, 22 Jun 2018 09:40:35 +0200</pubDate><guid>https://mogwailabs.de/en/blog/2018/06/canape-workshop-slides/</guid><description>&lt;p>In April 2018, we provided our free CANAPE workshop for the first time at the BSides Munich conference. CANAPE is a tool that allows you to analyze binary protocols which are still very common today. CANAPE is unique by taking the well known web application testing paradigm and applying it to abitrary network protocols.&lt;/p>
&lt;p>This hands-on workshop is based on the original workshop material by James Foreshaw (the author of CANAPE). and includes a complete walk-through through the most important CANAPE features. The slides are very detailed as we tried to create some kind of &amp;ldquo;missing manual&amp;rdquo; for this awesome tool.&lt;/p></description></item></channel></rss>