Fixing "error code: 1275" when using PHLASH to update BIOS on ancient laptops

If you happen to be turning old laptops into Chromebooks or something, and you're trying to flash the BIOS on an ancient laptop, and you can't do it from a DOS boot USB because it's a Windows-only flash utility, and you run into something like this:

Cannot load driver C:\dell\BIOS\WINPHLASH\PHLASHNT.SYS.

Please check your accounts, if you have no administrator privilege, please login again!

This driver has been blocked from loading

Error code: 1275

... then you're not alone. 

Here's what I tried that didn't work:

• Booting from a Windows 7 universal install disc. Trying to run PHLASH threw the error "the subsystem needed to support the image type is not present". I suspect this is because the install disc is primarily 64-bit, but PHLASH is 32-bit, but that's just a guess.
• Installing 64-bit Windows 7. The driver wouldn't load, throwing "Access is denied" in PHLASH.LOG, even when running as true Administrator. My theory is that this is because a newer kind of library or approach is needed by Windows 7 to write to the BIOS while Windows is loaded, and newer versions of the OS block the old method.
• Installing Windows XP. I couldn't find a version that had a variant of the offline algorithm used to validate the license key that recognized the key that the laptop actually shipped with. If I'd figured out how to do this, I suspect that it might have worked.

What did work was to boot from a 32-bit Windows Vista install/rescue CD. PHLASH was able to successfully run from there. 

Digging up an ancient BartPE might also work.

Updating the BIOS didn't fix my actual problem (some of the Neverware CloudReady menus are entirely black, as if there's some kind of video-driver overlay problem). 

But at least this Inspiron 1501 now has a 2008 BIOS instead of a 2005 one. "I'm doing my part!"

TIL: the unexpected back story of Mah Nà Mah Nà

Just read the Wikipedia article and the 2011 Slate piece.

... and then enjoy them:

The original, "Mah Nà Mah Nà", from the 1966 Italian movie "Svezia, inferno e paradiso" ("Sweden: Heaven and Hell")

The original 1969 Sesame Street version (video)

The 1971 Benny Hill version (audio only)

The version from 101st episode of the Muppet Show (video)

The 2011 Muppets Tonight sketch parody, featuring Sandra Bullock

The entry on the Muppet Wiki - many, many differnent versions and references

(Interestingly, the scat sequences actually vary from version to version, borrowing from a variety of musical sequences.)

Notes on passphrases as passwords

As we promote passphrases, we need to make it clear that not all phrases are created equal.

Phrases that match the rhythm of human language, and phrases that are even only somewhat based on anything that has already appeared anywhere -- lyrics, song titles, movie quotes, phrases that appear on Wikipedia, etc. -- are subject to guessing. The password cracking community is hot on this trail, and really pushing the envelope in this area. "Myd0ghasfle@s!" is certainly better than "abcdefgh" or "Summer2015!", but it is not sufficiently resistant to state-of-the art attacks. These attacks can quickly combine phrase lists with transformational rules, and really tap into the psychology of how people select naive passphrases.

Put another way ... we need to make sure that users do not walk away thinking that "itsmypartyandillcryifiwantto" is a good passphrase.

One problem is the word "passphrase". The layperson expects something called a "passphrase" to be a real, grammatically correct phrase, but that's exactly what we don't want them to use. Such phrases are inherently easier to guess. Only randomly-selected words provide resistance to both brute force and rules-based attacks.

The best balance of "memorizability" and strength is to use "Diceware"-style passphrases, just as that XKCD suggested (but perhaps with some adjustments to the size of the word pool and number of words). The words need to be truly randomly selected, and drawn from a relatively large pool of words that are nevertheless familiar enough to be easily remembered. An open-source, client-side, JavaScript implementation is available here, and some great statistics about the strength of the resulting passwords are shown there.

The sheer numbers behind Diceware-style passphrases are significant. When implemented correctly, even if I tell you which dictionary I've drawn from, and how many words that I used, brute-force cracking is still infeasible for any modern (and even many retired/outdated) password hashing methods.

One implementation hitch is that many sites either A) still apply naive complexity requirements to very long passwords, or B) don't allow passwords longer than a certain length.

To make Diceware-style passphrases compatible with naive complexity rules, users can add their own additional rule. Such a rule can make randomly generated passphrases compliant with such complexity rules. For example, I can always capitalize the first word, and appending "1!" at the end ("Correct horse battery staple1!") Even if I tell someone what my personal additional rule is, brute-force cracking is still infeasible.

If a website has an artificially low length cap (such as 15 or 20 characters), rather than trying to cram a shorter passphrase in, I recommend falling back to a randomly generated password that maxes out the allowed length, and storing it in a password manager.

The best things that web developers can do to support good passphrases is to:

• relax complexity requirements once a sufficient length is met, and
• support a high maximum password length (such as 128 characters)

Now with the SSLs

This blog (along with all other blogspot.com blogs) is now available over HTTPS:

https://roycebits.blogspot.com/

The RSS and Atom feeds are also HTTPS-aware:

https://roycebits.blogspot.com/feeds/posts/default?alt=rss
https://roycebits.blogspot.com/feeds/posts/default?alt=atom

Please update your bookmarks and feeds accordingly.

Geek note: you can see the Qualys SSL Labs Server Test results for this new setup. (Not perfect, but it's progress!)

Note: HTTPS is not yet available when wrapping a blogspot.com blog within your own domain (such as blog.example.net).

Hash filtering - an appeal to more than vanity

tl;dr: The major password-cracking projects should add support for general hash substring search (vanity hashes, partial collisions, etc.).

What is a vanity hash?

A vanity hash is a hash that contains an interesting substring. For example, my actual Bitcoin address is:

1AzVVHTijMGoWzPtUJoWkF5u6vyS1NcTzj

But it would be cooler if it was this:

1RoycehyNKfRC4nN5jKruZpjMKwNviQRb

That's a vanity hash. Finding one requires a brute-force search. The more characters you want, the harder it gets -- exponentially harder. But even just a few characters can be good enough.

Current examples of vanity hashes

We humans are vain creatures -- so when hashes are used as public identifiers, we want to personalize them:

• Bitcoin addresses can be "vanity addresses".
• Onion hashes and GPG keys can be vanity hashes.
• Tripcodes (used to prove identity on image boards) have vanity hash tools that can search for descrypt-like vanity hashes (at speeds in the 950Mh/s range!)
• Git commit hashes can be vanity hashes if patched to support it.
• Some folks want to personalize certificate signatures.

More than vanity

Searching for a vanity hash is really just an attempt to find hashes with certain content. Other efforts seek hashes with specific content for other reasons - hash collisions, partial collisions, etc. More generally, these are searches for hash substrings.

Why hash substring search is interesting

Finding substrings in hashes isn't just about vanity. Bringing hash substring search into the cracking platforms would enable other interesting work:

• Experimenting with collisions and partial collisions. This is a potential attack surface that is not adequately publicly explored. Nation-states are almost certainly capable of locating near-collisions for some hashes. When you check a download hash, how often is that check only a cursory visual check? True collisions for slow hashes are nigh-infeasible, of course -- but near-collisions may be interesting.
• Demonstrating weaknesses. For example, short GPG key IDs can have collisions.
• Filtering for hashes with broad properties (instead of just substrings). Hashes that contain only digits, or only letters, or letters and digits alternating, or only lower case (for hashes that distinguish case). Perhaps only a curiosity today, but they might be interesting in the future.
• Automatic/loose discovery of similar strings. This would be a nice-to-have at some point, but searching by edit distance would complement substring searching nicely. A minimum or maximum edit distance could be specified to find strings that are "close enough". One of the most common measurements of edit distance is Levenshtein distance, which has been implemented in most languages, and implemented efficiently on GPU.
• Working with non-contiguous substrings. Most vanity-hashing tools won't let you search for a hash that begins with "[aA][bB][lL][eE]" and ends with "[eE][lL][bB][aA]". But password crackers' mask syntax is perfect for this.
• Unforeseeable innovation. Once this capability is available across all hash types, people will tinker with it, revealing new use cases. I've seen some CTFs that involve searching for specific substrings in hashes. I think they're on to something.

Calling them "vanity hashes" doesn't do justice to the potential. I think that the activity of hash substring search -- partial collisions, vanity hashes, etc. -- needs a better name.

Let's call it hash filtering.

Why the password crackers are the best place to do hash filtering

• It's efficient. No one is better positioned to implement hash filtering than the password crackers -- and doing it anywhere else is a waste of resources. Each standalone vanity-search implementation reinvents the hash bruteforcing wheel - usually poorly: This rarely approaches the speeds that JtR and hashcat are capable of (though there are exceptions). The Bitcoin folks have an edge today because of FPGAs, but I expect this gap to close.
• It's high leverage. If implemented as a general framework within password crackers, all current and future hash types automatically inherit substring search capability, with little additional effort.

How the password crackers might respond

• Sound great! That would be awesome, but not likely to be the first reaction. So ...
• OK -- but it should be done as a separate executable. This is a waste of time. The best features of professional-grade password crackers -- core brute-force power, Markov, forking/parallelism, session management, masks, device selection, wordlist management, etc. -- would either be unnecessarily duplicated, left out, or suffer from bit rot.
• No. It will slow down cracking too much. Not necessarily. Hash filtering should be implemented as an early pre-optimization step, so that you only have to take the inevitable speed hit if you want hash filtering. Regular cracking would be unaffected.
• No. We're not interested in vanity hashing as a concept. That would be a mistake. Vanity hashing is already driving interest, contribution -- and even innovation (like entirely new S-boxes).
• No. It might attract noobs. Unavoidable -- but this should be offset by an influx of insight and talent. Also, we have to feed a certain number of noobs to Xanadrel, the Sarlacc of #hashcat. ;)
• No. It adds complexity. Technically true, but it should be a largely one-time cost. Also, I think that implementing Levenshtein distance on GPU would be kinda fun if I was atom or Sayantan. ;)
• No. Hash filtering itself will be too slow. By its nature, it will, indeed, be much slower than password cracking. But if it can be pre-optimized (see previous point), then it can take advantage of the rest of the cracking support structure, so that hash filtering will be faster, more portable, and easier to use than it would be anywhere else.

Implementation suggestions

• Allow the user to specify a "hash filter", using existing mask syntax. This would automatically enable specifying one or more desired substrings anywhere in the hash -- beginning, end, or middle -- as well as both non-contiguous strings and loose matching by character set.
• On the command line, consider long options with names like --hash-filter [mask] and --edit-distance [integer]. Or name it something else -- but keep it consistent across projects.
• Implement in the pre-optimization pass, so that the slowdown introduced by examining each hash will only kick in when hash filtering is explicitly requested.
• Add simple sanity checking. If the user supplies a mask that is longer than the target hash, warn rather than silently truncating. Also, warn if the user wants to filter for a mask that isn't possible (for example, if their descrypt filter's last character is not within [.26AEIMQUYcgkosw]).

Potential bounty?

If this proposal is not obviously compelling, I will consider setting up a bounty (or charitable donation of the winner's choosing). The bounty would go to each major natively Linux-based project (John the Ripper or hashcat) that incorporates hash filtering. Edit distance would be optional.

If you want to go in on a bounty, contact me and I'll do the Bountysource setup.

The ask

Bring vanity hashing and its kin into the fold -- generalize it into hash filtering that can be applied to all current and future hashes. I think that the results will bear interesting fruit.

Updated: to use a valid example Bitcoin vanity.

Cyber and information security certification frequency in job descriptions - 2015-10 edition

A rough study of Indeed acronym frequency when coupled with the word "security":

CISSP  12859 ISC main
ITIL  7233 see also ITILv3 below (+162)
CISA  5374 ISACA auditor
CISM  3927 ISACA manager
CompTIA 2857 a+, security+, network+, etc
GIAC  2368 (any)
CEH  2329 EC-Council
GSE  1501 GIAC expert/advanced
SSCP  1328 ISC – CISSP “lite”
GCIH  1279 GIAC incident handling
CRISC  804 ISACA risk
“CCNA Security” 660 Cisco
GPEN  554 GIAC pentester
OSCP  475 Offensive Security
GSLC  332 GIAC's CISSP analog
GWAPT  253 GIAC web pentest
“CCNP Security” 235 Cisco
CCSE  228 Checkpoint
GREM  219 GIAC reverse engineering malware
ITILv3  162 See also ITIL above (+7233)
“CCIE Security” 155 Cisco
GCFE  140 GIAC forensic examiner
OSCE  124 Offensive Security – advanced
CSIH  100 Carnegie Mellon
GXPN  73 GIAC exploit dev and advanced pentest
GCWN  66 GIAC Windows security
“Cisco CSS” 29 Cybersecurity Specialist – hard to search for right
WCAN  4 Wireshark

No sense in wasting the heat and air movement

My 6x GTX 970 open-air password-cracking rig.

Purpose:

• On-site password auditing under my consulting shingle, Tech Solvency
• Independent password research

Components:

• Case: Custom Spotswood
• - Case cover: Not pictured. Mostly for transport purposes, usually runs with the cover off
• - Handle: For carrying. Sorta helpful, but a little unwieldy
• Board: GA-990FXA-UD3 rev 4.0. Leave IOMMU enabled; add "iommu=soft" to grub parameters (otherwise, USB and NIC won't work)
• - Sound: No onboard sound - mini onboard speaker ($4)
• CPU: AMD FX-8350
• Memory: 32G for PRINCE headroom
• OS: Ubuntu Server 14.04 LTS 64-bit
• PSUs: 2x Corsair RM1000. No fan movement unless loaded. Room for growth if cards get upgraded
• - Dual PSU adapter: Vantacor
• - Power switch: Had to get a power/reset switch/cable - none onboard
• GPUs: 6x EVGA 04G-P4-2974-KR. Max 165W per card
• - Risers: Non-USB (ribbon) risers. The four x16 slots have powered x16-to-x16 ribbon risers, which isn't necessary for most GPU-centric cracking. x4 or higher is better for John the Ripper, but x1 is fine for cudaHashcat. The two x1 slots have unpowered x1-to-x16 ribbon risers. The USB-based risers would *not* work with this board. The symptom was that only a couple of the cards would work at a time.
• - GPU fans: locked at 50%. Temperatures do not break 78 at normal house temps, and do not break 72 in cooler rooms

Power consumption:

• Idle: 105W
• Idle, with GPU fans forced to 50%: 120W
• Full CPU load (all 8 cores, OEM CPU fan at 3600 RPM): 265W
• No CPU, oclhashcat job loaded but paused: 310W
• Full GPU-only oclhashcat job in progress, minimal CPU: 1050W
• Full processing load (CPU and GPU): TBD

UPDATES - Performance:

• cudaHashcat 2.01
• unified hashcat 3.10b97 (g57ce1fd)
• hashcat 3.30 (2gf88644f, 2017-01)

UPDATE - upgrades over time:

• GPUs are now 6x 1080s
• Ubuntu 18.04 LTS
• CUDA 10.1 (upcoming hashcat 6.0 restores CUDA support; now you can use all of your GPU memory! - good howto from Puget Systems here)
• almost always latest hashcat from GitHub