Problem dumping flash


I've got a mikrotik cap2nd with openwrt 18.06.2 installed. I have dumped flash memory (25q128jv winbond) using programmator. Then I opened it with hex editor and changed mac on which I needed.
After doing that I loaded dump on a different mikrotik cap2nd at which point this device turned into a brick giving no signs of life. If I am not changing mac address with hex editor everything goes fine -- I am getting the exact copy of the donor with all the settings and all works just fine.
I tried the same pattern with TPLinks and there were no problems, everything works. How would I edit .bin in the right way?
I used Xway, and also used hex editor.

I hope very much for your help.

  • What portion of this process involves OpenWrt?
  • You can use a download function in OprnWrt (but I don't beleive it was added until version 19).

There is no [safe] method to edit a .bin file - and the process you're undertaking is the exact example of what's not suggested. Some times it works...most times it doesn't. It has to do with cheksums...overwriting the available flash space, etc. - can't be sure in your case.

It seems the flashed dumped OK, you're editing the BIN and hence corrupting it.

1 Like

Hi @KlenKlenov,

It is possible to set the MAC addresses to different values in OpenWrt through /etc/config/network and /etc/config/wireless.
It may be that the bootloader will not accept a MAC that is out of a predefined range, or that you are mistakenly changing bits unrelated to the MAC address.
Mikrotik usually store the MAC address in a tag-length-value hard config parition. MIPSBE this uses the magic draH, and starts (and ends, usually 4K long) on a 4K (0x1000 bytes) boundary. The MAC tag is ID 4, and length 8 (MAC address, with two zero bytes after it): 00 08 00 04 $MACADDRESS 00 00.
I would read the NOR from target device.
dd out the hard_config partition
change the MAC (make sure you are not adjusting length; only overwrite bits)
erase NOR at hard_config partition offset and length on target
flash only modified hard_config (offset and length) on target
then: read back what you have flash, and cmp or checksum it against the file you flashed, to check there were no errors in writing. If there were, try again, or write slower, or in smaller blocks (4K minimum).

1 Like

Hi lleachii.Thanks for your reply.

A new batch of microtiks has arrived with the latest version of RouterBoar 6.48.I tried to flash them using standard methods (I have done this several times before), but it did not work here.

DC:2C:6E:16:A4:3E: statically assigned to address [11/11 18:13:50.232] Rcvd DHCP Discover Msg for IP, Mac DC:2C:6E:16:A4:3E [11/11 18:13:50.436]

dnsmasq (from Lede)
Thu Nov 11 12:47:11 2021 dnsmasq-dhcp[1018]: DHCPREQUEST(br-lan) > dc:2c:6e:16:a4:3e Thu Nov 11 12:47:11 2021 dnsmasq-dhcp[1018]: DHCPNAK(br-lan) dc:2c:6e:16:a4:3e

Since it was urgently necessary to flash the devices, I did it through the programmator (I flashed 20 pieces using Ch341) Then I undermined the poppy using the settings.

I don't know how to solve this problem yet.

Hi johnth.Thanks for your reply.

Yes, that's exactly what I had to do. Thanks for your advice. I will try to use them shortly.