Jump to content

Lost password and brute force


Sunnysky86
 Share

Recommended Posts

Hi,

i'm a newbye and i have this problem: at work i have a device configured with a password, i wrote it the first time i put in but now it didn't work anymore! Maybe my coworker changed it but nobody seems to know the new one. I have looked online and there isn't any reset button or procedure for it. The device is connected to windows seven with a serial port. Is there any chance to do a dictionary-brute force over a serial connection? I need to regain access to this device :sad: Please if you can help me...

Link to comment
Share on other sites

Technically yes but without knowing a lot more we can't help. Loads of questions: Is it a common app, do you know the protocol it is using, do you have any programming experience, have you tried talking to the manufacturer?

Link to comment
Share on other sites

Can you dump the password hash... boot up kali usb on the machine... all the tools are there...

many many years ago I did this with backtrack 2. The password dumping tools were located on backtrack

/pentest/windows/binary/passdump.exe

lots of cool binaries located in this directory, was fun uploading each file to a windows machine from meterpreter and see what each executable can do., I used to have a copy of all these binaries...

Sbd.exe was bad ass netcat clone if any one can concur?

I think kali has a windows-binary package in the repo

Link to comment
Share on other sites

Device is a datalogger for temperature data acquisition, model 62D32, manufacter is Cryopak. The software used to interact with is called "Console Pro". There's an usb interface (serial port: COM1) where insert the datalogger and gain access:

<http://www.esis.com.au/Escort/EA-INT-USB.jpg>

I contacted manufacter but no answer (great support!). However from a generic manual about thier device:

Q: My password has changed, but I did not type a new one in; what is wrong?
A: The password prevents an unauthorised person from overwriting your data
There is no "back door" into the logger if you forget your password, so please
make sure no other person has access to your password and changes i
without your knowledge. If you are sure you have not reprogrammed you
password, you may have inadvertently changed it by entering the Set New
Password dialog (see Chapter 2, Programming the Logger), and hitting the
"OK" button, rather than the "Cancel" button. In this case the password has
changed to a blank password, and pressing “OK” in the Security Access
dialog will get you to the next dialog box, without having to enter a password
You can then set the password in the normal way.
Other possible reasons include:
1. The password within the logger has been corrupted. The software wil
attempt to reset the password back to the factory default.
2. You are experiencing communication errors. Please check with you
computer vendor to ensure your communication ports are configured and
functioning correctly.
3. The logger has corrupted configuration data, possibly as a result of the
electronics being subjected to an excessive electrostatic discharge o
exposure to high EM fields. The logger will require servicing.

Probably the password was changed...
So i'm stuck... I don't have any programming experience and I don't know what to do! :sad:

Link to comment
Share on other sites

From what they say, it sounds like you'll need to get it serviced to reset the password.

If you wanted to try to brute force it you'd need to set something up to capture the communication between the PC and the device, see if you can decipher the protocol then write something custom to go through and do some kind of dictionary attack. May be relatively easy, may be quite hard depending on your skill level and the way the device works. I've just done this to work out how a Windows app talks to an RFID writer, there was no spec so I had to sniff the traffic then use educated trial and error to reproduce it. It wasn't too hard but it did take quite a bit of time and was very frustrating, especially trying to work out how they did a checksum on one particular command.

Link to comment
Share on other sites

From what they say, it sounds like you'll need to get it serviced to reset the password.

If you wanted to try to brute force it you'd need to set something up to capture the communication between the PC and the device, see if you can decipher the protocol then write something custom to go through and do some kind of dictionary attack. May be relatively easy, may be quite hard depending on your skill level and the way the device works. I've just done this to work out how a Windows app talks to an RFID writer, there was no spec so I had to sniff the traffic then use educated trial and error to reproduce it. It wasn't too hard but it did take quite a bit of time and was very frustrating, especially trying to work out how they did a checksum on one particular command.

I don't think i have enough skill for that.... However if i want to try step by step what can i use for capture data from pc and device?

Thank you for your explanation.

Link to comment
Share on other sites

I've actually got a blog post waiting to be finished which details how I did my work.

Is it using pl2303 to do USB to serial? If so then I can try to explain. My method is probably a bit more complex than it needs to be and includes using a Linux host with windows running in a VM and then sniffing traffic with Wireshark and tcpdump. You could probably just do it with the latest Wireshark and Windows but in my case I couldn't get the pl2303 drivers I needed to use to play nice.

Link to comment
Share on other sites

Yes probably is a RS-232 serial (manufactor sells two type of interface: one with an usb connector and one with an DB9 connector usually associated with RS232). I disambled the interface and the main chio is FTDI 1435C GP170221 FT232RL.

From their website:

The FT232R is the latest device to be added to FTDI’s range of USB UART interface Integrated Circuit Devices. The FT232R is a USB to serial UART interface with optional clock generator output, and the new FTDIChip-ID™ security dongle feature. In addition, asynchronous and synchronous bit bang interface modes are available. USB to serial designs using the FT232R have been further simplified by fully integrating the external EEPROM, clock circuit and USB resistors onto the device.

The FT232R adds two new functions compared with its predecessors, effectively making it a "3-in-1" chip for some application areas. The internally generated clock (6MHz, 12MHz, 24MHz, and 48MHz) can be brought out of the device and used to drive a microcontroller or external logic. A unique number (the FTDIChip-ID™) is burnt into the device during manufacture and is readable over USB, thus forming the basis of a security dongle which can be used to protect customer application software from being copied.

The FT232R is available in Pb-free (RoHS compliant) compact 28-Lead SSOP and QFN-32 packages.

What's the best way to sniff traffic with this arrangement? I tried some softwares but no one seems to work...

Link to comment
Share on other sites

Are you connecting through a USB port or old school serial D connector?

If it is USB then Wireshark can sniff USB traffic, I did it in Linux so don't know anything about doing it in windows but it will be well documented.

Link to comment
Share on other sites

Just wanted to add a plug for the portpilot:

http://hakshop.myshopify.com/products/portpilot
 
in the hakshop. although I have not used it personally, It is a usb data logger, which you might consider if wireshark doesn't work for you.

Thank you but Wireshark did the trick! :smile:

I managed to get some packets but now it's difficult for me understand them.... Some of them:

No. Time Source Destination Protocol Length Info

60 0.514734 2.4.1 host USB 31 URB_INTERRUPT in

Frame 60: 31 bytes on wire (248 bits), 31 bytes captured (248 bits) on interface 0

USB URB

Leftover Capture Data: 00ff0200

No. Time Source Destination Protocol Length Info

61 0.530332 host 2.2.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00

Frame 61: 58 bytes on wire (464 bits), 58 bytes captured (464 bits) on interface 0

USB URB

USB Mass Storage

SCSI CDB Test Unit Ready

No. Time Source Destination Protocol Length Info

62 0.530332 host 2.6.2 USBMS 58 SCSI: Test Unit Ready LUN: 0x00

Frame 62: 58 bytes on wire (464 bits), 58 bytes captured (464 bits) on interface 0

USB URB

USB Mass Storage

SCSI CDB Test Unit Ready

No. Time Source Destination Protocol Length Info

63 0.530332 2.6.1 host USBMS 40

Frame 63: 40 bytes on wire (320 bits), 40 bytes captured (320 bits) on interface 0

USB URB

USB Mass Storage

No. Time Source Destination Protocol Length Info

64 0.530332 2.2.2 host USBMS 40

Frame 64: 40 bytes on wire (320 bits), 40 bytes captured (320 bits) on interface 0

USB URB

USB Mass Storage

No. Time Source Destination Protocol Length Info

65 0.530332 host 2.2.1 USBMS 58 SCSI: Request Sense LUN: 0x00

Frame 65: 58 bytes on wire (464 bits), 58 bytes captured (464 bits) on interface 0

USB URB

USB Mass Storage

SCSI CDB Request Sense

No. Time Source Destination Protocol Length Info

66 0.530332 2.2.2 host USB 45 URB_BULK in

Frame 66: 45 bytes on wire (360 bits), 45 bytes captured (360 bits) on interface 0

USB URB

Leftover Capture Data: 700002000000000a000000003a0000000000

No. Time Source Destination Protocol Length Info

67 0.530332 2.2.2 host USBMS 40

Frame 67: 40 bytes on wire (320 bits), 40 bytes captured (320 bits) on interface 0

USB URB

USB Mass Storage

No. Time Source Destination Protocol Length Info

68 0.530332 host 2.2.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x01

Frame 68: 58 bytes on wire (464 bits), 58 bytes captured (464 bits) on interface 0

USB URB

USB Mass Storage

SCSI CDB Test Unit Ready

No. Time Source Destination Protocol Length Info

69 0.530332 2.2.2 host USBMS 40

Frame 69: 40 bytes on wire (320 bits), 40 bytes captured (320 bits) on interface 0

USB URB

USB Mass Storage

No. Time Source Destination Protocol Length Info

70 0.530332 host 2.2.1 USBMS 58 SCSI: Request Sense LUN: 0x01

Frame 70: 58 bytes on wire (464 bits), 58 bytes captured (464 bits) on interface 0

USB URB

USB Mass Storage

SCSI CDB Request Sense

"URB_INTERRUPT in" maybe it's a sort of "stand by"; i don't know what "SCSI: Test Unit Ready LUN: 0x00 " stand for and probably "URB_BULK in" it's when the software try to interact with my device.

What can i do now? :mellow:

Link to comment
Share on other sites

You need to look at the raw packets, it may just be that Wireshark is spotting something it thinks it recognises and is trying to automatically decode it.

What I'd do is to capture from first connection to after a failed login. Do that a couple of times with various passwords and see if you can see where the password is. If you can then the next step is to write an app that repeats those packets with different passwords. That would be your brute forcer.

Link to comment
Share on other sites

It's not! It's a USB power meter.

That's good to know. The way I had read the description it sounded like it might have the capability of logging bytes of data traveling over the wire. Now that I reread it, I can see that its not what it does, that its able to record power data. Thank you.
Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...