Riding the Crazy Train: May 2020

Friday, May 22, 2020

New Printers Vulnerable To Old Languages

When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:

Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
Launch denial of Service attacks of various kinds:
- PostScript based infinite loops
- PostScript showpage redefinition
- Disable jobmedia with proprietary PJL
- Set the device to offline mode with PJL

Now exploitable from the web

All attacks can be carried out by anyone who can print, which includes:

Web attacker:
- A malicious website that uses XSP
Network access:
- Via Jetdirect (port 9100/tcp)
- Via LPD (port 515/tcp)
- Via IPP (port 631/tcp)
Wireless access:
- Apple Air Print (enabled by default)
Cloud access:
- Google Cloud Print (disabled by default)
Physical access:
- Printing via USB cable or USB drive
- Potentially NFC printing (haven't tested)

Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP's Software Security Response Team (SSRT) in February.

Conclusion: Christian Slater is right

PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer's parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, "The Wolf" like scenarios can get very real in your office…

Continue reading

Bypass Hardware Firewalls

This is just a collection of links about my DEF CON 22 presentation, and the two tools I released:

Slides:
http://www.slideshare.net/bz98/defcon-22-bypass-firewalls-application-white-lists-secure-remote-desktops-in-20-seconds

Tools:
https://github.com/MRGEffitas/Write-into-screen
https://github.com/MRGEffitas/hwfwbypass

Presentation video from Hacktivity:
https://www.youtube.com/watch?v=KPJBckmhtZ8

Technical blog post:
https://blog.mrg-effitas.com/bypass-hardware-firewalls-def-con-22/

Have fun!

More information

Thursday, May 21, 2020

Ufonet - Dos And Ddos Attack Tool | How To Install Bot

More info

Facebook Plans To Launch Its Own Cryptocurrency

The social network giant, Facebook is going through a bad phase with lots of ups and down. The recent scandal with Cambridge Analytica has caused the world's largest social network giant Facebook to change its stance on user privacy and to be more transparent about its use of the data it collects.

Since then, some social networks based in Blockchain have been popularized, namely Sphere, Steemit, and Howdoo. However, recently, something unusual announcement is announced by the social network giant Facebook itself, in which Facebook stated that it is investing in a Blockchain-based solution development team, but, the purpose of the project is not yet known.

It was with a post on the Facebook page that David Marcus confirmed his departure from the Messenger team and the creation of a small group dedicated to finding solutions based on the potential of Blockchain technology for Facebook.

David Marcus has not given much detail on the work he will do with his new group, saying only that they will study Blockchain from scratch so that they can use this revolutionary technology for Facebook.

"I'm setting up a small group to explore how to leverage Blockchain across Facebook, starting from scratch," stated David Marcus.

Despite being connected to Facebook's Messenger since 2014, David Marcus is no novice in these financial issues related to money transfers. In addition to having introduced the possibility of P2P payments in Messenger itself, David Marcus was President of PayPal and CEO of Zong, a company dedicated to payments on mobile devices.

However, his experience in this segment does not allow us to conclude that Facebook will create or support a crypto coin, but, it also doesn't mean that it will launch or support any crypto coin of its own. Blockchain technology has become famous thanks to crypto-coins, especially Bitcoin, but its potential expands dramatically to other areas.

The potential of Blockchain goes from the crypto-coins to the creation of real ecosystems online, supported by the users of the network. Sharing and storing data is a legacy that Blockchain allows you to explore and maybe the fact that Facebook will use it in your favor.

The lead post in Messenger was then handed over to Stan Chudnovsky, who now heads one of the most widely used communication services around the world, alongside WhatsApp.

Rumors also point out that James Everingham and Kevin Weil, both from Instagram, will also join David Marcus in this new onslaught of Facebook to one of today's most acclaimed technologies.

More information

Wednesday, May 20, 2020

Linux Command Line Hackery Series - Part 3

Welcome back, hope you are enjoying this series, I don't know about you but I'm enjoying it a lot. This is part 3 of the series and in this article we're going to learn some new commands. Let's get started

Command: w
Syntax: w
Function: This simple function is used to see who is currently logged in and what they are doing, that is, their processes.

Command: whoami
Syntax:   whoami
Function: This is another simple command which is used to print the user name associated with the current effective user ID.

Try it and it will show up your user name.

If you want to know information about a particular user no matter whether it is you or someone else there is a command for doing that as well.

Command: finger
Syntax: finger [option] [username]
Function: finger is a user information lookup program. The [] around the arguments means that these arguments are optional this convention is used everywhere in this whole series.

In order to find information about your current user you can simply type:

finger username

Here username is your current username.
To find information about root you can type:

finger root

and it will display info about root user.

Command: uname
Syntax: uname [options]
Function:   uname is used to display information about the system.

uname is mostly used with the flag -a, which means display all information like this:

uname -a

Command: df
Syntax: df [option] [FILE ...]
Function:   df is used to display the amount of space available.
If you type df in your terminal and then hit enter you'll see the used and available space of every drive currently mounted on the system. However the information is displayed in block-size, which is not so much human friendly. But don't worry we can have a human friendly output as well using df by typing:

df -h

the -h flag is used to display the used and available space in a more user friendly format.
We can also view the info of a single drive by specifying the drive name after df like this:

df -h /dev/sda2

That's it for now about df, let's move on.

Command: free
Syntax:   free [options]
Function: free is used to display the amount of free and used physical memory and swap memory in the system.
Again the displayed information is in block-size to get a more human readable format use the -h flag like this:

free -h

Command: cal
Syntax: cal [options]
Function: cal stands for calendar. It is used to display the calendar.

If you want to display current date on the calendar you can simply type:

cal

and wohooo! you get a nice looking calendar on screen with current date marked but what if you want to display calendar of a previous month well you can do that as well. Say you want to display calendar of Jan 2010, then you'll have to type:

cal -d 2010-01

Nice little handy tool, isn't it?

Command: file
Syntax: file filename ...
Function:   file is an awesome tool, it's used to classify a file. It is used to determine the file type.

Let's demonstrate the usage of this command by solving a Noob's CTF challenge using file and base64 commands. We'll talk about base64 command in a bit. Go to InfoSecInstitute CTF Website. What you need to do here is to save the broken image file on your local computer in your home directory. After saving the file open your terminal (if it isn't already). Move to your home directory and then check what type of file it is using the file command:

cd
file image.jpg

Shocking output? The file command has identified the above file as an ASCII text file which means the above file is not an image file rather it is a text file now it's time to see it's contents so we'll type:

cat image.jpg

What is that? It's some kind of gibberish. Well it's base64 encoded text. We need to decode it. Let's learn how to do that.

Command: base64
Syntax:   base64 [option] FILE ...
Function: base64 command is used to encode/decode data and then print it to stdout.

If we're to encode some text in base64 format we'd simply type base64 hit enter and then start typing the text in the terminal after you're done hit enter again and then press CTRL+D like this:

base64
some text here
<CTRL+D>
c29tZSB0ZXh0IGhlcmUK # output - the encoded string

But in the above CTF we've got base64 encoded data we need to decode it, how are we going to do that? It's simple:

base64 -d image.jpg

There you go you've captured the flag.
The -d flag here specifies that we want to decode instead of encode and after it is the name of file we want to decode.

Voila!
So now you're officially a Hacker! Sorry no certificates available here :)

That's it for this article meet ya soon in the upcoming article.

Related word

CSRF Referer Header Strip

Intro

Most of the web applications I see are kinda binary when it comes to CSRF protection; either they have one implemented using CSRF tokens (and more-or-less covering the different functions of the web application) or there is no protection at all. Usually, it is the latter case. However, from time to time I see application checking the Referer HTTP header.

A couple months ago I had to deal with an application that was checking the Referer as a CSRF prevention mechanism, but when this header was stripped from the request, the CSRF PoC worked. BTW it is common practice to accept empty Referer, mainly to avoid breaking functionality.

The OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet tells us that this defense approach is a baaad omen, but finding a universal and simple solution on the Internetz to strip the Referer header took somewhat more time than I expected, so I decided that the stuff that I found might be useful for others too.

Solutions for Referer header strip

Most of the techniques I have found were way too complicated for my taste. For example, when I start reading a blog post from Egor Homakov to find a solution to a problem, I know that I am going to:

learn something very cool;
have a serious headache from all the new info at the end.

This blog post from him is a bit lighter and covers some useful theoretical background, so make sure you read that first before you continue reading this post. He shows a few nice tricks to strip the Referer, but I was wondering; maybe there is an easier way?

Rich Lundeen (aka WebstersProdigy) made an excellent blog post on stripping the Referer header (again, make sure you read that one first before you continue). The HTTPS to HTTP trick is probably the most well-known one, general and easy enough, but it quickly fails the moment you have an application that only runs over HTTPS (this was my case).

The data method is not browser independent but the about:blank trick works well for some simple requests. Unfortunately, in my case the request I had to attack with CSRF was too complex and I wanted to use XMLHttpRequest. He mentions that in theory, there is anonymous flag for CORS, but he could not get it work. I also tried it, but... it did not work for me either.

Krzysztof Kotowicz also wrote a blog post on Referer strip, coming to similar conclusions as Rich Lundeen, mostly using the data method.

Finally, I bumped into Johannes Ullrich's ISC diary on Referer header and that led to me W3C's Referrer Policy. So just to make a dumb little PoC and show that relying on Referer is a not a good idea, you can simply use the "referrer" meta tag (yes, that is two "r"-s there).

The PoC would look something like this:

<html>
  <meta name="referrer" content="never">
  <body>
    <form action="https://vistimsite.com/function" method="POST">
      <input type="hidden" name="param1" value="1" />
      <input type="hidden" name="param2" value="2" />
      ...
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

Conclusion

As you can see, there is quite a lot of ways to strip the Referer HTTP header from the request, so it really should not be considered a good defense against CSRF. My preferred way to make is PoC is with the meta tag, but hey, if you got any better solution for this, use the comment field down there and let me know! :)

Tuesday, May 19, 2020

C++ Std::Condition_Variable Null Pointer Derreference

This story is about a bug generated by g++ and clang compilers (at least)
The condition_variables is a feature on the standard library of c++ (libstdc++), when its compiled statically a weird asm code is generated.

Any example on the link below will crash if its compiled statically:
https://en.cppreference.com/w/cpp/thread/condition_variable

In this case the condition_variable.wait() crashed, but this happens with other methods, a simple way to trigger it:

If this program is compiled dynamically the crash doesn't occur:

Looking the dissasembly there is a surprise created by the compiler:

Compilers:
g++ 9.2.1+20200130-2
clang++ v9

Both compilers are generating the "call 0x00"

If we check this call in a dynamic compiled:

The implementation of condition_variable in github:
https://github.com/gcc-mirror/gcc/blob/b7c9bd36eaacac42631b882dc67a6f0db94de21c/libstdc%2B%2B-v3/include/std/condition_variable

The compilers can't copile well this code in static, and same happens on other condition_variable methods.
I would say the _lock is being assembled improperly in static, is not exacly a null pointer derreference but the effects are the same, executing code at address 0x00 which on linux is a crash on most of cases.

Read more

OVER $60 MILLION WORTH OF BITCOINS HACKED FROM NICEHASH EXCHANGE

Over $60 Million Worth of Bitcoins Hacked from NiceHash Exchange. Bitcoin mining platform and exchange NiceHash has been hacked, leaving investors short of close to $68 million in BTC.

As the price of Bitcoin continues to rocket, surging past the $14,500 mark at the time of writing, cyberattackers have once again begun hunting for a fresh target to cash in on in this lucrative industry.

Banks and financial institutions have long cautioned that the volatility of Bitcoin and other cryptocurrency makes it a risky investment, but for successful attackers, the industry potentially provides a quick method to get rich — much to the frustration of investors.

Unfortunately, it seems that one such criminal has gone down this path, compromising NiceHash servers and clearing the company out.

In a press release posted on Reddit, on Wednesday, NiceHash said that all operations will stop for the next 24 hours after their "payment system was compromised and the contents of the NiceHash Bitcoin wallet have been stolen."

NiceHash said it was working to "verify" the precise amount of BTC stolen, but according to a wallet which allegedly belongs to the attacker — traceable through the blockchain — 4,736.42 BTC was stolen, which at current pricing equates to $67,867,781.

"Clearly, this is a matter of deep concern and we are working hard to rectify the matter in the coming days," NiceHash says. "In addition to undertaking our own investigation, the incident has been reported to the relevant authorities and law enforcement and we are co-operating with them as a matter of urgency."

"We are fully committed to restoring the NiceHash service with the highest security measures at the earliest opportunity," the trading platform added.

The company has also asked users to change their online passwords as a precaution. NiceHash says the "full scope" of the incident is unknown.

"We are truly sorry for any inconvenience that this may have caused and are committing every resource towards solving this issue as soon as possible," the company added.

Inconvenience is an understatement — especially as so much was left in a single wallet — but the moment those coins shift, we may know more about the fate of the stolen investor funds.

More info

Monday, May 18, 2020

Webkiller Tool | Information Gathering | Github

Continue reading

Secret Hack Codes For Android Mobile Phones

Secrete Hack codes for Android Mobile phones

Secret hack codes are usually hidden from users to prevent misuse and exploit. Android is a very new platform so there aren't many hack codes for Androids available. Today I will share all of the hack codes of Android cellphones that I know. I have tested these codes on my Samsung Galaxy with the Android OS version 2.2. I am sure these will work on all previous versions.

Secret Hack Codes for Android Mobile Phones:

1. Complete Information About Your Phone

*#*#4636#*#*

This code can be used to get some interesting information about your phone and battery. It shows the following 4 menus on the screen:

Phone information
Battery information (How to maximize or boost battery life in android phones)
Battery history
Usage statistics

2. Factory data reset

*#*#7780#*#*

This code can be used for a factory data reset. It'll remove the following things:

Google account settings stored in your phone
System and application data and settings
Downloaded applications

It will NOT remove:

Current system software and bundled application
SD card files e.g. photos, music files, etc.

Note: Once you give this code, you will get a prompt screen asking you to click on the "Reset phone" button, giving you the chance to cancel your operation.

3. Format Android Phone

*2767*3855#

Think before you input this code. This code is used for factory formatting. It will remove all files and settings, including the internal memory storage. It will also reinstall the phone firmware.

Note: Once you give this code, there is no way to cancel the operation unless you remove the battery from the phone.

4. Phone Camera Update

*#*#34971539#*#*

This code is used to get information about phone camera. It shows following 4 menus:

Update camera firmware in image (Don't try this option)
Update camera firmware in SD card
Get camera firmware version
Get firmware update count

WARNING: NEVER use the first option. Your phone camera will stop working and you will need to take your phone to a service center to reinstall camera firmware.

5. End Call/Power

*#*#7594#*#*

This one is my favorite. This code can be used to change the action of the "End Call/Power" button. Be default, if you hold the button down for a long time, it shows a screen asking you to select between silent mode, airplane mode, and power off.

Using this code, you can enable this button to power off without having to select an option, saving you some time.

6. File Copy for Creating Backup

*#*#273283*255*663282*#*#*

This code opens a file copy screen where you can backup your media files e.g. images, sound, video and voice memo.

7. Service Mode

*#*#197328640#*#*

This code can be used to enter into service mode. In service mode, you can run various tests and change settings.

8. WLAN, GPS and Bluetooth Secret Hack Codes for Android:

*#*#232339#*#* OR *#*#526#*#* OR *#*#528#*#* – WLAN test (Use "Menu" button to start various tests)

*#*#232338#*#* – Shows WiFi MAC address

*#*#1472365#*#* – GPS test

*#*#1575#*#* – Another GPS test

*#*#232331#*#* – Bluetooth test

*#*#232337#*# – Shows Bluetooth device address

9. Codes to get Firmware version information:

*#*#4986*2650468#*#* – PDA, Phone, H/W, RFCallDate

*#*#1234#*#* – PDA and Phone

*#*#1111#*#* – FTA SW Version

*#*#2222#*#* – FTA HW Version

*#*#44336#*#* – PDA, Phone, CSC, Build Time, Changelist number

10. Codes to launch various Factory Tests:

*#*#0283#*#* – Packet Loopback

*#*#0*#*#* – LCD test

*#*#0673#*#* OR *#*#0289#*#* – Melody test

*#*#0842#*#* – Device test (Vibration test and BackLight test)

*#*#2663#*#* – Touch screen version

*#*#2664#*#* – Touch screen test

*#*#0588#*#* – Proximity sensor test

*#*#3264#*#* – RAM version

@EVERYTHING NT

Related news

Open Sesame (Dlink - CVE-2012-4046)

A couple weeks ago a vulnerability was posted for the dlink DCS-9xx series of cameras. The author of the disclosure found that the setup application that comes with the camera is able to send a specifically crafted request to a camera on the same network and receive its password in plaintext. I figured this was a good chance to do some analysis and figure out exactly how the application carried out this functionality and possibly create a script to pull the password out of a camera.

The basic functionality of the application is as follows:

Application sends out a UDP broadcast on port 5978
Camera sees the broadcast on port 5978 and inspects the payload – if it sees that the initial part of the payload contains "FF FF FF FF FF FF" it responds (UDP broadcast port 5978) with an encoded payload with its own MAC address
Application retrieves the camera's response and creates another UDP broadcast but this time it sets the payload to contain the target camera's MAC address, this encoded value contains the command to send over the password
Camera sees the broadcast on port 5978 and checks that it is meant for it by inspecting the MAC address that has been specified in the payload, it responds with an encoded payload that contains its password (base64 encoded)

After spending some time with the application in a debugger I found what looked like it was responsible for the decoding of the encoded values that are passed:

super exciting screen shot.

After spending some time documenting the functionality I came up with the following notes (messy wall of text):


	Command	Comments
	.JGE SHORT 0A729D36	; stage1
	./MOV EDX,DWORD PTR SS:[LOCAL.2]	; set EDX to our 1st stage half decoded buffer
	.\|MOV ECX,DWORD PTR SS:[LOCAL.4]	; set ECX to our current count/offset
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our base64 encoded payload
	.\|MOVSX EAX,BYTE PTR DS:[EAX]	; set EAX to the current value in our base64 payload
	.\|MOV AL,BYTE PTR DS:[EAX+0A841934]	; set EAX/AL to a hardcoded offset of its value table is at 0a841934
	.\|MOV BYTE PTR DS:[ECX+EDX],AL	; ECX = Offset, EDX = start of our half-decoded buffer, write our current byte there
	.\|INC DWORD PTR SS:[LOCAL.4]	; increment our offset/count
	.\|INC DWORD PTR SS:[LOCAL.3]	; increment our base64 buffer to next value
	.\|MOV EDX,DWORD PTR SS:[LOCAL.4]	; set EDX to our counter
	.\|CMP EDX,DWORD PTR SS:[ARG.2]	; compare EDX (counter) to our total size
	.\JL SHORT 0A729D13	; jump back if we have not finished half decoding our input value
	.MOV ECX,DWORD PTR SS:[ARG.3]	; Looks like this will point at our decoded buffer
	.MOV DWORD PTR SS:[LOCAL.5],ECX	; set Arg5 to our decoded destination
	.MOV EAX,DWORD PTR SS:[LOCAL.2]	; set EAX to our half-decoded buffer
	.MOV DWORD PTR SS:[LOCAL.3],EAX	; set arg3 to point at our half-decoded buffer
	.MOV EDX,DWORD PTR SS:[ARG.4]	; ???? 1500 decimal
	.XOR ECX,ECX	; clear ECX
	.MOV DWORD PTR DS:[EDX],ECX	; clear out arg4 value
	.XOR EAX,EAX	; clear out EAX
	.MOV DWORD PTR SS:[LOCAL.6],EAX	; clear out local.6
	.JMP SHORT 0A729DAE	; JUMP

	./MOV EDX,DWORD PTR SS:[LOCAL.3]	; move our current half-decoded dword position into EDX
	.\|MOV CL,BYTE PTR DS:[EDX]	; move our current byte into ECX (CL) (dword[0])
	.\|SHL ECX,2	; shift left 2 dword[0]
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; move our current dword position into EAX
	.\|MOVSX EDX,BYTE PTR DS:[EAX+1]	; move our current dword position + 1 (dword[1]) into EDX
	.\|SAR EDX,4	; shift right 4 dword[1]
	.\|ADD CL,DL	; add (shift left 2 dword[0]) + (shift right 4 dword[1])
	.\|MOV EAX,DWORD PTR SS:[LOCAL.5]	; set EAX to our current decoded buffer position
	.\|MOV BYTE PTR DS:[EAX],CL	; write our decoded (dword[0]) value to or decoded buffer
	.\|INC DWORD PTR SS:[LOCAL.5]	; increment our position in the decoded buffer
	.\|MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our current dword position
	.\|MOV CL,BYTE PTR DS:[EDX+1]	; set ECX to dword[1]
	.\|SHL ECX,4	; left shift 4 dword[1]
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our current dword position
	.\|MOVSX EDX,BYTE PTR DS:[EAX+2]	; set EDX to dword[2]
	.\|SAR EDX,2	; shift right 2 dword[2]
	.\|ADD CL,DL	; add (left shift 4 dword[1]) + (right shift 2 dword[2])
	.\|MOV EAX,DWORD PTR SS:[LOCAL.5]	; set EAX to our next spot in the decoded buffer
	.\|MOV BYTE PTR DS:[EAX],CL	; write our decoded value into our decoded buffer
	.\|INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.\|MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our current half-decoded dword
	.\|MOV CL,BYTE PTR DS:[EDX+2]	; set ECX dword[2]
	.\|SHL ECX,6	; shift left 6 dword[2]
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our current half-decoded dword
	.\|ADD CL,BYTE PTR DS:[EAX+3]	; add dword[2] + dword[3]
	.\|MOV EDX,DWORD PTR SS:[LOCAL.5]	; set EDX to point at our next spot in our decoded buffer
	.\|MOV BYTE PTR DS:[EDX],CL	; write our decoded byte to our decoded buffer
	.\|INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.\|ADD DWORD PTR SS:[LOCAL.3],4	; increment our encoded buffer to point at our next dword
	.\|MOV ECX,DWORD PTR SS:[ARG.4]	; set ECX to our current offset?
	.\|ADD DWORD PTR DS:[ECX],3	; add 3 to our current offset?
	.\|ADD DWORD PTR SS:[LOCAL.6],4	; add 4 to our byte counter??
	.\|MOV EAX,DWORD PTR SS:[ARG.2]	; move total size into EAX
	.\|ADD EAX,-4	; subtract 4 from total size
	.\|CMP EAX,DWORD PTR SS:[LOCAL.6]	; compare our total bytes to read bytes
	.\JG SHORT 0A729D50	; jump back if we are not done

	.MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our last DWORD of encoded buffer
	.MOVSX ECX,BYTE PTR DS:[EDX+3]	; set ECX to dword[3] last byte of our half-decoded dword (dword + 3)
	.INC ECX	; increment the value of dword[3]
	.JE SHORT 0A729E1E
	.MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our current half-decoded dword
	.MOV DL,BYTE PTR DS:[EAX]	; set EDX (DL) to dword[0]
	.SHL EDX,2	; shift left 2 dword[0]
	.MOV ECX,DWORD PTR SS:[LOCAL.3]	; set ECX to our current encoded dword position
	.MOVSX EAX,BYTE PTR DS:[ECX+1]	; set EAX to dword[1]
	.SAR EAX,4	; shift right 4 dword[1]
	.ADD DL,AL	; add (shifted left 2 dword[0]) + (shifted right 4 dword[1])
	.MOV ECX,DWORD PTR SS:[LOCAL.5]	; set ECX to point at our next spot in our decoded buffer
	.MOV BYTE PTR DS:[ECX],DL	; write our decoded value (EDX/DL) to our decoded buffer
	.INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to point at our dword
	.MOV AL,BYTE PTR DS:[EDX+1]	; set EAX/AL to dword[1]
	.SHL EAX,4	; shift left 4 dword[1]
	.MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our current dword
	.MOVSX ECX,BYTE PTR DS:[EDX+2]	; set ECX to dword[2]
	.SAR ECX,2	; shift right 2 dword[2]
	.ADD AL,CL	; add (shifted left 4 dword[1]) + (shifted right 2 dword[2])
	.MOV EDX,DWORD PTR SS:[LOCAL.5]	; set EDX to point at our current spot in our decoded buffer
	.MOV BYTE PTR DS:[EDX],AL	; write our decoded value to the decoded buffer
	.INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to point at our current dword
	.MOV CL,BYTE PTR DS:[EAX+2]	; set ECX/CL to dword[2]
	.SHL ECX,6	; shift left 6 dword[2]
	.MOV EAX,DWORD PTR SS:[LOCAL.3]	; point EAX at our current dword
	.ADD CL,BYTE PTR DS:[EAX+3]	; add dword[3] + (shifted left 6 dword[2])
	.MOV EDX,DWORD PTR SS:[LOCAL.5]	; point EDX at our current decoded buffer
	.MOV BYTE PTR DS:[EDX],CL	; write our decoded value to the decoded buffer
	.INC DWORD PTR SS:[LOCAL.5]	; increment our deocded buffer
	.MOV ECX,DWORD PTR SS:[ARG.4]	; set ECX to our current offset?
	.ADD DWORD PTR DS:[ECX],3	; add 4 for our current byte counter?
	.JMP 0A729EA6	; jump

Translated into english: the application first uses a lookup table to translate every byte in the input string, to do this it uses the value of the current byte as an offset into the table. After it is done with "stage1" it traverses the translated input buffer a dword at a time and does some bit shifting and addition to fully decode the value. The following roughly shows the "stage2" routine:

(Dword[0] << 2) + (Dword[1] >> 4) = unencoded byte 1

(Dword[1] << 4) + (Dword[2] >> 2) = unencoded byte 2

(Dword[2] << 6) + Dword[3] = unencoded byte 3

I then confirmed that this routine worked on an "encoded" value that went over the wire from the application to the camera. After confirming the encoding scheme worked, I recreated the network transaction the application does with the camera to create a stand alone script that will retrieve the password from a camera that is on the same lan as the "attacker". The script can be found here, thanks to Jason Doyle for the original finding (@jasond0yle ).