-
PIC: viewing data memory to find program parameters? (in-circuit debugging)
Posted by iroc86 on 24 Mar, 2024 02:25 -
I have an industrial control device operated by a PIC18F67J60 and I was curious if it's possible to retrieve certain program parameters via firmware dump and in-circuit debugging. This device has a configurable IP address via an onboard web interface, but unfortunately I do not know the IP address and the manufacturer provides NO WAY to reset the configuration to factory settings. If you lose or forget the IP, then it's essentially bricked
. I purchased the device secondhand and I don't know it's history; the default IP doesn't work. (Already tried packet sniffing, too. It doesn't send ARP announcements.)
The PCB has a programming header and I was able to confirm that the pins are Vdd, Vss, MCLR, PGC, and PGG. The PIC18F67J60 does not have internal non-volatile memory, but I did find two other EEPROM chips on the board, which is where the TCP/IP settings are presumably stored, along with everything else.
I was thinking that I might be able to dump the firmware--assuming code protection isn't enabled--and possibly read the memory locations in-circuit with a PICkit and see if anything obvious jumps out. I suspect that the IP address, gateway, and subnet mask would have to copied into data memory at some point, and I might be able to find a pattern by looking through the hex values (e.g., a subnet mask of 255.255.255.0 might show up as FF FF FF 00 somewhere and maybe the device's IP address would be stored in a nearby register--would take some guess-and-check obviously).
Once I know the IP address, I can put the device on a local network, log into the web interface, and change the IP to something else.
Is this something that might be feasible? I don't have any programming hardware at the moment, and it's been years since I worked with a PIC, so I wanted to get a sanity check before I sunk too much time into this project. Thanks! -
You certainly can read firmware (if not protected), but if they use external EEPROM chip, why would they store IP inside?
You can sniff what they read from EEPROM with a scope. -
You’d probably succeed faster with network scanning tools - nmap, etc pinging unicast and broadcast addresses.
-
Thanks for the replies!
You certainly can read firmware (if not protected), but if they use external EEPROM chip, why would they store IP inside?
This device connects to a local network and can be administered through an onboard web server, so the TCP/IP configuration data needs to be stored someplace. It's possible to change the IP, but you need to know what it is to log into the device via the browser and make additional changes. I figured that the config would be stored in the EEPROM and then read into the PIC's data memory during initial boot-up, which would save me from needing to dump the EEPROM. If I can monitor the data memory "live," then I might get lucky.
I suppose it's also possible that the PIC could rewrite its own program data when the user changes the IP address, in which case the address might even be stored in a firmware dump. Knowing what I do about the way this device was designed, I wouldn't put it past the manufacturer--the hardware implementation is kind of a kludge and their documentation even says that the administrator password is hard-coded and needs to be reset by the factory if you ever lose it. Pretty poor software implementation.You’d probably succeed faster with network scanning tools - nmap, etc pinging unicast and broadcast addresses.
Unfortunately, that was a no-go, along with packet sniffing with Wireshark. Tried pinging 224.0.0.1 and 255.255.255.255 to no avail. I also tried mass-pinging the typical ranges--172.16.0.0/16, 192.168.0.0/16, and 10.0.0.0/24. I got through about 4 million addresses (and five days worth of pinging) on the latter when I got fed up and started looking at other techniques. There's no guarantee what address might have been configured, so it could take a very long time if one were to scan the entire IPv4 range, not to mention having to reconfigure subnets for each network (first) octet. -
Start WireShark, set a filter to not include the MAC your on and connect the device directly to your PC. When the device has booted, you're hopefully getting ARPs telling you the IP address.
Just an idea.
-
8 bit PIC debugging requires the firmware to be built for debugging, the debug executive to be appended and debugging enabled in the Config. None of that happens for a production build, or even for development builds unless a hardware debug tool is active in the IDE. Therefore you will *NOT* be able to attach a debugger to an OEM programmed PIC and perform any debugging function, including reading out RAM etc. *Most* manufacturers of non-open-source products will enable code protection, so even reading back Flash contents is fairly low odds.
Microchip have application notes and libraries for EEPROM emulation using FLASH program memory that handle wear management. Its a low endurance part (typ. 1000 flash writes), but for rarely changed data if you overprovision by a factor of 10, that gives a reasonable 10K endurance. Combined with the manufacturer stating that the admin password can only be reset by returning it to them, odds are fairly high that if they are at all security conscious, critical settings are stored internally so they cant be sniffed with a logic analyser on the external memory bus.
-
First dump the eprom with an external programmer (CH341 etc) and have a look.
Or remove the eeprom and boot, it might revert to default settings. -
ReneK, good thought on the ARP, but up above I mentioned that I already tried that. Unfortunately, this device doesn't send ARP announcements, so Wireshark doesn't detect anything.
Ian.M, that's good to know about the debugging capability being baked into the firmware. You're probably right that this wouldn't have debugging enabled in a production unit (I was hopeful).
DavidAlfa, I found another workaround so I didn't bother trying the EEPROM dump:
I spent some time this afternoon trying to find another way to access the device and had success with Modbus, interestingly enough. This particular product has another variant with Modbus support, and the internal connections were there (same PCB). Turns out the PIC had Modbus capability turned on, even though it's not documented on this model. I managed to query some registers from the related model and test the functionality that I needed to, so I'm not going to bother with trying to find the IP address and access the device via Ethernet. A bit anticlimactic per the intent of this thread, but I learned some things from you all. Thanks!