Posted: Sat Sep 09, 2023 1:10 Post subject: hash (md5/sha256) for beta firmwares
I have a wrt3200acm (kind of new though i think they are all old stock) and i want to put on dd-wrt. I downloaded the latest firmware (sept 8 2023) but i cannot find a hash anywhere and in this day and age of govt hackers and similar bogus firmware or corrupted data i would think hashes would be found. Is there a list of all hashes. I know for some other sites there will be a top level directory that list all the hashes but i can't find one here and various searches turn up nil. A very old message noted that one of the developer doesn't take hashes but that note was years old and i would presume probably incorrectly that there are hashes somewhere.
Joined: 16 Nov 2015 Posts: 6185 Location: UK, London, just across the river..
Posted: Sat Sep 09, 2023 8:22 Post subject:
notnobody wrote:
kernel-panic69 wrote:
There are no hashes to be found. That isn't something that's been done in ~15 years that I know of.
ok thanks. I would think it would be a security issue but it is what it is; after all beggars can't be choosey.
Why do you think so...any clues ?
TP-link firmware also doesn't provide hash's ...no idea about the others..
Hash's or checksums will not save your ass from hacking...usually the door is opened from inside...on layer 7 and poor internet hygiene...and it is very hard to compromise the router OS instead...
In general DDWRT firmware covers broad spectrum of routers...providing hashes will be very time/space consuming... and will not guarantee anything...anyway.. _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 53045 WAP
TP-Link WR1043NDv2 -DD-WRT 54420 Gateway/DoT,Forced DNS,AP Isolation,Ad-Block,Firewall,VPN,x1VLAN
TP-Link WR1043NDv2 -DD-WRT 54475 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear R7800 --DD-WRT 54475 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 54475 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 54475 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
There are no hashes to be found. That isn't something that's been done in ~15 years that I know of.
ok thanks. I would think it would be a security issue but it is what it is; after all beggars can't be choosey.
Why do you think so...any clues ?
TP-link firmware also doesn't provide hash's ...no idea about the others..
Hash's or checksums will not save your ass from hacking...usually the door is opened from inside...on layer 7 and poor internet hygiene...and it is very hard to compromise the router OS instead...
--
In general DDWRT firmware covers broad spectrum of routers...providing hashes will be very time/space consuming... and will not guarantee anything...anyway..
Providing hashes can be scripted when the binaries are generated. Assuming the person uploading the firmware is trusted and his identify can't be spoofed it prevent a middle person from generating a fake firmware and uploading it (of course this person can also generate a fake hash but there is a quasi solution for that). The other thing it protects against is bit corruption (for example a bad block on disk being zeroed out or parity error on the receiving or sending side). There are still bit errors at the source site that can occur but it improves thing. Also if people are using non ssl solution to download bit errors are more frequent than we would like to believe. Having worked at one of the large cdn i saw frequent bit error at the interface or router level and there are many routers between source and end user. crc checking on interface is severely lacking. ssl uses stronger hashes which will catch most bit errors.
Joined: 18 Mar 2014 Posts: 12487 Location: Netherlands
Posted: Sat Sep 09, 2023 9:59 Post subject:
We can see the benefit of using hashes but is just not practical, building for 300+ routers already takes 12 hours and for making the hashes it will seriously add to this.
Joined: 16 Nov 2015 Posts: 6185 Location: UK, London, just across the river..
Posted: Sat Sep 09, 2023 17:02 Post subject:
I suppose you are 'missin' the dodge work 300+ with different .bin names and few .trx but yea you are correct it should, not take a long...I do love 'hash'ss' will make use offf...
Cheers ! _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 53045 WAP
TP-Link WR1043NDv2 -DD-WRT 54420 Gateway/DoT,Forced DNS,AP Isolation,Ad-Block,Firewall,VPN,x1VLAN
TP-Link WR1043NDv2 -DD-WRT 54475 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear R7800 --DD-WRT 54475 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 54475 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 54475 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Joined: 08 May 2018 Posts: 13898 Location: Texas, USA
Posted: Sat Sep 09, 2023 19:01 Post subject:
Comparing already downloaded firmware image files to doing an md5sum during compilation is not exactly the same as the firmware images are built in parallel - BUT, once all of the images are finished being compiled, running an md5sum probably would be of insignificant impact to the resources. There are details I won't go into that were shared with me, but I will say that I've automated the process for running FreshTomato builds, but I don't post those publicly, so it's sort of moot. Also, the firmware upgrade process in DD-WRT checks the CRC of the file per the header information, so the likelihood of there being bogus firmware images involved might also be nonexistent...
For the record sha256 is better than md5 for various reasons from a security perspective but not necessarily for a correctness purpose.
crc are weak; interfaces use simple crc and frequently double bit error go undetected. No clue if the crc in the firmware header are more robust as i know nothing about them; but i'm happy zfs uses something a bit more robust to validate blocks
