Virtual Datapower First Configuration and Initialization!

Finally I got my hands on with DataPower Virtual Appliance. It was hard to tinker on real environments. Even using them as your lab environment is somehow bothersome. But having a virtual one is very good since one can do most of the software tinkering without having to worry.

I will show you how to get the thing up and running with admin gui, in fact it is so pretty easy; this whole post is like unnecessary.

Once it boots the first screen we saw is login screen. It is dummy at this point. Just type admin for login name and admin for password...

After that it asks if Disaster Recovery mode to be enabled, say yes,

Just right after it is going to ask a new password, not every password will be accepted. Type a secure one,

Then it is going to ask if wizard is to be used. 'Yes' is the answer,

First to be configured is Network. It is also true for the hardware variation. Until network to be configured, we use the serial telnet connection. It holds true for virtual one, in theory we are using the console port right now. No interface has ip yet, configure as needed. I use dhcp for all 4 interfaces, VM host side interfaces should be 'bridged' not NAT. Least until initial configuration part is done,

Step 1 (network is completed), now is time for the step 2 and 3. They are easy, give a DNS and unique identifier... Such as;

Step 4-5-6-7 are also easy, screenshot is below and pretty much self explanatory;

Now it is actually done but we cannot use DataPower yet. We need to accept the terms and license. This can only be done via the Web-GUI. it actually tells how to enable it, type it exactly...

 

web-mgmt
admin-state enabled
local-address 0 9090
exit

 

open up a browser of choice. Type the first interface's ip like http://x.x.x.x:9090 then accept the terms. If you do not know the ip that it took from dhcp type "show interface" without quotes.

 

In the console now you can write mem and save the config. That's it. You can use you DPXI52 virtual appliance as if it is a real one.

Hostname Change for WebSphere 7+

Hello, this post is also about WebSphere. As you may prolly know WebSphere family is a `hostname dependent`, uhmm let's say, architecture. If you want to migrate your server or even take a clone of the OS and sysprep it and start it, you are going to need some extra steps to start Websphere correctly. Even many cases without below steps you may not be able to start even Deployment Manager. Frankly the errors WebSphere generate are also no help at all, messy and confusing. So doing as below will save you a lot of trouble.

Let's assume you successfully migrated your server (or clone etc...), everything is in order and starting WebSphere is the next thing in place. Great! As you are aware since we cannot start DMGR and wsadmin.sh connects to DMGR upon initialized we are in a little bit trouble. We need to start wsadmin.sh without connecting, fortunately IBM thought a parameter to do so. In some cases this parameter is unnecessary, cause if it cannot connect to an active DMGR it simply goes offline mode, this is exactly what we need but most of the cases it will give and error and you are not going to be able to do anything with it. So let's be safe and use the parameter. Start the wsadmin.sh under the bin directory of DMGR profile like below;

./wsadmin.sh -conntype NONE -lang jython

After this we have 2 choices to change the hostname config of the DMGR. An interactive one and a automated silent one. Let's do the interactive one. You can easily automate the process if you write some python code. Type the below command to start interactive mode;

AdminTask.changeHostName ('[-interactive]')

*Node Name (nodeName):

type the nodeName of the DMGR node. Usually people use dmgr01 or something like that. Type it an press enter.

*Host Name (hostName):

Type the new hostname. This hostname should be pingable from the machine you are working on. So if there is a dns suffix or anything type it as it should be.

System Name (systemName):

Type the name of the cell that the DMGR manages.

Regenerate Certificates (regenDefaultCert):

Just press enter. This'll generate the cell and node certificates so the dmgr and nodes can talk to each other securely as before. It is at this point an unavoidable thing to do in fact. You can change them later if your company's internal security dictates or anything like that. Anyways press enter and let it renew them.

After that, it'll ask to finish or cancel it;

Select [F, C]: [F] F

Finish is the default answer. Just press enter or type F and press enter. It'll give the wsadmin command line back. We should save our new config;

AdminConfig.save()

After saving the config we can exit.

At this point our DMGR is in working order once again. But if we have any other node on this machine, we should change their hostnames too... Let's start wsadmin.sh the same way and start the interactive way and change the hostname for the other node. Below the commands and an example;

AdminTask.changeHostName ('[-interactive]')

*Node Name (nodeName): AppServerNode01
*Host Name (hostName): newhostnameoftheserver
System Name (systemName): wascell
Regenerate Certificates (regenDefaultCert):

Finish it and save the config just like we do for DMGR. Exit the wsadmin.sh for good and return to shell or command prompt.

We still have some work to do, as this is not enough; nodeAgent won't start if you try to do so. we need to manually sync the node, so node will know the new configuration and start correctly. Go to the profile's binary directory.

sh syncNode.sh DMGRHOST DMGRSOAPPORT

Type the username and the password if the console security is enabled. Let it sync itself. That's it, now the node agent should start normally and we are done.

PS: If you are doing all this when your original server is running, there is a probability that new dmgr connects to the old machine's working nodeagent. I know it is silly, just to be safe after all this just restart the dmgr and nodeagent one last time and you are done.

WebSphere Messaging Engine and Stuck Messages

Hi, in this post we are going to do some house keeping to WebSphere Messaging Engine. In some cases messages got stucked in committing or removing state (IBM calls them indoubt messages). When that happens, it is impossible to manage them via administration console.

Service Integration > Buses > xyzServiceBus > Messaging Engines > abcMEBus > Queue Points > queueA > Runtime > message > delete etc...

So we need to use wsadmin.sh and some commands. I always use the wsadmin.sh under the DMGR profile. So start the wsadmin.sh and connect to DMGR, type your username and password if your cell is secure. What we need first is to get the correct message id. Use below command;

$AdminControl invoke [$AdminControl queryNames type=SIBMessagingEngine,*] getPreparedTransactions

This will give us a very long string, expect something like

!V0FTRAAAACQAAAFC72342347HesQAAAAIAAj8tAnvvXi34ge4rh5tjhe4f43e3wov5krh54i-r62ZrKqTBuEAAAAAAA2AAABQu*x3rEAAAACAAI-LQJRGDRHDRGS7714qL*ZK432fw4r2eeIv6*tmayqkwbhAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAC

Did you get such an id? Good. Now we are going to use this id in another command.

$AdminControl invoke [$AdminControl queryNames type=SIBMessagingEngine,*] commitPreparedTransaction msgid

Do not use quoation or anything just paste the message id we got from previous command as a whole instead of where I wrote msgid in italic.

This will commit any stuck messages in any state, if this does not solve your problem we have another parameter for rolling back the message.

$AdminControl invoke [$AdminControl queryNames type=SIBMessagingEngine,*] rollbackPreparedTransaction msgid

This will rollback, but I usually don't need to use it, committing manually solves almost all stuck messages.

Have a nice debugging.

Pyrit and CUDA, How To?

Hello again for another quick guide, this time I am trying to light your path to Pyrit-CUDA on Kali Linux and an hybrid notebook. By hybrid I mean, 2 GPU; 1 Intel 1 NVidia.

It was originally my first experience with gp-gpu experience and it was ridiculously hard. I mean I really gave more time and effort than actually learn to crack some WPA in the first place. Whole drivers and SDKs, finding the right libraries, correct combinations, etc... was very tiresome; I tried and crashed Kali and re-install like so many times actually forgot the count.

Anyways the below is the way I got it working with my Fujitsu Lifebook LH532, essentially it is a Core i3 notebook with a GT 620m GPU.

First thing is first, like on many Debian start with;

apt-get update

Of course if anything goes wrong you know what to do. Get a better sources.list and kernel-headers.

Then this is the critical part. It will quite possibly crash your setting if it is not like mine. But what the cow, you prolly did crashed your system so many times already; at this point you are willing to try anything...

apt-get install nvidia-detect nvidia-libopencl1 nvidia-opencl-common nvidia-support nvidia-opencl-icd nvidia-visual-profiler nvidia-glx nvidia-installer-cleanup nvidia-kernel-common nvidia-smi nvidia-alternative nvidia-opencl-dev libglx-nvidia-alternatives nvidia-kernel-dkms nvidia-cuda-toolkit nvidia-vdpau-driver nvidia-xconfig glx-alternative-nvidia libgl1-nvidia-alternatives nvidia-settings libgl1-nvidia-glx xserver-xorg-video-nvidia libcublas4 libcudart4 libcufft4 libnpp4 libnvidia-compiler libcuda1 libcuinj4 libnvidia-ml1 libxvmcnvidia1 libcusparse4 libcurand4 python-pycuda-doc python-pycuda-headers python-pycuda nvidia-cuda-doc nvidia-cuda-gdb

I found above command as a whole on a japanese blog, and cannot find again to give credit. But thanks to dude who did in the first place. I remember he stated this line should work for Ubuntu on a hybrid notebook also.

Again sources.list is very important if you intend to complete above command successfully.

If everything is still working order, then do the magic below;

/root/.bashrc <<

PATH=$PATH:/usr/lib/nvidia-cuda-toolkit/bin
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/nvidia-cuda-toolkit/lib:/lib
export PATH
export LD_LIBRARY_PATH

After this we actually have CUDA on Kali, just restart the system and see if it is still booting up :) if not well re-install Kali, sorry.

----------------------------------------------------

Now time for actually settin up Pyrit-CUDA, don't worry tho; worse is behind and there is no danger crashing after this point.

We should download the official packages from the official site. which are pyrit-0.4.0.tar.gz and cpyrit-cuda-0.4.0.tar.gz that you need. Before you do anything just get below 2 library first.

atp-get install libpcap-dev python2.7-dev

Then for Pyrit do the following;

tar -xzvf pyrit-0.4.0.tar.gz
cd pyrit-0.4.0
python setup.py build
python setup.py install

Now you have Pyrit if everything went smoothly, but not yet Pyrit-CUDA. Here goes the magic again;

tar -xzvf cpyrit-cuda-0.4.0.tar.gz
cd cpyrit-cuda-0.4.0

setup.py <<

for path in ('/usr/local/cuda', '/opt/cuda'):
>> (must be like below or appropriate)
for path in ('/usr/local/cuda','/usr/lib/nvidia-cuda-toolkit','/opt/cuda'):

python setup.py build
python setup.py install

Tadaa (Windows 3.1 sound) !!! We have Pyrit with CUDA support. Enjoy the show;

note: you can see the device by "pyrit list_cores" and test via "pyrit benchmark".

HD 7770 (x2) X-Fire Setting For OpenCL + Pyrit

Not long ago, I bought 2 HD7770 for my rig. And then decided to give a try to the Pyrit. Everyone knows Pyrit right? Ok.

It's actually pretty easy to set Pyrit up for gpu. IN THEORY! I spent 4-5 hours for my setting to operate correctly this time around... Last time I was trying Pyrit-CUDA on a hybrid gpu notebook and it was a real pain. Like real pain.

Anyhow, I use Kali as my distro cause at least it is pre-patched for all my wifi dongles. I, at least, don't bother with the firmware patching and stuff.

So let's start with the AMD-ATI official drivers. Use this script to install them, the guy who wrote is brilliant and did a tremendous amount of work. So we don't have to get through that hell every time we need to install AMD-ATI drivers. Script simply works just run it and pour a cup of coffee and enjoy.

Then we need to install AMDAPP 2.7 because the script installs drivers version 8.96 something. these can be found on official AMD site. If you somehow manage the install the drivers without above script, you probably have another version. You should check the appropriate compatible version of APP SDK and then download that specific version accordingly. You can trust the instructions on the official page. They work, unlike the driver installation part of the official AMD site.

If all is well so far, then we need some more libraries that is not included with the standard setup of KALI Linux. Below the command to do that;
apt-get install opencl-icd-dev
apt-get install libpcap0.8-dev

You may need to update kernel headers and apt-get update. I assume you are familiar with those or already done it.

Now it is time for us to compile Pyrit. We should edit cpyrit/setup.py script accordingly to this blog. Read carefully and do exactly, we should be fine. Then we compile opencl-pyrit module. We should get no error if everything is good so far.

We should be done at this point just test it if Pyrit sees your AMD OpenCL supported device by 'listcores' parameter. We should see the whole device as one single core just like a CPU core. That's OK though. Pyrit will utilize all the cores available on that OpenCL device.

Congrats, you have now acquired more power to crack WPA passwords faster. If you still have problems or could not complete the guide above for some reason, please let me know so I may be able to help.

PS: Sorry I published this post before I finished it and never realized. This is the finished version.