Repository navigation
Fix Windows compatibility: UTF-8 output, path anchoring, BOM handling - #198
Open
jaywavy616-arch wants to merge 1 commit into
Open
jaywavy616-arch wants to merge 1 commit into
jaywavy616-arch wants to merge 1 commit into
Conversation
Four bugs that make Blackbird unusable or silently wrong on Windows. 1. Redirecting output crashes the tool. On Windows a redirected stdout defaults to the cp1252 locale codec, which cannot encode the emoji in Blackbird's output. `blackbird.py -u foo > out.txt` dies with UnicodeEncodeError and exit 1. Fixed by reconfiguring stdout and stderr to UTF-8 before rich initialises. 2. The tool only works when launched from the repo root. config.py and pdf.py resolved data, log, asset and font paths against os.getcwd(). Running from anywhere else could not find wmn-data.json or the PDF fonts. Fixed with a BASE_DIRECTORY anchor derived from __file__. 3. A UTF-8 BOM in an input file silently breaks the search. getLinesFromFile used a bare open(), so a list saved by Notepad made the first username '\ufeffp1ngul1n0'. The search then returned nothing and reported no error, which is the worst failure mode for an OSINT tool. Fixed with encoding="utf-8-sig". 4. userAgent.py leaked a file handle and used the locale codec. Bare open() without a context manager. Latent today because the file is ASCII, but it is the same class of bug as 3. Verified on Windows 11, Python 3.11.15, locale cp1252: - Before fix: `blackbird.py > out.txt` exits 1 with UnicodeEncodeError. After fix: exits 0 and writes real UTF-8 bytes (F0 9F 94 8D). - BOM'd input file: first entry now parses as 'p1ngul1n0' rather than '\ufeffp1ngul1n0'. - config imports and resolves correctly from an unrelated working directory.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four Windows bugs, three of which I hit on a fresh install before the tool would run properly. All verified on Windows 11, Python 3.11.15, locale
cp1252.1. Redirecting output crashes the tool
dies with
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f50d'and exit 1.On Windows a redirected stdout does not inherit the console's UTF-8 setting. It falls back to the locale codec, which is
cp1252on a US install, and cp1252 cannot encode the emoji in Blackbird's output. Interactive runs are fine, so this only shows up the moment someone pipes or redirects.Fixed by reconfiguring stdout and stderr to UTF-8 before
richinitialises.Before: exit 1, traceback.
After: exit 0, and the file contains real UTF-8 bytes (
F0 9F 94 8Dfor the magnifier).2. The tool only works when launched from the repo root
config.pyandpdf.pyresolved the data list, log file, fonts and images againstos.getcwd(). Launching from anywhere else could not findwmn-data.jsonor the PDF fonts.Fixed with a
BASE_DIRECTORYanchor derived from__file__, so paths follow the installation rather than the shell's current directory.3. A UTF-8 BOM in an input file silently breaks the search
getLinesFromFileused a bareopen(). A username list saved by Notepad is UTF-8-with-BOM, so the first entry parsed as'p1ngul1n0'instead of'p1ngul1n0'.The search then returns nothing for that user and reports no error. For an OSINT tool a silent false negative is worse than a crash, since the operator has no signal that anything went wrong.
Fixed with
encoding="utf-8-sig".Before:
repr(lines[0])is'p1ngul1n0'.After:
'p1ngul1n0'.4.
userAgent.pyleaked a file handle and used the locale codecBare
open()with no context manager. Latent today becauseuseragents.txtis pure ASCII, but it is the same class of bug as 3 and costs one line to fix.Scope: deliberately limited to Windows compatibility. 5 files, +31 / -17. I have other fixes in a local branch (a
None == Falsecomparison inprecheck.pythat lets failed pre-auth checks fall through, a--filterIndexError, and a test fixture issue) but those touch behaviour rather than portability, so I have kept them out of this PR. Happy to open them separately if useful.