ついに給料自体がマイナスに突入しました、やったね！
12月の出社日数が2日、当然給料は会社経由で払われている保険料金を下回り、振り込みは0円。
当然マイナス行った分はあとで請求が来るので(ry
今は鬱前でお金に困ってなかった頃の定期を解約してなんとかしている状況
それもこのまま進むと半年もちません、これはひどい。
とはいうものの、一月からは普通に8時間労働出来ているので、
この調子なら何とかなる、といいなぁ。
ちなみに回復した理由は、薬が増えたのと同居人ができたからのどちから、もしくは両方。
薬はこれが上限らしいので、これでだめになったら別の薬を探すかしないといけない状態だったわけですが
とりあえず何とかなってよかった。
……とまだ安心していいのかわからない段階ですけどね。
こっちは年レベルで放置していた中の人です、こんにちは。
鬱とか鬱とか鬱のせいで休みはしないものの出社時間が安定しなくなり(ひどいときは20時出社など)、お給金を下げて許してもらっているわけですが
鬱初期に一時実家に引っこんでいたために生じた二度の引っ越し、半年を超える休業、通院や調剤費用などなどもあってお金がものすごい勢いで溶けていき
今や貯金額が五桁、収支はぎりぎりマイナスで貯金額がちょっとずつ減っていく日々。
数か月以内に何とか就労時間を安定させないと餓死も視野に入りかねない状態だったりします。
医者だけで毎月1万強飛んでいるとか、薬の副作用で食費が倍になっているとか、いろいろ改善可能そうな点はあるので
だましだましなんとかしていく予定。
まぁ最悪インターネット解約すれば収支はプラスになるので死にはしない、といいなぁ。
会社の上司曰く「君ほど怒らない奴は珍しい」。
母親曰く「すぐ怒って睨んでくる」。
前者は「ああいう時ぐらい怒ってもいいのに」という趣旨の会話で「怒り所なんてありましたっけ」なんて返した結果。
後者は口論中に突然泣かれ、落ち着いた後に母から言われた泣いた理由。
たぶん内弁慶とかそういうことではない、はず。
(もちろん距離感まで完全に一緒とまでは言わないが)
なんでだろうね、睨むレベルにはすぐ到達するけど、それ以上はいかないとかだろうか。
母が泣いているのなんて二度しか見たことない(上記のが二度目)ことを考えると相当な気がするのだが、正直さっぱりなのであった。
単に鬱病ってた間だからだろうか？ でも前者も鬱病ってた時だしなぁ。
あぁ、鬱病は既に治った(はず)。
まだ休業中ですけどね。
とりあえず復活だけしておく。
何を書くかは知らない。
というわけで、今日は午前5時20分帰宅という凄まじい状況だった中の人です。
一応リリースは明日(既に今日と呼ぶべき時間とも言う)だったんですが、諸事情により1日早く出す事になり
そういう時に限ってやたらと好調なデバッグ作業によりバグ見つけて直してまた見つけてのループを繰り返し続けてこんな時間。
総合的に考えれば見つかるのは良いことで、きっと未来の自分は感謝感激雨あられのはずですが、今だけはバグが見つかり続けたあの現状を恨みたい。
そんな状況でも何の戸惑いもなくバグ見つけてくる当たり、バグを探す作業自体は楽しんでる気がするけど……
とりあえずこれで修羅場は一応終了して、明日からは死ぬ事は無いはず。
といいつつ、普通に修羅場フラグ立っているので、何の滞りもなく明日以降も修羅場り続けるかもしれませんけどね。
あぁ、そういえば、ネット上の友人に例大祭のあと飲みに行かないかって誘われました。
その友人の誘いなら是非とも受けたかったし、地理的にもいける位置に住んでいるし、何より例大祭に行きたかったんですが、こんな状況なのでお断りせざるを得ない事に。
もし、万が一にも余裕が出来たら、改めてこちらからお誘いするんだ……
そういえば未だにお酒一滴も飲んだことない人なんですが、仮に飲みに誘われたときってどう対応すればいいんでしょうね？
お酒って飲んだ事無い人がいきなり手を出してもやけどしないものなのかしら。
自分とかパッチテスト(?)で先生に驚かれたレベルなんで、下手に手を出したら最悪次の朝日が拝めなくなりそうでちょっと怖いんだけど
0は偉大です、そりゃあもう0なしでは生きていけないぐらい偉大です。
ありとあらゆる法則で0だけ例外なんて日常茶飯事、むしろ例外じゃない事柄の方が少ないぐらいなんじゃないですかね。
というわけで、フル0による暗号化もしくは圧縮の解析手法について。
前提：ファイル読み書きアプリがあり、ファイルフォーマットが不明で、圧縮か暗号が施されているが、、かけているだろう場所が大雑把にでも判明している。
ぶっちゃけここまで着てたら丸1日も頭捻れば大抵のフォーマットなら展開方法が出てきますが、まぁ少しでも楽するための手法です。
まず全Byteが0x00で埋まったファイルを用意します。
このファイルを読み込ませ、ちょうど圧縮なり暗号なりを終えたところでブレイクし、メモリー上に展開されている変換後のデータを覗き見ます。
ここでありえるのは大抵以下のパターン
・0xC7とか、特定の数値が延々とファイルサイズ分並んでる。
・ランダムっぽいバイト列が出ている
・ただ0x00で埋まってる
・メモリー確保した直後のままで、0xCCとか不定っぽい値が並んでる
・数バイトだけ何か出ているが後は手付かず
・それ以前にクラッシュした
特定の数値が並んでいるだけならすぐわかるとは思いますが、単なるxorもしくは加算か減算暗号です。
全byteにその数値でxorか、最上位bitか最下位bitがローテーションする加算や減算を試してみましょう、たぶん復元できます。
ランダムっぽいバイト列が出た場合は乱数xor法(私的命名)か、X次xor法(私的命名)です。
乱数xor法は種から生成できる乱数(有名どころはメルセンヌツイスター)をひたすらxorしている暗号化で、一度だけ見た事があります。
単に一つの数値でxorしないだけマシですが、該当するコードの逆アセンブリから種とアルゴリズムを洗えばすぐ解けると思います。
X次xor法は意外とよく見る手法で(なので、何か正式名前あるかも)
for(int i = 0; i < size; i++){
data[i] ^= a;
a += b;
b += c;
c += d;
i++;
}
大体こんな感じのコードによる暗号化です。
簡単に言えばサイズ1byteの乱数を作り出す簡易アルゴリズムによる乱数xor法で、+=している変数(上記の例ではabcdの四つ)が増えれば増えるだけ判別が難しくなります。
が、所詮は簡易アルゴリズムなので、出てきたデータから逆算するか適当に逆アセンブリした物から生の値を拾ってくれば解けます。
実装が容易でxor暗号なので暗号化と展開で別に実装する必要が無く実行速度も速く、変数の数と初期値を弄ることで容易に生成数値を変更できる事が利点です。
この辺が好まれて良く使われている理由なんですかね？ 正直mtによる乱数xorの方が楽で強度も高いと思うのですが。
0x00もしくは不定値で埋まっている。
(不定な値の判別が付かなければ、メモリーの確保を捕まえてそこから内容が変わっていないかを見ます)
これはフォーマットの足がかりとなるべき部分がファイル先頭に埋まっていることを意味します。
たとえばファイルサイズといった情報がファイル内に保持されており、それらの情報を元に展開を行う予定だったが読み取れなかったために展開作業を行えずに終了した、という事になります。
これにに明確な対応方法はありません。
ただ、明らかに暗号化ではなく圧縮の傾向があります。 少なくとも素の暗号データではなく暗号化データを含むコンテナファイルでしょう。
バイナリを眺める作業に戻る、逆アセンブリコードから初期の処理だけでも読み取るなど、何かしらの手は打たないといけません。
自分だったらとりあえず0x0F、0xF0、0x7F、0x80、0x01、0xFFなどで埋めたデータを読み込ませてみてその挙動を見てから考えます。
数バイトだけ何かが出ているが手付かず。
これは大分絞り込めます。
おそらくは圧縮で、なおかつ位置情報か長さ情報を含むタイプのデータが連続するタイプです。
たとえばLZSSが実装によってはこういう挙動を示します。
先頭1byteだけ弄って再読み込みなどしてみると大まかな挙動は掴める筈。
その時点でたとえ思い当たるアルゴリズムは無くともなんとなく概要はつかめているはずなので、後は適当に細部を詰めていけば理解可能です。
クラッシュした場合は多少傾向は変わりますが、0ｘ00不定値数バイトのどれかです。
ただ先頭付近に埋まっているだろうデータが位置でも距離でもサイズでもなく、何かしらの通し番号である可能性が高いです。
(たとえば使用する圧縮アルゴリズムのIDなど)
そこが仕様上使えるようには残してあるが完全に想定外な数値である為、どのようにも扱う事が出来ず、なおかつエラーチェックが不足しているためクラッシュ。
これがよくあるパターンです。
ぶっちゃけこれに遭遇したらちまちま逆アセンブリを追う位しか手がありません、何か暴走してデータ壊れても困りますしね。
それと、上記には述べませんでしたが。
0x01,0x02,0x03,0x04と連番を仕込んだデータを読ませたり、途中まで元データと同じであとは0x00のデータなど読ませても特徴的な挙動を見つけられる事が多いのでお勧めです。
どちらにしろ、データを読ませてその結果を見れる状況になれれば後はトライアンドエラーでサクサク進みます。
逆に言えば、解析を阻止したいならここが最終ラインです。
createfileとreadfileのAPIさえ押えればここまでたどり着けますので、論文にでも載りそうな高度な物を使わない限り
呼び出しAPIリストがばれる＝ファイルフォーマットまではばれると覚悟しておくべきでしょう。
問題は、そこまでして隠す必要があるのか、ということですが。
余計な事したくなるよね。
むっちゃ空腹だとか、帰宅が午前2時半だとか、明日も大変だとわかっているとか、そもそも今日は睡眠不足だったとか。
そんなの色々あって、すぐさまご飯食べて寝るべきだと体も理性もわかっているのに、なぜか自分はこれを書いています。
なんていうんだろうね、締め切り間近で現実逃避的に部屋の掃除始めるなら判るんだけど、ただ疲れ果てて～な時でも現実逃避とかあるのかしら。
それとも、精神的ストレスの解消とか？
人間って必要最低限のことしかやらないで居ると無駄なことをしたくなる生き物なのかしら。
まぁいいや、無事ご飯の準備できたら、友人に勧められて買った普段の倍高い卵で卵かけご飯を食べるんだ……
ルナティック級に縛りプレイがうまい人、なんて条件が無ければ応募したのに……
またタイトルが危ないとか、条件付けが高すぎるとか、荒れるかもしれない要素が合って不安。
別に他のサークルさんであれば何の問題もないけど、あそこは性質の悪いクレーマーが付いちゃってるから批判されうる文言つくだけで危険に思えてならない。
どうか杞憂でありますように。
テストプレイが出来ない腹いせに
一時期公開されてたソースコードでも読んでみて、バグでも見つけて送ってみようかねぇ
問題は、そんな趣味に割いてる時間が無いぐらい忙しいって事だが
プロジェクトマネージャーさん達って本当に大変だと思う。
例えば、○○をAさんにやってもらうというだけでも、ただお願いするだけでは全然足りない。
もちろん、Aさんが自力でマネージメントして、全て最善にこなしてくれうる人材ならそれでも回るけれど
そんな人はフリーランスでそれなりに経験を積んだような人だけで、普通は内容忘れるし期限過ぎるし依頼内容とはずれたものを上げてしまう。
ならマネージャーはどうすればいいかというと
まずは、Aさんがうまく行かなくても回るようにスケジュールを組む、最低でも期限を過ぎた上で2~3度差し戻しても間に合う程度のスケジュールを組む。
自分の上司曰く、最低プログラマーの自己申告の2倍、普通は3倍ぐらいとる、ってぐらい余裕を持たないと回らないらしい。
自分はプログラマーなので他の業種は知らないけど、たぶん人間って皆そんな感じだと思う(そうじゃない方々にはすいません)
そして、内容に齟齬が発生しないように、なおかつ気軽に情報を交わせるように、できるだけ密接に連絡を取る。
一般的に指示を受ける側は受身でいるので、何かあれば連絡が上がってくるだろうでは、致命的でもうどうしようもなくなるかその一歩手前ぐらいまで連絡が来ないことも多い。
何か困っている事は無い？と聞かれたら答える事があるが、聞かれない限り言いもしなかったという経験なら誰しもがあると思う、要するにそれだ。
なので、気軽に情報を上げられる空気を作りつつも、作業に意識が向く程度には空気を引き締める、たぶんこれが一番重要。
といっても厳しくするとか、露骨に急かすのはダメ、あくまで連絡を密にとるのが目的であって、プレッシャーをかけるのは逆効果だから。
これまた上司の言葉だが、「過失が無いもしくはしょうがない過失であっても、怒れば言わなくなり、その結果何とかなる問題が何とかならなくなるまで表面化しなくなる事がある」だとかなんとか。
具体例を挙げると
「すいません、○○を想定しないで××を作ってしまったので××が丸々使えないことに……」
「あー、××って必須部分のか。 もし君が作り直したらどれぐらいかかる？」
「がんばれば大体3日ぐらいかと」
「なら作り直してもらえる？ わるいけどプロジェクトの都合もあるから多少急いでもらえると助かる」
こんな空気だと問題もすぐマネージャーまで上がってくるのでやりやすいみたいです。
もちろん、怒らないといけない場面というのは当然あるので、怒るなという意味ではなく
問題にもランク付けを行って、本当に直して欲しいことだけを怒ることが大事なよう。
意見のすり合わせ、ぶっちゃけここはよくわかってない。
要するに、マネージメントされる側からは見えないところでいつも魔法のように解決してしまっているから。
これがもう、違うマネージャーさんの下で仕事を請けたら愕然とするぐらいに違う。
他はある意味でマネージメントされる側の意識改革にも近いものがあって、どちらかがそれを意識していれば最悪何とかなるのだが、これだけはもうどうにもならない。
まず全体像を把握しないといけないし、その上でのスケジュールを暫定であろうと脳内に描けていて、どれはどこまで自由に出来て、それは絶対にこの範囲に抑えなければいけないのか、
責任の所在や、関係する全員の人間関係に、お互いがお互いに持っている印象などなど。
それらをだいたい把握した上で、全体で見て最良と思える着地点を決めて何とかそこに調整し、その上で全員から確実にOKを取る。
そこまでやってようやく個々の人材を回せるようになる。
本当にあれはもう特別な才能でもないとこなすのは無理だと思う、事実上の二点はできてもこれがうまく行かずにｇｄｇｄするマネージャーさんを良く見る、会議とか話し合いだけ無駄に長い状況とかまさにこれです。
「船頭多くて船、山に登る」という状況で太平洋横断を果たすようなもの、といえば通じるだろうか。
可能な対策は、それが上手な人を見つけ出して、その人から生のノウハウを手に入れるぐらいしか手がない気がする。
少なくとも自分はいつも知らぬ間に恩恵にあずかっているだけでまったく知らない、関わる時はいつもそんな人が居ない時だけだし。
まずマネージャーがいるのにエターなるのは2番目の連絡がうまくいっておらず、マネージャーの知らないところで要らぬコストが発生しまくっている時。
次に、プロジェクトが上手く回らないのは3番目の意見のすり合わせが上手くいっておらず、皆雲を掴むような気分のまま作業が進んでいるせい。
最後に、期日に間に合わないのは1番目のスケジューリングが上手くいっておらず、取れるはずのマージンをとり損ねたから。
全部マネージメントされる側に過ぎない自分の経験からくる主観なので、十中八九合っていないのだけれど
まぁなんか上の文書いていたら書きたくなった。
最初の話の流れがどこか言っているとか、勘違いしているとわかっているのに断言調だとか、そこまでわかってても書いちゃう。
にしても、これだけの作業をこなさなきゃいけないマネージャーの人って本当にお疲れ様といわざるを得ない。
一つでも出来ているならたとえ他がズタボロでも自分は尊敬する(それすらも出来ないので)
ただし、全部放棄してる上、来た情報を誰にも言わずに忘れるを繰り返すマネージャーは死んでいい。
(自分が知らないだけでIT土方周辺ではこれ以前の問題らしい。 IT土方ｺﾜｲ)
LZSSとは、直近Xバイトのデータを辞書とし、その辞書中の位置と長さの形で表現する事で圧縮を行うアルゴリズム。
理解しやすく実装が簡単ながらそれなりに効果が高いアルゴリズムだと有名で、様々な方面で取り入れられているのを見る事が出来る。
個人的な感想として、LZSSの弱点はビット演算が必須な所だと思う。
そういう意味では、表のブログで解析した某アプリで使われていたバイト単位で処理できるLZSS実装は非常に優れていたと思う。
ただ、あれは辞書位置と長さの合計が8の倍数ビットで無ければいけない制約があり、辞書サイズが制限される問題があったように見えた。
そこで、位置と長さをバイト単位に制限せずに、他は出来る限りバイト単位で入出力できるLZSS実装を考えてみる。
まず最初に思いつくのが、実データおよびフラグと、位置長さデータの分離案。
例えば、最初に位置長さデータをまとめて持っておき、実データの先頭アドレスも持っておく
一致不一致フラグは8個分まとめて1byteとして実データ上に配置する。
そして実データ先頭アドレスから不一致フラグ1bitごとに1byteずつ展開していき、一致フラグがあったら位置長さデータの先頭から順に参照していく。
この方法の利点は、位置長さデータのbit数は制限されず、しかし実データは必ずバイト単位で扱えるので余分な演算が発生しない事。
欠点は、位置長さデータが完全に別の位置にあるので、まとめてメモリー上に読んでおけるサイズを超えていた場合にランダムアクセスが発生する事と
圧縮結果を出力しつつ圧縮といった手法が非常にとり辛いこと(位置長さデータが全て判明しないと、実格納位置が判明しない。 逆に位置長さデータを後ろ側においても同じ)
欠点では無いがある意味でのデメリットとして、実データが他の圧縮方式に比べてかなり生に近い形で配置されるので、解析行為に弱いこと
(現に自分はバイト単位LZSS実装において、バイナリエディタだけにも関わらず非常に短時間で展開コードまで辿りつけている)
位置長さデータを全てメモリー上に展開できるサイズならって条件付なら、バイト単位LZSSと同等の速度で位置長さデータの制限からは開放されると思う。
他には、位置長さデータ長を変動させるのはどうだろう。
一致不一致フラグを8個まとめるなどバイト単位LZSSを元にするのは同じ。
その上で、位置長さデータが現れるたびにバイト数を変えてやる。
具体的には、位置長さデータが合計18bitであれば3,2,2,2バイト、といったようにだ。
要するに、位置長さデータにおいてバイト単位にならなかった場合は、その余白に次の位置長さデータを格納していく形で表現するわけだ。
利点は、上記と同じく位置長さデータのbit数が制限されない事と、上記案の欠点であったランダムアクセスも発生しない事。
欠点は、圧縮時にメモリー上に保持しておけるバイト数を超えるぐらい一致せずにいた場合に、位置長さデータを書き込むためのランダムアクセスが必須である事。
それと、上記に比べると多少はマシだが、やはり解析に弱いこと。
圧縮に問題があるのは上の案でも同じだし、こちらの問題の方が遥かにどうにかなるので、たぶんこちらの方が優秀。
展開性能は条件なしでバイト単位LZSSとほぼ同じコスト、圧縮は上記のとおり若干高コスト。
うーん、これぐらいしか思いつかん(一応、一致不一致フラグと同じように8個まとめるとかも考えたけど、明らかに下位互換なので)
ぶっちゃけ、展開コードだけで圧縮コードは書いた事無いし(dat作成コードでは全て不一致フラグという暴挙に出ている)
一度真面目に組んでみれば、もっと色々見えてくるものがあるかもしれないなー
仮に、こんなコードがあったとします。
//a.c
int a(void){
return 1;
}
int b(void){
return a();
}
//b.c
int c(void){
return a();
}
このとき、b()==c()が真にならない可能性はあるか？ というと、あります。
具体的にはx86系CPU上で*(int*)a = 0xCCC3C033;とコードを書き、その上で最適化を最高にしてコンパイルするなど。
(実際にはメモリーに書き込み属性付与など色々必要です)
なぜかというと、関数bは関数aの中身まで見えており、なおかつインライン展開した方がコストが低いと判るのでインライン展開し、実際に関数aにはアクセスしません。
ですが、関数cは関数aの存在は知っていても別ファイルなのでインライン展開できず、関数aにアクセスする機械語を生成します。
そこで、直接関数aをフックするなどして動作を変更した場合、関数cのみ動作が代わり、b()==c()は成立しなくなるというわけです。
これは完全にコンパイラ依存な上(関数cにもインライン展開されたり、関数bもインライン展開されなかったり)、まったく持って役に立たない知識ですが、一応手軽な改造対策に使えます。
たとえば、それなりに重要で、まず改造の標的となり得る関数を上記手法で別々に分けます。
そうすると、完全に同じ動作をする別の関数となるため、両者の結果を比較して同一であることを検証するようにすることで、簡易的かつ信頼性には欠けますが改造対策となります(絶対に誰もやらないだろうけど)
ただ思いついたことをだらだら書いていたらわけがわからなくなったが気にしない！