NNL-labs

Ok, just a quick blog on this... If you've looked at the registry keys created by Waledac you've surely seen the RList key. This key contains a rather large blob of data. Turns out that this is where the bootstrap IP list is stored in order to keep it current over reboots.

The data contained within this block of data is obviously not plaintext. Turns out the data is encrypted using our favorite crypto algo: AES. The transform for this data is very, very simple. Simply applying AES to the data puts the data back into plaintext of a BZip2 file, then un-BZip2 to get the data out. The un-BZip'd plaintext is the same format as the .php data received by the node during an update. Waledac LOVES XML.

Once decoded, the XML looks like this:

 <lm>
  <localtime>1233218778</localtime>
   <nodes>
    <node ip="84.16.228.132" port="80" time="1233218778">33a4c14ed5b99a93d9051e861950c95b</node>
    <node ip="12.205.66.175" port="80" time="1233218757">b713d64b73575e3f4633c4301c584a40</node>
    <node ip="216.55.178.126" port="80" time="1233218757">a96cec187076ae257f349b160d581762</node>
    <node ip="76.114.1.52" port="80" time="1233218757">317db9596777f9481c47185c29775a3f</node>
    <node ip="173.33.75.204" port="80" time="1233218757">1a157b0a0d5c2a158757c321c33f9c1d</node>
    <node ip="169.254.94.105" port="80" time="1233218727">397af561c83d6b019c406e76b605d564</node>
    <node ip="168.20.212.47" port="80" time="1233218684">2f15c624bc2edb24e60b3c2ac405c17c</node>
    <node ip="169.254.168.251" port="80" time="1233218638">082cea1d3d1b8a244356ea236e6fa818</node>
    <node ip="165.132.20.161" port="80" time="1233218521">785a6759b2277d48453cde32f11b1072</node>
    <node ip="76.170.178.95" port="80" time="1233218498">3a12bb283c195c4b020b2f67ba699323</node>
 ... and so on.

The above data came directly from one of my node's registry after being decoded. The AES key can be one of two hardcoded values contained within the binary making this data easy to recover.

greg.

I figured since others were sharing more, I'd share more too

Over the weekend I was able to breakdown all of the packets used by Waledac for communication. The communication between nodes is rather simplistic, but potentially expandable. I'm not going to put a lot of pretty text around my notes, just my notes. Please do enjoy. If you have questions, drop me a line.

greg.

---

XML Format for versions 28+ (maybe earlier, but havent checked)

All Request Packets have the following standard header added at the start

<lm>
 <t>{command name}</t>
 <v>{version of node}</v>
 <i>{hash ID of node}</i>
 <r>{repeater status 0 or 1}</r>
 <props>
  //{p/n fields here}
  
// and the following standard footer is added to close out
 </props>
</lm>

Reply Packets have the following standard headers added at the start
<lm>
 <v>{version of node}</v>
 <t>{command name}</t>  // this is matches the command name sent in the request packet
 <props>
 
// and the following standard footer is added to close out the reply
 </props>
</lm>

Command Names are:

0 : "getkey"
1 : "first"
2 : "notify"
3 : "taskreq"
4 : "words"
5 : "taskrep"
6 : "httpstats"
7 : "emails"
 

---

Command Number: 00 (aliased on the wire as 0xFF)
Command Name: "getkey"

Request Format:

{standard request header}
  <p n=cert>{ASCII form of public cert</p>  
{standard request footer}  
  
  
Reply Format:
{standard reply header}
  <p n=key>{base64 encoded RSA encrypted AES Key 0 value}</p>
{standard reply footer}

---

Command Number: 01
Command Name: "first"

Request Format:

{standard header}
  <p n=winver>%d.%d.%d</p>     // = majorver.minver.subver, i think
  <p n=label>mirabella_site</p>  // hardcoded value
{standard footer}  
  
  
Reply Format:
{standard reply header}
{standard reply footer}  

NOTE: The reply is basically ignored.

---

Command Number: 02
Command Name: "notify"

Request Format:

{standard request header}
  <p n="label">{see note below}</p>  // hardcoded value that varies by version
  <p n="time_sys">{current time in ASCII}</p>
  <p n="time_init"> {time node was activated in ASCII}</p>
  <p n="time_now"> {current time in ASCII} </p>
  <p n="time_ticks"> {current tickcount, converted to 64bit ASCII} </p>
{standard request footer}  
  
  
Reply Format:
{standard reply header}
  <p n="ptr"> {RDNS of node} </p>
  <p n="ip"> {IP of node} </p>
  <p n="dns_ip"> {DNS server to use/test with,???}</p>
  <p n="smtp_ip"> {SMTP server to use/test with, ???)</p>
  <p n="sender_threads"> {presumably, the number of sender threads to activate at once}</p>
  <p n="sender_queue"> { not exactly sure} </p>
  <p n="short_logs"> {not exactly sure, if present the value is "true"}</p> // available in version 31, not 28
  <p n="http_cache_timeout"> {presumably, the timeout for caching proxy/repeater data}</p> // this is present only if <r> = 1
  <p n="commands"><[CDATA[  {see commands below} ]]></p>
 </props>
 <dns_zones>
  <zone>{dns zone name}</zone>
 </dns_zones>
 <dns_hosts>
  <host>{dns host ip}</host>
 </dns_hosts>
 <socks5>
  <allow max_conn="%d">{IP address to allow}</allow> // i'm not 100% certain on the max_conn format, that might be wrong
 </socks5>
 <dos>
  <target>
   <ip> {IP of target} </ip>
   <port> {port to DDoS} </port>
   <rate> {presumably, the flood rate for each node} </rate>
   <rate2> {some sort of flood rate as well} </rate>  // in version 31
  </target>
 </dos>
 <p2p>
 </p2p>
 <filter>
  <deny> {ip address in dot notation} </deny>
 </filter>
</lm>

NOTE:
"n="command"" commands:
 update
 download
 downloadR
 downloadS

"n="command"" format:
<somenumber>|<command>|<arguments>{\0x10\0x13}

<dns_zone> and <dns_host> are handled by the CDnsPlugin.
<socks5> is handled by the CSock5Plugin class
<p2p> is handled by the CKadPlugin class. This seems to be a stub.. might not actually be built yet (looking at the v28 code)
<dos> is handled by the CDosPlugin class.
 
<dns_zone>, <dns_hosts>, <dos>, <p2p> and <sock5> are all plugins based on CPlugin, but not sure how they are activated. They dont seem to be checked by the handler, but i've seen <dns_zone> etc in this command reply.

Known "label" values: "lynx" (version 31) and "mirabella_site" (version 28)

---

Command Number: 03
Command Name: "taskreq"

Request Format:

{standard request header}
{standard request footer}  
  
  
Reply Format:
{standard reply header}
 <props>  // not sure what, if anything, is ever in here
 </props>
 <tasks>
  <task id="%d">  // %d = decimal number presenting this task identifier, more than one task can be present in the <tasks> block
   <body>{body of email message in proper Base64 encoding</body>
   <a> {email address to spam}</a>   // there can be MANY of theses in here
   <w> {either words or variables, not sure}</w> // there can be MANY of these in here
  </task>
 </tasks>
 <words>
  <w name="..." time="..."/>  // not sure what name or time are used for
 </words>
{standard reply footer}  

 

---

Command Number: 04
Command Name: "words"

Request Format:

{standard request header}
  <p n="word_name">{word}</p>
{standard request footer}  
  
  
Reply Format:
{standard reply header}
 <word name="{word}">
  <![CDATA[ {series of words, one per line} ]]>
 </word>
{standard reply footer}  

NOTE:
 It is believed that this updates the dictionary for a spam campaign

---

Command Number: 05
Command Name: "taskrep"

Request Format:

{standard request header}
  <p n="b64">true</p>   // hardcoded. Indicates the use of base64 for lower sections as indicated
 </prop>
 <reports>
    <rep id="{%d number}" rcpt="{email address in Base64 encoding}">{status in base64 encoding}</rep> // rcpt is the email being reported on with status indicating success or failure at deliever, i believe
 </reports>
</lm>  
  
  
Reply Format:
{standard reply header}
{standard reply footer}  

NOTE:
 the <rep id... field can be included multiple times in the <reports> section, one per email.
 The {status in base64} in <rep id=... is the base64 encoded string for either: OK or ERR
 
 The reply is basically ignored.
 

---

Command Number: 06
Command Name: "httpstats"

Request Format:

{standard request header}
  <p n="b64">true</p>   // hardcoded. Indicates the use of base64 for lower sections as indicated
 </props>
 <http_stats>
  <stat ip="{ip address that made a request}" time="{time of request in UNIX decimal format}"><![CDATA[{the URL request in typical W3C log format}]]></stat>
 </http_stats>
</lm>  
  
Reply Format:
{standard reply header}
{standard reply footer}  

NOTE:
 Multiple <stat> entries can be in the <http_stats> block.
 
 The reply is basically ignored.
 

---

Command Number: 07
Command Name: "emails"

Request Format:

{standard request header}
 </props>
 <emails>
  <![CDATA[ {emails, one per line, newline == \n} ]]>
 </emails>
</lm>
  
  
Reply Format:
{standard reply header}
{standard reply footer}  

Note:

 The reply is basically ignored.

---

Node Update Packets:

Request Format:

none. Simple empty GET request to a .php script (i.e. /index.php)

or...

GET request to / with the HTTP header:

 "X-Request-Kind-Code: servers"  <---- for repeaters

or the header:

 "X-Request-Kind-Code: nodes"    <---- for spammers

followed by the bot's node list converted to XML (see example in Reply Format section), BZip2'd and compressed with AES (using Key 1 or Key 2. default is key 1).

Reply Format:

 <lm>
  <localtime>{UNIX time of the request}</localtime>
  <nodes>
   <node ip="{next tier IP address}" port="{port number}" time="{time stamp/age of this entry}">{32digit HASH ID for peer}</node> // multiple entries possible (and probable)
  </nodes>
 </lm> 

NOTE: This type of reply do not contain the normal 5 byte header like the command packets have. Additionally, this data is NOT BZip'd after being decoded if the reply was to /index.php, but it is BZip'd if a request to /.

Around Xmas of this past year (2008) the Waledac trojan really sprang to focus. Many researchers, myself included, have likened the trojan to the now dark Storm bot. Waledac shares many similarities to Storm in the way communications are handled, spam is sent, etc. The details of this are well publicized so google will show you the way. What many researchers did not know was the way the data was traveling across the network. The basic format of a Waledac data exchange looks like this: POST /llveaamncz.png HTTP/1.0
Referer: Mozilla
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla
Host: xz.y.x.x
Content-Length: 317
Pragma: no-cache
a=AgAAANNpvPXwbiby6EtaZNszVV6nuKqqhcVLqnhso4DolBU-GjkaaU1r1HA2X1EHMUqfSaFpB-YGWYHxB8Q82WQagJzJWgoDEezx4-vc_pnCMUb75jr4kb4jsqWYWSX9xT_Di3w5LDS4f9-fzzEJF85OiNvBWPQCl3CbZRIxaFr73pRCfnvZrUSwissNv3HbfrvwHd0KkvBnHv40yQ4ZlGwPQDWSATlBFlTNBbI4fqSDV5wKfzirb_kXRW3Yn4Q-ZtDDFzTcj6g6Xq-TK6oeMj8WtpRCfrfdloDX9sJ9gHsksoArXA&b=AAAAAA


HTTP/1.1 200 OK
Server: nginx/0.6.34
Date: Mon, 19 Jan 2009 22:11:48 GMT
Content-Type: text/html
Connection: close
X-Powered-By: PHP/5.2.8
AgAAAUoKNmr3RcU00DZic-18qqACaDxVXTahwKgk42DBL3fpMxLsud5GfRxwMtczeWltVkYqT8etqa_OssVU16MrXBfV9Gk2EPbKI2bua3aqll25EursbNT61Zgc-Tqzgn8E3wwgQFVi_tFb-VKHU4QDTwZytQl_vmKnwlLfI2V4ACtpwButN7b42QSekMO2YYEpF3l0NWUi4KEuOOpExrE8VPCE9TBTKtfqxwPa447hMaLkRhQcwBNyP575YBlxozfXjOlRDAMPuLOckdBjHxRB7MeyB71dgmIKyTmUT4Em4oMxBduw7_XT2tGVL00QcES91QsRSA1IAuCPWoGPXEcXOlz9RFHqpTtl5Hkn8gjlTIOs2Da26LPEjxg_cxCvhvmfRQ_viUsCblqRHp4ccwNY3heb98lW321pb-6P7jAKuPn2hHGKZgtWcqrDUEyUh34c92M

The first reply comes from a spammer node (a bot that is behind a firewall). The familiar a= &b= tags look very much like Storm. And like Storm, the data is Base64 encoded.... well, sorta. Turns out to make Base64 decoding annoying, the author(s) of Waledac made some simple substitutions, but very minor ones. To un-Base64 the data, the _ character must be replaced with / and the - character must be replaced with +. Also, the data is not exactly in Base64 block size. Therefore if the data being encoded ends with =, the = is stripped.

Making the replacements and padding the string size with = will allow the string in a= to be Base64 decoded. Once decoded, the data takes the following form:

[Byte] Command Type {0xFF, 1, 2, 3, 4, 5, 6, 7}
[DWORD] Size of Data Once Fully Decoded
[variable] AES Encrypted Payload

The command type identifies what type of request or reply is being made and as a result, which key is used to decompress the AES encrypted payload. The DWORD size field identifies how big the decrypted payload will be.

To decrypt the AES payload there are really only two keys which matters. For type 0xFF one key is used (which can be found in the binary). For the other commands a key handed down by the botmaster is used. The reason 0xFF uses a hardcoded key is that this command is known as “getkey” and the purpose of this command is to pass up to the botmaster the node’s public key/certificate. The botmaster will then encrypt the AES key to use for the other command types using that public key. It is then up to the bot to use the private key to decrypt the key. This, in theory, prevents researchers from being able to spy on or spoof command types 1-7. This can be defeated given a particular flaw I found in the system.

Before anyone asks, no, I will not yet give out the way to recover the dynamic AES key. I still need this for my research and I don’t want people polluting the data. Do you not remember what happened when researchers started looking at storm?

Once the AES payload has been decrypted, the data is still not yet accessible for plaintext. It turns out that the author(s) of Waledac wanted to save a little bandwidth and BZip2 compressed the payload. The solution to this, as you might imagine, is to simply un-BZip2 the data. Once you have decompressed the data, you will find that the payload is a XML data structure. Therefore, Waledac uses XML for command and control communication. This makes understanding what is happening in a particular decoded packet trivial. And for that I thank them.

To get an idea of what this XML looks like, the request sent from the node above decodes into the following text: (note that I added the newlines and tabs. The XML sent is a single string)

<v>31</v>

<i>234 {omitted the rest of this} 9</i>

<r>0</r>

<props>

<p n="label">lynx</p>

<p n="time_init">Tue Jan 20 01:40:51 2009</p>

<p n="time_now">Tue Jan 20 01:41:45 2009</p>

<p n="time_sys">Tue Jan 20 01:41:45 2009</p>

<p n="time_ticks">2338031</p>

</props> </lm>

As you can see from the output, it is pretty straightforward. <t> represents the name of the command, <v> is the version of the bot making the request (or botmaster if it is a reply), <i> is the hash ID of the node, <r> is 1 if the bot is a repeater (e.g. “proxy”, unfirewalled) or 0 if it is a spammer (firewalled). The <props> section is where attributes unique to each command are stored. The format is always <p n=”…”>…</p>. I will post the meaning of these at a later date. The XML always starts with the <lm> tag.

As for the reply from the botmaster (or next tier bot) it is decoded in exactly the same way the request is. The only difference being that the data is not contained with a URL variable, but rather in the body of the reply.

Over the next few days/weeks I will try to post more of my findings here. I have a lot more, but I need to focus on my day job so they’ll keep paying me.

UPDATE [20090128]: Felix Leder and Tillmann Werner pointed out something I had not thought of. While the base64 modifications are annoying, they may very well serve a more valuable (to the bot developers) purpose. It turns out / and + are reserved characters in the world of URL strings when using application/x-www-form-urlencoded and therefore they must be changed or escaped. Given that Waledac does a lot of URL parameter passing in Base64, adjusting these reserved characters would allow for less problems. This may very well be why the changes are made and are not a direct result of trying to annoy researchers. Thanks for pointing this out guys!

<lm><t>notify</t>

I'll admit it, I was one of those people standing outside the Apple store whenever the new iPhone 3-oh-my-god-why-won't-this-piece-of-shit-work-G came out. I was happy to have a shiny new iPhone in my hands. I immediately took it home and selected every single icon I could find. I played with it for a few days and then i tried to make a phone call.

Since that fateful day, i've had nothing but a horrible, horrible experience with the iphone. god forbid i want to make a phone call and if i'm lucky enough to get the call to actually go through, i better say my piece quickly because i'm going to get my call dropped.

I live downtown in a city that has a LOT of AT&T coverage. I get 4 out of 5 bars at any given time and more often than not I get 5 out of 5. But i can't get this damn thing to keep my call running for any length of time. When the miracle of the 2.1 OS came out, I immediately upgraded because i was told this would fix the phone issue. It didnt. What it did do was keep me from getting my emails for 2 months until the software decided that it was finally ok to start receiving emails again. I called Apple's tech support many, many times and was told to do the same things over and over and over and over... and over. My mother told me once that the definition of insanity is repeating the same actions over and over and expecting a new outcome each time. Therefore, Apple is insane.

So the 2.2 OS came out and again, I'm being told that this will fix the evil phone problem, that my phone calls will last longer than 5 minutes and that when i hit the send button my phone will not immediately say "call failed." I've upgraded. And now I can't get on the internet via my iphone. I can't checked my email, I can't get the www.apple.com website, I can't even check the fucking weather! Apple's solution... reinstall your firmware. WHAT? That is the same answer they gave me after the email issues with the 2.1 upgrade. At least this time they aren't telling me call Microsoft because my email comes from an exchange server.

I hate Apple. They are a pretenious as hell and I hate how smug they are about their miracle products. Their products are ok at best. Sure, the Mac OS doesn't have the same stability issues as Windows 98. Neither does XP. I am by no means a fan of Vista, so don't think I'm smoking from the Microsoft bong. Apple makes some pretty little products, but they have performed an Epic Fail with their iPhone. Thanks to a 2 year contract, they have the majority of their subscribers by the short and curlies. Luckily, I make enough money (even in today's economy) that once I find a better device I will happily tell Apple and AT&T to go fuck themselves. Unlike the iPhone, I'm going to do my research before i jump to my next phone.

For those of you who saw Michael Ligh's blog entry on the Kraken work he and I did, you are probably wondering where the plugin code is. I have released the wireshark plugin here in my Code section of the site.

I should warn you about the plugin... I'm not a plugin writer. This is literally my second attempt at it. It may very well crash your WireShark under some situations. Just keep that in mind. If your version of wireshark is 0.99.8, you should be fine. If you are running 1.0.0, you should be fine too (however, the Protocol tab will say UDP instead of Kraken.. i'm not sure why that is).

Feel free to use this as you see fit. However, if you use any of the code, make sure you reference BOTH this website [nnl-labs.com] and Michael Ligh's [mnin.org] website!

enjoy.

greg.

From time to time you come across that special kind of IDA database where the things you take for granted are simply not how they should be. I was recently working on a binary that started out something like this...

call $+5

pop ebx

add ebx, 014350h

Then later on in the function all the variable references take the form of

mov eax, [ebx-01212h]

As you might have guessed IDA doesn't particularly care much for this. My xfer tables are nearly bare. Obviously one could go about manually calculating the location of all these variables, but I'm lazy.. ok, not really lazy, perhaps unmotivated. So I wrote a quick and dirty IDC script to calculate these offset locations and store the results in a comment beside the operand. 

The script is extremely simple in that very little error checking is done. The basic logic of the script is to identify the first call $+5, the pop <reg>, and add <reg>, <offset> signature in the function. From this, the script can identify which register is being used for the offset and then find each line of code that uses this register in a [<reg>+<displacement] configuration. For each line found, a comment is created that will contain either the address that is being referenced or if a name exists for that address, the label of the address.

It wouldn't take much effort to modify this function to run through all functions in a binary and perform this same operation for each of those functions. But for now, this suits my needs.

greg.

Relative offset commenting script 

On my code page are two new IDC scripts that will be helpful to anyone trying to groom a CHICKEN idb. The first script will take the heavy lifting off a reverse engineer when constructing variable names to associate with the symbol strings. The script will not be able to handle situations where the symbol system starts with a non-printable character (for symbols with the "##...#" labeling), but it will indicate where these manual touch up points are. When dealing with several hundred symbols, this script will save a reverse engineer hours.

The second script will setup the basic structures and enums used with CHICKEN applications. While not exactly necessary when grooming a CHICKEN database, these items are extremely helpful.

greg.

Remember back in your college AI class when the professor made you use Lisp to program your AI experiments? Or maybe you were in a programming language class and you had to use Lisp. Remember the pain and suffering imposed by the use of ( and )))))))))))))))))))? I do.. and as such I've always had a particular dislike for Lisp and any other languages like Lisp... namely, Scheme.

I was working on a project recently that required me to reverse engineer a particular binary responsible for handling a key piece of data manipulation for the system under review. So I loaded the binary up in IDA and gdb and off I went to see what was under the hood. No sooner than I traced the one and only call from the main(...) did it occur to me that something was very, very wrong. Of the nearly 1000 functions in the binary, about 99.5% of them ended in either

call eax
or
call eax+4
and then the function would end. That's it, just end. Not a retn in sight. So obviously this was frustrating. Moreover, the eax in question was the result of some obscure function call that passed a variable that never seemed to be assigned a value. So how the hell was I supposed to trace this program? Or more importantly, how the hell did it even execute?

As a reverse engineer with years of x86 experience, there are certain things I expect to see in a function.. a stack, a jmp, a call to a defined function, a function that returns. You know, the basics. So what was going on with this program?

Digging around a bit more I found that this program called a library named chicken. Seriously, it calls a library called chicken. Digging around the web lead me to the source of this mysterious library... www.call-with-current-continuation.org.

As it turns out the binary I was reversing wasn't originally written in C or assembly or even Fortran for that matter.. it was written in Scheme (a dialect of Lisp). My blood immediately turned cold. My hard feelings toward the language of the ( and )))) had come back to haunt me. So not only did I feel that the language was evil in its original form, but this compiled version did nothing more than to strengthen my dislike of it.

Well, I had to reverse this part of the system.. I had no choice in that matter. How the hell was I going to do this? The program was used as a CGI script so I could execute it through the web and watch how it interacted. That was an option, but I'm old school in that I love doing static analysis. I love it! Give me a binary, ask me how it works down to the level of how the structures are defined and leave me alone for a while, and I'll come back to you with a report on the insane details of the program. Its what I do, it's what I enjoy. But static analysis was out of the question it looked like, so with gdb fired up and ready to go, I ran the program single stepping all the way. This painful process only deepened my hatred of Scheme and this bastardized compiled version of it.

I quickly realized that single stepping through this program would be a waste of my time and the few remaining threads of sanity I had were quickly being eroded by this program. Time for a different technique....

A few weeks passed and a lot of research was done. I read the website for CHICKEN, I read the wiki on CHICKEN. I learned a lot, I forgot even more. I found a paper on the wiki that described the process by which Scheme is changed to C by CHICKEN and then compiled. You heard me, CHICKEN takes Scheme code, converts it to C and then compiles it (typically with gcc). In this paper they gave two examples of how the conversion works, neither of them were easy to follow for someone who didn't understand Scheme (which, I will admit, I still don't). But the paper did give me enough insight into what is happened to start making some educated guesses. As it turns out, CHICKEN converts Scheme into C by changing the way the program is executed. Instead of a standard stack being used to hold local variables for a function and return addresses for functions to, well, return to, CHICKEN converts the Scheme code into "continuous passing style" ... in a nutshell this means that each function simply calls the next function and passes along a data block for local variables the function will use and a data block to be used (at some point in the future) to call after that. There is a lot more to it, trust me.. but that'll give you an idea.

This was great... I was looking at a program that malware authors would send back saying "um, yeah, even we don't make programs that hard to follow." And the web, the web was useless when it came to trying to find resources for reverse engineering CHICKEN applications.

But never fear... long story (and this was a long story) short, I come to you with a paper on how to reverse engineer CHICKEN applications.. ta-da (this is where the trumpets would start sounding). After a few long weeks of reversing, researching and experimenting, I have finally figured out how to read CHICKEN applications. I can't convert them back to Scheme (and really, why would anyone want to?) but I can now give you the information you need to reverse these horrible little programs yourself.

I hope my suffering can help you in the future. As a friend of mine said when I told him I was writing a paper on this topic once told me "I'm sure the other 3 guys on the Internet trying to reverse CHICKEN will thank you."

greg.

The paper to date: Reverse Engineering CHICKEN with IDA

This is the start of the NNL-lab website/blog. ... more a website tho. I have nothing else to say... but I'm working on it.