First and foremost I'd like to take a moment to thank someone who has helped me with this project and so many others. Not 
often do you find people in this industry who are willing to completely and untiringly help and share information with another
person. I was fortunate enough to find someone who has taught me more than I could probably teach myself in years. He has shown
me how important sharing information is and this is one of the reasons I've released this information. galt heh you've helped
me more than I can describe and I thank you once again. General shoutouts to all in #innercircle. Now, lets get started...

After writing up a document on hacking citrix and in the end securing citrix. I have been given plenty of responses on how one
would go about securing this application. One flaw that I found was easily defeated by setting Citrix to only allow published
applications to run. Supposedly a fix brought to my attention by Brian Madden was to fix the published application scanner from
working. After testing whether or not this worked, I found it to *not* prevent the scanner written by Ian Vitek of ixsecurity. 
Since I made this discovery *after* I wrote this code/paper I guess it is pretty pointless... But regardless here is another
way one can find a list of published applications.

The other way to defeat this 'fix' I began looking how Citrix descerns from a valid application. The answer came rather quickly 
when sniffing the network responses from my test machine. Here is the communication on port 1604 UDP when someone is attempting 
to connect to a valid application on a citrix server. Regardless whether or not 'Only allow Published Application's' is in use, 
this flaw is encountered. As long as you can access the Citrix Server on port 1604 UDP this will work.  If you have no idea what 
I am talking about, please see my paper at http;//sh0dan.org/files/hackingcitrix.txt

Packet 1: Valid Connection 
Client ->
                              1e 00 01 30 02 fd
a8 e3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

The first packet sent is a 'hello are you out there' type packet. This will invoke a response from the citrix server.
This packet payload *never* changes and you will always see this first.

Packet 2: Valid Connection 
<- Server
                              30 00 02 31 02 fd
a8 e3 02 00 06 44 c0 a8 00 f7 00 00 00 00 00 00
00 00 00 00 00 00 00 00 06 44 c0 a8 00 f7 00 00
00 00 00 00 00 00 00 00 00 00

This packet is the response from the server, it is also static and will never change. 

Packet 3: Valid Connection 
Client ->
                              42 00 02 34 02 fd
a8 e3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 26 00 02 00 35 00 00 00 00 00
41 43 52 4f 42 41 54 20 52 45 41 44 45 52 00 01   [42-52 = ACROBAT READER]
00 04 00 41 54 54 41 43 4b 45 52 00

This packet is a bit more interesting. The first byte in the payload is 0x34H + the length of the application name + the
length of NetBIOS/Hostname. After doing some small testing, I've only had this work when my hostname was 8 bytes long. 
At this current point in time I'm unsure why this is, but I'm sure someone will know the answer to this. In my code, I 
have left the #define NBNAME so that you can change it to what you want, as long as its eight characters! Sorry I wish I
had more time to investigate this issue. The next 33 bytes also *never* change. The 34th byte is 0x27H + the length of the 
application name again and + the nbname/hostname. I have not fully investigated why it is required twice but it may be just 
for error checking. The two length identifiers seem to always be the same. The 43rd byte is where the application name in 
ASCII is placed. The following 5 bytes after the application name is also static.  The last 8 bytes are either the hostname 
or the NetBIOS name of the machine attempting to connect. 


Packet 4: Valid Connection 
<- Server
                              3e 00 02 35 02 fd
a8 e3 02 00 06 44 c0 a8 00 f7 00 00 00 00 00 00
00 00 00 00 00 00 02 00 18 00 26 00 00 00 00 00
01 00 ff ff 02 00 06 44 c0 a8 00 f7 00 00 00 00
00 00 00 00 00 00 00 00

The final packet is the acceptance of the published application. This packet is also *always* the same. You can begin
to see now how my program works in determining whether or not a published application is valid. If you do not, take a
look at the next packet dump from an INVALID application request.

Packet 4: Bad Application Request.
<- Server
                              20 00 01 3a 02 fd
a8 e3 02 00 06 44 c0 a8 00 f7 00 00 00 00 00 00
00 00 00 00 00 00 0e 00 00 00

Hmm... quite different no? Well this also never changes... It is always the same length with the same content. All we
have to do is calculate whether or not packet 4 payload is 32 bytes (INVALID) or 62 bytes (VALID) and we have our answer 
whether or not our application is invalid. To make things even easier, our applications are *always* in upper case. So 
all we need to scan for is a application name in uppercase and not have to worry whether or not RaNdoM pArTS of the 
application name is capitalized.

I've also included some 'common' published applications. Feel free to add your own. My code only works because of galt helping
my un-coding self. It works it maybe dirty but it works. See the usage for the flags. It doesn't require capitals but
my previous version did so don't be afraid to add non-uppercased characters.
Enjoy.

-wire