求个简单函数,请赐教:)

f0restwow 2013-09-22 10:15:41
发帖目的:求一个函数
功能:传入一个YYYYMMDD。生成一个时分秒序列。。
得到一个新的日期,为YYYYMMDD H24:MI:SS这个一个格式。
时分秒随机生成。
...全文
113 5 打赏 收藏 转发到动态 举报
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
f0restwow 2013-09-23
  • 打赏
  • 举报
回复
引用 2 楼 super007007007 的回复:
SELECT TO_DATE('20130922' || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 24)), 2, '0') || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 60)), 2, '0') || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 60)), 2, '0'), 'YYYYMMDD HH24:MI:SS') FROM DUAL;
谢谢。。
f0restwow 2013-09-23
  • 打赏
  • 举报
回复
谢谢楼上几位朋友。
Persistence_x 2013-09-22
  • 打赏
  • 举报
回复
引用 2 楼 super007007007 的回复:
SELECT TO_DATE('20130922' || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 24)), 2, '0') || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 60)), 2, '0') || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 60)), 2, '0'), 'YYYYMMDD HH24:MI:SS') FROM DUAL;
正解
super007007007 2013-09-22
  • 打赏
  • 举报
回复
SELECT TO_DATE('20130922' || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 24)), 2, '0') || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 60)), 2, '0') || LPAD(FLOOR(DBMS_RANDOM.VALUE(0, 60)), 2, '0'), 'YYYYMMDD HH24:MI:SS') FROM DUAL;
无敌小二傻 2013-09-22
  • 打赏
  • 举报
回复
dbms_random.value(1,to_char(sysdate,HH24MISS))
【文章标题】: 绕过 Enigma Protector 2.xx 注册保护 【文章作者】: CodeGame 【作者邮箱】: CodeGame@Yeah.Net 【作者主页】: http://blog.csdn.net/codegame 【作者QQ号】: 441673604 【软件名称】: windows 计算器 【软件大小】: 669kb 【下载地址】: windows xp 系统自带 【加壳方式】: The Enigma Protector 2.20 正版 【保护方式】: The Enigma Protector 2.20 正版 【编写语言】: VC 【使用工具】: OllyDBG 【操作平台】: Windows XP sp3 【软件介绍】: 1+1=2 【作者声明】: 文笔菜的很谅解,只是感兴趣,没有其他目的。失误之处敬诸位大侠赐教! -------------------------------------------------------------------------------- 【详细过程】 参考了 http://unpack.cn/thread-59541-1-2.html 定位方式,迅速定位到了 Enigma 注册授权位置: 010F2CBF E8 CC76F3FF call calc_em.0102A390 010F2CC4 8B45 E8 mov eax,dword ptr ss:[ebp-0x18] 010F2CC7 E8 FC78F3FF call calc_em.0102A5C8 010F2CCC 50 push eax 010F2CCD E8 DE90FFFF call calc_em.010EBDB0 ; Check Registration Key Info 010F2CD2 85C0 test eax,eax ; Eax =1 Success! 010F2CD4 0F95C0 setne al 这里010EBDB0 这个CALL负责检测注册码是否正确,正确返回1 否则返回0,由于 Enigma有多线程内联补丁保护因此不能 直接硬写此处代码,所以我们采用了硬件断点HOOK来实现。 1:定位PatchAddress: 先看此块内存信息: 地址=01026000 大小=002F4000 (3096576.) 属主=calc_em 01000000 区段= 类型=Imag 01001002 访问=R 初始访问=RWE 这块内存实际是Enigma的内置DLL授权模块,此块DLL是被加密压缩过,因此也无法直接patch,通过对比加不同的程序 发现这块区域解压后的代码都不变: $+CCCBF > E8 CC76F3FF call calc_em.0102A390 $+CCCC4 > 8B45 E8 mov eax,dword ptr ss:[ebp-0x18] $+CCCC7 > E8 FC78F3FF call calc_em.0102A5C8 $+CCCCC > 50 push eax $+CCCCD > E8 DE90FFFF call calc_em.010EBDB0 ; Check Registration Key Info $+CCCD2 > 85C0 test eax,eax ; Eax =1 Success! $+CCCD4 > 0F95C0 setne al 因此PatchAddress = BaseAddress+PatchOffsetAddress,通过上面分析得到 Enigma Protector 2.20 的 PatchOffsetAddress = 0xCCCD2 ,不同版本的PatchOffsetAddress 有可能不一样,BaseAddress 的获取就更简单了, 直接搜索区段判断VirtualSize为0x002F4000的VirtualAddress+GetModuleHandle(0)即为BaseAddress,整理公式: PatchAddress = GetModuleHandle(0)+VirtualAddress+0xCCCD2 定完毕。 2.硬件Hook: 这里我们采用AddVectoredExceptionHandler向量化异常API来实现,具体细节自己google,重点讲下Hook触发后的过程 由于我们Patch点为$+CCCD2 > 85C0 test eax,eax ,因此只需要模拟操作EFlags然后跳过此段指令即可: pException^.ContextRecord^.EFlags := $202; //TEST eax,eax pException^.ContextRecord^.Eax := 1; //TEST eax,eax PException^.ContextRecord^.Eip := PException^.ContextRecord^.Eip + 2; //Nex 3.整体封装: 这里我们采用是把硬件HOOK和处理的过程都封装成DLL 然后导出一个GoPatch的函数供目标程序调用,那么如何使目标程序 加载并执行我们的GoPatch函数呢,我想办法很多注入,远线程等等。。这里我采用了劫持EIP的方式使目标程序加载我们的 DLL并执行GoPatch函数。 到这里已经全部完成,执行GoPatch后任意输入或者不输入用户名、注册码都可以直接绕过Enigma 的注册保护直接执行。
包含了1-3093的rfc中文翻译。 组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者: 李超(licc_li licc_li@sina.com) 译文发布时间:2001-5-23 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须 保留本文档的翻译及版权信息。 Network Working Group S. Casner Request for Comments: 2508 Cisco Systems Category: Standards Track V. Jacobson Cisco Systems February 1999 低速串行链路下IP/UDP/RTP数据包头的压缩 (RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links) 本备忘录的状态 本文档讲述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建议以 得到改进。参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度 和状态。本备忘录的发布不受任何限制。 版权声明 Copyright (C) The Internet Society (1999). All Rights Reserved. 摘要 本文描述了一种对IP/UDP/RTP数据报头进行压缩的方法,它可以降低在低速串行链路上 的网络开销。多数情况下,三个头可压缩到2-4字节。 赐教并将您的建议发送到工作组邮件列表rem-conf@es.net或直接给作者。 本文中的关键字“必须”,“必须不”,“要求的”,“应该”,“不应该”,“会”,“不会”, “建议”,“或许”,“可选的”在 RFC 2119 中解释。 目录 本备忘录的状态 1 版权声明 1 摘要 1 1. 介绍 2 2. 设想和折中 2 2.1. 单工与全双工 3 2.2. 分片与分层 3 3.压缩算法 3 3.1.基本概念 3 3.2 RTP数据包头压缩 4 3.3协议 5 3.4. RTCP控制包压缩 12 3.5.非RTP UDP包压缩 13 4.与分片的交互 13 5.压缩协商 13 6.致谢 14 7.参考文献 14 8. 安全性考虑 14 9.作者地址 15 10.版权声明 15 1. 介绍 随着实时传输协议(RTP)成为正式的RFC[1]发行,人们对于利用RTP实现不同的网络音视 频应用程序间互操作的兴趣也日益增长。然而,我们也注意到,当使用低速链路如14.4Kb/s 或28.8Kb/s拨号时,12字节的RTP头对于仅有20字节的负载而言开销实在太大。(为了减少 头占用的字节,一些已经在类似环境下存在的应用通常使用自定义的协议,而这样做的代价 就是削减了RTP相关的功能。) 事实上,正如在TCP中已经取得巨大成功,也可通过压缩技术来令IP/UDP/RTP包头变小。 这时,压缩可以针对于RTP头(在端到端应用中),或者IP,UDP,RTP的组合头(在Link-by-Link 应用中)。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果,因为两 种情况下的结果大小均为约2-4字节。同时,由于延迟和丢失率都很低,对Link-by-Link应 用进行压缩性能上也更好。因此我们在这里定义的方法就是针对Link-by-link应用下 IP/UDP/RTP头进行组合压缩。 本文定义的压缩方案可应用于IPv4包、IPv6包或封装了多个IP头的包。为了能同时在IPv6 和IPv4下使用,这里定义的IP/UDP/RTP压缩符合[3]中规定的通用压缩框架。该框架把TCP 和非TCP定义为IP之上的两个传输类。本规范将IP/UDP/TCP从非TCP类中抽取出来创建为第三 类。 2. 设想和折中 本压缩方案的目标是,在不发送UDP校验和的情况下,将大多数包的IP/UDP/RTP头压缩到 2个字节,在带校验和时则压缩到4个字节。这一方案的提出主要是受使用14.4kb/s和 28.8kb/s拨号调制解调器发送音视频时遇到的相关问题所引起。这些链路提供全双工通信, 所以协议利用了这点,尽管协议在用于单工链路时可能性能会有所下降。该方案在本地链路 上往返时间(RTT)很低,从而实现性能最高。 为了降低低速链路下的延迟,除了在第四节中确定了分片和压缩中可能使用的一些交互 外,本规范并未提出大型数据包的分片和占先策略。分片方案可能会单独定义并与本压缩方 案配合使用。 应该注意到,实现的简单性是评价压缩方案的一个重要因素。通信服务器可能要用一个 处理器支持多达100个拨号调制解调器的数据压缩。因此,如下的考虑都是比较恰当的,即 在设计阶段为了实现简单而牺牲一些通用性,或者在设计上灵活通用但为了简单性可对设计 进行子集化。通过在压缩和解压器之间用更复杂的模型通信改变头字段还可以达成更好的压 缩效果,但其复杂性却是没必要的。下一节将讨论这里列出的一些折中方案。 2.1. 单工与全双工 在没有其它限制的情况下,单工链路上的压缩方案应成为首选。但为防止错误发生,单 工链路上的操作需要用一个含有压缩状态信息的未压缩包头进行周期性的刷新。如果明显的 错误信号可以返回,则恢复延迟也可以实质性地缩短,无错误情况的开销也会降低。为了实 现这些性能的优化,本规范包括了一个可逆向发送的明显错误指示。 在单工链路中,可以使用周期性刷新来取代。解压器一旦侦测到错误存在于某个特定的 流中,它可以简单地放弃该流中所有的包直到接收到一个未压缩的头为止,然后继续解压。 其致命弱点在于可能要在恢复解压前要放弃大量的包。周期性刷新的方法在[3]的3.3节中进 行描述,它应用于单工链路的IP/UDP/RTP压缩,或者应用于其它非TCP包流的高延迟链路。 2.2. 分片与分层 在低速链路上发送大型数据包所需时间而导致的延迟对于单向音频应用不算什么大问 题,因为接收方可以适应延迟变动。但对于交互式的交谈,最小端到端延迟是非常关键的。 对大的,非实时数据包进行分片以允许小的实时包在分片间隙进行传送可以降低这种延迟。 本规范只处理压缩,并且假定,如果包括分片,也将被处理为一个单独层。将分片和压 缩按这种方式进行集成并不可取,因为一旦如此,在没有必要或不可能进行分片的情况下, 连压缩都不能使用。类似地,应该避免预留协议的任何需求。除了要求链路层提供一些包类 型码,一个包长度指示和良好的错误检测外,该压缩方案可独立于任何其它机制而应用在本 地链路的两端。 相反,单独对IP/UDP和RTP层进行压缩丢失了太多的压缩效率,这些效率可以通过将它们 一起对待而得到。由于相同的函数可以应用于所有层,实现跨越这些协议层边界的方案是恰 当的。 3.压缩算法 本文定义的压缩算法主要利用了RFC 1144[2]描述的TCP/IP头压缩的设计。读者可以参考 该RFC获取更多的关于对包头进行压缩的基本动机和通用原理。

17,089

社区成员

发帖
与我相关
我的任务
社区描述
Oracle开发相关技术讨论
社区管理员
  • 开发
  • Lucifer三思而后行
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧