Hello, I have a piece of software "CDRVBLiveClient.exe" that is used to pull call detail data off of a Nortel BCM 50. This is a sample VB application that came with the BCM 50 hardware. However, this hardware is long since out of service, as a result I cannot obtain the API documentation that would allow me to create my own application. This piece of software requires only three inputs - IP address (of the hardware), username, and password. Because a password is required I believe I can safely assume the protocol is encrypted. My problem is I need to figure out what type of encryption is being used along with the specifics of how data is transferred to and from the BCM 50. I am able to capture all the relevant packets using Wireshark; however, I am at a loss as to how to proceed with packet analysis for the goal of automating the collection of data without this program (as its functionality is extremely limited). If it would help to see the wireshark outputs please let me know and I can send the logs. Any help with the above would be greatly appreciated! Thank you, ~Daniel asked 17 Dec '12, 14:57  achilles showing 5 of 7 show 2 more comments |
3 Answers:
Maybe it's way cheaper to buy something than to develop your own application.
Regards answered 18 Dec '12, 00:52  Kurt Knochner ♦
well, the mentioned tool writes all data into a database and you could read that database and do whatever you want to do. You would eliminate the process of reverse engineering the (probably encrypted) communication protocol. I'm not sure if it is possible to automate that tool. You better contact the vendor and ask them.
Well, that's a problem, as the mentioned tools works only on Windows. However it's a .Net application and maybe it is possible to execute it under Mono for Linux (with low expectations for success ;-)) (18 Dec '12, 06:16) Kurt Knochner ♦
can you post a full capture file somewhere (your web/ftp server, one-click file hoster, cloudshark.org). Beware the privacy issues of doing so!! (18 Dec '12, 06:19) Kurt Knochner ♦
Maybe the vendor of the mentioned tool (http://www.bcmcalllogger.com/) can help. They should have access to the API and maybe they are willing to share knowledge or help in other ways. In a blog they were talking about access to the source code and a mono build for linux :-) http://www.reincubate.com/labs/bcm-call-logger-telephone-call-recording-and-reporting-tool/ (18 Dec '12, 06:45) Kurt Knochner ♦ Another solution might be some hidden features of the BCM.
Cite: Alternatively, on some older BCMs you can access the individual log files from a hidden web page. Read the page above for more information. (18 Dec '12, 06:50) Kurt Knochner ♦ Another alternative could be web scraping According to the BCM50 Troubleshooting guide, you can download the logs from the Admin webgui (page 84).
If that works manually, you can use your preferred web scraping tool to automate that process. (18 Dec '12, 07:00) Kurt Knochner ♦ There seems to be a BCM feature that's called "CDR Push", which allows to export the Call logs to an FTP server. That feature should be configurable through the BCN web gui. bcmcalllogger.com mentiones that feature in their user guide.
Details as described in the BCM Call Detail Recording System Administration Guide
Apparently the downloaded call records are compresses (ZIP). Maybe that's the reason why you could not find anything 'readable' in the capture file. (18 Dec '12, 07:11) Kurt Knochner ♦ showing 5 of 6 show 1 more comments |
Uh, no you can't - there are tons of protocols that carry usernames and passwords that aren't encrypted, for example standard FTP. About your problem - enter a password and try to see if you can find it in the protocol data in clear text. If your hardware is old, chances are high that you can find it. And regarding on how to proceed - if you want to collect data from the device you'll have to write a new program that mimicks the communication that the sample program does. Basically you'll have to reverse engineer the protocol to write another application that can "speak" the same language with the device. answered 17 Dec '12, 16:00  Jasper ♦♦ edited 18 Dec '12, 08:08 |
Reverse Engineering can be difficult. I found the following web page at Avaya which sounds relevant. It talks about "Developer Toolkits" for the BCM50 (among other systems). Business Communications Manager, Call Detail Recording APIs A related page says
It looks like anyone can register and then have access to the various downloads... (Have you already pursued this route ?). answered 17 Dec '12, 18:38  Bill Meier ♦♦ edited 17 Dec '12, 18:42 |
Jasper: I should have mentioned that I have already looked at the packet outputs that WireShark provides and none of the information is in plain text - I.E. none of the information outputted by the sample application turns up as human readable in the packets nor does the username or password.
Bill: I have gone down the route of trying to download the CDR API's directly from Avaya (which bought out Nortel), but after going through the process of creating a devConnect account it turned out that all those links for the CDR API's no longer function (they bring back a 500 error). I am willing to pay for a solution and have even contacted Avaya directly with regards to their broken links, but I can't seam to get anyone to help me because I am not one of their certified distributors (an expensive proposition).
Kurt: Perhaps it would be cheaper and a lot faster to purchase an already developed application, but I have a few specific requirements that seam to go beyond all the commercial applications I have found. Most notably the application would ideally have to work on Linux (every program I have found is exclusively windows based) and I would need to be able to interface with it via PHP.
I should also mention that I am very experienced in coding a wide variety of applications, so once I know the specifics of the protocol I will have no trouble whatsoever replicating the functionality of the sample application. I simply have never ventured into the area of reverse engineering an unknown protocol and am looking for any help I can get to speed up this process. I appreciate all your responses; however, any help in actually reverse engineering the protocol or even some direction to proceed in would be greatly appreciated.
Thanks, ~Daniel
I have uploaded the full capture to http://www.cloudshark.org/captures/baea58084a83
I should also mention that this data would be used in real time, which is the beauty of the sample application as the data is pushed from the BCM 50 to the application immediately instead of being pulled on a specific schedule. So using programs that act as an intermediary between my application and the BCM poses a potential problem in that I would not know when new data is available, I would have to constantly check the database or whatnot.
please read the numerous comments I added ;-))
Yep, data looks encrypted (or at least scrambled). Reverse engineering that is almost impossible without any hint about the encryption method used. You could try to run the client application in a debugger and/or a disassembler to get at least some ideas.
BTW: can you post a different capture? Just to see if there are 'constant parts' in the communication?
I must thank you for all your help Kurt, you have gone above and beyond :)
I am in the midst of contacting a few different CDR providers including BCMcalllogger.com and hopefully one of these will be able to provide me with the needed documentation. Also, I am aware of the push to FTP ability of the BCM as well as the logs, and may end up pursuing this route; however, it is not the most ideal as data would be pushed on a schedule, not immediately as a call comes in.
At the same time, if anyone has anything to add on reverse engineering the protocol given the WireShark packets I have uploaded, please speak up :)
New capture log: http://www.cloudshark.org/captures/623309050159
Your're welcome.
well, there is identical payload in the two capture files. However: reverse engineering an unknown protocol, just by looking at capture files is almost impossible. You need a real device and then test how the device reacts upon data you send it. And that's a though and tedious job. You'd better off with pursuing a simpler route to the solution of your problem, by asking people for help that have access to the required information ;-)
Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.