Verify these files

This site is closed source, so you cannot audit how the disc was built. What you can do is check every claim with public tools. The commands below were run against these files and the output is copied, not illustrative.

You need sha256sum or Get-FileHash, unzip or 7-Zip, cmp, and optionally OpenSSL 3 and a JDK for jarsigner.

Hashes and sizes

curl -LO https://…/SHA256SUMS.txt
sha256sum -c SHA256SUMS.txt

hen.iso matching the reference digest for the Bonk HEN 14.00 disc is the claim that you are getting the original artifact rather than an edited variant. Compare it against any digest for that disc published elsewhere.

The disc is what the docs say

$(( 6225920 / 2048 ))        # 3040 sectors, exactly

# pull the payload straight out of the image at its documented offset
dd if=hen.iso bs=2048 skip=596 count=95 2>/dev/null \
  | dd bs=1 count=192403 2>/dev/null of=jar-from-iso.bin
sha256sum jar-from-iso.bin   # equals the 00000.jar digest above

Mount the image and confirm the volume identifier BONKHEN and these sizes: BDMV/BDJO/00000.bdjo 164, BDMV/JAR/00000.jar 192,403, BDMV/STREAM/00000.m2ts 3,975,168, NOTICE.txt 564. The transport stream is MPEG-TS, so every 192-byte packet carries 0x47 at byte offset +4, after the four-byte adaptive timestamp field:

python3 -c "
f=open('hen.iso','rb'); f.seek(1413120); s=f.read(3840)
print(all(s[i+4]==0x47 for i in range(0,3840,192)))"
# True

Signature

On a modern JDK, jarsigner reports the expected weakness and still parses the archive:

$ jarsigner -verify 00000.jar
The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled.

That message is correct and expected. The signature is SHA-1 and current JDKs disable SHA-1 by default. The archive is signed, and nobody stripped it.

The cryptographic check that does pass:

unzip -p 00000.jar META-INF/SIG-BD00.RSA > sig.der
unzip -p 00000.jar META-INF/SIG-BD00.SF  > signed-content.sf
openssl pkcs7 -inform DER -in sig.der -print_certs -noout
openssl smime -verify -noverify -inform DER -in sig.der -content signed-content.sf -out /dev/null

subject=CN=Studio, OU=Codesigning Department, O=BDJCompany.56789abc, C=US
issuer=CN=Studio, OU=Codesigning Department, O=BDJCompany.56789abc, C=US
subject=CN=Producer, OU=Codesigning Department, O=BDJCompany.56789abc, C=US
Verification successful

SIG-BD00.RSA is a 1,708-byte detached PKCS#7 blob. BDJCompany.56789abc is a self-signed BD-J developer identity, which matches the orgid="0x56789abc" in the permission file. It is not a certificate authority and it grants you no licence.

Digest counts come out at 69 in both files, which is 78 entries minus 6 directories minus the 3 META-INF members:

unzip -p 00000.jar META-INF/MANIFEST.MF | grep -c '^Name: '   # 69
unzip -p 00000.jar META-INF/SIG-BD00.SF  | grep -c '^Name: '   # 69

One quirk survives from the original author, deliberately: the SIG-BD00.SF header block is LF-terminated while its per-entry sections are CRLF. Strict parsers complain about that. Fixing it would have changed the artifact.

JAR inventory

$ unzip -l 00000.jar | tail -2
---------                     -------
   676785                     78 files

unzip -l 00000.jar | awk '{print $4}' | grep -c '^bonk/local/templates/cmd-.*\.bin$'   # 40 templates
unzip -l 00000.jar | awk '{print $4}' | grep -c '^bonk/local/[^/]*\.bin$'              #  7 metadata
unzip -l 00000.jar | grep hen.bin                    # 562240  bonk/hen.bin
unzip -p  00000.jar org/bdj/bluray.InitXlet.perm     # permission request

The permission file is worth reading for its own sake. It requests applifecyclecontrol, bd-bindingunitarea, bd-vfs, file, servicesel and read/write userpreferences, and asks for nothing network-related. Security notes quote it in full.

The difference between the two images

$ cmp -l hen.iso hen-branded.iso | wc -l
469
$ cmp -l hen.iso hen-branded.iso | head -1
917526 110 162
$ cmp -l hen.iso hen-branded.iso | tail -1
918027  40  12

The 1-based span 917526 to 918027 sits entirely inside the NOTICE.txt extent, which occupies bytes 917504 through 918067 at sector 448. Confirm that nothing else moved:

dd if=hen.iso        bs=2048 count=384 2>/dev/null | sha256sum
dd if=hen-branded.iso bs=2048 count=384 2>/dev/null | sha256sum   # same digest

All 384 leading sectors, which hold the UDF descriptors and directory records, hash identically. reports/BRAND_REPORT.json lists every changed range. The replacement notice is pinned to exactly 564 bytes so that no descriptor needs rewriting, which is why two redundant words were removed to make room for the credit.

The check suite behind these files

reports/VERIFY_REPORT.json holds the full machine-readable result of the run that accepted these artifacts: 117 checks, 0 failures. It covers the 78 JAR entries down to CRC-32, compressed size and local offset; the 69 manifest and 69 signature digests plus the PKCS#7 verification; all 38 ISO file extents; a replay of the disc's own twenty-five preflight checks against the JAR extracted from the finished image; and the dormancy analysis of the remote-control code. reports/BUILD_REPORT.json records the toolchain that produced them.

Treat those reports as evidence rather than as a rebuild path, because the build and verification tools are not published. Sections 1 through 5 above are reproducible by anyone, and a check you can run yourself is worth more than a report you have to trust.

What none of this covers

No amount of hashing proves the disc boots. I have run it on one console at 14.00 and it worked, which is a sample of one machine, one burner and one disc brand, so the checks on this page are worth more to you than my result. The signing certificate is self-signed and means nothing about trust. And the analysis covers firmware 14.00 and nothing else.