Decoding Java Script Walk Thru

This is from a request by Herbie Zimmerman‏ @HerbieZimmerman to show how my decoding process works to decode a script found on Payload Security by My Online Security‏ @dvk01uk (Twitter Link to Conversation

Link to file download on Payload Security

After downloading the script we first see this . This just looks like a big mess.


If we look at the bottom of this section we find this.


As we can see here is is using “DcyHCgvJUL” as the split then rejoining the sections that were created.

What is is effectively doing is replacing the string “DcyHCgvJUL” with nothing or just remove every instance of the string from the full string.

So after we do that and clean it up so it is readable we get this.


We can see the highlighted in green the function and Char Code that get replaced. In red shows the “String.fromCharCode”.

After we clean that up we see this part.


Here “ivtDmuhkcPSLyzelI” is getting the value of the registry key which is the same for Windows 7 or Windows 10.


So the value is “C:\Users\Public\Music”

Here “rxMIJzwygfbtaPXoR” is using the function “sNIVfMCzcKwAmxOPoEv” to get the char code at index 1 which is decimal 58. Index will start counting at “0” Zero here.

That’s as far as we can go here, so lets take a look at the remaining parts of the script.

Next we see a section that will get the current year.


In the next section it looks similar to the first but if we search for the variable name there is only 1 hit which could indicate that it is only used to confuse the reverser.


After looking further down and not finding anything that would decode and use this function, lets just get rid of this section.

Next we see what the get year does.


It will get the current year and compare it with the value of 2017 and if they match then run eval function. Which we don’t find yet.

The next section down is another large section of scrambled looking text. After looking further this appears to be more junk code so lets get rid of it too.

That leaves us with this final section that appears to decode something . Lets clean it up and see what it does.


This section will take the string in “LIDuvEgKznlBWFkV” and run thru each char and get the char code and add an amount to it and if it equals 1 of 2 amounts or the file path from the registry does not exist or if the file path = 58 then ignore it. Else we take the charCode and get the Char and add it to a new string.

But first we need to reduce that math function to know what values they are working with.


In order to figure out what this will evaluate to we have to understand the order of precedence for the math functions.

So going by the order of precedence we would see this.


So this value is  “-1”

And the Next 2 values


So now we can get a better idea of what the values are doing.


So now we know we get the char code for each Char and add “–1” (Subtract 1 from char code) if result = 42 or 64 we ignore it and go onto the next Character in the string.

And when Decoded it looks like this.


This could have been done by building a html wrapper around the functions needed to decode but I usually just build a windows program for doing this type of decoding.

But you can also see that it also needs to be “Unescaped”


This is meant to be evaluated so it has extra escapes in it so lets clean it up a little better.


So this is the final script that gets run.

While looking at the code and following all of the eval functions there was 1 variable name that was not found anywhere during the decoding process which suggest to me that this script was called by something else.

This is at the very bottom of the script , it calls this final decoded script to run it.


Well that it for now I hope someone learns for this as I did.

Posted in Malware, security | Tagged , | Leave a comment

A look at the Magnitude Exploit Kit encoding

In this post I will be going thru the multiple ways that they use to encode 3 pages in the pcap. I will use the pacp available from Zerophage @Zerophage1337 located here

We will start with the initial get request at packet 178.


Notice anything strange about the “Full request URI: “ It is doubled up. Make note because we will need this later.

Next we get our first encoded page in packet 180.


When we first see this it looks like a jumbled mess.


After formatting by hand it is a little more clear on what it is doing.


In an older version they had “toString” set as a variable but here they are using Unicode encoding “toS\u0074r\u0069\u006e\u0067” so lets fix that.


Next lets take a closer look at the first function.


So what does this do? A quick look would make it appear that it is using the value left of the comma on each side of the operator to get a Boolean result and the larger number right of the comma gets used in the “toString” function. In other scripts I’ve looked at if the result is true then it will use the left value, if false then it will use the right value.

In the “toString” function it really only accepts 1 parameter so the second value appears to be ignored.

When we see a function like this “ (1294399205).toString(36) “  this would be converting Base 10 to Base 36.

I’ve noticed that so far that the number on the right is always used so I don’t bother to do the math. It is still only 2 possibilities anyway. So the result of decoding this is.


So lets go thru and do all of the decoding and replacements.


Now that is a little better but we still have some encoded parameters.

So how does this work ? This is where that note comes into play from above. We take the full path “ http://fx4you%5B.%5Dnet/” (not including the brackets.) and tack on the string  “m6t35”.

So the numbers in the parentheses is the index value from the combined string.


So lets do the replacements on those.


Now that we have that complete, that just leaves the parameter of “dgaO0”. The values generated from this is a form of a Checksum calculated by adding the char code values of each letter for the screen property and then Xor’ing that result by a number and tacking on “y” and then the real value of the property and tacking on a “t”. It will continue for all of the property values.


In each of the pcaps I’ve looked at the Xor value has been different. So that number will change.

When all of that is combined we end up with the full get request in packet 182.


So now we are at packet 184 lets take a closer look at the formatted page.


This decoding is similar to the last one but as you can see something strange is going on here. They are using a value from the screen info  and adding something else.

After decoding the first part now we have this.


Now if we look closer at the function “n57TV13J” we will see that it takes as input 2 number values and the left will add the value of  screen height to it and the right will subtract the value of “systemXDPI” from it.


We can reverse calculate what these values are or pull them from the last get request.

If we set it up like a chart then we can see what we need.


The indexed values are the values from the get request. The bottom list is the calculated parameter values. We can just look and see that for “Height” we get a value of 632 for the checksum and 1024 for the real screen height. We get 987 for the checksum and 96 for the real value.

And to calculate the result.


Now lets go thru and do the rest of them. Here is what we end up with.


Now it looks like we still have several Index values to replace using the URL that led us here.


Now lets do the index replacements and see what we end up with.


As we can see here it is checking for Kaspersky Virtual keyboard and if not found it will make the call to the next Url. I assume it will just quit if it does or throw an error, I can not find a reference to the value in the catch statement.

In packet 186 we see the get request and in packet 200 we see the obfuscated page we will work with.


This is a very busy page. It used the base decoding like in the first section, but it also uses Hex, Integer, and Octal Char codes to build strings.

I’ll save everyone the step by step on this one as it is a long drawn out process to do it by hand.

After decoding and formatting the first section and decoding the variable array for “lW” we get this.


All of the “lW” items highlighted get replaced by the index value, so lets do that. (Note: commented section with the decoded array.)

Even after decoding and doing the replacements we still have some math functions and other encoding to tend with. We have multiple layers to hide what is going on but we can still get and idea of what is happening even with the bad formatting that yet needs to be cleaned up.


The highlighted section shows a call to download a scriptlet file.

Here further down we can see 2 possible execute calls.


There is still a lot of formatting and possible junk/unused code that could be removed but we should have enough to tell what this is doing and it most likely would not run  in this state either.

The web request from above is found in packet 329 and the response in in packet 340.

After formatting this packet here is what we have for the downloaded scriptlet file.


Even with the slight obfuscation here we can see that it will make a call out to that URL download and run the file.

And if we look up that Class ID we find this.


What do you know borrowed malware.

Well that’s as far as we are going on this one.

Thanks for reading if you got this far.

Posted in Malware, Networking, security | Tagged , | 2 Comments

Angler Exploit Kit Steganography

When I first started working with exploit kits I started with Angler EK.

I was learning how the redirect from the compromised site worked and building tools to decode them. Once you get to the exploit kit landing page then the work really begins. There were several different encodings and encryptions used to conceal what was on the landing pages.
With that much data to go thru I did not work much with the flash files as most of my spare time was used trying to figure out a new encoding for the landing page or the PHP redirect and then build tools to quickly decode them.
Now that I have a little more experience and more tools in my toolbox I decided to go back and take a look at a later version of the flash file before they disappeared from the internet.

Our first sample from here

We see the layout of the flash file and how obfuscated it is.


Anything with “this.Var_1.” gets a replacement.


Now if we skip forward in time to this one and take a look at the PCAP file we see that there are 2 different flash files downloaded.


Lets take a look at the first one.

We first see a picture file and no binary data file.


We also notice that there are only 3 script files in this one.


Hmm, looks like it might be working with a picture file.


What are these numbers as a string ?


This Look like it might do something . Lets save this and take a closer look with Notepad++.




Even obfuscated you can see what this third section does. This is a RC4 decryption that uses the “&” instead of “%” 255. (I’ve seen both used in different decoders)

Now lets do the replacements and see what this looks like.


This first part is getting us set up , I’m mainly just showing it with the replacements.


Here you may be able to see my notes. Method_1 will kick things off and call the function to get and extract the data from the picture file then it passes that data to method_2 to do the decoding using the key from function “lII1I1()”. It will then load the bytes returned and go from there.


Here we see it gets the picture data using the built in function to work with bitmap data.

It will create 1 loop inside another to extract the the data using the height and width as the upper limits for the 2 different index values.

It will next get the first pixel a position 0,0 and convert the RGB values into an integer value and then “&” it with “16777215” to use as a output data length limit.

This will keep looping thru until it gets all of the data into a new byte array.

It then runs it thru the RC4 decryption to decode.


Now we have enough information to build a new tool.


This tool is simple. We select the Picture file, input the extracted key string and click a button and it returns the decoded hex output.


Next we just copy paste this into a hex editor to see what we have, and as you can see it is another flash file.

We now save this in the hex editor as a swf file.

After opening it up in JPEXS Free Flash Decompiler we see that this is a large file.



There is a lot going on in this one and will take some time to work my way thru it.

I went thru another one from later and it was much smaller so this may have still been in the development  mode. The later version  also used the same decoding function but a different decryption key.

That’s it for this one.

Thank you for reading.

Posted in Computer, Malware, security | Tagged ,

Ghost In The Wires Paperback Ciphers

I received the book in mid December 2013 as a early Christmas present and completed reading it on December 24th 2013 and then began working on the ciphers.

I was first trying to copy all of the ciphers  by hand to a notepad document and it was taking a long time and discovered I had several mistakes as I would go back thru and double check.

Next I got the bright idea of trying to scan the pages into a text document. That did not work very well either, the scanner program used did not recognize all of the characters in the font used in the book and was more of a problem to fix them than to try and copy by hand, so that was what I did, copied every 1 and 0 and everything else by hand to a text document. Needless to say it took a while to get it done and I still found mistakes as I was going thru the ciphers to solve them.

It has been some time since I have worked with any ciphers so I needed to go back and look up how to work with them. I spent the first bit of time trying to see just what type of ciphers are out there and how to work with them. There are allot of pages on the internet to help.

Next I looked up to see if anyone had already posted all of the answers.

I first ran across this page about the Hard Cover version of the ciphers.

That gave me an idea on how to start and what kind of ciphers were used in the hard cover version. They are different in the soft cover version.

Once I was about a quarter the way thru I ran across this page for the soft cover version.

This site had the answer to one of the ciphers I was working on and my tool that I created did not agree with the answer they had, so I emailed Fabien Sanglard to ask about it, but before he had a chance to answer I found the mistake in my program and I was able to verify the results posted on the site.

It was his suggestion that I write up my answers and post them for others to view.

I already had several of my own tools for other things and created more as needed and then converted some of the C++ versions from the hard cover version to VB.Net to help me. Next there are also allot of tools online to help with different ciphers but they do not all work the same or give the same results for the same Cipher.

When I was over half way thru I ran across this page by the co creator of the ciphers
Disa Johnson that was written April 29 2013 they explain about the way the ciphers were written and at that point only 1 person had submitted the correct answers.!/2013/04/ghost-in-wires-ciphers-paperback.html

That post got me looking closer at the patterns of the ones I have already solved and I was able to apply that to more and solve others. (Mainly the rail fence and Play Fair ciphers)

Most of the ciphers have at least two levels to decipher them. Some were just reverse the string then split them into the proper words after the first level was done.
Not all of the ciphers require you to have the answer to the one before to solve them so I was able to skip around a little as I got stuck on some.

Once you get the cipher deciphered to get the question, you still need to go to the book for that chapter and find the answer to the question. Then you are done with that chapter.

Next I will go thru and tell what they were. Some were just a matter of running them thru every tool I could find till I got the plain text, I was able to solve some of the column ciphers with pencil and paper. As you go thru them you do start to notice certain patters and are able to eliminate certain ciphers that would not have been used.

I will not post the answers to the questions that were revealed in the ciphers here, you will have to read the book and find them on your own. This post is just for the ciphers and the questions they revealed.

I mainly just copied from my notepad notes what my output was.

Chapter 1: Rough Start
Max vhlm hy max unl wkboxk ingva B nlxw mh ingva fr hpg mktglyxkl
The cost of the bus driver punch I used to punch my own transfers

This cipher is a standard rotation cipher they left all of the spacing and just rotated the alphabet. It is encoded with “Rot 19” and decodes with “Rot 7”. There are 26 letters in the alphabet so to figure this out we subtract 7 from 26 to get 19 that tells us what it was encoded with.

I started with a tool that I made that would rotate what ever number you wanted from 1 to 26. If you rotate 26 you get back to the same text you started with.



Chapter 2: Just Visiting
Estd mzzv esle elfrse xp szh ez ncplep yph topyetetpd hspy T hld l acp-eppy
This book that taught me how to create new identities when I was a pre-teen

This is another rotation cipher. Encode with Rot 11 decode with Rot 15.

Chapter 3: Original Sin
pbzfsobp dkfobtpkx lq pbkfi ppbkfpry aoxtolc iixz lq abpr bobt pbzfsba cl bmvq obail bpbeQ
secivres gnirewsna ot senil ssenisub drawrof llac ot desu erew secived fo epyt redlo esehT
These older type of devices were used to call forward business lines to answering services

This is another rotation cipher but this time they added a twist they reversed the string.
At this point is was getting time consuming to click the button for each number so I created a new tool that would do all of them at once.


In order to see if one of these are correct we need to read from both sides and see if it reveals the plain text. I have another tool that will reverse a text string but that was a pain to copy paste all of the time so I added that ability to the program. if you look close at the screenshot above you can see the reverse plain text as Rot 3 so lets reverse it with this tool and see what we get.


Now that is easier to read and quicker to see if it is a “Rot” cipher or not.

Chapter 4: Escape Artist

the name of the mainframes I hacked at usc in the arpanet days

This cipher is a Atbash cipher where the alphabet is just reversed  a=z b=y and so on.

I created a tool for this one too.

Chapter5 : All Your Phone Lines Belong to Me
jbi ujt veo eco ntk iwa lhc eeo anu uir trs hae oni rfn irt toh imi ets shs leu

I took a course in this subject when i ran from the juvenile authorties l (extra letter on the end for fill)

This is a column cipher. They are split into three letters, if you stack them from left to right top to bottom then read down the right column you can see what the plain text is.

The tip by looking at it is that they are split into groups of 3.

Chapter 6: Will Hack For Love

name the company where bonnie was employed when we started dating

The two equal signs on the end is a dead giveaway that this is Base 64 encoded.
There are several tools on line to decode this but I already had a tool from other projects that made this easy.

Chapter 7:Hitched In Haste

number of door codes i had for pacific bell central offices.

This is a Keyed substitution cipher. It uses the key of gte.

Several tools are available online to encode decode this one.

Chapter 8: Lex Luthor
‘siass nuhmil sowsra amnapi waagoc ifinti dscisf iiiesf ahgbao staetn itmlro

I said I wasn’ This famous magician While being a smart ass to prision officials

This cipher is a column cipher if we start stacking the groups of letters starting from the right and read down on the left side then the plain text is clear.

A clue on this one was that they were split into equal parts again.

Chapter 9: The The Kevin Mitnick Discount Plan
tvifafwawehes hsesoonvtlimaeloemtcagmen irnoerrldony

this version of novatel firmware allowed me to change my esn

This is a rail fence cipher the clue given for the number of rails is the amount of groups the text is split into. In this case it is 3.

Chapter 10: Mystery Hacker
gnkusr ooursnsisti ttnotoihiec rolwaintmlk ovtgp

got root on unlv work station using this simple trick

This is a rail fence cipher also. It uses 5 rails and the cypher text is split into 5 parts.

Chapter11: Foul Play
ow gw ty kc qb eb nm ht ud pc iy ty ik tu zo dp gl qt hd

This is a playfair cipher it uses a standard alphabet minus the letter j and no keyword.

When I read the title it made me think of playfair, but none of the titles really seemed to have anything to do with the cipher chosen.

Chapter 12: You Can Never Hide
idniidhsubrseognteiuignuhrzdalrd ietfetinmeablnigorcsnuatoieclei

i identified this number as belonging to eric using unauthorized caller id

This is another railfence cipher uses 2 rails.

Clue was text is split into 2 parts.

Chapter 13: The Wire Tapper

manager who i tipped off about wiretaps on teltec’s lines

This is another “Rot” with a reversed string. encode Rot 24, decode rot 2, reverse the string.

Chapter 14: You Tap Me, I Tap You
c2VuaWxzJ2RhZHltbm9zcGF0ZXJpd2VodHRjZW5ub2NLcm RuYXNlbGVnbmFzb2xvdHlsZm90ZGFob2h3dG5lZ2F5d GlydWNlc2xsZWJjYXBlaHQ=

the pac bell security agent who had to fly to los angeles and rK connect the wiretaps on my dad’s lines

This one was given away by the equals sign on the end as base 64 again. Decode and then reverse the output to get the plain text.

Chapter 15: How the “F” did you get that?
ud mn cf ub mw re lb is ba of gx ty qc qh il ea ym nx bz ub he cf th is


This is a playfair cipher using a normal a-z alphabet minus J and no keyword then reverse the result string.

Chapter 16: Crashing Eric’s private party.

i asked eric for the key to this phone company facility

This one I had some trouble with at first until I used the correct key.

This starts with a phone dial cipher to convert the numbers to letters.
once you get the letters then it deciphers with the Vigenere cipher using the keyword heinz.

The problem with this one was, the keyword was not in the section of text that the answer to the previous question came from like the previous ciphers. They only listed the persons first name and not the last. You had to get that from another location in the book. And thus the keyword was the persons last name.

Chapter 17: Pulling back the curtain
100 0000 10 1 01 001 00 1000 1 010 11 000 0 0000 11 000 000111 00011 10000 11111 11110 11000 00111 10000 11111 10000 11111


What number is this 310-477-6565

This is Morse code as 1’s and 0’s instead of dots and dashes. First you get the letters and numbers as a dot would be 0 and a dash would be 1, then you reverse it the dot would be 1 and the dash would be zero. Read up and down to get the plain text

I made a tool to help with this too.


Chapter 18: Traffic analysis


i identified the fbi cell phones that where calling eric by hacking into this ceppwxktmzsbhzc

This one is hex to start with and then we convert to ASCII. Next we run it thru a Vigenere decoder with the key IBFAL (the shortened and reverse of the previous answer).

Chapter 19: Revelations

te el ae fn ba et hs cv rd ni ya js pw rl
hr an mo af ig nw oe oe ie tt ws oe he ne

the real name of an fbi agent whose cover identity was joseph wernle

This one is a column cipher also. I discovered this one by accident using another tool I built that will split a string into how ever many characters you want up to the length of the input. When I split them in two and copied them to a notepad it just happened to only be wide enough for half of them to fit wrapping the remaining half to the next line.

Read up and down to see the plain text.



Chapter 20: Reverse String
yo kb pn oc ox rh oq kb oh kp ge gs yt yt hg sa li mt ob sa po po mk pl md


This is a playfair cipher using the key of fbi .

just a note some of the play fair ciphers were split into 2 chars.

Chapter 21: Cat and Mouse

darrell santo’s voice mail password was this

This is hex that converts to ASCII then  run thru a Vigenere decoder with the key TRW.

Chapter 22: Detective Work


This is a playfair cipher using a normal a-z alphabet minus the letter J and no keyword.

Chapter 23: Raided
1001 0111 01 00 0 0 101 011 1111 1110 1011 1111 101 0110 1111 1101 110 010 100 0 0100 11 1011 1011 000 10 101 01


This one starts out as Morse code with the 1’s and 0’s reversed (in my tool). Next it is run thru a Vigenére Autokey  tool with a key of DDI.

Chapter 24: Vanishing Act

code for a wanted person in las vegas

This one is a playfair cipher with the Key fibdonuts then reverse the output to get the clear text.

The trick here was the spelling of the key. “Donuts” not “Doughnuts”

Chapter 25:Harry Houdini

nhy ite kmn ryo ogm wef eho ctt ntn oau tto sum ooa lge i

i lost once working out at the gym the amount of money

This one was split into 3 chars and then stacked starting from left to right top to bottom

then read from bottom left up.

Chapter 26: Private Investigator

11 0100 000 111 010 0 011 0010 000 010 11 10 1101 01 01 1 000 1 1111 01 0 011 1 010 1 1000 000 010 01 00 01 01 011 00 1101 0010 1 010 1 10 0
001101 110010 001101 110010 001101 100 0000 1 10 101 0 111 0 10 010 0101 0000 11 10 001 10 1 011 00 100 1 10 0 00 0 00 1 000


i looked for infants  that were born in a different  _______  When researching new idendenties

This one starts out with the Morse code. We need the forward and reverse then stack them.

Read up and down zig zag to get the plain text.

I used the Blank space here to help me focus on the answer to the question revealed in this chapter.

Chapter 27: Here comes the sun
the host name which was used for the security bug database at sun microsystems

This is an autokey cipher using the the key of state.

Chapter 28: Trophy hunter


a security flaw in this program allowed me to break into novell’s firewall

This one starts with Hex encoding, we convert to ASCII. Next we use Vigenre Autokey with the key of elmer , next we reverse the output to get the clear text.

Chapter 29: Departure

the name of the employee that set me up an account on novell’s 3com dial up terminal server

This one is a playfair cipher using the key of sendmail. I used the decoder on this site instead of this one because to properly decode the cipher you had to uncheck the box dealing with double letters.

next reverse the output of that to get the plain text.

Chapter 30: Blindsided

the reason i was fired from the law firm in denver

This one uses the autokey cipher with the key Nunley . Next reverse the output to get the plain text.

Chapter 31: Eyes in the sky

this person was tricked into sending me numerous vms security holes

This one uses the Autotkey cipher with the key of consulting. Next reverse the output to get the plain text.

Chapter 32: Sleepless in Seattle

i compromised this user’s password through network monitoring to hack into shimomura’s server

This one is an Autokey cipher also with the key of Clift. Next reverse the output and to get the plain text.

Chapter 33: Hacking the Samurai

010 1 0001 101 0 111 000 100001 01 101 001 00 111 00 00 1111 000 01 111 1 10 000 0000 1001 000 11 0000 0 111 0 0 0101 010 110 111 111 0 1111 1
101 111 1101 110 01 00 010 111 000 0100 111 01 100 00

I was looking fo* * (the) source to this phone on shimomuras server

This one starts out as Morse code as 1’s and 0’s again. You have to get the forward and reverse of the output  stack them and then read zig zag from upper left.

Chapter 34: Hiding in the bible belt

this employee at intermetrics uploaded the motorola compiler for me

This one uses the Bifid Cipher and the keyword of oki. Next you reverse the output to get the plain text.

The interesting thing about this one is I used the tool located here to decipher it with. with more research on this cipher I discover that it also uses a “period” or length of text to work with. I then looked at these two online tools and

This is where I discovered about the period. So after some more investigation I discovered that this cipher was deciphered with a period equal to the length of the cipher text.

Chapter 35: Game Over

someone logged into my “marty” account on this system from the well

This Cipher is also a Bifid cipher, decipherd using the same tool as above.

Key = Marty and the “period” = Cipher text length.

Chapter 36: An FBI Valentine



Chapter 37: Winning the scapegoat sweepstakes


Chapter 38: Aftermath: A Reversal Of Fortune

001101 110010 001101 110010 001101 110010 001101 110010 11 00 011 00 10 110 0000 11 00 1001 110
0100 111 10 11 00 1101 1001 0100
10 100 11 01 101 0010 11 101 011 111 00 100 010 1001 001 1 101 01 010 1010 01 0 1110 10 0111 010 010


The use of statistics what not of much use in the solving of these ciphers in regards of Identification of them with the exception of the obvious things such as Hex,base 64 encoding Etcetera.

I found 3 online cipher ID programs and none came close to the ones I tried to run thru them.

One was from a program that is called Crypto Crack than can be found here: . It still has some bugs in it and I was able to crash it using several of the cipher crackers although the ID part did run without problems.

Next was from a online site here. . This runs the statistics on the input unknown cipher.

Last one is this one and it looks like it has been updated since the last time I tried it. .

This one gives extended information about the cipher.

The best use of statistics was the use of “N-Gram” files  for scoring potential plain text.

On this page for the Bifid Cipher I found information and a “C” version of a cracker program.

After converting the “C” to VB.Net I was able to then use the scoring system in several other programs.

See Bifid Cipher Under tools.

Using the tools to try and find what cipher I was dealing with the top result was always for the “Running Key Cipher” so being stuck on chapter 36 I made a tool for that.

See Running Key Cipher

The Index of Coincidence (I.C) I one method for testing what type of cipher it may be.

Looking at the results of 5 Playfair   ciphers used in this group of ciphers we see that the I.C. score is varied.

11: playfair cipher no keyword, just normal a-z alphabet -J  I.C. = 0.0384  (38 chars)
15: playfair cipher no keyword, just normal a-z alphabet -J ,reverse string  I.C. = 0.0346  (48 chars)
22: playfair cipher no keyword, just normal a-z alphabet -J   I.C. = 0.0541   (30 Chars)
24: playfair key= fbidonuts,normal a-z alphabet -J, reverse string   I.C. = 0.0506    (30 Chars)
29: playfair key of sendmail, do not Encode double letters (down and right one spot), reverse string output. I.C. = 0.0411  (72 Chars After Clean extra)

As we can see by these results the ones without a key had low scores along the lines of a Vigenère cipher with the exception of the one that was only 30 Characters long.

The last one had a lower score than the two biggest I.C scores.

So and I.C. score does not always prove what kind of cipher it may be.


I have shown a few tools above but will show a few more below but will not go into great detail on how they work because of the complexity of them would require an article about them on their own.

When I find time I will do one on the Hill 2 Cipher and the plain text cracker I made.

Bifid Cipher:

This was the first tool I made with the scoring system so the source code is kind of ugly but works.


Here we see the unsorted result of running the keyword list thru the program. The keyword list is the list of words from the previous result in this case this is Chapter 35 cipher with the keywords from the result of Chapter 34. From that list the program will create a new list of keywords using the original keyword forwards, backwards and spiral which is why there are so many close together.


Here is a sorted list, since these are negative numbers the lower the number the closer to Zero it is the better the score. Some online tools would change the keywords into several different directions on how they laid out in a alphabet. As you see in this example the keyword was prepended to the alphabet and those letters were removed from the remainder of the alphabet.

The interesting thing here is whether the alphabet was used forwards or backwards it still decrypted the text the same.

I have updated this with the new Quicker Score output to speed this up.

Running Key Cipher:

The running key cipher uses a section of text, perhaps from a book or a newspaper, etc. to encrypt  the Phrase that you want to hide.

Here we will use text from chapter 35 that I was able to locate online.

Here is the Phrase we will encrypt pulled at random from the chapter 35 text.

Plain: Several weeks earlier JSZ had set up an account for me on escape com

Here is the text we will use to encrypt it by, again chosen by random.

ET: Shimmy was winging his way to Raleigh JSZ sent me a message that left me up in the air Hi This AM my dad had

Although this text is longer than the Phrase to encrypt the tool will only use what it needs.



When I first built this tool there was no automation so I would pick a section of text and step thru it 1 letter at a time but after working out the scoring system I added the automation.

This program will clean all formatting including punctuation, Spaces,number etc. .

Here we assume that the key text is somewhere in in the chapter 35 text so we will load the N-Gram file in this case Bigrams(2 Characters) and  the entire text from chapter 35 that I have a previously cleaned version to speed things up a bit.


A newer version of this program and others I added an extra part of the scoring system to only output the top scores that greatly improved the performance of the programs that used this system.

So far the Bi-gram file was good enough to discover the correct output in every cipher tool I have built so far as long as I had the correct input for the cipher type, as in the wrong input key list will not return decrypted text properly.


In conclusion I would like to thank everyone that posted papers or created web pages on the many ciphers that are out there.

Next I may try and tackle the Kryptos K4 cipher I have a few Ideas that I would like to try.

(None of those worked out but this came close )

Here it is now in November 2016 and I have not had the time to find the solution to the last 3 ciphers but will post this anyway since I could not find any others with this many online.

I will update this if and when I get the answers to the last 3.

If you made it this far, Thank You for reading this rather long blog article and I hope you learned something  from it as well I as I did writing the programs and discovering the inner working of so many ciphers.

Posted in Ciphers, Programming | Tagged

A new version of the Rig EK

It looks like the developers of the Rig EK have been busy.

In my last post Pulling apart Rig Exploit Kit we see the way the decompiled flash file looked. It used several action script files and used 2 different configuration/replacement arrays to do its work. They used a combination of RC4 and AES to decode the embedded binary’s to get the arrays.

The first sample of this new version I have found is 2016-09-08 – EITEST RIG EK FROM from Brad @malware_traffic and found here . If you read that article you see the the EITest campaign was back after a short pause.

If we take a look at the flash file from 2016-08-31 – EITEST RIG EK FROM Here and do a quick check with SWF Investigator we see this.


Here we have multiple Action scripts and 5 defined binary data items.

If we look at the new version we see this.


This one only has 2 action script files and 1 defined binary item.

The first few that I looked at had the same “Names” but after that I have seen a change.

So what in the world did they do here.

Lets open this up in “JPEXS Free Flash Decompiler” from Here and see what we find.


We can see here that is has changed and starts out with a with the check for.


Next we scroll down to the the decoding function for our embedded byte array.


and here


Do you notice anything strange about this ?

There are several “this.init” assigned the same name. So what gives.

If you didn’t notice in the above screenshot this flash is obfuscated by the DoSwf tool.

If we go to their site then we see this.


And on another page we see this.


So that explains it.

After an Issue was submitted on the “JPEXS Free Flash Decompiler” site in their issue tracker, within a few days there was a new version available that can help with this problem.

So thank you Jindra Petřík (aka JPEXS) for fixing this so quickly. I’m sure most issues don’t get fixed as quick though.

So what does it look like afterwards.

Before setting the checkbox to auto rename  classes  we can see the name are not readable.




And a closer look at the code.


If you notice now there is an index number on the end of the names to make them distinguishable. Now that we have an idea of what goes where lets take a look at the embedded binary.


Ok so how do we read this ?

If we take a quick look at the SWF File Format specification then we see this about bytes and unsigned integers.


So we read the bytes like so.


Now we can look at our code again.


The first thing this does is pull our data bytes out. “_loc2_” will be our new byte array formed from the last “init#24”(0x5640) length bytes from the embedded byte array.

While less than this length it will do a nested while on lengths of “init#27” (0x14)  Xor’ing the byte at the index position by “init#26”(0x60) , each loop it will add 7 to the index.

Once it completes this loop it will then do a Un-compress. One thing to note is that this is using the ZLIB version not the same version that Neutrino was using.

So what do we get when we get done ?


As is, this will not load in a decompiler do to what ever it was that the DoSWF has done to it.

If we scroll down our code more we have an idea to help us to figure it out.


Looking at this it tells us it is taking the first byte and reading it in as a Boolean value. If True it will just go to the function  “this.garbageBytes#23” and create a garage Swf byte array.

If false then it will continue on and check the next byte which in this case appears to result in “True” .

Next it will take the next 4 bytes to get the length in LittleEndian byte order for a new Flash byte array.

That is about as far as I have gotten on this right now.

As you can see there is more research to do here and time to dig back into the SWF File Format specification to see if I can find a way to get this to load into a decompiler.

That it for this one I hope it helps someone.

Posted in Malware, Networking, security | Tagged , , | 3 Comments

Pulling apart Rig Exploit Kit

In the last post, A look at a cross bred Neutrino EK–Rig EK Flash file we see where the two exploit kits were merged into one.

This one is pure Rig and looks the same on the surface as other samples I’ve looked at.

The sample used here is from Brad @malware_traffic 

The main differences between Rig EK  and Neutrino EK are the the Neutrino EK uses a layered approach with multiple flash files and embed binary files that get decoded as needed. The Rig EK uses more of a scattergun approach. they use 1 flash file and multiple embed binary resource files.

They also split the functions into many classes, functions and parameters to make it more difficult to follow along. Some parameters/vars just get passed to a new ones and not used right away.

Note: My hats off to the person(s) that made the obfuscation tool the exploded this thing into 20 different files. That said I hope whomever it was is turned into a babbling idiot after writing it. I almost was trying to follow along with this crazy maze. I feel better now.

As mentioned above they are splitting everything into 20 action script files and are using 5 different embedded resource files.

They are using 2 different Xor functions to calculate the index value for the extracted replacement values.

They are also using the RC4 encryption for one set of replacements and AES 128 ECB for the other set of replacements for a total of 25 different values decoded for use as replacements throughout various parts of the code.

If we look at what the files look like in the folder normally after decompiling we see this.


But if we let it do a rename for us we see this.


That’s much Better and if we look at the Second file that it calls.


And after renaming it looks like.


If this looks familiar then that is because it is the same function from the last post. The difference is, instead of leading to the RC4 decrypter it is leading to a very well exploded self contained version of the AES decryption routine. It will work the same way passing the values to get decrypted.

I believe that they may have done it this way so there would not be a call to the built in crypto provider to raise a flag on what was used, or what they wanted was not available.

This version is only extracting 6 byte arrays to decrypt and 1 key. The last byte array is 2528 (0x09E0) bytes long and is listed as the shell code.

They do several things to this “Shell Code” byte array before it gets used anywhere. It gets sent to string, has another string tacked onto the end of it, get turned back into a byte array, gets reversed (littleEndian) , and that’s all I can remember off hand.

In this view of class_12 (file)  we can see there is allot going on.


If you look close at the two “Calculate replacement index value”, you will notice that they are calling two separate classes. Although they are two separate classes the number that those values gets XOR’ed with is the same number. The class_14 gives you the value for the index number to calculate in the RC4 decode, the class_2 is the extracted and reversed binary value and converted to Integer to get the value to XOR with,  that is for the AES decode.

Here we see the the start of the RC4 decode routine with the value (var_78) that is used to do the XOR to get the index value.


and here is the XOR routine.


I the screenshot above I was comparing the the values from the the RC4 and the AES to verify they were the same.

Using a tool I created for working with Angler EK to calculate the XOR  32 bit values we can verify what the results are. Using Calc.exe on a 64 bit system gives a different result.


So here is the list of RC4 replacements.


Here is the AES replacements.


Well that it for this one.

There is allot more that could be said about this one but tracing the code can be difficult at times. I traced the AES function across 4 class files and multiples functions and variables.

Thank you for reading.

Posted in Malware, Networking, Programming, security | Tagged , | 1 Comment

A look at a cross bred Neutrino EK–Rig EK Flash file

A recent post by Jérôme Segura of Malwarebytes

Although this post showed the flash file being sent from the compromised site rather than a “Gate” is interesting. What is more interesting is what is inside of this flash file.

After decompiling the the second level of this flash file the fist thing I noticed was the file structure.


To me this folder structure and naming convention looked more like the Rig EK than Neutrino EK.

If we take a look inside this to find where the configuration file gets decoded we see this.


Interestingly enough if we look at the Rig EK sample from Broad Analysis here

As we can see here.


Besides the naming of the variables these two functions are the same, what they do after that is somewhat different though.

After beating my head against the wall for a couple of days trying to figure out these weird loops I finally broke down and  took a crash course how how to crash a flash debugger.

Ryan Chapman @rj_chap in his BSides presentation here was using FlashDevelop from Here  , so I decided to try and install it. After several try’s and Google I finally figured out how to get the the decompiled file to recompile with that program. After a few more hours of trying to figure out how to solve a problem of it throwing an error on readint() I finally gave up and abandoned that program. The break points didn’t break and a few other things about it makes me never want to try it again.

So I went back to the Free flash decompiler and figured out how to set it up to run as a debugger. That finally helped get me the last clues even though I was not able to step thru it like a normal debugger and see what all of the values were.

One thing this version did was, instead of using a normal RC4 Function like this.


They separated the functions inside to three different ones.


Our decode function from above will send the key in this part, build the SBox then it will be used in this section (below) for the final Xor.


It will then be returned to the original function and pushed as a string, basically to a list.

It will cycle like this several times, in this case 45 times.

A list of What? Well of replacements.


And where are these used ?


And if we compare that to the last one I pulled apart.


We can see here it is pretty much the same, but what are all of these values ?


As it turns out this gets Xor’ed with a value from the embed binary data that gets the bytes reversed and converted to integer.


So if we Xor these numbers then we end up with something like.(The comment Values)


Which as it turns out does match up to the index values shown above in the decoder.

So how does this decode function work ? Lets look and the binary files and let them tell us.


We skip the first 2 bytes, take the next 2 bytes and convert them to an Integer and that is how many times we will loop.

Next we skip 2 more bytes, take the next 2 bytes  and that is how many “Data Bytes’” we will take and add to the array of “Array Of Bytes” for later decryption.

Then skip 2 bytes again and repeat until you have looped thru the given amount of times.

In the Rig sample it was only 6 times.

I’m pretty sure I’ve seen this method used somewhere before.

Lets look at the Key file.


And the number of bytes to get is called from this function.


Well that pretty much covers the bulk of this one.

So the question remains Which EK will this get identified with? This sample has both.

Is this just a trial run or a new way they will be built.

As it turned out my shiny new decoder did not work on the Rig EK sample even though they used the same method to pull the bytes.

The difference is however the Neutrino EK was running those bytes thru a RC4 decoder and the Rig EK sample was running them thru a AES decrypter.

So I guess I’ll have to build a new decoder for that one. Bummer.

This one is kind of short compared to the others but before I go 1 more thing.

While trying to update a new test system.


Enough said.

Posted in Malware, security | Tagged | 2 Comments