вторник, 1 сентября 2015 г.

compile tshark with custom lua

Linking with liblua failed.

lua: 5.1.4
wireshark: 1.12.2

1. download lua sources, download wireshark sources;
2. build shared library for lua
Edit Makefile fo building liblua.so.
You'll have to complete src/Makefile. Name the target, add it to the main list, and add a build rule, like this:

LUA_SO=liblua.so 

ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T) $(LUA_SO)

$(LUA_SO): $(CORE_O) $(LIB_O)
    $(CC) -o $@ -shared $?

Also in the main Makefile, have the shared library installed along
with the static one:

TO_LIB= liblua.a liblua.so

3. run ./configure for wireshark with special flag for linker:
LDFLAGS="-ldl" ./configure --disable-wireshark --with-lua=/usr/local/

souces:
http://lua-users.org/lists/lua-l/2006-10/msg00091.html

среда, 5 августа 2015 г.

36 от Вадима Макишвили

О кризисе среднего возраста; о том, как остаться пригодным верстальщиком; о разнице между тобой и Артемием Лебедевым; о том, сколько наших сайтов останется в интернете, когда нам стукнет 60;

http://eduard.kozachek.net/blog/vadim-makishvili-36/




понедельник, 27 июля 2015 г.

Project tag cannot be selected if version is not yet mapped

Project tag cannot be selected if version is not yet mapped



[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on project commons-all: Project tag cannot be selected if version is not yet mapped -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on project commons-all: Project tag cannot be selected if version is not yet mapped
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Project tag cannot be selected if version is not yet mapped
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:295)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Project tag cannot be selected if version is not yet mapped
at org.apache.maven.shared.release.phase.InputVariablesPhase.execute(InputVariablesPhase.java:114)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
... 23 more


while you get this message just renew your release iteration

-Dresume=false
mvn -Dresume=false release:prepare

суббота, 18 июля 2015 г.

как выбрать диск


не подскажу модель, но подскажу как выбирать.
1. у всех производителей есть диски low-cost под десктопы и различные модели под серверные нужды — надо брать их. При чем они бывают заточены под разные виды данных — потоковая запись/чтение или рандомная запись/чтение.
2. есть материал пластин — стекло (специальное естественно) или алюминиевый сплав. Но это обычно для новых дисков не известно пока кто-то не разберет. Стеклянные обычно быстры и если их не трогать долго пашут, т.к. сама пластина более сбалансирована, но она более хрупкая — от падения 99% загнется.
3. количество пластин. Обычно технология у всех примерно одинаковая ± мелочи. Насколько мне известно сейчас 1tb — 1 пластина у новых дисков. Также играет роль плотность пластины — чем плотнее, тем больше шансов на ББ. 500gb-1tb — оптимальная на сегодняшний день. На вскидку нашел такую инфу: rml527.blogspot.ru/2010/09/hdd-platter-capacity-database.html

По каждому производителю есть расшифровка номеров модели, именно по ним удобнее всего выбирать. Сначала на сайте производителя, потом уже искать нужный хард по магазинам. (http://www.wdc.com/wdproducts/library/other/2579-001028.pdf — например) Просто по моделям в таком виде сразу можно вычислить энтерпрайзные диски и уже за ними охотиться.

четверг, 5 марта 2015 г.

custom class loader

https://github.com/kostapc/CustomClassLoader

Java обладает одним свойством, которое иногда очень сильно раздражает разработчиков - она легко декомпилируется. Чаще всего от этого спасаются обфускацией кода, что не решает основную задачу - декомпиляцию, но делает анализ кода демотивирующи сложным, но все же посильным в разумные сроки.

Сама структура организации скомпилированного кода (байт-кода) достаточно проста и уже сама по себе может дать какую-то информацию о приложении без декомпиляции - будь то jar (zip папки, по сути) или просто файлы классов. Более того, даже код, прошедший обфускацию, содержит в скомпилированном виде паттерны, которые могут быть использованы, например, антивирусами.

Чем тут можно сделать? Java позволяет создавать собственный загрузчик классов, где на входе мы получаем бинарный поток данных, а на выходе должны предоставить экземпляр искомого класса. Таким образом, собственно, байт-код может быть закриптован любым способом, на который только хватит фантазии.

Тут приведен самый простой вариант такого загрузчика. Код состоит из 2-х частей:
криптограф - класс, который шифрует байт-код и упаковывает в файл дополнительную информацию, необходимую для загрузки класса.
загрузчик - класс, который загружает закриптованный файл, расшифровывает и запускает метод main(). Таким образом, зашифрованный класс будет запускаться точно также, как и без шифрования.

В качестве шифрования сугубо для примера используется BASE64. Такая пара криптограф-загрузчик позволяет зашифровать и загружать любой скомпилированный класс-файл. Несложная доработка позволит, таким образом, паковать в единый файл целую структуру классов.

---
Изначально статья была написана для interception e-zine
inception e-zine en
inception e-zine ru