2019年4月14日（日）に技術書典6で頒布予定の「IoTSecJP Vol.3」について訂正情報がある場合はこちらに記載いたします。
初版訂正情報 2018/03/24：現在訂正情報はありません。
IoTSecJP Vol.2 訂正情報
2018年8月10日（金）にコミックマーケット94で頒布予定の「IoTSecJP Vol.2」について訂正情報がある場合はこちらに記載いたします。
初版訂正情報 2018/07/21：現在訂正情報はありません。
古いマルウェアを観察するシリーズ（２）Gafgyt
こんにちは。にほんももんがです。それではまたしても古いマルウェアを観察するシリーズをやりたいと思います。
今回はGafgyt（Lizkebab,qbot,Torlus,LizardStresserなどたくさん別名がある）です。Miraiが注目を浴びてからあまり注目されませんが、観測しているとまだまだ生きているみたいです。また、2018年4月に書かれた以下の記事でもまだまだ生きていると報告されていますね。
このマルウェアはたくさん別名があるのですが、掲示板やYoutubeにころがっている動画などを見ると、悪い人たちの間ではqbotで通っていることが多いみたいです。全く別のQbotというマルウェアもあるので、ここではGafgytと呼ぶことにします。
検体情報
- sha256
- 340ed60806df8656ced7c8989854adc680b2390dc6466a6108f307a0e5750175
- Virustotal
もう一ヶ月ほど前になりますが、今回観察した検体は、2018年5月21日ごろハニーポットにひっかかりました。
stripされていなかったため、radare2で関数一覧を見てみました。
$ radare2 340ed60806df8656ced7c8989854adc680b2390dc6466a6108f307a0e5750175 Warning: Cannot initialize dynamic strings -- Execute a command on the visual prompt with cmd.vprompt [0x00008190]> aaa [x] Analyze all flags starting with sym. and entry0 (aa) [ ] [Value from 0x00008000 to 0x0002014c aav: 0x00008000-0x0002014c in 0x8000-0x2014c aav: 0x00008000-0x0002014c in 0x2814c-0x2f590 Value from 0x0002814c to 0x0002f590 aav: 0x0002814c-0x0002f590 in 0x8000-0x2014c aav: 0x0002814c-0x0002f590 in 0x2814c-0x2f590 [x] Analyze len bytes of instructions for references (aar) [x] Analyze function calls (aac) [x] Use -AA or aaaa to perform additional experimental analysis. [x] Constructing a function name for fcn.* and sym.func.* functions (aan) [0x00008190]> afl 0x00008094 1 24 sym._init 0x000080b0 2 56 sym.__do_global_dtors_aux 0x00008128 1 8 sym.call___do_global_dtors_aux 0x00008130 1 28 sym.frame_dummy 0x00008188 1 8 sym.call_frame_dummy 0x00008190 18 46936 -> 444 entry0 0x000081cc 4 204 sym.init_rand 0x000082a0 3 300 sym.rand_cmwc 0x000083d8 11 304 sym.trim 0x00008508 4 108 sym.printchar 0x00008574 20 388 sym.prints 0x000086f8 18 488 sym.printi 0x000088e0 33 1004 sym.print 0x00008cd0 1 64 sym.zprintf 0x00008d10 1 68 sym.szprintf 0x00008d54 1 200 sym.Heliosprintf 0x00008e1c 29 632 sym.fdpopen 0x000090a4 11 384 sym.fdpclose 0x00009228 9 208 sym.fdgets 0x000092f8 5 124 sym.parseHex 0x00009378 22 424 sym.wildString 0x00009520 4 100 sym.getHost 0x00009584 4 88 sym.uppercase 0x000095dc 4 136 sym.makeRandomStr 0x00009664 19 720 sym.recvLine 0x00009938 1 56 sym.get_telstate_host 0x00009970 6 172 sym.read_until_response 0x00009a1c 7 296 sym.read_with_timeout 0x00009b44 3 112 sym.advance_state 0x00009bb4 1 48 sym.reset_telstate 0x00009be4 1 44 sym.contains_success 0x00009c14 1 44 sym.contains_fail 0x00009c44 5 96 sym.contains_response 0x00009ca4 9 216 sym.contains_string 0x00009d7c 14 640 sym.connectTimeout 0x00009ffc 9 400 sym.listFork 0x0000a194 21 396 sym.negotiate 0x0000a320 13 364 sym.matchPrompt 0x0000a490 25 676 sym.readUntil 0x0000a734 37 1008 sym.GetRandomPublicIP 0x0000ab2c 1 92 sym.GetRandomIP 0x0000ab8c 8 344 sym.csum 0x0000ace4 1 272 sym.tcpcsum 0x0000adf4 1 276 sym.makeIPPacket 0x0000af08 4 76 sym.sclose 0x0000af54 8 332 sym.socket_connect 0x0000b0a0 11 5088 -> 736 sym.StartTheLelz 0x0000c480 6 416 sym.sendSTD 0x0000c624 10 356 sym.sendHTTP 0x0000c790 41 1724 sym.sendUDP 0x0000ce4c 36 1620 sym.sendTCP 0x0000d4bc 98 2956 sym.processCmd 0x0000e084 11 448 sym.initConnection 0x0000e250 21 720 sym.getOurIP 0x0000e534 1 24 sym.getBuild 0x0000e550 83 3100 main (以下略) [0x00008190]>
気になる関数名いくつかで検索してみたところ、以下のように同種の検体を解析している記事が見つかりました。「SSHハニーポットへの典型的な攻撃分析」といった内容の記事です。
www.sohu.com ※捜狐（sohu.com）は中国のポータルサイトです。
この記事で解析されている検体には「UpdateBins」という検体を更新するための関数があるようですが、今回ハニーポットで捕まえたものには存在していませんでした。 （リンクは貼りませんが、適当に検索して見つけたリークされたコードによると、UpdateBins関数はC2からUPDATEコマンドを受け取った際に決め打ちしたアドレスからファイルをwgetしてくるコードがハードコードされているだけでした）
記事内でも言及されているように、gafgytはmiraiと同じく様々なところにソースコードらしきものが転がっており（しかもそれぞれ実装言語が違ったり機能が違ったりする）、検体によってはそれらのコードから機能がさらに追加されていることがあります。2014年ごろから存在が確認されているようなので*1、もはや元のコードと違って当たり前なんでしょうね（とはいえそんなに変わっていないようにも見えるんですけど…）。
ちなみに、IoTSecJP Vol.1*2で観察日記を書いた「Remaiten」はこのgafgytとkaitenという別種のマルウェア両方の特徴を持っているものです。
C2の見つけ方
（100%でない&やり方が雑なのは自戒しつつ）gafgytはパッキングされていない限り、stringsコマンドにかけた結果を適当にIPっぽい文字列を抽出できるようgrepしてやればC2を見つけることができます。
$ strings <ファイル> | grep -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+:[0-9]\+'
静的解析ができるともう少し書けることがあるのかもしれませんが、今だにアセンブラ読めないのでこのへんで終わります。ジャーキー美味しい。
古いマルウェアを観察するシリーズ（１）Dofloo
お久しぶりです。にほんももんがです。先日参加した技術書典で頒布した「IoTSecJP vol.1」でも書いた通り、Cowrie（ハニーポット）を運用している私ですが、ssh/telnetを狙ってくるマルウェアは古めのものが多くあまり真新しいものを見つけられません。*1
もちろんちょっと前に流行った（今もかな？）GPON狙いのマルウェアなど、時流に乗ったマルウェアも時々いらっしゃったりするのですが、そもそも自分が気づく前にセキュリティリサーチャーの方々が非常に有用で詳細なレポートを出してくださるので、私がブログに書けるようなことがありません。*2
それでもどうにか少しづつマルウェア解析できるようにならないかなあと色々調べたりしているわけですが、最近ドツボにはまってしまい、ひたすらqemuのドキュメントやメーリングリストを読んでいるだけの日々を過ごしています。１日経つと何を調べていたか忘れてしまうので、だいたいは一度読んだことがあるページを開き、はて、どんな内容だったかなと首をひねる毎日です。
PEファイルの解析方法は詳細なものが色々と出ていますが、MIPSやARMのELFの解析方法なんてWriteupくらいしか見当たらず困っています。しかもWirteupなんてだいたいは理解している人々に対して書いているものなので、凡人には意味不明です。
仕方がないので、既にたくさん情報があり、本職の方々には「あー、まだ生きてるんだ〜！」と言われるようなマルウェアを観察しつつ日々を過ごして行きたいと思います。
検体情報
- sha256
- 6f5227c1af466bd47ba6247474165767fb3a36bd9831206b25e18dccac5f5a4a
- Virustotal
First submissionは5/3ですが、ハニーポットには6/1ごろひっかかりました。複数のアンチウイルスソフトがDoflooだとかAesddosだとか言っています。 これらのキーワードで検索するとSymantecさんのブログに行き当たりました。
このマルウェアはDDoS 攻撃の実行だけではなく、バックドアを開けるようで、C&C サーバーとの通信を暗号化する際に AES アルゴリズムを使うのでAesddosなどと呼ばれたりしているようです。
いつごろから出てきたのか調べてみたところ、SANSのホワイトペーパーには「Around mid-2014」って書いてありました（P5）。
https://www.sans.org/reading-room/whitepapers/malicious/analyzing-backdoor-bot-mips-platform-35902
捕まえたものはx86用でしたが、MIPSやARMなどのものもあるようです。
C2はどこなの
Dofloo（読み方わからない）はよくあるkaiten(tsunami)やGafgytなどとは違い、stringsさえ見ればC2わかってまうわ〜ということはありませんが、親切な（たぶん）リサーチャーによって検体からC2情報を抽出するスクリプトが提供されています。
最終更新が2017年の2月頃と既に1年以上経ってしまっているので今でも使えるのかなと思いましたが、少なくとも上記検体からは抽出することができました（IPアドレスとポート）。 このスクリプトで抽出成功するということはC2のアドレスのオフセットやマジックナンバーが変わっていない様なので、きっと攻撃者は面倒くさがりやさんなんですね。
他にも色々と知りたいことはありますが、もうそろそろ飽きてきたのでここで終わります。 このファミリーについてもっと深く知りたい人はMalware Must Dieさんの記事を読むといいんじゃないかと思います。
MMD-0026-2014 - Linux/AES.DDoS: Router Malware Warning | Reversing an ARM arch ELF · MalwareMustDie!
今日もまたこの後はqemuと格闘します。では。
*1:面倒がってパスワードファイルを工夫したりしていないこともおそらく原因です
*2:360netlabさんのブログがすてき：GPON - Page 1 - 360 Netlab Blog - Network Security Research Lab at 360
IoTSecJP Vol.1 訂正情報
2018年4月22日（日）に技術書典4で頒布予定の「IoTSecJP Vol.1」について訂正情報がある場合はこちらに記載いたします。
初版訂正情報
2018/04/01：現在訂正情報はありません。
サーバのパケットキャプチャを取ってMirai亜種からのスキャン活動をELKで視化する
こんにちは、にほんももんがです。昨年植えたハニーポット（Cowrie）ですが、今日も今日とてインターネットの片隅で細々と活動しております。可愛らしいなぁと最近始めた水耕栽培のサラダ菜の芽を見つめるような目でログを眺めている日々です。
ところで、Cowrieはssh/telnetの低対話型ハニーポットなので、最近流行しているマルウェアが引っかかることはあまりない*1ようなのですが、IIJ Security Diary: 日本国内における Mirai 亜種の感染状況 (2017年12月)の脚注1に記載があるように、パケットキャプチャをして「初期シーケンスNo＝サーバ（ハニポ）のIPアドレスのSYNパケット」を抽出すれば、インターネットの片隅にあるサーバでも世の中のビッグウェーブに乗れるのかもしれないなあと思い立ちやってみました。
気分は完全に田舎のジャスコでは都会から流行が何週間遅れてやってくるのか調査する人って感じです*2。
それでは結論だけ知りたい方は結論に飛んでください。実際に何をしたか知りたい方は引き続きお読みいただければ幸いです。
目次
- 目次
- 環境
- tsharkでパケットキャプチャを取る
- tsharkで該当パケットを抽出する
- logstashでelasticsearchに放り込む
- Kibanaで可視化してダッシュボードを作る
- 結論
- 宣伝
環境
| ソフトウェア | バージョン |
|---|---|
| OS | macOS Higth Sierra 10.13.3 |
| tshark(Wireshark) | 2.4.3 |
| Elasticsearch | 6.1.3 |
| Logstash | 6.1.3 |
| Kibana | 6.1.3 |
| Kibana | 6.1.3 |
tsharkでパケットキャプチャを取る
まず、サーバのパケットをキャプチャします。今回パケットキャプチャをするのに使ったのはtsharkです。ポイントはtcp.relative_sequence_numbersというオプションをFASLEにすることです。該当パケットの抽出の際に設定すればいいオプションかと思いきや、取得の際に設定する必要があるようです（自信はないのでキャプチャするサーバと同様に分析PCのWiresharkでもこのオプションをFALSEにしておいてください…GUIの設定からでもFALSEにできます）。
キャプチャコマンド例）
$tshark -i ens4 -o tcp.relative_sequence_numbers:FALSE -b filesize:200000 -w ens4-capture -q &
※指定インターフェースやファイルサイズなどは適宜読み替えてください。
キャプチャを始めたら適当にお好みの日数熟成させます。満足行くまでキャプチャ出来たら、キャプチャしたファイルをなんらかの手段で分析用のPCへ移します。
ちなみに私はscpコマンドで雑に手元のPCにダウンロードしてきました。当たり前ですが、この時にまだtsharkを動かしたままだとこのダウンロード作業もキャプチャされるので注意してください。
tsharkで該当パケットを抽出する
次に、ダウンロードしてきたpcapから、tsharkを使って必要な情報だけ抽出します。今回は時間とソースIPくらいでスキャン行為の可視化は十分できるのですが、後ほど利用したい情報はそれ以外にもここで抽出しておいてください。ここでのポイントは、時間として抽出する列をframe.time_epochで指定することです。
frame.timeと指定してもFeb 4, 2018 16:53:46.464606074 JSTといったような表記で時間を得られるのでこれでいいかと思いがちなのですが、logstashのdateフィルターが最後の「JST」というタイムゾーン表記に対応していないため*3非常に面倒なことになります。
tsharkを用いた抽出例）
# 時間とソースIP以外も、ソースポートとディスティネーションポートを抽出しておくことにしました $tshark -r <pcapのファイルパス> -Y "tcp.seq == <サーバのIPを10進数で指定>" -T fields -e "frame.time_epoch" -e "ip.src" -e "tcp.srcport" -e "tcp.dstport" > <適当なファイル名.csv>
出力されるcsvのセパレータはデフォルトでタブです。
logstashでelasticsearchに放り込む
抽出したcsv用にlogstashのコンフィグファイルを書いてlogstashを起動し、elasticsearchへデータを放り込みます*4。
ここでのポイントは、csvフィルタのセパレータに\tでなく （ハードタブ）を指定することです。\t指定だとタブ指定になりません*5。まあそもそもtsharkでcsv出力する時点でセパレータをカンマにすればよかった話なんですけど…。
コンフィグ例）
Kibanaで可視化してダッシュボードを作る
ワールドマップ
それではここからは画像のオンパレードです。まずKibanaにアクセスして、メニューの「Management」をクリックし、先ほどLogstashでElasticsearchに放り込んだデータをインデックスパターンに設定して「Next Step」をクリックします。
@timestampを選択して「Create Index Patterns」をクリック。
これでインデックスパターンが作成できました。ここで、「geoip_location」のtypeが「geo_point」になっていることを確認します。これがgeo_pointタイプになっていない場合はデータの取り込みに失敗しているので地図にマッピングはできません。
次に、メニューの「Visualize」を選択し、「+」マークか「Create a visualization」をクリックします。
とりあえずみんな大好きな世界地図へのマッピングがしたいので、「Cordinate Map」を選択します（以前はTile Mapと呼称されていたようですが変更されました）。
先ほど取り込んだデータで作成したインデックスを選択します。
まず、Metrics>Agrregationで「Count」を選択します。次に、Buckets>Aggregationでは「Geohash」を選択します。すると、Fieldの項目が選択できるようになるので、「geoip.location」を選択します。そして最後に右上の「▶︎」マークをクリックします。
マッピングできました。
Option>Map Typeを変更することでヒートマップにもできます。
右上のSaveをクリックして、名前をつけて保存しておきます。あとでダッシュボードを作る時に利用します。
ヒストグラム
スキャン活動を時系列で観測するため、データのヒストグラムを作ります。メニューの「Visualize」を選択し「＋」マークから新規作成し、Vertival Barを選択します。
Y-Axis（Y軸）のAggregationはCountのまま、X-Axis（X軸）を追加します。Aggregationを「Date Histogram」にし、Fieldを「@timestamp」にして「▶︎」マークをクリックして反映すると、図のようにヒストグラムができますので、こちらも保存しておきます。もし何も表示されないといったような場合は、データを表示する期間などを調整してみてください。
スキャン元都市ランキング
次は、スキャンのログの数を都市別にカウントし、スキャン活動が多い≒感染端末が多い都市ランキングを作ります。メニューの「Visualize」を選択し、「＋」マークから新規作成し、Data Tableを選択します。
MetricsのAggregationはCountのまま、Bucketsで「Split Rows」を選択し、Aggregationを「Term」に、Fieldを「geoip.city_name.keyword」に、Sizeに抽出する数を入力して「▶︎」マークで反映すると、どの都市から何回スキャンが来ているかのランキングを出すことができます。Fieldを「geoip.county_name.keyword」などにすることで国ごとのランキングにすることもできますし、「source_ip.keyword」にすることにより同じホストが何度スキャンして来ているのかのランキングを作ることもできます。
ダッシュボード作成
それでは今まで作成してきたグラフをまとめたダッシュボードを作成します。メニューの「Dashboard」を選択してダッシュボードの新規作成を選びます。
次に右上の「Add」を選択します。
すると下図のように今まで保存して来たグラフが（名前だけで）一覧として出てくるので、それを選択してゆくと下の方にグラフが追加されてゆきます。レイアウトはドラッグ&ドロップなどで自由に変更することができます。
じゃーん！これでダッシュボードが完成しました。ダッシュボードも忘れず 保存しておきましょう。
結論
今まで作って来たダッシュボード上でフィルタgeoip.country_name == Japanを適用してみた結果が以下です。
5日間パケットキャプチャしているだけでも、自分が思っていたよりも日本国内ホストからのMirai亜種（と思しき）スキャン活動があるなあということがわかりました。インターネットの片隅での細々とした観測（つまりグローバルIPは一つしか保持してないってことです）でもこれだけスキャンされるので、いろんな場所にあるサーバで観測していれば、感染端末の規模感をそれなりの精度で予測できそうです。
ちなみにMiraiからのスキャンをマッピングしていたサービス、Mirai Trackerを公開していた（今は公開されていない）@MalwareTechBlog氏は500台くらいセンサー（観測するサーバ）を用意したと発言している*6ので、そのくらいあると本格的に規模感を把握できるのかもしれません。
宣伝
一連の話をデモを交えて「第3回 ハニーポッター技術交流会」で話す予定です。インフルエンザなどにかからなければ、3度目の正直で今回こそ参加できる予定です。
他の発表者が若者なので緊張しますがよろしくお願いいたします。
*1:ハニポ検出技術によって、丁寧な職人仕事（？）の施されたマルウェアはあまり捕獲できないような印象を受けます。印象でしかないので本当かどうかは保証し兼ねますが…。IoT狙いのコインマイナーとか雑な感じのマルウェアはわりとあっさり捕獲できたりしています。もちろん、最近流行のMirai亜種はスキャン活動をしているボットとは別にマルウェアをダウンロードしてくるサーバがあるので、おそらくボットよりもかなり数が少ないであろうそいつがイソイソとやってこないとマルウェアが設置されないからという理由もあるのでなんとも主張し兼ねますが…とにかく、アンチハニポ検出技術をご存知の方は教えてくださいということでよろしくお願いいたします。
*2:決して田舎のジャスコをdisっているわけではありません。随分お世話になっております。私はイトーヨーカドー派ですがジャスコもサイコーですよね。
*3:対応しているタイムゾーン表記はこちらです：Joda-Time - Java date and time API - Time Zones。JapanはOKなのに何故JSTがダメなのか納得いかない。
*4:Logstashをよく使われている方はご存知かもしれませんが、Windowsの場合ファイルのパスのセパレータに「¥」ではなくて「/」を利用してください。
*5:elasticsearch - logstash tab separator not escaping - Stack Overflow
技術書典にサークル参加して得た知見（というか反省）
にほんももんがです。 台風が近づいておりますが、本日無事に技術書典3に参加し、本を頒布することができました。
サークル参加した中で得た知見がいくつかありましたので、今後はじめてサークル参加する方に向けて知見（というほどでもないかもしれないですが…）を共有します。
準備編
まず、今回（10月22日開催）の技術書典の締め切りは3ヶ月前の7月下旬に締め切りがありました。 私は締め切りギリギリ（7月23日）に申し込み、8月ごろから準備を始めました。
- テーマ決め
- 目次決め
- （悪名高きエクセル方眼紙を使って）スケジュール決め
くらいまでを8月中には行っていました。 この時点では、「9月一杯の土日とシルバーウィークを使って執筆し、10月上旬には入稿する」という予定でした。 とにかく、誰がなんと言おうと当初はそういう予定だったんです。
ネタ収集編
9月初旬、ネタ集めのためいくつかハニーポットを構築・運用し始めます。 以前にも以下の通り運用していたことはありましたが、運用費が家計を直撃していたので（AWSでT-pot運用は月7千円くらいはかかりました。年間8万4千円、帰郷費3回分だなと思うとでかすぎます、ていうかそのお金を学資保険に回したい…）、今回は家計を圧迫しない運用を目指そうといろいろな方法やサービスを比較していました（が、結局大手クラウドサービスが安いし利便性が良いというおもしろくもなんともない結果に…）。
ここまでは順調でした。ここまでは。
頒布物制作編
それまではほぼスケジュール通りだったものの、ハニーポット構築後、土日はほぼ寝込む（というか平日も寝込む）という体調不良に10月中旬まで見舞われてしまい、頒布物は絶望的だ…と思いながら布団の中でうんうん唸っていました。
しかし、そこでお布団で横になりながらスマホでちょくちょく原稿を書くという諦めの悪さを発揮し、割増料金にはなってしまいましたがなんとか入稿することができました（この時点で10月18日、つまりイベント4日前でした）。
印刷所さんにめっちゃ迷惑かけてしまった編
しかしながら、印刷所さんに頼んでの印刷ははじめてだったため、データ不備でめちゃくちゃご迷惑をかけてしまいました。 ちなみに利用したのは日光企画さんのオンデマンド平閉じフルカラーセットです。
画像の濃淡がなさすぎる
GCPのコンソールやビューワーのWebインターフェースなどで使われている灰色のラインなどが薄く、そのままの状態ではすべて白に見えてしまうかもしれない、と指摘がありました。
⬇️濃淡薄すぎ画像
⬇️最終的に採用した画像
結局全体的に画像を差し替えさせていただき、ことなきを得ました。
トンボの位置が仕上がりサイズにかぶって入っている（トンボが見えた状態の仕上がりになる）
なぜか「特定のツールでトンボを設定する方法はわかるがどういうトンボが正しい状態か理解していない」という中途半端な理解度でトンボをつけたため（なんちゅう良い加減な）、なんと仕上がり位置から余白（ドブ）を入れずにトンボを入れてしまうというミスを犯していました。
トンボはあくまで仕上がり位置のガイドなので、仕上がり位置+余白3ミリ以上（3ミリよりも多くていい）の外側に入れないといけません。
この「仕上がり位置+3ミリ以上の余白（ドブ）の外側」という指定が最初どういうことかまったくわかっていなかったのですが、これ見てやっと意味を理解しました（遅い）。
Illustrator初期設定(サイズとトリムマーク"トンボ"設定方法)｜Illustrator入稿・印刷データ作成方法/注意点｜印刷通販の【WAVE】
なぜそんな中途半端な知識でトンボを入れたのか今となってはよくわからないのですが、ツールを使うのもはじめて&トンボを入れるのもはじめて&作業日が締め切り日という切羽詰まり具合だったのでそのせいかと思われます…😫
⬇️ダメなトンボ（仕上がりサイズちょうどに入れたためトンボが重なって表示されている）
⬇️正しいトンボ（ずれて表示される）
トンボの位置を修正したはいいが、余白が少なすぎる
上記の図で「おお、正しい位置に入れられた！」と喜び勇んで差し替え入稿をしたわけですが、実際は余白（ドブ）が3mミリに達しておらず（今回はサイズ計算を間違えるというポカ）、「探したらトンボが見えちゃうかも…」と印刷所の方から連絡がありました。
もう差し替えできる期限を過ぎてしまっているため、そのままでお願いします、とお伝えしましたが、そもそもそれまでに適当すぎる原稿を入稿するなって感じです…反省しています。
印刷所の方にはめちゃくちゃご迷惑をかけてしまいましたが、終始丁寧に応対してくださって救われました…。
当日編
その後なんとか入稿が完了し、イベント当日まで時間があったので、電子版のQRコードが入ったチラシを作っていました。
前日にチラシを印刷しようとしたところ、通院や買い物でバタバタしてしまい、「まあ明日でも印刷できるか…」と思い当日を迎え会場に向かいました。
その油断がよくありませんでした…
USBメモリにチラシを入れてきたはずが入っておらず、急遽QRコードを生成してネットプリントを試したのですが、どうしても上下が切れてプリントされてしまったり、「画像が小さすぎます」と言われプリントできなかったりといった事態に見舞われました…。
頒布数が少なく早々に完売してしまったため、電子版の問い合わせを多数いただいていたようなのですが、QRコードがなく「あとでサークルページからリンクたどってください」という不親切な案内をせざるをえなくなりました…前日までに準備は万端にしておけということですね…悲しい…。
その後携帯にQRコードを表示させて置いておくという手段に出ましたが、やはりチラシがあるのとないのとでは違っただろうなぁと感じました。
「コミケとか、なんかみんな当日コピ本印刷&製本とかしてるし大丈夫っしょ」とか思ってましたがあれは全然大丈夫じゃない人たちだったんだなということがわかりました（友人たちに失礼ですが）。
まとめ
反省点がありすぎるサークル参加でしたが、非常に勉強になりました。次回以降はこの反省点を生かします！
本日は購入してくださったみなさま、応援&協力してくださったみなさま、本当にありがとうございました。